Hide Forgot
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.
At which point during the initramfs sequence does it fail? The output of a boot without quiet would probably also be helpful.
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?
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
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.
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.