[Fedora-livecd-list] Boot over NFS/PXE

[Phil Meyer]

On 11/20/2011 05:21 PM, Francesco Frassinelli wrote:
> Hi all,
> I need to boot a livecd on some hard disk less clients. I tried to use 
> livecd-iso-to-pxe, but in my case it unacceptable to load the whole 
> iso into initrd (the iso is not small).
> I made a custom livecd adding dracut-network package, I mounted 
> squashfs/root image, exported with nfs, and I've tried to boot the 
> clients with root=nfs:192.168.1.50:/home/frafra/root/ selinux=0, but 
> Fedora gives me many errors because it can't write on it.
> I found this old thread 
> http://comments.gmane.org/gmane.linux.redhat.fedora.livecd/4261 but it 
> doesn't work for me.
> Is there a way to get a livecd behaviour with this nfs directory? Or 
> can I combine the isolinux.cfg livecd options with 
> root=nfs:192.168.1.50:/home/frafra/ (where it could found the iso or 
> the mounted iso)?
> I'm using dnsmasq with its internal tftp server, which gives vmlinuz0 
> and initrd0.img (copied from livecd), pxelinux.0 and a configuration 
> file with the above root=nfs:[...] selinux=0 options.

The real issue is not the size of the iso, but using tftp protocol to 
load it.

TFTP needs to ack each segment before the next is sent, thus severely 
throttling throughput.

On a 100BT interface, tfpt maxes out at about 2MB/sec.
On a 1000BT interface, tftp maxes out at about 15MB/sec


I would propose using a different method for identifying the initrd to 
dracut during the PXE boot process.

Current:
     KERNEL /images/centos_server_kvm/vmlinuz0
     APPEND rootflags=loop initrd=/images/centos_server_kvm/initrd0.img 
root=live:/centos_server_kvm.iso rootfstype=auto ro liveimg quiet  rhgb 
rd.luks=0 rd.md=0 rd.dm=0

Proposed:
     KERNEL /images/centos_server_kvm/vmlinuz0
    APPEND rootflags=loop 
initrd=http://mymirror.mycompany.com/images/centos_server_kvm/initrd0.img root=live:/centos_server_kvm.iso 
rootfstype=auto ro liveimg quiet  rhgb rd.luks=0 rd.md=0 rd.dm=0

That would literally shave minutes off of boot times by increasing 
throughput of the large image by a factor of 10 or more.

This is somewhat of a paradox issue, because many of the network and 
protocol drivers are within the initrd images.  Surely there must be a 
way ...

Thanks for listening.