Ventoy is very handy for running things live though, and not all installers/situations are affected by this (and there they are, it isn't really ventoy's fault).
I tried to set up netboot a few times, it seems like this should be very easy to do, especially that I self host many things, but I get lost in the technical details every time. I think I succeeded once, with the dhcp server running on a laptop running Debian…
Turns out doing some speleology to find a USB key and burning an ISO on it using cat or pv ends up being radically easier…
(OTOH it's been a while since I last tried and now I have root on my router running OpenWrt so I guess it would be a tad easier…)
For what it's worth, there is a Ventoy for that, too.
That used to be the only way to install Linux on apple hardware (think original iMacs here). You could likely find some archived docs there.
next-server 192.0.2.11;
if exists user-class and option user-class = "iPXE" {
option ipxe.no-pxedhcp 1;
filename "http://192.0.2.11/tftpboot/menu.ipxe";
} else {
if option client-arch = 00:06 {
filename "ipxe.efi-i386";
} else if option client-arch = 00:07 {
filename "ipxe.efi-x86_64";
} else {
filename "undionly.kpxe";
}
}
(use your addresses instead of rfc 5737 addresses). Note that the client-arch for amd64/x86_64 matches what PXE clients actually use instead of what the rfc 4578 says (there's an errata, but rfc policy is not to incorporate corrections sigh ). If you've got other archs, you can probably figure it out.You've got to run a tftp server on the next server address; and just FYI some PXE clients won't reach outside their subnet to get to the tftp server. Grab the ipxe binaries from wherever is convenient and they live in the root of the tftpserver.
You can follow the ipxe docs for what to put in your menu file. I've got a menu of weird things, which includes item --key n netboot netboot.xyz [n]
:netboot
chain --autofree http://boot.netboot.xyz/
goto main_menu
You could probably just use the boot.netboot.xyz in your dhcpd config and then you don't have to write a menu at all.Depending on your client machines, expect to have to fiddle around a bit. I've got some machines where PXE works, but the keyboard won't work in PXE, so that's not super useful. Others where PXE doesn't really work in UEFI mode, only in BIOS mode; there's probably some vice versa. Also, I've never figured out a good way to load ISOs in UEFI mode ... in BIOS mode you can use MEMDISK and if the OS supports it, it can find the disk image in memory and mount it when it boots. The netboot people do a good job of finding ways to make things work, but don't expect everything to work.
I originally started from some version of this document [2], but I've moved on since then. IMHO, netbooting is a nice way to run hobby OSes... no need to worry about a boot loader and all that, just build for multiboot and ipxe will work (and grub will work, too, if you ever do want to run off a disk)
It's possible to get Windows ISOs to boot with PXE, but it takes a lot more patience than I've got to make it work well ... if I use iscsi, the OS loads, but takes several minutes to get the disk image mounted after the installer starts; it would probably be faster to write the image to a usb disk and run from there. I was able to install to an iscsi drive, but then the same problem with mounting happened when I tried to boot from there, and then you just end up at a stop error screen because the OS really does want a mounted filesystem when it starts. (there's something about tweaking the driver setup, but that's too much work for me, I found a drive to run off of, and did what I needed to do)
[1] https://ipxe.org/howto/dhcpd
[2] https://wiki.debian.org/PXEBootInstall?action=show&redirect=...
I've had this since about 2014.
I mainly had this issue with the default Windows install image names.
Fragmentation can be a bit annoying, especially when using exFAT, which doesn't appear to have defragmentation tools available. It can be avoided by never deleting files and instead reformatting every so often.
That being said, it's still a fantastic tool because all the images "just work" everywhere a class-compliant USB optical drive would.
The cynical take is that what's on display in this issue is feigned ignorance/incompetence constructing plausible deniability.
Their security posture has not evolved with the times, the threat-landscape, and the growth of the project.
[0]: Very doubtful if you have been following this saga or dig around enough
This is the first I'm hearing of any of this drama. Any links to relevant information indicating that the maintainer is being disingenuous?
https://nixsanctuary.com/ventoy-718-shades-of-open-source/
https://news.ycombinator.com/item?id=40689629 (See also: Sus behavior from Deepin which recently got the project removed from Suse)
It just works really well.
I'm not willing to trust it.
Paraphrasing, but things like: "Ah well, some blobs are ok, it is just for convenience" just smells like trouble.
The project is free and all, but damn. Has nobody, in the last half a decade, thought about automagically building those blobs alongside the project?
In my brain you're just postponing a large build system refactor, one that will get worse over time.
As far as I am aware, BLOB is an acronym for "Binary Large Object" [1], but it is part of the pun that, as you wrote, a blob is (also) an amorphous ball of goop.
[1] At least according to the German Wikipedia: https://de.wikipedia.org/wiki/Binary_Large_Object
https://web.archive.org/web/20231108173312/https://www.ibpho...
At least this acronym took on a life of its own: we now also have CLOBs (which correspond to no English word that I am aware of): https://en.wikipedia.org/wiki/Character_large_object
verb: informal hit (someone) hard. treat or deal with harshly. defeat heavily.
Noun: British slang for Clothes, circa 1879
The Fantastic Four's The Thing's catchphrase, "It's clobberin' time!" was the only "clob" I was aware of prior to doing these searches.
Or if you don't like blobs but do like recursive acronyms: Bloody Large Odious BLOB.
And because Windows don’t allow direct access to the physical layer from a user-space shell.
Such a waste.
It's also possible to use the usb stick for regular files, Ventoy will just ignore them. Pretty useful when you need it.