Bug 432112 - kernel- on i386 fails to boot
kernel- on i386 fails to boot
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-02-08 16:42 EST by Michael Sinz
Modified: 2008-02-09 11:48 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-02-09 11:48:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The requested "working" initrd from the -107 kernel release (2.90 MB, application/octet-stream)
2008-02-08 21:49 EST, Michael Sinz
no flags Details
The requested "failing" initrd from the -115 kernel release (2.81 MB, application/octet-stream)
2008-02-08 21:54 EST, Michael Sinz
no flags Details

  None (edit)
Description Michael Sinz 2008-02-08 16:42:47 EST
Description of problem:

With the new kernel- installed, my Pentium-M 1ghz laptop fails
to boot.  This is not a problem with kernel- and thus is a

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

How reproducible:
100% - I have un-installed and grabbed a fresh download of the -115 RPM and it
still happens.

Steps to Reproduce:
1. Install latest (-115) kernel
2. Boot
3. (there is not step 3 :-))
Actual results:
The boot process starts failing right after it validates that there is no resume
image within swap and starts creating root device.

It fails doing a mount of /dev/root on /sysroot as auto with a "No such device"

From this point on many other failures occur such as failing to mount /proc or
/sys or changing rights on /dev due to the lack of directories due to the lack
of mounting of /dev/root.  This prevents the boot to complete switchroot which
then ultimately causes the boot to stop with a "Booting has failed" message. 

Expected results:
Normal boot up process - mount of /dev/root, setup of other filesystems, pivot
root to the actual root filesystem.  All of which fails.

Additional info:
This is on a laptop partitioned without LVM.  Physical partitions include
/boot(sda1) swap(sda2) /(sda3)  (This is a laptop and thus runs a very
simplistic disk setup)

The partitions are mounted with labels, with "/" and "/boot" and "SWAP-sda2"
being the labels (default configuration for Fedora systems)

Boot options are:

kernel /vmlinuz- ro root=LABEL=/ vga=794
initrd /initrd-

I can not paste anything from the actual boot process as no log output is
created (no disks are mounted, boot process just hangs)
Comment 1 Chuck Ebbert 2008-02-08 16:50:09 EST
Can you upload the initrd files [/boot/initrd-<version>.img] from the new and
old kernels?

Also, were any other packages updated at the same time?
Comment 2 Michael Sinz 2008-02-08 21:41:44 EST
I always do the kernel updates on their own (well, kernel and kernel-devel and

I will upload the initrd but they are unchanged from the RPM (this system runs
generic FC8, at least as far as the kernel/initrd and boot scripts go)
Comment 3 Michael Sinz 2008-02-08 21:49:31 EST
Created attachment 294442 [details]
The requested "working" initrd from the -107 kernel release

I have attached the working initrd for the kernel version. 
This  is the last released kernel/initrd that worked.
Comment 4 Michael Sinz 2008-02-08 21:54:37 EST
Created attachment 294443 [details]
The requested "failing" initrd from the -115 kernel release

This is the initrd for the kernel that fails to boot.
Comment 5 Michael Sinz 2008-02-09 11:48:22 EST
I believe I found the problem but am unsure as to why it happened.

The init script in the initrd under 115 did not load the mbcache.so module,
jbd.so, or ext3.so which caused the failure of the mkrootdev.

The problem was caused by the fstab having "auto" as the file system type for
"/"  (Verified now that I have reinstalled with fstab having the file system
type set to ext3)

Now, as to why the file system type was changed, it is unclear.  However, also
interesting is that the mkinitrd did not correctly notice that the file system
type needed was that of ext3 (after all, it was running on that file system at
the time)

I am sorry for not having noticed this earlier.  I submit that this bus should
be "closed" as some sort of user error albeit it would be interesting to look
into mkinitrd as to a way to prevent this user error in the future.

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