> How is the ISO image presented to the booting machine via the network?

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

Yes, that is how you would do it if you are rolling your own boot setup.

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.

The situation is not all that different from their other tool for having multiple ISOs on a usb drive though, is it?

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.

> does something that makes it possible to boot the ISO

The "something" is what I am asking about.

>either via tftp, or perhaps http or tftp

I saw that iVentoy seems to have an NBD server, so it might just be mounting the ISO from the server via NBD.

Indeed, it seems iVentoy uses NBD to present block storage devices (eg: ISOs) to the DHCP client. I just installed iVentoy 1.0.08 in my lab on a Debian 12 VM (via VMware 8 server). From there, I created a new VM and booted Linux Mint 21.1 via UEFI boot. Linux Mint install went well with no noticeable issues.

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

So, it loads some kind of shim that presents as a BIOS optical drive, but reads its data via NBD?

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?

It seems to be hot-patching the image to redirect the kernel command line to boot from the iventoy server.

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.

NBD = "Network Block Device"

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.

NBD is fairly similar to AoE or iSCSI, you can connect to an NBD and then format it, as you suggest doing with iSCSI and APFS. One use case people were doing a lot at one time is doing RAID-1 with a local partition and a remote partition over NBD in HA clusters.

Hadn’t heard about NBD before.

> 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!

https://en.wikipedia.org/wiki/Network_block_device