fstab

NYCJacob

when I modify fstab to mount a loop filesystem my system always fails to reboot properly and goes into emergency mode. I then remove the line and can reboot normally. In researching fstab everything I read says the last it for pass order should be 0 1 or 2 but in the materials 3 is used. Is 3 something special for loop filesystems? I do not find anything on using 3 in that field.

NYCJacob

I checked the journalctl file and it can't find the imagefile. I think it is getting deleted because it is in the tmp directory. Am I the only one who has experienced this?

gserlenga

This is how I test-mounted a read-only disc image permanently using the '/etc/fstab' file. I had trouble too getting it to mount on reboot, until I specified the correct filesystem , 'iso9660'. Using the 'file' command on a file will tell you the precise type it is.

Example:

$ file /media/hdd/downloads/posix/CentOS/CentOS-7-x86_64-LiveGNOME-1503.iso 
/media/hdd/downloads/posix/CentOS/CentOS-7-x86_64-LiveGNOME-1503.iso: DOS/MBR boot sector ISO 9660 CD-ROM filesystem data 'CentOS-7-live-GNOME-x86_64' (bootable); partition 2 : ID=0xef, start-CHS (0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 172, 10324 sectors

I had success mounting a loop device in the '/etc/fstab' file using this entry line:

# test example of mounting a loop device at boot
/media/hdd/downloads/posix/CentOS/CentOS-7-x86_64-LiveGNOME-1503.iso	/mnt/test	iso9660 loop,auto	0	0

Reboot and verify:

$ mount | grep CentOS
/media/hdd/downloads/posix/CentOS/CentOS-7-x86_64-LiveGNOME-1503.iso on /mnt/test type iso9660 (ro,relatime)
$ sudo blkid | grep loop
/dev/loop0: UUID="2015-03-31-10-40-42-00" LABEL="CentOS-7-live-GNOME-x86_64" TYPE="iso9660" PTUUID="5bdad414" PTTYPE="dos"

I didn't need to specify 'ro' for this mount because the .iso image was created as 'ro'.

Make sure you use the correct space or tab delimiters between fields in your '/etc/fstab' file as well.

In the example I gave, the '/media/hdd' directory is actually the mountpoint for a 2nd hard drive on which the .iso image I am mounting as a loop device is located. So it was important its mount line in '/etc/fstab' precedes the loop device mount line. The man page on 'fstab' mentions this.

luisviveropena

NYCJacob wrote:

when I modify fstab to mount a loop filesystem my system always fails to reboot properly and goes into emergency mode. I then remove the line and can reboot normally. In researching fstab everything I read says the last it for pass order should be 0 1 or 2 but in the materials 3 is used. Is 3 something special for loop filesystems? I do not find anything on using 3 in that field.

Hi NYCJacob,

1) Please specify the Lab# you are working on.
2) What's the line you are adding to /etc/fstab?
3) What's the specific error you are getting on the boot?

Thanks,
Luis.

coop

1) if you are on an Ubuntu system, /tmp is erased on every boot. Some other distros will do that as well, others use "tmpwatch" and erase after 10 days (by default). So don't put anything in /tmp you want to keep for a long time, or even across a reboot if your distro does this.

2) The second number in the "dump" field in fstab is the "pass_no" for filesystem checks. You are right that most Linux documentation mentions only 0, 1, 2. However, 3 means do after 3, 4 means do after 3 etc. This is an old UNIX thing and I'm not 100 percent sure that Linux does this (FreeBSD definitely does so) but some authors seem to say yes.
It's a rather obscure point and the text should not just dump it in there on dump

Try using "0" which means don't check at all.

The order your filesystems get loaded in matters. If you are trying to load a
loop file you must load the filesystem it is on first for example. Thus the order
of entries in fstab matters as the system reads the file.

I don't know if this solves your problems, but try.

JasePow68

I know this is responding to an old thread, but if you modify your fstab, and there are significant errors, the system may fail to boot. Your errors can include changing the order of parameters in the fstab line, wrong UID #, or similar... Whenever altering the fstab, it's a good idea to make a backup file (i.e.: fstab.old) so that you can return it to its previously stable setting from within an emergency mode session...

coop

yes, true, backup any significant system file when messing with it, including /etc/fstab. It is equally important to understand how to deal with it when the boot fails. We don't really cover this until the end of the course unfortunately so students have to have the spirit of working through it.

In this case, when it fails, I usually do the following:

1) supply the root password as you are prompted for usually
2) mount -o remount,rw / #(so you can alter /etc/fstab)
3) edit /etc/fstab to fix the problem, or just comment out the change say
4) either just reboot, or type telinit 5 etc, something that tries to go forward, reboot is simpler (type reboot)

and hope for the best.