Hey guys and welcome back. So in the previous nugget we discussed how we could manually
mount our fail systems but we did notice that we did not have any type of persistence. A
simple reboot would simply just unmount the fail systems we mounted with the mount command.
You might have noticed that despite the reboot some of the file systems did persist. Say for
example we do an LS BLK-F we can see this one here is still mounted as well as this one right
here. So what is going on? Why are these ones mounting and the other ones are not? What it comes
down to is a very very important file and you really want to be remembering this file. It is the
in fact let me just type cat the etsy fs tab file really really really remember this file.
So if I open this up in fact let me go in via nano instead so we can get the color highlighting.
Okay right so let me tell you what's going to happen when the system boots up the mount command
is going to be issued but it's going to be issued with a very particular flag it's going to be issued
with the dash a flag so mount dash a. Now what this is going to do it's going to mount all of the
file systems that have been defined to mount within this particular file right here. So what we can
actually see here are a bunch of different columns now I will admit the way the columns have been
formatted is really quite ugly it is quite difficult to actually follow which column is which
but let me walk you through it quite briefly. Now the very first column is going to be the
file system uuid okay so this is the uuid for my sda5 the reason why I know that is because I can
see the very next column which is the mount point and by the way if you want to be able to correlate
what I'm looking at first column is file system next column is mount point so I happen to know
the mount point here is root which correlates to my sda5 the next column is the type and like I say
the formatting here not so good the type is going to be this one here ext4 that is the file system
type and then we see the mount options we briefly mentioned what this was all about so we can see
here what's going to happen is on error we will attempt to remount using read only now we do have
these other options here dump and pass I'm not really going to dive into the details of what
those are right now and below we can see the file system here identified with the uuid again this
is mounted at boot efi that's going to be my sda1 partition we can see the file system is vfats
we can see the mount options and we can see for dump it's got the value zero and pass it's got the
value one okay so check this out what this means then is that if I want to mount my file system in
such a way that it will be auto mounted upon a boot up then I don't just want to use the mount
command I actually want to put that information within xafstab that means when the system boots
up and runs that mount dash a command if my information is within this file then it will
be mounted now the first thing to notice here is that this is unrightable that is because I didn't
use my super user privileges so I'll just exit back out here further now and I'll say sudo nano
xafstab type in my passwords okay so what I will do here is I can specify the uuid or I can just give
the device type so that means I can just specify if I so choose dev sdb1 which is my device type
and then I can specify the mount points my mount points here is going to be home ipv0 and the backups
directory and then the file type I'll say is ext4 with respect to the mount options I'll just specify
the defaults and then I'll give the value zero and zero for my dump in my pass if I happen to
write this save you and I exit out I do my lsblk-f notice right now that the system or rather the
file system should I say is still not booted that is because we need to run the mount dash a command
or we could alternatively reboot the system which will automatically invoke that command being run
so I'll say sudo mounts dash a if I rerun my command notice now we have actually mounted sdb1
and we've mounted it within home ipv0 backups and again if I reboot my system in fact do my sudo
command sudo reboot what's going to happen is my system will reboot and it's rebooting as we can see
okay dog so my system has booted backup I do an lsblk-f and notice the sdb1 device that is
mounted now the mounting is now persistent that is because like I say the information has been
updated and included within the xcfs tab file so very very important to understand that difference
now one thing I do want to mention before we end this nugget is that we can also use system d with
respect to mounting and unmounting our file systems so like I say we have our lsblk-f command we can see
we have this device mounted if I wanted to use system ctl to check this what I could do is I could
say sudo system ctl and I can specify the status and then I could go into home ipv0 and backups
basically just checking the mount point I'll have to type in my super user password and notice it says
that this is active and mounted we can also see what it is i.e the device and if we wanted to
unmount that what we could do is we could change the option from status to stop and if I try status
once again notice it is no longer mounted it is inactive and dead that means if you run lsblk
we can see it is no longer mounted but check this out if I just say start and give it the same mount
points and hit enter notice it has mounted but check this out how did it know which device to
actually mount I just gave it a mount point how did it know to actually mount sdb1 but what happens
is that if we go into cd and run and then system d and we want to be remembering this location here
by the way and then into generator within here we actually have a whole bunch of files see these
dot mount files these are the unit files which contain such information so if I try to mount
into home ipv0 backups system d is going to look for this mount file if it has already been created
which it has so if I go into here and I open it notice the information is right here it says
whereabouts we should mount it what we should mount i.e the device and the file type you see that
similarly if we look at the other mount points we can see we have our bootefi dot mount i can say
so I can say nano bootefi dot mount we can see here that is going to be type vfats and in this case
here it's just been identified by the uuid as opposed to sda1 so really what we want to be
remembering within this nugget right here is that if we want to have persistence we really really
really want to be remembering the name of that file say fs tab as well as knowing that we can use
system ctl to mount particular file systems as well as check their status and unmount them and like
I say the way system d can do this is by tracking this information within the run system d generator
directory and look for those dot mount files okay docs I hope this has been informative for you
and I'd like to thank you for viewing