Red Hat Bugzilla – Bug 236476
Upgrade FC6->F7test3 aborts because fstab entries don't match newer kernel
Last modified: 2007-11-30 17:12:02 EST
I attempted to upgrade a FC6 box to F7test3. After selecting the pre-existing
installation to upgrade, anaconda aborts and reboots because it couldn't mount 2
pre-existing mount points in the pre-existing /etc/fstab.
The reason is because my FC6 box contains references to specific /dev/* entries
and F7test3 kernel maps IDE drives differently then FC6. I worked around and
completed the upgrade by manually modifying the /etc/fstab running FC6 and then
immediately rebooting into F7test3 installer.
I have a computer that came with 1 SATA drive and to which I added a spare PATA
drive to back files up to onto the same cable as my DVD drive. I'm guessing
this is an common setup as people are transitioning to SATA drives and have old
PATA drives lying around.
Under FC6 kernels, this arrangement causes the SATA drive to be labeled as
/dev/sda and the PATA to be labeled as /dev/hdb. The PATA drive shows up as
/dev/hdb because of the DVD drive being first on the cable and the main reason
the PATA controller is still in the box.
Under F7test3, this arrangement causes the SATA drive to be labeled /dev/sdb and
the PATA drive to be labeled as /dev/sda .
Any hardcoded references to either /dev/sda or /dev/hdb in my old /etc/fstab
become invalid during the upgrade. Anaconda attempts to mount these two drives,
fails to do it and reboots.
I guess there are a few ways to handle this...
1) Modify the kernel so that PATA drives are always labeled after SATA drives
(if any found). When PATA&&SATA co-exist, this should result in old SATA
retaining the same names and only invalidate the /dev/hdxx entries in
/etc/fstab. This is a more useful solution for users upgrading kernels outside
an anaconda upgrade.
2) During the upgrade. anaconda could detect some common SATA and PATA combos
and update /etc/fstab or some other method so the drives get mounted correctly.
Upgrading /etc/fstab on the original partition to early has obvious
disadvantages because anaconda aborts before the upgrade for many reasons and if
/etc/fstab is updated super-early then the user will not be able to boot their
old system on failed upgrades.
My original /etc/fstab is listed below which comes from uprading since probably
Red Hat 4. This is actually the hand modified to show both old /dev/ names and
new /dev/ names that allowed me to upgrade.
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /proc proc defaults 0 0
none /dev/shm tmpfs defaults 0 0
#/dev/sda5 swap swap defaults 0 0
/dev/sdb5 swap swap defaults 0 0
#/dev/sda1 /c vfat defaults 0 0
#/dev/hdb1 /b1 ext3 defaults 1 2
/dev/sda1 /b1 ext3 defaults 1 2
*** This bug has been marked as a duplicate of 229704 ***