Description of problem: When booting Fedora Core 8 from PXE using custom initrd.img and "init=disklessrc" kernel option, it gives a "grow_buffers" kernel panic message, in case if initrd.img doesn't contain an "/init" file inside. Version-Release number of selected component (if applicable): 2.6.24.3-50.fc8 How reproducible: 100% Steps to Reproduce: 1. Create a custom initrd.img file, which doesn't contain "/init", but "/disklessrc" init script. 2. Copy it to TFTP server. Have proper DHCP/NFS boot environment set up. 3. Specify kernel option "init=disklessrc" inside of /tftpboot/linux-install/pxelinux.cfg/default file. 4. Boot using PXE method. Actual results: kernel panic message: === kernel_panic_message_cut === 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 List of all partitions: No filesystem could mount root, tried: iso9660 Kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(1,0) === kernel_panic_message_cut === Expected results: Either 1) Skipping /init script when "init=" kernel option is provided or 2) Proper error message, reporting missing /init file inside of initrd.img. Additional info: I was able to get around this problem by linking my "disklessrc" to "init" script: ln -s disklessrc init and then regenerating initrd.img. But it took a while to find out... My /tftpboot/linux-install/pxelinux.cfg/default file: === cut === default FC8 label FC8 kernel FC8/vmlinuz append initrd=FC8/initrd.img root=/dev/ram0 init=disklessrc NFSROOT=192.168.0.1:/netboot/FC8 ramdisk_size=60000 ETHERNET=eth0 SNAPSHOT=snapshot ip=dhcp === cut ===
grow_buffers: requested out-of-range block 18446744071562067968 for device ram0 = 0xffffffff80000000
Update for "additional info" section: It turned out, that "ln -s disklessrc init" didn't work for "switch_root" command of BusyBox, which gave "not rootfs" error in case if "/init" doesn't exist or if it's not a regular file. I had to do "cp disklessrc init" instead. I found a clue from the following link: http://busybox.net/lists/busybox/2006-August/023999.html You may want to extend this bug to BusyBox developers as well. From my point of view, "switch_root" should also check if "init=" kernel option is being passed and do lstat() for this file instead of hard-coded "/init".
What kind of initrd are you using? (Is it a compressed filesystem or a cpio.gz file?) If it is a filesystem, what blocksize is used? The kernel will default to trying a 4K blocksize unless you specify 1K with ramisk_blocksize=1024 and this can cause the block out of range errors.
It's cpio in newc format, made on filesystem with a blocksize of 4K. I used the following command to generate initrd from the current directory: find . | cpio -o --verbose --format=newc | gzip -9 >/path/initrd.img Just tested it with a standard initrd-2.6.24.3-50.fc8.img (knowing, that it won't be able to mount root due to lack of NFS support). 1) Unpacked it into a folder and simply repacked with the command above without any changes. Got expected "unable to mount root; unable to switch_root; booting has failed" messages without kernel panic. 2) "mv init diskless", repacked with the same command. Got "grow_buffers" message with kernel panic.
(In reply to comment #4) > 2) "mv init diskless", repacked with the same command. Got "grow_buffers" Sorry, I meant "mv init disklessrc", of course.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.