Probably in two stages.
First a small kernel/initrd is booted with PXE from dhcp+tftp
Then that one has the ability to get the iso image either via tftp, or perhaps http or ftp or some other protocol, from the machine that served the initial files over tftp
But, most ISO images are not set up to work this way, and the implication of the iVentoy site is that you can just use unmodified ISO images.
That is what I am wondering: How can you use unmodified ISO images to boot, as images, over the network? (Or can you?)
All the iPXE forum posts about this idea essentially end with "you can't do that without kernel support for reading the rest of the ISO.", so if iVentoy has solved that, I wanted to know how.
You have ISO images that usually you would write onto a CD or write to a USB drive with dd. These cannot boot by themselves if you just put the ISO file as is onto a FAT32 USB drive or similar. But Ventoy has a stage one boot thing for USB which you can then use to select an ISO file from your USB and somehow boot it.
So iVentoy would work the same way. The stage one is from iVentoy, not from the ISO itself. And that stage one does something that makes it possible to boot the ISO that it retrieved. Similar to how the USB based thing somehow can boot the ISO files from the USB.
The "something" is what I am asking about.
I saw that iVentoy seems to have an NBD server, so it might just be mounting the ISO from the server via NBD.
Overall, first impressions are looking good. Found a few bugs that need to get worked out including:
* UEFi boot requires iVentoy to have 2 vCPUs (see forums)
* Restarting the iVentoy script resets the IP Boot config (specifically the Subnet Mask and Gateway)
From their release page, iVentoy supports a bunch of Linux and Windows install images, and you can even inject custom auto-install scripts to the ISO for unattended installs. Very cool. Finally, the iVentoy discussion forum seems very active, and the developer seems engaged.
I will probably support the developer ($49) because he was able to leverage NBD to overcome some iPXE issues I struggled with for a long time. I know how much time/effort goes into making iPXE booting look seamless. Kudos to him/her/them
Then, say, the linux kernel of the vanilla ISO installer sees that shim program as a sort of virtual cdrom?
When you installed Mint, did you happen to notice from where the installer thought it was reading the files?
I booted ubuntu-22.04.2-live-server-amd64.iso and the resulting kernel command line of the installation environment has a "url" argument that points at the iventoy server URL for the iso image.
I was not able to directly boot a homegrown Debian live ISO image, so I think they just have a broad set of specific ISOs that work with iVentoy. It's not a generic "boot any ISO" solution.
I'm not totally familiar with this in the context of low-level boot.
I've used iSCSI (SCSI protocol over Ethernet), AoE (likewise, ATA) and FreeBSD has a network layer of their GEOM virtual storage stack.
A "file server" takes a local filesystem (like Ext4) and shares it to network clients. Client and server need to agree on the protocol for sharing (SMB for example), but the client need not understand the server's local, on-disk data layout. My Mac doesn't run Ext4.
A Network Block Device just serves up storage blocks, not files. Sort of the inverse of the file server, where the server need not understand the local, on-disk layout of the span of blocks it's sharing. The NBD client interprets the blocks it receives as a file system. I could install an iSCSI driver on my Mac, share a volume from a Linux iSCSI server, and format the volume with APFS. I could encrypt the volume, such that the server couldn't access the decrypted data on its disk. It just serves up "raw" blocks.
> On Linux, network block device (NBD) is a network protocol that can be used to forward a block device (typically a hard disk or partition) from one machine to a second machine.
Nice! That makes a lot of sense!