The current PXE setup on the ISO has some drawbacks:
1) We still use ipconfig, as I stated in my previous mail. 2) Without changing the configuration, archiso can only guess where the NBD/NFS/http server is. In that guess, we abuse DHCP's next-server option, which is meant to identify the TFTP server. 3) Without changing the configuration, the user can choose between NBD, NFS and http, although only one option will actually work.
When I tried addressing 1), I also noticed that dhcpcd does not parse the next-server option, so we cannot use it like we did with ipconfig. While that is easy to patch, it is still not the right way.
I propose the following new setup to improve this:
a) (Actually unchanged, just for clarification) DHCP sends next-server and filename as usual, sets DHCP options 209 and 210 so that pxelinux finds the configuration. pxelinux loads the kernel and initramfs and boots them. (BTW, this can already be done via http if ipxe is used, so we only need to put a single ipxe configuration file on the TFTP and the ISO only on http.)
b) There is only one PXE option in the menu instead of three. This passes an option like 'archiso_pxe_autodetect=224,225' (option syntax to be discussed, explanation below) and omits the http/nfs/nbd-specific options.
c) We run dhcpcd in the initramfs instead of ipconfig. We make sure to use BOOTIF= to identify the correct interface and pass that along to userspace using /run/archiso/dhcp_interface. We also copy the lease to /new_root/etc/dhcpcd/ after mounting to make sure we have a consistent IP setup.
d) The DHCP server passes two strings as DHCP options. The options 224 and 225 as given above are "for private use". Option 224 contains either "http", "NFS" or "NBD". Option 225 contains the actual URL.
The advantage of this setup is that we can just extract the ISO and configure everything via the DHCP server configuration file. There is no need to change the archiso bootloader configuration, and we only get a single option in the boot menu, instead of three.
I can implement this, but I thought I'd put this up for comments first, as I didn't get a chance to do it yet.
On 08/24/2012 08:30 PM, Thomas Bächler wrote:
The current PXE setup on the ISO has some drawbacks:
- We still use ipconfig, as I stated in my previous mail.
- Without changing the configuration, archiso can only guess where the
NBD/NFS/http server is. In that guess, we abuse DHCP's next-server option, which is meant to identify the TFTP server. 3) Without changing the configuration, the user can choose between NBD, NFS and http, although only one option will actually work.
When I tried addressing 1), I also noticed that dhcpcd does not parse the next-server option, so we cannot use it like we did with ipconfig. While that is easy to patch, it is still not the right way.
I propose the following new setup to improve this:
a) (Actually unchanged, just for clarification) DHCP sends next-server and filename as usual, sets DHCP options 209 and 210 so that pxelinux finds the configuration. pxelinux loads the kernel and initramfs and boots them. (BTW, this can already be done via http if ipxe is used, so we only need to put a single ipxe configuration file on the TFTP and the ISO only on http.)
b) There is only one PXE option in the menu instead of three. This passes an option like 'archiso_pxe_autodetect=224,225' (option syntax to be discussed, explanation below) and omits the http/nfs/nbd-specific options.
c) We run dhcpcd in the initramfs instead of ipconfig. We make sure to use BOOTIF= to identify the correct interface and pass that along to userspace using /run/archiso/dhcp_interface. We also copy the lease to /new_root/etc/dhcpcd/ after mounting to make sure we have a consistent IP setup.
d) The DHCP server passes two strings as DHCP options. The options 224 and 225 as given above are "for private use". Option 224 contains either "http", "NFS" or "NBD". Option 225 contains the actual URL.
The advantage of this setup is that we can just extract the ISO and configure everything via the DHCP server configuration file. There is no need to change the archiso bootloader configuration, and we only get a single option in the boot menu, instead of three.
I can implement this, but I thought I'd put this up for comments first, as I didn't get a chance to do it yet.
I like it, will look good :)
When this is done, or maybe during the transition we can migrate from nfsmount and start using commands from nfs-utils, in order to get rid off klibc stuff at all.
Am 25.08.2012 18:09, schrieb Gerardo Exequiel Pozzi:
d) The DHCP server passes two strings as DHCP options. The options 224 and 225 as given above are "for private use". Option 224 contains either "http", "NFS" or "NBD". Option 225 contains the actual URL.
The advantage of this setup is that we can just extract the ISO and configure everything via the DHCP server configuration file. There is no need to change the archiso bootloader configuration, and we only get a single option in the boot menu, instead of three.
I can implement this, but I thought I'd put this up for comments first, as I didn't get a chance to do it yet.
I like it, will look good :)
When this is done, or maybe during the transition we can migrate from nfsmount and start using commands from nfs-utils, in order to get rid off klibc stuff at all.
Okay, I just tried, and I am dropping this for now, maybe I'll get motivated again soon.
1) dhcpcd is the crappiest piece of a dhcp client that exists. You cannot make it request any custom options. And if you force the dhcp server to send custom options, dhcpcd does not parse them.
The only options that dhcpcd will recognize are the standard options that are hardcoded. Everything else will be considered an "unknown option". I cannot find the words to express how stupid this behaviour is. Configurability = non-existent.
2) dhclient can deal with custom options.
However, instead of custom hooks, it has one script (dhclient-script) to deal with the setup - I cannot just write a short "hook" to deal with my custom options only.
And it gets worse: The upstream dhclient-script is based on a 13 year old script and uses ifconfig and route for everything (except ipv6, where it uses ip). Despite relying on /bin/bash and using some bash extensions, most test constructs use the stupid [ "x$foo" = "x" ] syntax to check variables, making the script hardly readable.
Fedora has an updated dhclient-script that seems to be written properly, but it uses tools that we don't seem to have on our system. (Another example of how Fedora submit their improvements upstream.)
Fixing dhcp clients and their management scripts is not what I had planned to do on a Sunday and I am stopping now before I start throwing computer parts around.
arch-releng@lists.archlinux.org