|
Bugzilla – Full Text Bug Listing |
| Summary: | Unable to boot system after normal kernel upgrade | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 11.1 | Reporter: | Archie Cobbs <archie.cobbs> |
| Component: | Bootloader | Assignee: | Michal Marek <mmarek> |
| Status: | RESOLVED DUPLICATE | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | eirikjbj |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 11.1 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Patch to initrd image that works around this bug (for me) | ||
|
Description
Archie Cobbs
2009-03-12 18:48:44 UTC
Following comment in the forum is: just pressing the CTRL+D makes linux boot.. so i suppose the module for rootfs is loaded! lsmod was I unable to run Don't know what's wrong in initrd... Note: Just to be clear, in my particular problem described here, I never said "just pressing CTRL-D makes linux boot". What I said was: FIRST running "modprobe reiserfs" and THEN pressing CTRL-D makes it boot. The mystery is: why, even though the reiserfs module seems to be included in the initrd as it should be, does it not get loaded at the appropriate time so that root can be mounted? The just pressing CTRL+D worked for me, probably bacause of different rootfs (ext3). But it is sort of same problem, since we both halt at "invalid root filesystem". I did some debugging and here is some more info.
The problem occurs in the initrd script boot/83-mount.sh in this code:
if [ -z "$rootfstype" -a -x /sbin/udevadm -a -n "$sysdev" ]; then
eval $(/sbin/udevadm info -q env -p $sysdev | sed -n '/ID_FS_TYPE/p')
rootfstype=$ID_FS_TYPE
[ -n "$rootfstype" ] && [ "$rootfstype" = "unknown" ] && $rootfstype=
ID_FS_TYPE=
fi
What's supposed to happen in there is that udevadm spits out "ID_FS_TYPE=reiserfs" (among other stuff). When you run this command after the system has booted, it in fact does work properly:
$ /sbin/udevadm info -q env -p /devices/virtual/block/md0
MD_LEVEL=raid1
MD_DEVICES=2
MD_METADATA=1.00
MD_UUID=dec8fad4:b86893d1:8a7eeeb6:e791be9d
MD_NAME=0
ID_FS_USAGE=filesystem
ID_FS_TYPE=reiserfs
ID_FS_VERSION=3.6
ID_FS_UUID=743d0ae3-6a8d-4b7a-81fa-fbfe890870a8
ID_FS_UUID_ENC=743d0ae3-6a8d-4b7a-81fa-fbfe890870a8
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=
However, when the boot/83-mount.sh script runs at boot time as part of the initrd bootstrap, this same command outputs only this (as determined by hacking this script):
MD_LEVEL=raid1
MD_DEVICES=2
MD_METADATA=1.00
MD_UUID=dec8fad4:b86893d1:8a7eeeb6:e791be9d
MD_DEVNAME=0
MD_NAME=0
So this failure of udevadm to spit out the ID_FS_* stuff seems to be the root of the problem.
I've attached a workaround that I've applied to my initrd. This of course only works if your root filesystem is reiserfs.
Created attachment 279626 [details]
Patch to initrd image that works around this bug (for me)
after updating to the latest factory kernel, I do not need to press CTRL+D to start! so the it is fixed for me! Problem still occurs after upgrading to kernel-trace-2.6.27.21-0.1.2. Fixed in a later kernel update. *** This bug has been marked as a duplicate of bug 445490 *** |