Bug 129120
| Summary: | kernel 2.6.7-1.503 on x86_64 fails to find root device by label | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
| Component: | kernel | Assignee: | Dave Jones <davej> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | ehoover, pfrields, wtogami |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-11-28 08:30:35 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 123268, 136451 | ||
|
Description
Michal Jaegermann
2004-08-04 06:47:58 UTC
An update to 2.6.7-1.509 on x86_64 does not change anything in the picture. Does mkinitrd-4.0.1 help? > 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".
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? Setup: FC3T1 x86-44 AMD FX-53 ASUS SK8N 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) I see still the same behaviour with mkinitrd-4.0.3-1 and 2.6.7-1.515 kernel. 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> 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. > 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.
> 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
SATA.
>> 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".
> "/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.
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. 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 mass update for old bugs: Is this still a problem in the 2.6.9 based kernel update ? I believe now that the problem was really with mkinitrd and not with kernels. This looks like solved. |