Bug 130288 - FC2 Kernel update moves some SATA drives from /dev/hda to /dev/sda without updating /etc/fstab file; causes hangs on boot (and/or failure to mount swap).
Summary: FC2 Kernel update moves some SATA drives from /dev/hda to /dev/sda without up...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
URL: http://www.redhat.com/archives/fedora...
: 129806 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-18 20:42 UTC by Japheth Cleaver
Modified: 2015-01-04 22:09 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-24 06:43:06 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Japheth Cleaver 2004-08-18 20:42:57 UTC
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.
3. Reboot.

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:

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.

Comment 1 Manuel Ulloa 2004-08-25 02:45:07 UTC
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.

Comment 2 Dave Jones 2005-02-24 06:43:06 UTC
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.

Comment 3 Dave Jones 2005-02-24 06:44:44 UTC
*** Bug 129806 has been marked as a duplicate of this bug. ***

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