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 problem. 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. 3. Reboot. Alternate: 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. Actual results: 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. Expected results: 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 without warning. Additional info: (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: http://www.redhat.com/archives/fedora-list/2004-August/msg01773.html and http://www.redhat.com/archives/fedora-list/2004-August/msg01185.html and http://www.redhat.com/archives/fedora-list/2004-August/msg01091.html 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 s/hdX/sdX/ on.
*** Bug 129806 has been marked as a duplicate of this bug. ***