Bug 310711 - fc7 kernel boot fail
fc7 kernel boot fail
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
i386 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-28 08:26 EDT by richard.shi
Modified: 2008-05-17 15:23 EDT (History)
2 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description richard.shi 2007-09-28 08:26:37 EDT
Description of problem:

I used fc7's kernel(vmlinuz-2.6.21-1.3194.fc7) and I rebuilt my initrd with the
following command:

dd if=/dev/zero of=myinitrd.img bs=1k count=2500
mkfs.ext2 -Fq myinitrd.img -m 0 2500
mount -o loop myinitrd.img /mnt
mkdir /mnt/ ........... #make some directory and busybox.
umount /mnt
gzip -9 myinitrd.img
cp myinitrd.img.gz /boot

Added following content to grub.conf
title FC7 (2.6.21)
        root (hd0,0)
        kernel /vmlinuz-2.6.21-1.3194.fc7 root=/dev/ram0 ramdisk=40960
init=/linuxrc vga=791
        initrd /myinitrd.img.gz

reboot computer. 

so the kernel can't work, the error message is:

md: Autodetecting RAID arrays.
md: autorun ...
md: ... autorun DONE.
RAMDISK: Compressed image found at block 0
grow_buffers: requested out-of-range block 18446744071562067968 for device ram0
isofs_fill_super: bread failed, dev=ram0, iso_blknum=17, block=-2147483648
No filesystem could mount root, tried: iso9660
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Christopher Brown 2008-01-14 13:03:21 EST
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

I am CC'ing myself to this bug and will try and assist you in resolving it if I can.

There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?

If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
Comment 2 Christopher Brown 2008-02-15 21:43:22 EST
Closing as per previous comment. Please re-open if this is still an issue for you.
Comment 3 Vince Skahan 2008-04-29 20:28:09 EDT
I'd like to reopen this bug please.  I've run into the same thing on every
kernel in FC6 'except' 2.6.20-1.2962.fc6 (vanilla kernel fails, all other
updates kernel fails) and I'm seeing it now trying to create a large initrd into
ramdisk system on F8 using both the vanilla kernel and the latest updated kernel
in F8 updates.

What I'm doing is building a minimal(ish) image and running it all in ramdisk. 
This has worked since Redhat-7.2 all the way up through FC4 flawlessly.  In my
FC6 development I found only that one kernel that worked, all other kernels
showed the same non-bootable problem described above.  Seeing it still in F8. 
Has to be a kernel bug in my opinion.

I can provide the build scripts etc. for whatever you need to try to do to
recreate the situation as needed.  Thanks...
Comment 4 Chuck Ebbert 2008-05-05 21:18:44 EDT
 18446744071562067968
= 0xffffffff80000000
Comment 5 Chuck Ebbert 2008-05-05 21:20:57 EDT
That looks familiar...

Bug 443678
Comment 6 Vince Skahan 2008-05-06 10:23:09 EDT
I sure can't tell from the skeletal last two comments nor the reference to
443678 what you're saying.  I don't have busybox in my big-ramdisk image at all.

Bottom line for me is it sure seems like there is a kernel patch that used to be
there which was dropped in later kernels (???).  If that's accurate, let me know
what to look for and I'll try to hand patch something up into a later kernel and
see if it works again.  I'm pretty much dead stopped at this point with the
as-is so I'm somewhat inclined to spend the time to try stuff, given a clue what
to try.
Comment 7 Vince Skahan 2008-05-07 20:16:09 EDT
update - this afternoon I successfully got an almost totally F8-based initrd
image to boot (295MB used running in a 384MB ramdisk) by using the
2.6.20-1.2962.fc6 kernel instead of the one supplied with F8.  If I use the same
build scripts and rpms and switch (only) to the F8 kernel, no joy trying either
a initrd-based or cpio-based image so the ticket should still stay open please.

Incidentally the workaround for the "requested out-of-range block" seems to be
to specify ramdisk_size=1024 in your grub menu. Description of why is on
http://osdir.com/ml/redhat.release.tikanga.beta/2006-09/msg00112.html which
mentions a change in kernel settings in RHEL5 betas which lines up with FC7 in
terms of time if memory serves.

Again, I have a couple quick scripts available to let you try to build the
ramdisk os images and play with different kernels, if anybody at RH is so
inclined.  Please contact me via email as needed.  Thanks.
Comment 8 Chuck Ebbert 2008-05-13 01:34:05 EDT
(In reply to comment #7)
> 
> Incidentally the workaround for the "requested out-of-range block" seems to be
> to specify ramdisk_size=1024 in your grub menu. Description of why is on
> http://osdir.com/ml/redhat.release.tikanga.beta/2006-09/msg00112.html which
> mentions a change in kernel settings in RHEL5 betas which lines up with FC7 in
> terms of time if memory serves.
> 

You mean ramdisk_blocksize= ?
Comment 9 Vince Skahan 2008-05-17 15:23:38 EDT
oops - yes indeed, ramdisk_blocksize. Incidentally the same big-ramdisk initrd
implementation works just fine with Centos-5.1 i386 if that helps.

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