Hello Rob,
Am 17.02.2025 um 18:17 schrieb Rob Berendt <robertowenberendt@xxxxxxxxx>:
Perhaps I misunderstood something about tftp
I know tftp mainly as a very lightweight protocol for bootstrapping "things" in an automatic way.
It knows no ls, no authentication, just get and put in binary mode, uses udp instead of tcp, and needs very little memory.
Its primary purpose was — and still is — bootstrapping machines from the network from ROM:
- Machine ROM routines initializes Ethernet NIC, and starts a minimal TCP/IP stack
- TCP/IP sends out a DHCP request for IP address
- DHCP server tells the machine its according IP configuration, and a "next server" information: IP address, path and file(s) to load and run
- tftp client in the ROM contacts the tftp server, loads and launches a simple scrollbar-menu so the user can actually pick from multiple options
- further code for booting the machine according to user choice is loaded by tftp. For Linux based setups, this is the kernel, and initrd containing hardware drivers, as well as command line parameters for the kernel obtained through the simple menu from above
- After loading, the kernel is launched, initializes hardware, and (again) requests an IP address through a kernel integrated DHCP client
- Kernel tries to contacts an NFS server according to parameters from the menu system with a root file system in an image file, opens and mounts it, and gives control to the upper layer OS in the root: You can watch Linux boot on console.
This is my primary recovery plan for PC style hardware when hardware goes up in smoke, and I need to restore from backup. The Linux root on NFS is tailored to contain the most important packages so I can just partition any disks, create RAID volumes, create file systems, mount them, restore from backups on the backup server, write the boot block (or add an UEFI boot entry), and am ready to rock again. Always presuming that the initial hardware damage is resolved.
In early times, the described combo was also used for actually netbooting clients. Sun Microsystems sold diskless systems in their early days, because disks were expensive. In universities, there were often a bunch of cheaper Sun based "X terminals" booting over the network from a big server machine, mounting /usr from that server machine, hence sharing a common pool of user binaries. Editor, mail client, etc. On the following logon-screen users actually logged on to the central big machine, while the x terminal was just displaying the graphical output from the applications running on the big server, transferred over the network.
I presume, IBM i is not much different. There is a central binary blob which the machine loads by tftp and subsequently executes. I have no further details about the precise process, though.
Also, earlier Cisco gear probed for an IP address and tried to load a configuration file named after their MAC address by tftp, when network connectivity at power on was available, and no local configuration was found.
:wq! PoC
midrange.com
