Bug 204099 - Kadischi built x86_64 kernel cannot read initrd superblock
Summary: Kadischi built x86_64 kernel cannot read initrd superblock
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-08-25 15:31 UTC by Jasper O. Hartline
Modified: 2015-01-04 22:28 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-09-11 01:59:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jasper O. Hartline 2006-08-25 15:31:21 UTC
Description of problem:
After building a LiveCD using Kadischi the resulting image boots the kernel but
the kernel cannot read the initrd superblock resulting in a kernel panick of
unable to mount rootfs at unknown block 9,1

The blocksizes used were 1024 and 4096, niether work.

Version-Release number of selected component (if applicable):
vmlinuz-2.6.17-1.2174_FC5

How reproducible:
Compile, install kadischi on x86_64 Fedora. Run kadischi against a x86_64
repository and boot the result LiveCD.


Steps to Reproduce:
1. Outlined above
2.
3.
  
Actual results:
CD kernel panicks.


Expected results:
CD should boot fully reading the initrd superblock

Additional info:
There is no additional information at this time.

Comment 1 Jasper O. Hartline 2006-08-26 18:56:06 UTC
Bug 187858 also has some information with it, about what I've summed up here.
It is a bug against Kadischi but no forseeable problems are with Kadischi so it
is now moved upstream to kernel devel maintenance list here.

Thanks. 

Comment 2 David Lawrence 2006-09-05 15:55:28 UTC
Changing to proper owner, kernel-maint.

Comment 3 Jasper O. Hartline 2006-09-05 16:30:53 UTC
Just for reference and to eliminate any confusion.. we've moved to using an
initramfs for Kadischi and the kernel, and it does boot properly. This however
doesn't mean there isn't still some bug or problem in the kernel's initrd code
or similar areas. 


The initrd was a gzipped Ext2 image.
The initrd was checked for it's magic and it had a magic of 0xEF53
which is correct for 32 bit architecture Ext2 filesystems.

Comment 4 Dave Jones 2006-09-11 01:59:44 UTC
as this isn't used by default, I'm not going to look into this any further, as
we've hundreds of other bugs of higher priority.



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