Description of problem:
At some point in 2.6.7 development, many SATA chipsets (or at least
two) began to be recognized as /dev/sdX instead of /dev/hdX.
Unfortunately, anyone whose drives are specified in /etc/fstab using
the /dev/hdX will be unable to boot until they're updated.
Specifically, the swap partition will always be unmountable using the
old style, and any other partitions that are not using labels will
fail as well.
For example, we have a kickstart-based system which performs a fresh
install of FC2, performs a yum -y update, and then reboots. There is
no easy way to do this because the FC2 CDs recognize drives
as /dev/hdX and install the fstab file appropriately. however on
reboot the updated kernel is looking for /dev/sdX. Anyone who yum
updates immediately after a fresh installation (most people?) and is
booting off a SATA drive on an affected chipset will have this
Version-Release number of selected component (if applicable): 2.6.7(?)
How reproducible: Every time.
Steps to Reproduce:
1. Perform a clean default installation of FC2 onto a machine with
one or two SATA drives (only) as your boot volume.
2. After the install is finished, run a full yum -y update to update
to the latest kernel.
1 Create a kickstart file that specifes a partition as
type "reiserfs". This partition will not be assigned a label equal to
its mount point (even though reiserfstune supports labels) and will
be entered into /etc/fstab as /dev/hdX. Continue with #2 and #3,
except now you will be unable to boot as a result of the upgrade.
The swap partition will always fail to mount, because it is specified
using /dev/hdX. If you have any other partitions that are not
specified using labels (eg, you're using ReiserFS), you will be
dropped into a root shell due to errors and be unable to boot.
The system should always be able to boot! A point kernel upgrade
should not cause a major system distruption that requires
manual /etc/fstab tweaking, especially when many people auto-update.
The kernel package should be aware of the changes it is making and
update ancillary files (like /etc/fstab) as needed.
Furthermore, there should be a policy on future device changes like
this to prevent similar things happening in the future to people
(See also bug #127961)
This is running on a Biostar M7VIZ (v5.1) motherboard with a VIA
KM400 and VT8237 chipset (our standard platform). Based on other
information around the internet, this affects other SATA chipsets
that were previously identified as /dev/hdX before, too. Again, the
bug is not the change, but the change causing an unbootable system
with no warning.
See discussion here:
One thing that would help would be to ensure that filesystem LABELS
are created on all filesystems that support them, including ReiserFS.
This should be a separate (anaconda) bug.
Yes, this one IS goofy. The last "official" FC2 kernel where it
worked was 2.6.6-1.435.2.3. From then on they all do expect it
the other way. Why change? Why cause this kind of grief without
reason? Hours spent, and not even chasing a real bug.
yes, this interface change was extremely nasty, but somewhat unavoidable given
this changed upstream. :-/
in-place editing of files like /etc/fstab from within the kernel rpm isnt
necessarily a good idea sadly, as users could have all sorts of things in there
which makes getting it right pretty much impossible. For eg, on a mixed
PATA/SATA system, the editing process would have no idea which drive to do a
*** Bug 129806 has been marked as a duplicate of this bug. ***