Hi Joerg, On Mon, 07 Aug 2006, [EMAIL PROTECTED] 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. -- edubuntu-users mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/edubuntu-users
