Bug 443678 - PXE grow_buffers error
PXE grow_buffers error
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
i386 Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-22 16:04 EDT by Vladislav Staroselskiy
Modified: 2009-01-09 01:24 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-09 01:24:40 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 Vladislav Staroselskiy 2008-04-22 16:04:47 EDT
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 ===
Comment 1 Chuck Ebbert 2008-04-22 22:57:16 EDT
grow_buffers: requested out-of-range block 18446744071562067968 for device ram0

= 0xffffffff80000000
Comment 2 Vladislav Staroselskiy 2008-04-24 11:46:22 EDT
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".
Comment 3 Chuck Ebbert 2008-05-13 01:34:56 EDT
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.
Comment 4 Vladislav Staroselskiy 2008-05-13 12:23:08 EDT
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.
Comment 5 Vladislav Staroselskiy 2008-05-13 12:25:36 EDT
(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.
Comment 6 Bug Zapper 2008-11-26 05:32:47 EST
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
Comment 7 Bug Zapper 2009-01-09 01:24:40 EST
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.

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