Bug 197701 - mkinitrd is not creating the appropriate root mount point resulting in a /dev/root kernel panic
mkinitrd is not creating the appropriate root mount point resulting in a /dev...
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: mkinitrd (Show other bugs)
5
i386 Linux
medium Severity urgent
: ---
: ---
Assigned To: Peter Jones
David Lawrence
bzcl34nup
:
: 197702 197703 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-05 12:35 EDT by Brian Wright
Modified: 2008-04-04 04:49 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-04 04:48:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Complete details on this issue including a work-around (5.38 KB, text/plain)
2006-07-05 12:35 EDT, Brian Wright
no flags Details
Implementation of the "root=%x" kernel parameter support. (1.53 KB, patch)
2006-07-07 12:00 EDT, Jan Kratochvil
no flags Details | Diff

  None (edit)
Description Brian Wright 2006-07-05 12:35:50 EDT
Created attachment 131946 [details]
Complete details on this issue including a work-around
Comment 1 Brian Wright 2006-07-05 12:35:50 EDT
Description of problem:
mkinitrd is not creating the appropriate root mount location, resulting in 
a /dev/root kernel panic

Version-Release number of selected component (if applicable):
Current release

How reproducible:
Install a kernel rpm or compile a custom kernel and then run mkinitrd for the 
given kernel.  The kernel rpm install does the mkinitrd automatically

Steps to Reproduce:
1. Compile the kernel and copy bzImage to /boot/vzlinux-2.6.17.3
2. mkinitrd initrd-2.6.xx.x 2.6.17.3
3. Reboot the system.  A Kernel panic is generated because /dev/root can't be 
mounted to /sysroot
  
Actual results:
init has "mount /sysroot"

Expected results:
init should have "mount -o defaults --ro -t ext3 /dev/hdc2 /sysroot"

Additional info: Please see the attached text file, it was posted to the fedora-
users list and gives more information on this issue.  I currently have to hand 
edit the init file to change "mount /sysroot" to "mount -o defaults --ro -t 
ext3 /dev/hdc2 /sysroot
Comment 2 Brian Wright 2006-07-05 18:22:11 EDT
Disregard bugs 197702 and 197703, those were sent by mistake and I apologize 
for that :)
Comment 3 Jan Kratochvil 2006-07-06 09:04:47 EDT
Please verify a different and more simple workaround:
Just drop any "root=/dev/hdXY" lines in your "/etc/lilo.conf" and replace them
by: append="root=/dev/hdXY" lines for each kernel, possibly as:
append="root=/dev/hdXY original_append_parameters"

This one does not work:
/etc/lilo.conf: root=/dev/hda5 \n append="nmi_watchdog=1 panic=10"
kernel log: Kernel command line: BOOT_IMAGE=t ro root=305
BOOT_FILE=/boot/vmlinuz-2.6.16.2.6.9-34.0.1.EL_lace0 nmi_watchdog=1 panic=10
root=/dev/hda5 console=ttyS0

as failing with:
Creating root device.
Mounting root filesystem.
mount: could not find filesystem '/dev/root'

But this one works:
/etc/lilo.conf: append="root=/dev/hda5 nmi_watchdog=1 panic=10"
kernel log: Kernel command line: BOOT_IMAGE=t2 ro
BOOT_FILE=/boot/vmlinuz-2.6.16.2.6.9-34.0.1.EL_lace0 nmi_watchdog=1 panic=10
root=/dev/hda5 console=ttyS0

Using Fedora Core 5:
lilo-21.4.4-26
mkinitrd-5.0.32-1

So just mkinitrd should be able to parse the kernel parameter type: root=305
Comment 4 Brian Wright 2006-07-07 08:23:23 EDT
I tried the workaround and the issue was resolved. :)  No errors or kernel panics.

I'm not sure if this problem would resurface if I were to migrate to grub
though, unless there's a workaround for that.

I think it would be a good idea to post an adivisory about this because there
are probably a lot of folks that are still using lilo on their Fedora boxes and
I've no doubts that they may have run into this problem as well.

Thanks! :)

--Brian
Comment 5 Jan Kratochvil 2006-07-07 12:00:22 EDT
Created attachment 132065 [details]
Implementation of the "root=%x" kernel parameter support.
Comment 6 Peter Jones 2006-07-13 11:16:35 EDT
*** Bug 197702 has been marked as a duplicate of this bug. ***
Comment 7 Peter Jones 2006-07-13 11:16:46 EDT
*** Bug 197703 has been marked as a duplicate of this bug. ***
Comment 8 Leon Flaks 2006-07-31 19:50:50 EDT
The workaround from comment #3 solved one of my problems, reported in bug #192272. 
Using lilo-21.4.4-26 and mkinitrd-5.0.39-1 on FC5.
Hopefully this fix will make its way into updates one day...
Thanks for a good job!
Comment 9 Leon Flaks 2006-07-31 20:08:16 EDT
The workaround from comment #3 solved one of my problems, reported in bug #192272. 
Using lilo-21.4.4-26 and mkinitrd-5.0.39-1 on FC5.
Hopefully this fix will make its way into updates one day...
Thanks for a good job!
Comment 10 Botond Kardos 2006-08-22 12:22:23 EDT
mkinitrd-5.1.9-1 still sucks. It fails if the kernel has a "root=LABEL=/"
parameter. It succeeds if I replace it to "root=/dev/mapper/nvidia..." (I'm
using dmraid).
Some more hint: when the kernel has the "root=/LABEL=/" parameter the mkrootdev
command fails to create the /dev/root node.
Comment 11 Hans de Goede 2006-08-31 10:51:23 EDT
(In reply to comment #10)
> mkinitrd-5.1.9-1 still sucks. It fails if the kernel has a "root=LABEL=/"
> parameter. It succeeds if I replace it to "root=/dev/mapper/nvidia..." (I'm
> using dmraid).
> Some more hint: when the kernel has the "root=/LABEL=/" parameter the mkrootdev
> command fails to create the /dev/root node.

Boton,

This sounds awefully similar to the problem a friend of mine was seeing which
I've managed to work around (and I'm working on a proper fix). See bug 203241

You could try to fix things like this:
-save the second attachment of bug 203241
-do "patch -p0 < mkinitrd.diff"
-regen your initrd: "mkinitrd -v -f /boot/initrd-`uname -r`.img `uname -r`
-reboot

Better to discuss this further in bug 203241, as this bug is about lilo problems
and your problem is totally different.
Comment 12 Hans de Goede 2006-08-31 17:12:45 EDT
(In reply to comment #11)
> (In reply to comment #10)
> > mkinitrd-5.1.9-1 still sucks. It fails if the kernel has a "root=LABEL=/"
> > parameter. It succeeds if I replace it to "root=/dev/mapper/nvidia..." (I'm
> > using dmraid).
> > Some more hint: when the kernel has the "root=/LABEL=/" parameter the mkrootdev
> > command fails to create the /dev/root node.
> 
> Boton,
> 
> This sounds awefully similar to the problem a friend of mine was seeing which
> I've managed to work around (and I'm working on a proper fix). See bug 203241
> 

Actually bug 203241 is about this but is approaching it wrong, please see bug
204768, which contains a real fix for this.
Comment 13 Pekka Savola 2007-04-24 07:47:02 EDT
Was there any resolution to this?

I think I'm having the same issue w/ RHEL5 (actually Centos5) with RAID1 root
(/dev/md0, IDE disks) and lilo.  Grub works but that's probably
due to the different way it puts info to the boot blocks.
Comment 14 Bug Zapper 2008-04-03 23:13:45 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 15 Hans de Goede 2008-04-04 04:38:02 EDT
AFAIK this has been long fixed.

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