Bug 432112 - kernel-2.6.23.14-115.fc8 on i386 fails to boot
Summary: kernel-2.6.23.14-115.fc8 on i386 fails to boot
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: i386
OS: Linux
low
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-08 21:42 UTC by Michael Sinz
Modified: 2008-02-09 16:48 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-09 16:48:22 UTC
Type: ---
Embargoed:


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

Description Michael Sinz 2008-02-08 21:42:47 UTC
Description of problem:

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

Version-Release number of selected component (if applicable):
kernel-2.6.23.14-115.fc8

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"
message.

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-2.6.23.14-115.fc8 ro root=LABEL=/ vga=794
initrd /initrd-2.6.23.14-115.fc8.img

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 21:50:09 UTC
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-09 02:41:44 UTC
I always do the kernel updates on their own (well, kernel and kernel-devel and
kernel-doc)

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-09 02:49:31 UTC
Created attachment 294442 [details]
The requested "working" initrd from the -107 kernel release

I have attached the working initrd for the 2.6.23.14-107.fc8 kernel version. 
This  is the last released kernel/initrd that worked.

Comment 4 Michael Sinz 2008-02-09 02:54:37 UTC
Created attachment 294443 [details]
The requested "failing" initrd from the -115 kernel release

This is the initrd for the 2.6.23.14-115.fc8 kernel that fails to boot.

Comment 5 Michael Sinz 2008-02-09 16:48:22 UTC
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.