Bug 202715

Summary:	Loop in __find_get_block_slow after building a Kadischi FC6T2 LiveCD
Product:	[Fedora] Fedora	Reporter:	Jasper O. Hartline <jasperhartline>
Component:	kernel	Assignee:	Dave Jones <davej>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6	CC:	Jasper.Hartline, wtogami
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:	2006-08-16 18:19:39 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:

Description Jasper O. Hartline 2006-08-15 22:30:53 UTC

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
__find_get_block_slow

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):
kernel-2.6.17-1.2517.fc6

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
2.
3.
  
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.

Thanks.

Comment 1 Jasper O. Hartline 2006-08-15 22:45:22 UTC

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 23:11:49 UTC

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 18:19:39 UTC

the initrd has to be 4kb blocksize.

Comment 4 Jasper O'neal Hartline 2018-10-03 19:01:32 UTC

We have initramfs now so no worries there. We also have a great LiveDVD Workstation Edition for Fedora 28 now so that is good.