1

On my home LAN, I have

  • A router/switch which is also a DHCP server
  • A desktop
  • A (really really old) laptop, which won't even boot from USB

I want to use PXE to install a (32-bit) Linux distro on that laptop.

I have two problems (that I know of):

  1. The pages I see discuss doing this (e.g. this question here on the site) all say I need to setup a DHCP server on my machine... which is fine, except that there's already that other DHCP server. Won't the laptop prefer the other server?

  2. Will any bootable 32-bit ISO work?

  3. How do I know which files from the distro's mounted ISO to copy where?

Note: To be more specific, I'll try to install Linux Lite.

einpoklum
  • 8,772
  • 19
  • 65
  • 129
  • Regarding (1), if there are two DHCP servers that provide IP addresses to the Laptop, either of them may be used. Solution: Remove the Laptop from the router's configuration. (2) There are bound to be ISO files that don't work, e.g. if installation requires more RAM than the Laptop has. (3) since LiteOS is based on Ubuntu, I'd find Ubuntu instructions. – berndbausch May 02 '21 at 22:54
  • It might be easier to take out the drive out and connect it to your desktop using an adaptor (IDE-to-USB / IDE-to-SATA if necessary) and install the OS from there. – Freddy May 03 '21 at 06:22
  • @berndbausch re: multiple DHCP servers on the same LAN segment: The only valid answer is **don't do that** (unless they're both configured identically), otherwise you **will** break the network (and bring the wrath of the network admins down upon you if it's not your network). For this question, if instructions say "install a DHCP server" and you already have one on the network, then use the existing DCHP server - modifying the config if required. – cas May 03 '21 at 08:19
  • @cas Thanks for preventing bad practices. My guess is that OP's router is more difficult to configure and less flexible than a Linux-based DHCP server. Setting up a separate DHCP server for this specific task should be acceptable if you have full control over both servers. – berndbausch May 03 '21 at 08:22
  • @Freddy: That's an interesting suggestion actually! – einpoklum May 03 '21 at 10:05
  • @cas: I doubt I can make my router's server serve TFTP-related info. But I'll try. – einpoklum May 03 '21 at 10:05
  • If the router's dhcp daemon is primitive (or has a brain-damaged GUI/web config that doesn't expose its full capabilities) then it's still better to have only one dhcp daemon. It is **never** a good idea to have multiple DHCP servers on a LAN segment if they don't have the same configuration - they can give out conflicting responses and only luck/timing decides which gets used by the client. Disable the one in the router, and install a dhcp daemon on a linux box (which then has to run 24/7, or at least be up and running whenever client machines need to get/renew a lease). – cas May 03 '21 at 10:39

1 Answers1

3

Note that Linux Lite's own documentation suggests using the PLoP Boot Manager if boot from USB is not available: PLoP is a boot manager that can be booted from CD or even from a floppy disk, and it includes built-in basic USB storage support.

https://www.plop.at/en/bootmanager/download.html

https://www.howtogeek.com/howto/16822/boot-from-a-usb-drive-even-if-your-BIOS-wont-let-you/

I've once used it to start an USB-based installation on an old system that had no USB support in BIOS.

But if you want to use PXE, the overall sequence of events in PXE booting is as follows:

  1. The PXE BIOS extension (or UEFI firmware's built-in network driver in modern systems) activates the network card, and makes a DHCP request with a few special identifiers added:

    • The vendor-class-identifier (PXE option #60) is set to a string that begins with the word PXEClient and includes a code that identifies the processor architecture used. This can optionally be used to provide tailored PXE boot solutions for different client types, but in simple setups the DHCP server can just ignore this.
    • The DHCP request will indicate that the client wants to know the values for DHCP options #66 and #67: the TFTP server name and the name of a boot file that the client should load, respectively.

  2. The DHCP server has actually two ways of supplying the TFTP server name and the name of the boot file: it can either use the above-mentioned DHCP options, or since DHCP can be backwards compatible with BootP, it can use the old BootP fields next-server and bootfile-name in a DHCP packet to supply the information.

(Some PXE BIOS extensions may be buggy and support only one or the other. I've seen a PXE firmware that added an extra zero byte to the boot filename if the DHCP option #67 was used, but worked correctly using the BootP legacy style. Troubleshooting things like this may require using Wireshark or tcpdump to view the actual DHCP and TFTP requests and responses to puzzle out what is going wrong.)

  1. The PXE BIOS extension will configure the network interface using the DHCP response, download the specified file from the specified TFTP server, and execute that file. In principle, anything that happens after that is fully controlled by the program code in that file (the PXE bootloader). In practice, the two most common PXE bootloaders in Linux circles these days will probably be either PXELINUX of the SYSLINUX family, or iPXE. Both of those will essentially start over the network configuration and make another DHCP request with a different special identifier. This allows the DHCP server to use another DHCP option to tell the PXE bootloader where to load the bootloader configuration file.

    • for PXELINUX this is optional: if there are no extra options, it will attempt to download its configuration from the same TFTP server the bootloader itself was loaded from. For example, if the TFTP path to download PXELINUX was /pxe/pxelinux.0, then it will attempt to download its configuration from /pxe/pxelinux.cfg/default.
    • for iPXE, specifying the name of the configuration file using DHCP options is mandatory, but iPXE has built-in support for HTTP, so it can accept a regular HTTP URL as a DHCP option value.

  2. The bootloader configuration file may include a definition for a nice boot menu, or simply tell the bootloader to load a particular Linux kernel and an initrd/initramfs file for it. This works just like regular GRUB, except the loading happens over the network instead of from disk. The bootloader configuration file may include boot options for the Linux kernel, just like GRUB's configuration. In network installation scenarios, you'll usually need to use a boot option to specify where the installer should find the ISO image or its contents: the value for this option usually takes the form of a HTTP URL in modern distributions.

  3. Once the PXE bootloader has successfully loaded the kernel and the initramfs file to the client system's RAM, its job is done: it starts the Linux kernel and hands the initramfs contents and any kernel boot options to it, and then the bootloader gets overwritten as the kernel transitions the system out of 16-bit compatibility mode into true 32-bit protected mode and rearranges the virtual memory map to suit its own needs. The Linux NIC driver will reset the network adapter as the driver starts up, so the IP address configuration is typically just lost. (A modern UEFI system would start already in 64-bit protected mode, but UEFI has its own complications in Secure Boot.)

  4. In most distributions that offer network-based installation, the initramfs includes its own DHCP client, so the boot scripts will just make a DHCP request (yet again) to get the network address parameters. Then the first part of the installer within the initramfs starts up, connects to the URL specified by the kernel boot parameters to download more parts of itself, and eventually begins the OS installation process.

So for your questions:

1.) If your router's DHCP server can be configured to provide the necessary DHCP option values to the client, you don't need a second DHCP server. You're correct in that having two uncoordinated DHCP servers in the same network will make things random and complicated.

2.) The installer within the ISO will need to support network-based installations.

3.) Basically, you need to find two files: a kernel file and an initramfs file. The most common 32-bit Linux bootloader on ISO images is probably ISOLINUX of the SYSLINUX family: you could just read the isolinux.cfg or syslinux.cfg configuration file, find the paths of the kernel and initramfs files and any necessary boot options, and copy them into the configuration of your network bootloader of choice. Some distributions offer a separate kernel+initramfs set dedicated for network booting: look at the contents of the ISO for directories named images/netboot or similar.

Since you'll specify the TFTP pathnames that will be used to fetch those files, you can place them basically anywhere you like. But you might want to keep things simple and just place them on whichever directory is the default "TFTP root directory" of your TFTP server of choice.

Once you've tackled the part of passing the right kernel and initramfs files to the client, you'll just need to find out how to provide the rest of the ISO contents. Usually that is just a matter of putting either the ISO or its extracted contents (or a loop-mounted ISO image) to any convenient location on a web server, and adding a kernel boot option that specifies an URL of the ISO into the PXE bootloader configuration.

  • For a modern RHEL/CentOS/Fedora and clones, the required kernel boot options will be something like ip=dhcp inst.stage2=http://some.www.server/root/of/ISO
  • Debian/Ubuntu will have enough functionality in their installer initramfs to contact the distribution's repository servers (like deb.debian.org) directly, so if outgoing connections are allowed, you might not need the full ISO at all.
telcoM
  • 87,318
  • 3
  • 112
  • 232