be0ba 2023-03-11
Introduction
9front (and Plan 9) is a wonderful operating system, built and designed to run in any size cluster. To facilitate this, Plan 9 has always been able to network boot. These days, this is done using the PXE option ROM present in even the lowest priced consumer network adapters.
NVRAM
One thing that has always been an annoyance to me in a network booting scenario is the requirement for some form of NVRAM. In some systems, NVRAM is provided by actual hardware based storage attached to the motherboard. The vast majority of modern hardware (e.g. amd64/x86_64-based systems) do not have any such support. Plan 9 makes up for this by using a (usually) 1 sector subpartition on the local disk drive.
This NVRAM data is needed only for network boot…
be0ba 2023-03-11
Introduction
9front (and Plan 9) is a wonderful operating system, built and designed to run in any size cluster. To facilitate this, Plan 9 has always been able to network boot. These days, this is done using the PXE option ROM present in even the lowest priced consumer network adapters.
NVRAM
One thing that has always been an annoyance to me in a network booting scenario is the requirement for some form of NVRAM. In some systems, NVRAM is provided by actual hardware based storage attached to the motherboard. The vast majority of modern hardware (e.g. amd64/x86_64-based systems) do not have any such support. Plan 9 makes up for this by using a (usually) 1 sector subpartition on the local disk drive.
This NVRAM data is needed only for network booting of CPU and FS servers; terminals go through a standard login process. If you don’t have that data, you must type it in at each and every boot. This is not an issue if you only have a one or two servers, but if you have more, this quickly becomes a very tedious and annoying process.
ATA-over-Ethernet
One of the many features that the majority of people using Plan 9 never use is the built-in support for ATA-over-Ethernet. AoE is a predecessor to iSCSI that has fallen out of wide use elsewhere, due to certain constraints. AoE has no security support, and uses raw Ethernet frames to transmit data, so it cannot be routed like iSCSI.
Danger Ahead
Using AoE, one of your servers can provide the NVRAM it uses itself to any other server. As mentioned above, there is NO SECURITY possible with AoE. Any device that can connect to the Ethernet segment that the AoE server is present on can access the AoE device.
The Actual Setup
The overall setup for this consists of only a handful of lines in two strategic places:
/cfg/$sysname/cpurc:
#!/bin/rc
...
disk/vblade -r -e '#l0/ether0' -a 1.1 /dev/sdC0/nvram &
/cfg/pxe/$server_macaddr:
...
aoeif=ether0
aoedev=e!#æ/aoe/1.1
nvram=#S/sde0/data
I recommend you read the vblade(8), aoe(3), and sdaoe(3) man pages so you are familiar with the overall invocations, but there is not much going on here.
The options used:
disk/vblade:
-r: raw mode. Do not use a configuration header. (You don't want to overwrite the NVRAM).
-e: Ethernet link to use.
-a: AoE shelf and slot to use.
/dev/sdC0/nvram: location of the disk-based NVRAM to use. This is probably
different for you.
plan9.ini:
aoeif: interface to rx/tx AoE on.
aoedev: device node to create in /dev.
nvram: specify location of NVRAM.
That’s truly all there is to this. It’s a very simple setup, and seems to work quite well. It still isn’t a good idea, but if you insist, well… I can’t stop you.