Bug 202715 - Loop in __find_get_block_slow after building a Kadischi FC6T2 LiveCD
Loop in __find_get_block_slow after building a Kadischi FC6T2 LiveCD
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-08-15 18:30 EDT by Jasper O. Hartline
Modified: 2015-01-04 17:28 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-16 14:19:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jasper O. Hartline 2006-08-15 18:30:53 EDT
Description of problem:
After building a LiveCD using Kadischi using a FC6T2 stock disc as a repository,
I boot the CD image in Qemu and/or on normal hardware and get an endless loop in

The loop looks like so:

__find_get_block_slow() failed. block=18446744071562067968, b_blocknr=2147483648
b_state=0x00000020, b_size=4096
device blocksize: 4096

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

How reproducible:
Build LiveCD with Kadischi, boot teh CD under Qemu or normal hardware.

Steps to Reproduce:
1. kadischi --text /path/to/FC6T2/repository -f /tmp/fc6t2live.iso
Actual results:
Loop in __find_getblock_slow() kernel problem.

Expected results:
Should boot into a Live system.

Additional info:
Relevant information includes:
We already load cdrom.ko and ide-cd.ko which is used to allow find_live_cd.c in
Kadischi find and mount the CD in question after finding a /.livecd file on the
CD. This may or may not be a problem in find_live_cd.c or the kernel it's self
but I want to get more info before making an assumption.

cdrom.ko and ide-cd.ko were a part of the kernel before, and this didn't happen.
This could be a cause?
Also: Kadischi uses an Ext2 gzipped image as initrd, is this a problem either?
As The loop ends up happenning right after finding a compressed RAMDISK image at
block 0 during kernel bootstrap.

Comment 1 Jasper O. Hartline 2006-08-15 18:45:22 EDT
Additional information:
I happenned to be able to just get a peek at what it says before the loop and
after finding a compressed RAMDISK at block 0, and it does say:

Block size too small for device

I will try with a larger block size to Kadischi during making the initrd, and
report back results before pursuing this incedent as a bug. Thanks.
Comment 2 Jasper O. Hartline 2006-08-15 19:11:49 EDT
Additional information:
Adding mke2fs -b 4096 _does_ rectify the situation in Kadischi LiveCDs when
making the initrd..
This is using a initrd at size 10MB. 

If this is right, please close this bug. If not I can provide any additional
information needed to rectify this issue.
Comment 3 Dave Jones 2006-08-16 14:19:39 EDT
the initrd has to be 4kb blocksize.

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