Edubuntu does not work with DHCP Konfiguration on port 1067

[Gavin McCullagh]

Hi Joerg,

On Mon, 07 Aug 2006, mailing-joergd at gmx.net wrote:

> The clients should be able to boot the existing system as well as
> Edubuntu.  That's why a distinction based on the machines is not
> practicable. A pxe multiboot solution might work, but I'd prefer a
> solution where edubuntu works independent of the other system. The users
> just should put in the etherboot-diskette if they would like to boot
> edubuntu.

I understand.  It's actually desirable for the client to be able to choose
their DHCP server.  Unusual, but I can see where you're going :-)

> > eg "-p 1068" so I'd imagine there should be a config file option.  
> 
> Yes, but how to implement this option in the client image?  I'm not sure
> that the second dhcp request (the one which causes the trouble) is
> triggered by the nfs mounted /opt/ltsp/i386.
> 
> If 2nd dhcp request fails, the client crashes down to the busybox.
> After 2nd dhcp request succeeds, the client starts mounting its filesystem over nfs.
> 
> I think the dhcp request is started by the vmlinuz/initrd.img image
> located in /var/lib/tftpboot/ltsp.

Yes! Of course you are correct.  Sorry I hadn't thought that out correctly
(it's a public holiday in Ireland today!).

> > If it came to it, you could rebuild the dhcp3-client package and
> > install it into your edubuntu chroot with the default port number
> > changed in the source.  (ick!)  It looks like you need to look at
> > client/dhclient.c line 298.
> 
> Hmmm I'm pessimistic after trying to build my own kernel already failed...

It _should_ be straightforward to rebuild the dhcp3-client package.  An
example is here:

http://www.debian-administration.org/articles/20

However, as you've pointed out, it's the initrd dhcp client that you need
to modify.

I created an nfs mounting initramfs here (I don't have edubuntu here but
debian should be close) and looked around within it.  The file /scripts/nfs
seems to be where the network interface is brought up. 

	# For DHCP
	modprobe -q af_packet
	ipconfig ${DEVICE}

This script is apparently copied from a master copy at
/usr/share/initramfs-tools/scripts/nfs when you create the initrd using
mkinitramfs.  The master copy of the script is part of the initramfs-tools
package.

You can modify this script to read as follows:

	# For DHCP
	modprobe -q af_packet
	ipconfig -p 1068 ${DEVICE}

and then run mkinitramfs to rebuild your initrd image (this is in the ltsp
chroot obviously).  I've tested here and that ipconfig does recognise the
-p option.

Obviously you'd need to redo this every time initramfs-tools got upgraded.

You may come up with a better answer than this, but I think the above
should work to get you going.

> These option settings are used to bypass specified options (like DPORT)
> to the client kernel. As described, the kernel delivered with
> ltsp_initrd_kit recognizes the DPORT setting. For other people using the
> ltsp package it seems to work with the option settings, too (take a look
> at the ltsp mailing list).

I guess I understand, it's just that (as I understand) the kernel doesn't
do the dhcp do it must then pass this info on to whatever does.

> How are the edubuntu images in /var/lib/tftpboot/ltsp created? Is there
> any chance to adapt them without having to make a new kernel? What are
> the differences between the edubuntu images and the ltsp images?

mkinitramfs, I presume.

> Thanks a lot for your help,
> hopefully we can fix this issue somehow.

Try the above.  I think it should work.

Incidentally, if you want to look inside an initrd image you can do:

gunzip -c /var/lib/tftpboot/ltsp/initrd-xxxx.img >/tmp/initrd.tmp
mkdir tmproot/
cd tmproot/
cpio -i --make-directories < ../initrd.tmp

and you should be able to explore the archive, see listing 2 here:

	http://www-128.ibm.com/developerworks/linux/library/l-initrd.html

If you manage to make a modified initrd, I think this should get you going.
Of course, I've never done this, but everything I've tried here suggests it
should work.

Gavin

PS If you get your thin client up and running on the nfs root, dhclient
probably takes over the ongoing dhcp responbilities so you may need to
convince it to use the other port too.