Description of problem:
I used fc7's kernel(vmlinuz-2.6.21-1.3194.fc7) and I rebuilt my initrd with the
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.
gzip -9 myinitrd.img
cp myinitrd.img.gz /boot
Added following content to grub.conf
title FC7 (2.6.21)
kernel /vmlinuz-2.6.21-1.3194.fc7 root=/dev/ram0 ramdisk=40960
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):
Steps to Reproduce:
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.
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.
Closing as per previous comment. Please re-open if this is still an issue for you.
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...
That looks familiar...
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
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
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.
(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= ?
oops - yes indeed, ramdisk_blocksize. Incidentally the same big-ramdisk initrd
implementation works just fine with Centos-5.1 i386 if that helps.