Red Hat Bugzilla – Bug 208093
Try to be more intelligent in handling of noauto filesystems which should be auto mounted
Last modified: 2007-11-30 17:11:44 EST
Description of problem:
I usually setup a different partition for /boot (a very common practice).
When Anaconda mounts the previous FC in /sysimage, it only mounts the root and
home partitions, neglecting to mount (and use) the previous /boot partition.
The information itself is available under /etc/fstab (+partition label).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install FCx with /boot under a different partition.
2. Upgrade to FCx+1.
Anaconda does not detect and mount the old /boot partition, installing the
kernel in the old root partition.
Anaconda should scan the /etc/fstab, detect the /boot configuration and mount it.
Same problem exists if /boot uses an software RAID1 array.
/boot should be mounted as long as it's in /etc/fstab and findable. Can you
Sadly enough the FC5 imaged died due to a botched upgrade attempt. :(
*** Bug 208193 has been marked as a duplicate of this bug. ***
Hrmm... without that (or /tmp/anaconda.log from the install), it's hard to
figure out exactly what happened here. I've definitely done an upgrade and
/boot got properly mounted :/
Created attachment 137259 [details]
I've recreated the FC5 vmware image and started over.
As before, anaconda failed to mount the boot partition.
What did /etc/fstab look like -- there's no indication in the log at all that it
ever saw /boot there :/
LABEL=/boot /boot ext3 noauto,defaults 1 2
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
/dev/VolRoot/LogHome /home ext3 defaults 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
/dev/VolRoot/LogSwap swap swap defaults 0 0
/dev/hdc /media/cdrom auto noauto,defaults,users
/dev/VolRoot/LogRoot / ext3 defaults 1 2
Aha -- it's because it's marked as noauto, so we don't try to mount it as the
fstab says "don't mount this by default". anaconda listens to that (otherwise,
we end up getting hosed by things like your cdrom entry)
... This leaves a very wierd problem.
Not mounting boot by default is a -good- thing. I'd recommend adding support for
hidden root to Anaconda and yum... but that's a different sory.
A. OK, boot wasn't mounted. Why did Anaconda crash?
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208193) It should have
created a brand new grub configuration instead of the missing one. (Wild guess:
Anaconda saw the grub.conf symbolic link [which points to nothing, as boot was
never mounted] tried to parse it and died.)
B. Shouldn't it be prudent to add special case support for /boot as unmounted
/boot is not uncommon in production machines.
Anaconda should have detected the missing /boot and ask the user for directions.
Test4 didn't automount /boot, which is OK (It disabled the "grub update" option
until I manually mounted the /boot partition. (it'll be nicer if Anaconda didn't
just disable the update option).
Installation worked just fine, no exceptions.
However, when I tried to reboot the machine, I got the dreaded "GRUB GRUB GRUB
I had to rebooted the test4 ISO in rescue mode and fix the grub configuration
(grub; root (hd0,0); setup (hd0); quit) in-order to get the grub working again.
Created attachment 137626 [details]
Changing the summary to reflect reality a little bit more.
Although, realistically, I'm not sure how much we can reasonably do without
making the upgrade UI impossible for ordinary users.
Repost of my -testing message:
It seems to me that there's a bigger problem at stake here.
Currently the user is unable to detect (and correct) FS/hardware/etc problems
during the mount phase, such as failed mounts (due to FS errors), failed
software RAID arrays (due to missing/failed drives), etc - all of this might
generate botched upgrades or unexplained Anaconda exceptions.
In-order to solve the bigger problem, I suggest that:
A. Once Anaconda is done scanning the fstab, it should display the list of
detected devices and partitions. This options is a must - especially when
upgrading a machine with LVM and/or MD array(s).
B. Either (1) enable the "Back" button, giving the user an option to restart the
fstab detection phase or (2) add a UI button "Terminal", giving the user an
option to load missing drivers/fix the fstab/fix a bad software RAID array/etc.
C. Once the user selects "Back" (B1) or exists the terminal (B2), goto step A.
Of the top of my head, A -> B1 -> C -> A sounds like a rather simple solution to
implement (that requires 0 UI changes) - but I don't know Python and/or Anaconda
well enough to verify this bold assessment.
requested by Jams Antill
This is a CANTFIX bug. Anaconda has to obey fstab on systems it's upgrading.
If you change your /boot partition to be noauto, we obey that. Breaking the
rules in anaconda opens the door to future problems, i.e., there is always a
The suggestions in comment #13 are ok for an advanced user, but severely
complicate the UI for ordinary users.