Bug 129120 - kernel 2.6.7-1.503 on x86_64 fails to find root device by label
Summary: kernel 2.6.7-1.503 on x86_64 fails to find root device by label
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact:
Depends On:
Blocks: FC3Target FC4Target
TreeView+ depends on / blocked
Reported: 2004-08-04 06:47 UTC by Michal Jaegermann
Modified: 2015-01-04 22:08 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-11-28 08:30:35 UTC

Attachments (Terms of Use)

Description Michal Jaegermann 2004-08-04 06:47:58 UTC
Description of problem:

After an update to 2.6.7-1.503 an attempt to boot ended
up with the following:
Creating block device
Creating root device
mkrootdev: label not found
Mounting root file system
mount: error 2 mounting ext3
Switching to new root
Switchroot: mount failed: 22
Kernelpanic: Attempted to kill init

Replacing initrd with one created by mkinitrd from FC2
(a compressed file system instead of a compressed cpio archive)
resulted in somewhat different messages but the key one,
i.e. "mkrootdev: label not found", was there and end results

Booting 2.6.7-1.501 on the same hardware and with with similar
options is not a problem.  I also booted 2.6.7-1.503 with
a root device specified by label on Athlon machine.  But only
after I replaced "root=LABEL=/1" by an explicit "root=/dev/sda11"
the whole thing started here without further complications.

Comment 1 Michal Jaegermann 2004-08-06 19:42:10 UTC
An update to 2.6.7-1.509 on x86_64 does not change anything in
the picture.

Comment 2 Bill Nottingham 2004-08-10 20:37:00 UTC
Does mkinitrd-4.0.1 help?

Comment 3 Michal Jaegermann 2004-08-10 21:56:14 UTC
> Does mkinitrd-4.0.1 help?
You meant mkinitrd-4.0.2-1, I hope, as this is the current version
AFAICT.  I am afraid that not.  To be sure I recreated initrd
for 2.6.7-1.509 kernel and ended with the same problem.

A stupid question.  In a search of a root partition is something
is printing something with a witdth of field given as a difference
of two pointers?  Because if you subtract from NULL then on x86_64
you will likely overflow and you will not print anything and chances
are that you will get away with that on x86.  Or something similar...

BTW, the label to be found happens to be "/1".

Comment 4 Erich Hoover 2004-08-11 02:11:27 UTC
I'm also having the problem, I can't use 503 or 509.  Do you mean we
should try with the older mkinitrd-4.0.1?

FC3T1 x86-44
Western Digital SATA drive WD740GD
lspci reported RAID bus controller: Promise Technology, Inc. PDC20378
(FastTrak 378/SATA 378) (rev 02)

Boot Options:
kernel /vmlinuz-2.6.7-1.509 ro root=LABEL=/1 rhgb quiet
(same for 501, 503, & 509 - only 501 works)

Comment 5 Michal Jaegermann 2004-08-11 18:39:21 UTC
I see still the same behaviour with mkinitrd-4.0.3-1 and
2.6.7-1.515 kernel.

Comment 6 David V Herman 2004-08-11 20:26:03 UTC
Kernel 509 also does not boot for me.  messages are

. . .
Red Hat nash version 4.0.0 starting
mkrootdev: label   not found
mount: error 2 mounting ext3
switchroot: mount failed : 22
kernel panic: attempted to kill init!

System required reset to restart, previous versions (503 and earlier)
of the kernel boot and function.

System configuration
Athlon 64 2800+
512 M
SATA (system drive)
MSI-K8TM (Motherboard)
IDE ( 20MB & DVD-RW - both master on each channel)

Testing x86_64

-- David V Herman <dvherman@bigfoot.com> 

Comment 7 Phil Dybvig 2004-08-11 22:19:04 UTC
This is probably related to I problem I have (and others probably have
but don't realize) with my swap partition.  When I upgraded to kernel
2.6.7-1.494.2.2, my SATA drives /dev/hde and /dev/hdf were renamed
/dev/sda and /dev/sdb.  This was not a problem for the partitions
using LABEL= in /etc/fstab, but the swap had the actual mountpoint
/dev/hde2 in /etc/fstab and failed to mount.  My fix was to change
/dev/hde2 to /dev/sda2 in /etc/fstab and then mount using swapon -a
(or reboot).  I figured out the new drive names from /etc/mtab and
remembering how I set up the partitions that did mount.

Comment 8 Erich Hoover 2004-08-11 22:52:38 UTC
> When I upgraded to kernel 2.6.7-1.494.2.2, my SATA drives /dev/hde
and /dev/hdf were renamed /dev/sda and /dev/dsb.

My SATA drive has always been /dev/sda since I installed FC3T1 fresh.
 I think this is somehow a problem with how initrd is detecting labels
on SATA drives so it doesn't understand the label /1 the way it used to.

Comment 9 Michal Jaegermann 2004-08-11 22:59:57 UTC
> This is probably related to I problem I have with my swap partition.
I do not think so.  That transition happened quite a while ago
(and I do have a SATA drive on an affected machine).  I did carry
for a while in my /etc/fstab
/dev/sda5  swap ...
/dev/hde5  swap ...
lines and one or another was erroring depending on which kernel
I was booting. :-)

OTOH you may be to something.  All affected machines seem to
be using SATA drives.  My other box which is fine does not have

Comment 10 Phil Dybvig 2004-08-11 23:08:02 UTC
>> This is probably related to I problem I have with my swap partition.
>I do not think so.
yes, you are right; this is a problem starting with kernel
2.6.7-1.494.2.2, not *.50x.*.  Also, my LABEL= partitions are fine. I
do bet there are a lot of people who have impaired performance because
they did not notice that their swap partition was not mounted.

Just as a hunch, "/1" seems like a weird label.  I wonder if the
problem would go away if it were changed to "root" or "root1".

Comment 11 Michal Jaegermann 2004-08-11 23:26:17 UTC
> "/1" seems like a weird label
What so weird about this label?  It is no more weird than widely
used default "/". I am using labels of that kind for years and
I have pretty good reasons for doing so.

Comment 12 Michal Jaegermann 2004-08-13 18:02:15 UTC
With mkinitrd-4.0.5-1 a boot sequence, or more precisely nash,
seems to be finding labels on my SATA drive just fine.  Remaking
initrd images for older kernels makes them to recognize a root
file system specified by a label too. So apparently this was filed
against wrong component.

Comment 13 Erich Hoover 2004-08-15 18:38:49 UTC
Same here, problem goes away (though finding the label takes much
longer than it used to) using mkinitrd-4.0.5-1 to re-create the image:
/sbin/mkinitrd /boot/initrd-2.6.7-1.517.img 2.6.7-1.517

Comment 14 Dave Jones 2004-11-27 22:32:03 UTC
mass update for old bugs:

Is this still a problem in the 2.6.9 based kernel update ?

Comment 15 Michal Jaegermann 2004-11-28 01:33:18 UTC
I believe now that the problem was really with mkinitrd and not
with kernels.  This looks like solved.

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