The attached patch adds support for turning a liveCD ISO image into a network-bootable PXE image.
Myself and Chris Lalancette looked into this in some detail and came up with two different ways to do this. This is the simpler of the two methods and results in the least invasive changes to livecd-creator -- just a single line patch to mayflower and a 100-or-so-line extra script called 'livecd-iso-to-pxeboot' which works analogously to 'livecd-iso-to-disk'.
The way it works is to bundle the complete ISO image inside the initrd. The kernel and (bloated) initrd are downloaded using PXE in the normal way, and the init script finds and loopback-mounts the ISO image and booting continues as normal.
One possible con of this approach is whether or not it's a good idea to download a very large (min 200 MB) initrd image over TFTP. There are two reasons we can think of why you *wouldn't* want to do this:
(1) "traditional" TFTP is limited to 32 MB max file size, although all modern TFTP implementations supersede that with a 4 GB limit (RFC 2348).
(2) TFTP uses its own transport layer which might not be able to back-off as nicely as TCP on busy networks.
However in my testing there was no problem at all using TFTP on large files over an ethernet LAN.
The other approach which we looked at and partially implemented was to modify the normal initrd/init so that it could do a separate request to download the ISO. It could possibly do this over another protocol such as HTTP (although in Chris's tests he just used a separate TFTP connection). The implementation of this is considerably more complicated:
(a) The initrd has to carry around dhclient, network scripts, and all the network programs like '/sbin/ip'.
(b) The initrd has to be able to find the TFTP server again, which basically involves making another DHCP query. In Chris's original implementation he also added specific DHCP options to carry the TFTP server information since it wasn't clear how to get this out of stock dhclient.
(c) After booting, because of (b), the network is already set up, which is not how a live CD expects it to be. Therefore the live CD itself would need to be changed if it does any network configuration.
All in all, I would say that the attached patch is a simpler and better approach.
Rich.
On Mon, 2008-02-11 at 16:22 +0000, Richard W.M. Jones wrote:
The way it works is to bundle the complete ISO image inside the initrd. The kernel and (bloated) initrd are downloaded using PXE in the normal way, and the init script finds and loopback-mounts the ISO image and booting continues as normal.
Hmmm, while sort of painful for the reasons you mention, the trivial amount of change required is somewhat attractive in the short-term. And I guess that in reality, it's always something that someone might for some crazy reason want to do.
One thing you can do to make your script easier is just stick the iso in another cpio.gz file and append it to the main initrd (which is an initramfs). The kernel should then do the right thing with multiple initramfs's.
Alternately, if you're expecting that people are using pxelinux (which it seems you are), you don't even have to do the append. Just make the cpio.gz of the iso image and use syntax like append initrd=initrd0.img,isocpio.gz in the pxelinux.cfg.
The other approach which we looked at and partially implemented was to modify the normal initrd/init so that it could do a separate request to download the ISO. It could possibly do this over another protocol such as HTTP (although in Chris's tests he just used a separate TFTP connection). The implementation of this is considerably more complicated:
Longer-term, I suspect this is something which is more interesting to support but I also think that it needs to wait until we really have the live initramfs process integrated with mkinitrd (which already has all of the network bring-up bits). Redoing all of that is on the todo list, but probably not for this time around.
Jeremy
Richard W.M. Jones wrote:
The attached patch adds support for turning a liveCD ISO image into a network-bootable PXE image.
Thanks for the work. However, for this to be of any real use we're going to need some way to integrate this into an existing PXE boot and /tftpboot configuration. What I would like to be able to do is specify the tftp root directory, the subdirectory to put the kernel and initrd images, and a name for the boot file. In my case I would do something like:
/tftpboot/ks/live/devel/minimal/{vmlinuz0,initrd0.img}
/tftpboot/ks/pxelinux.cfg/live.devel-minimal :
DEFAULT pxeboot TIMEOUT 20 PROMPT 0 LABEL pxeboot KERNEL /live/devel/minimal/vmlinuz0 APPEND initrd=/live/devel/minimal/initrd0.img root=/livecd-fedora-minimal-200802111321.iso rootfstype=iso9660 rootflags=loop ONERROR LOCALBOOT 0
And also have it not try to create pxeboot.0 and pxelinux.cfg.
So, something like:
livecd-iso-to-pxeboot --tftproot=/tftpboot/ks --imagedir=live/devel/minimal --bootfile=live.devel-minimal livecd-fedora-minimal-200802111321.iso
to create the above.
Orion Poplawski wrote:
And also have it not try to create pxeboot.0 and pxelinux.cfg.
So, something like:
livecd-iso-to-pxeboot --tftproot=/tftpboot/ks --imagedir=live/devel/minimal --bootfile=live.devel-minimal livecd-fedora-minimal-200802111321.iso
to create the above.
My original idea was to create a local tftpboot directory, and populate it with the stuff that we knew we needed for ourselves; then people are free to integrate it however they want into their existing infrastructure, or just to use it verbatim. I'm afraid with your suggestion that there are going to be too many caveats for too many different infrastructure setups, and you'll just end up with a maze of options.
Chris Lalancette
On Mon, 2008-02-11 at 16:29 -0500, Chris Lalancette wrote:
Orion Poplawski wrote:
And also have it not try to create pxeboot.0 and pxelinux.cfg.
So, something like:
livecd-iso-to-pxeboot --tftproot=/tftpboot/ks --imagedir=live/devel/minimal --bootfile=live.devel-minimal livecd-fedora-minimal-200802111321.iso
to create the above.
My original idea was to create a local tftpboot directory, and populate it with the stuff that we knew we needed for ourselves; then people are free to integrate it however they want into their existing infrastructure, or just to use it verbatim. I'm afraid with your suggestion that there are going to be too many caveats for too many different infrastructure setups, and you'll just end up with a maze of options.
Yeah, I think that just outputting something simple that can be copied around is going to be less error-prone.
Jeremy
Richard W.M. Jones wrote:
(a) The initrd has to carry around dhclient, network scripts, and all the network programs like '/sbin/ip'.
(b) The initrd has to be able to find the TFTP server again, which basically involves making another DHCP query. In Chris's original implementation he also added specific DHCP options to carry the TFTP server information since it wasn't clear how to get this out of stock dhclient.
(c) After booting, because of (b), the network is already set up, which is not how a live CD expects it to be. Therefore the live CD itself would need to be changed if it does any network configuration.
This turns out not to be a problem in practice; the network init scripts are just fine re-doing all the configuration that the initrd did, it just takes some time. In particular, another downfall with this method that Richard did not mention is that by the time you've actually booted, you've DHCP'ed 3 times on the same interface; once to find your PXE server and TFTP the kernel/initrd, once in the initrd to fetch your root filesystem, and finally a third time to bring the interface up for real. Each of these takes time, slowing down the boot process. In Richard's version, this is reduced to two DHCP's; the first one to fetch everything via PXE, and the second in the network init scripts.
Chris Lalancette
Chris Lalancette wrote:
This turns out not to be a problem in practice; the network init scripts are just fine re-doing all the configuration that the initrd did, it just takes some time.
There is a problem: I tried this using a static IP address network configuration in the live CD. The network configuration worked, but then the network broke a few minutes later when the original dhclient woke up and screwed around with the eth0 configuration. This caused my P2V transfer to halt some way through.
Of course it's possible to fix even this, but I still maintain that the live CD can be confused by a different network configuration existing at boot than it's expecting (ie. when it's expecting none at all).
Rich.
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
The other approach which we looked at and partially implemented was to modify the normal initrd/init so that it could do a separate request to download the ISO.
Did you look at mounting the ISO over NFS? I would expect that a lot of the cases where PXE is available NFS (or some type of network FS) is available. That's the path I was planning to chase.
Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjones@redhat.com said:
The other approach which we looked at and partially implemented was to modify the normal initrd/init so that it could do a separate request to download the ISO.
Did you look at mounting the ISO over NFS? I would expect that a lot of the cases where PXE is available NFS (or some type of network FS) is available. That's the path I was planning to chase.
Again, that's possible but also much more complex. The administrator now has to set up an NFS server as well as DHCP, TFTP and PXE.
This is designed to be a solution with minimal impact on livecd-creator, and mostly effortless for existing pxeboot administrators.
Rich.
livecd@lists.fedoraproject.org
-
Chris Adams -
Chris Lalancette -
Jeremy Katz -
Orion Poplawski -
Richard W.M. Jones