Red Hat Bugzilla – Bug 212270
Bind mounts listed in /etc/fstab confuse anaconda and cause upgrades to fail
Last modified: 2007-11-30 17:11:46 EST
+++ This bug was initially created as a clone of Bug #185835 because I can't
reopen closed bugs. +++
If there are any bind mounts listed in /etc/fstab,
Anaconda gives an error message and fails to mount the filesystem (with an
option to continue with the install or reboot).
In my case this is a harmless error, but people who bind mount critical parts of
the system (i.e. something in /usr, /var, etc.) will probably not be able to
upgrade because of this.
I've done an FC5->FC6 upgrade on a machine with a bind mount defined in /etc/fstab:
/home/mock /var/lib/mock auto bind 0 0
I've also upgraded a machine with loop mounts:
ro,loop,fscontext=system_u:object_r:public_content_t 0 0
iso9660 ro,loop,fscontext=system_u:object_r:public_content_t 0 0
The installer didn't appear to have any issues with either of these, though I
didn't check to see that these mounts were actually done correctly during the
install (i.e. under /mnt/sysimage) and it's possible that they were simply
ignored and I wouldn't know any better. However, theyt didn't cause a failure or
any other error symptoms. I have a couple of machines still to do, so I can try
looking in more detail on those.
Can you provide the fstab you're using?
/dev/System/Root / ext3 user_xattr,acl,defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
/dev/Storage/Media /mnt/storage ext3 user_xattr,acl,defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
/dev/System/Swap swap swap defaults 0 0
/mnt/storage/nicholas/media /home/nicholas/media auto bind 0 0
/mnt/storage/nicholas/stuff /home/nicholas/stuff auto bind 0 0
/dev/hdc /media/cdrom auto ro,noauto,pamconsole,defaults 0 0
/dev/hdd /media/cdrecorder auto ro,noauto,pamconsole,defaults 0 0
Just to make sure I understand what's going on here, can you please attach the
error message and a copy of /tmp/anaconda.log from an attempted upgrade? I know
there's plenty of stuff attached to the previous bug, but I'd like to see what
FC6 has to say just to make sure I'm looking at the latest. Thanks.
Created attachment 140316 [details]
At this point in time, mount reports:
/proc on /proc type proc (rw)
/dev on /dev type tmpfs (rw)
/dev/pts on /dev/pts type devpts (rw)
/sys on /sys type sysfs (rw)
none on /tmp type ramfs (rw)
none on /tmp/ramfs type ramfs (rw)
/proc/bus/usb on /proc/bus/usb type usbfs (rw)
/tmp/cdrom on /mnt/source type iso9660 (ro)
/tmp/loop0 on /mnt/runtime type squashfs (ro)
/selinux on /selinux type selinuxfs (rw)
/dev/System/Root on /mnt/sysimage type ext3 (rw,data=ordered)
/dev/hda1 on /mnt/sysimage/boot type ext3 (rw,data=ordered)
which is consistent with anaconda.log indicating that it skips straight from
mounting System/Root to attempting the bind mounts without ever mounting
Apparently "Bug currently in NEEDINFO. Adding comment will automatically toggle
status to ASSIGNED." is still a dirty lie.
Trying again with a regular comment instead of an attachment to see what happens.
Whoops, forgot the actual error message. It is:
"An error occurred mounting device /mnt/storage/nicholas/media as /home/nicholas
media. You may continue installation, but there may be problems. [Continue]
Do you still have this system available for testing? I would like to point you
at an updates image you can use during installation to see if it clears up this
problem. I'll probably put that together sometime within the next day or two.
Yes, it can be tested.
I've made an updates image available at:
You can either download this and put it on a USB key or floppy and add the
"updates" command to your boot options, or just boot with "updates=http://..."
depending on your network setup.
Basically, I've just reworked how mounts get ordered so these bind mounts get
mounted after whatever they're under. Let me know how this works for you.
This works. (No error messages, and inspections of the actual mount points shows
that it did the right thing.)
Hopefully these bind mount changes also apply to moved mounts and any of the
other exotic things you can do with mount these days.
I don't think we have the objects in anaconda to support too exotic filesystem
types or the options in our mount code to handle those unusual things. However
I'm glad this case is fixed. Hope we don't have any more bind mount problems.