Bug 310711
| Summary: | fc7 kernel boot fail | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | richard.shi <sttty.china> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 7 | CC: | chris.brown, vince.skahan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-02-16 02:43:22 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. 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... 18446744071562067968 = 0xffffffff80000000 That looks familiar... Bug 443678 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. 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. (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. |
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: