Bug 458470

Summary: livecd-iso-to-pxeboot data once pxebooted fails to enter into ISO image
Product: [Fedora] Fedora Reporter: Michael DeHaan <mdehaan>
Component: livecd-toolsAssignee: Jeremy Katz <katzj>
Status: CLOSED WORKSFORME QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: apevec, clalance, davidz, katzj
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-08-12 21:02:33 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 Michael DeHaan 2008-08-08 17:15:00 UTC
Description of problem:

livecd-iso-to-pxeboot when run against the F9 x86_64 live ISO as described here:  https://fedorahosted.org/cobbler/wiki/HowToPxeAnyLiveCd results in the PXE CD booting but not entering inside of the "f9live.iso" "stage".  Basically if one does an ls at the bash prompt the pxe booted image gives you can see the ISO (f9live.iso) but you have not entered inside of it.  This seems to indicate something may be wrong with the init script as the root flags and such appear to be correct as I'm using the flags basically as the livecd-iso-to-pxeboot script generates them.

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

I'm using the livecd downloaded from the Fedora torrent for x86_64, though here's what I was using for livecd-iso-to-pxeboot:

[mdehaan@localhost cobbler]$ rpm -q mkinitrd
mkinitrd-6.0.52-2.fc9.i386

[mdehaan@localhost cobbler]$ rpm -q livecd-tools
livecd-tools-017.1-1.fc9.i386

Additional (from email exchange with Chris Lalancette):

>> Hm, odd.  I honestly haven't done much with this since I originally wrote it
>> >> (and Rich Jones further modified it), since it seems to "just work" for oVirt.
>> >> Looking at your /proc/cmdline, the only thing I can come up with is that I'm not
>> >> sure the /images/LIVE_DISTRO/{initrd0.img, vmlinuz.img} paths are correct.  For
>> >> reference, when one of our oVirt nodes PXE boots, it looks like:
>> >>   
> > 
> > Those are the TFTP urls.  They are correct as the image did get served 
> > up (via TFTP) just before that.   The only problem
> > is that inside the image it seems to be in an earlier "stage" and didn't 
> > jump inside the live image.
> > 
> > Are you saying those parameters might be being reused for how to find 
> > the item /inside/ the image? 

Yeah, that's the key point, which you put much more eloquently than I did.  This
is all based off of memory from many months ago, though, so I could be totally
off my rocker.  I think you'll have to look at the init script to tell for
certain; please share if you find out, since I'm curious to know (again?).

Chris Lalancette

---

Further discussion on #ovirt pointed to this code being part of mkinitrd now:

http://git.fedorahosted.org/git/?p=mkinitrd;a=blob;f=mkliveinitrd;h=5fee1db1e87003e9c991ea183c288fd1400618fe;hb=HEAD

----

> > cat /proc/cmdline
> > 
> > initrd=/images/LIVE_DISTRO/initrd0.img rootflags=loop root=/f9live.iso 
> > rootfstype=iso9660 BOOT_IMAGE=/images/LIVE_DISTRO/vmlinuz.img
> > 
> > This is using the Fedora-9-x86_64-Live.torrent, downloaded yesterday, on 
> > x86_64 hardware.

----

Meanwhile on #ovirt apevec says the ovirt CD does not have this problem.  So perhaps there is something specific about livecd-tools doing this -- either size related or path related.  I'm not sure how to chase it, but plan to do some more testing Monday with other live images including ones I've built myself.

Comment 1 Jeremy Katz 2008-08-09 19:20:28 UTC
At which point during the initramfs sequence does it fail?  The output of a boot without quiet would probably also be helpful.

Comment 2 Michael DeHaan 2008-08-11 12:26:41 UTC
There's no visible failure that I could detect or find in something like /var/log/messages, you are just left at a bash "#" prompt rather than jumping inside the CD.  I'd be more than happy to dig further and see what the actual error is, though I'd need to know where to look.

What do I need to do to build a "non-quiet" live CD?

Comment 3 Jeremy Katz 2008-08-11 13:29:09 UTC
Non-quiet is ensuring 'quiet' isn't passed as a boot arg to the kernel

As far as where to look, hard to say with what data is here.  You're not going to have /var/log/messages because you're very very very early in boot.  You (probably) don't even have the rootfs mounted.

Everything ends up getting mounted as /sysroot, so checking  that makes some sense.  You'll also want to look at what loop devices are set up, dmsetup table, etc.

Also is should give *some* indication as to why it's dropping you to a shell

Comment 4 Michael DeHaan 2008-08-12 20:47:03 UTC
I just retested this using a koan image (irrelevant what the image does, I'm using it just because it is smaller), koan-live-cd.iso and it works fine.

I'll get some more data on the larger-ISO environment next.

Comment 5 Michael DeHaan 2008-08-12 21:01:54 UTC
Ok, so I tried this again, and it worked.

I will blame user error.

The full live image can be sent over the wire in ~5 minutes, a smaller image much less so, so we should abuse this coolness as much as possible.

I apologize for the confusion.