Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 236476 - Upgrade FC6->F7test3 aborts because fstab entries don't match newer kernel
Summary: Upgrade FC6->F7test3 aborts because fstab entries don't match newer kernel
Status: CLOSED DUPLICATE of bug 229704
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2007-04-14 21:26 UTC by Chris Bagwell
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-04-16 14:19:37 UTC

Attachments (Terms of Use)

Description Chris Bagwell 2007-04-14 21:26:37 UTC
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

Comment 1 Chris Lumens 2007-04-16 14:19:37 UTC

*** This bug has been marked as a duplicate of 229704 ***

Note You need to log in before you can comment on or make changes to this bug.