Another neat "pick an OS to boot into" tool I discovered recently is Ventoy [1]. You install the bootable menu on your USB drive, and then you just drop ISOs or IMGs on there to add choices.
I'm not sure what your issue was, but I've used ventoy across 5-ish computers and with multiple OS'es (various linux distros and win10) and never had an issue. Did you file a bug report or find out what the issue was?
Same. Ventoy has been pretty awesome for me. I like to have options for if a friend wants me to set up and show them one of the simpler distros, or if I'm at work and I need to re-install Arch (or just boot the ISO and fix the existing install). Way better than either bringing multiple thumbdrives, or having to just pick one OS to be able to have on the go, and rolling with it.
Have you tried it on different USB dongles? There are notoriously crappy no-name ones that fake their capacity or have other problems, but once in a while also legit ones can fail in strange ways: I had this branded USB key bought in a regular shop that passed all data integrity tests but refused to boot. I had bought 3 of the same model the same day and the other two worked fine, but that one would never boot, no matter which image i would flash it with; I never discovered what the problem was, and the dongle still works fine for other uses. So you may want to test other dongles to be sure.
Love Ventoy. Been using for a while now. Makes it very easy to boot a number of ISOs via simple USB drive. My go-to boot tool when doing system rescues.
"Ventoy is an open source tool to create bootable USB drive for ISO/WIM/IMG/VHD(x)/EFI files."
From the description of the project it doesn't seem running from a dedicated hard-drive partition is an actual goal of the project. I don't know that making choices which don't support a non-goal of a project are questionable.
It works great for my use case of booting from a USB drive and I very much appreciate that it exists.
I took the time to read the comments on the issue and I can't see anyone refusing to do this.
It seems like the person that suggested it can't compile ventoy as it requires a particular version of fedora.
This needs somebody to compile ventoy and make a PR.
Tabgentially it seems like the solving the issue where it needs an old version of fedora would make it easier for others to participate.
The best way of moving this forward would be to free up a block of time and either work on a PR, or if not that a PR to make ventoy compilable on more distros.
> I took the time to read the comments on the issue and I can't see anyone refusing to do this.
Personally, I see a lack of interest and a lack of desire to expand the functionality
> It seems like the person that suggested it can't compile ventoy as it requires a particular version of fedora.
Yes, that was me.
> This needs somebody to compile ventoy and make a PR.
As you may guess by how I explained the problem and the solution (with code!), I would be happy to make a PR, but I don't want to waste more time by writing code that won't be merged.
> solving the issue where it needs an old version of fedora would make it easier for others to participate
Yes, that too
But given the lack of interest by the maintainer of the low hanging fruit of making ventoy usable on partitions, even when it would bring the side benefit of respecting the block size of removable media (like thumbdrives, SD cards...) I think working on either would be a waste of time :(
> The best way of moving this forward would be to free up a block of time and either work on a PR, or if not that a PR to make ventoy compilable on more distros.
A week ago, someone started a fork for a better integration with other tools.
If you want to join in to fix the compilation issues (so that it doesn't require a specific old Fedora for example) I'll be happy to fix the partition stuff.
PXE is one of those great old technologies which always excited me. I got the opportunity very early on to build an automated system to allow developers to install fresh operating systems to test on machines in the datacenter by filling out a web form which resulted in a hands-free install the next time they rebooted the target system.
I've wanted to replicate that kind of thing at home or work ever since but with cloud tech it's just not necessary (but I hear often done by the cloud providers themselves) and at home it doesn't quite solve any real-world problems.
I’ve spent a lot of time doing that stuff at reasonable scale, now more than 20 years ago. Lot of fun!
When discovering gpxe/ipxe it got real interesting - now we could make web calls in pxe boot mode that let us automatically select os image based on asset tag from our cmdb. Role based app deployments to servers, and app streamed to clients. Those were the days… We built ci/cd not even knowing it was a thing.
When cloud started to be pushed I was like: “so pretty much what we’ve built here” (barring the promise of elastic scaling - we had barcodes preped from vendor batched to cmdb before delivery though). I wasn’t yet aware that most places didn’t use software to manage compute, end to end.
The real world home usage for me is being able to install Linux or BSD without needing to manually download and image and burn it to a USB drive (in fact the reason I set up PXE booting in the first place was because I kept losing USB drives and thus wouldn’t have anything to boot from).
I was looking into netboot.xyz recently, as I do Raspberry Pi development. I'd love to be able to just run a VM that lets me load a few different Raspberry Pi OS images and choose which one I want the Pi to boot into on next reboot. netboot.xyz seemed promising, but I couldn't figure out how to use it.
The docs don't explain much.[0] I tried running the Docker container and couldn't figure out what to do with it. I didn't see a way of uploading new images to it, and I didn't know how to refer to the netboot.xyz container as a PXE target.
Has anyone found a good guide on how to use netboot.xyz? Is netboot.xyz capable of doing what I want? (i.e., I load different Raspberry Pi OS images onto netboot.xyz in a VM/Docker container, and then I point my Pi to network boot from the netboot.xyz server, and netboot.xyz serves the Pi the OS image I want). The Pi natively supports network booting[1], but I don't know if I'm putting the right pieces together.
Throw a copy of iPXE on USB, then chainload it. Super easy. If you're using virtualization then there might be a chance iPXE is already used, in which case it's super easy. Not sure if that changes much with Pis though, as they tend to be a different beast.
That's why a serious user sets up their own server, serves the images that they have selected and checked, and doesn't serve outside of their known netspace.
I did that for a while but keeping images up to date was a chore I’d often forget to do then regret not doing once I needed it. Sure I could probably automate it with a little effort but instead I switched to this service and have been running with it for a few years now without any issues.
While I know there is a risk involved, pragmatically that risk is very low given I’m just an anonymous individual very occasionally using this for personal devices.
You can actually run this service locally though. I did contemplate running their Docker container on my home server. However I use it so infrequently that even running their Docker container locally felt like an unnecessary additional piece of work.
I've found it convenient (once setup...) to run internal package mirrors.
These with even relatively dated 'netinstall' media can provide you with current installations. Then provide you with super fast updates.
I'm more familiar with doing this with RPM based distributions -- CentOS, Fedora, etc. It's basically a web server and rsync behind a [parameterized] systemd timer so you can centrally control existing/new mirrors
The results can admittedly be a little funny. If the netinstall is so far behind that RPM doesn't know what to do with the new packages, then yea - time to get a new one :)
That was the issue for me though. It would often be years between usages since the only time I needed it was when a computer stopped booting or I was repurposing a device. Neither being things that happens very often.
The risk wouldn't be someone deliberately targetting you: the risk would be someone deciding that this is an excellent vector to gain backdoor root access on many random machines.
I wasn’t suggesting I would be personally targetted. I was stating that the infrequency and low criticality of my usage vastly narrows the risk of getting exposed to the attack.
Hence my point that if I were using this regularly then I might want to invest in a more secure mirror. But when it can be years between my usages the benefits of self hosting are vastly outweighed but the cost (both in time and electricity) of managing it. Thus I’m willing to take that slight risk in this specific instance.
> people agitate against `curl blah.xyz | sh` for a reason.
What’s the reason, exactly?
If you’re principled about only ever installing anything from vetted repos, then sure, your position is at least consistent. But my experience is that people who are appalled by pipe-to-sh are for whatever reason much less appalled by downloading random binaries or .deb files from blah.xyz and running them manually, which seems like just a more labor-intensive version of the same thing.
I replaced our legacy PXE boot environment with Netboot, and it made a huge difference. The performance speed from tftp to http is night and day. Plus, you can compile a custom boot image to provide the exact boot environment you need.
Cloud services do this to provision hypervisors and other infrastructure, the vms effectively do similar post boot. If you architect your management network well transport security should not be an issue.
The ‘piping curl into bash is dangerous’ meme is silly unless you’re actively reviewing shell scripts prior to execution. It’s no different to a git clone, pip install or npm update.
This project looks neat. I boot well over 10,000 blade computers that don't have onboard storage, with iPXE. Kind of amazing technology. Had to develop our own super minimal Ubuntu distro though. Used a hacked up version of debirf to do it. Not sure this project offers what I need, which is a less hacked up version of debirf.
There used to be a tool called, IIRC, "firebreather" that was a multicast image broadcaster for booting clusters of systems. I did a search and couldn't find any reference to it now. An associate used it to boot hundreds or thousands of systems back in the early 2000s, it would take a minute or two.
Basically: The systems would PXE boot the bootloader (or maybe it was burned locally to the boot ROM or similar, I don't recall). Then firebreather would spray the kernels and associated boot data over multicast to all the machines at once. Any that were lagging behind or missed packets, would catch them the next time around, firebreather would spray the images a few times or something.
That's really cool. Luckily, our datacenters where these machines are all Tier 3, so the full reboot doesn't happen very often. We've only had to shut down a lot of racks once for some power management issues. It was a bit of a struggle, but things eventually booted.
The bigger issue that we faced was that dnsmasq couldn't keep up with all the UDP packets and we had to switch to Kea kind of mid-flight, which was a bit of work since it was a weekend (of course things fail on friday night) and restarting everything to get new leases (and a few with duplicate IPs) was a bit of nail biting. It all sorted itself out though and we haven't had any more issues on that front.
That sounds a bit like UDP multicast. One of those tragically under used features of the networking stack. Ripe for abuse were it exposed on the open Internet certainly, but still very cool.
Why Ubuntu? Mostly because it just makes packaging and compatibility easier. There is a plugin system which creates tarballs out of overlays... so you can add additional software into the system and the building of the tarballs can include things like apt install. These tarballs get downloaded and installed early on by a hacked init script. This way, we can do things like install minimized downloads of GPU drivers.
There are some issues with this, but overall it works ok. For now, it is just what I ended up with. Total boot download is about 100megs, which isn't too bad... machine is up and running in 60s, which is fine for this workload right now. It does suck rebooting the whole datacenter at once though. ;-)
The lbu stuff looks interesting for sure. I'm not a huge fan of the additional NFS requirement, but I assume that can be worked around. That said, I'm open to changing stuff up and optimizing things further. This is some esoteric stuff and we are hiring. =)
My side project for the last while was pretty similar to what you're describing, and as a result I've become very familiar with this "esoteric stuff". If you're hiring, I'm interested :)
I didn’t use PXE to boot diskless machines, but I do find it great for remote maintenance. I’ve used it for rebuilding servers remotely from a boot image with only a very limited KVM. Serving boot media over PXE was a life saver. Honestly, I’ll be keeping a PXE server (with an HTTP server for images) on all my future clusters. It’s just that useful, especially for disaster recovery.
I've wondered for some time why none of the major OEMs have built this. Surely if I could embed an iPXE module into my board's BIOS with HTTPS support and a custom boot server that chainloads all of it logic from the internet, including a plethora of hardware support tools.
They could even tie the availability of premium internet-booted tools to the service tag and get that sweet SaaS subscription money.
Dell machines do this, if you boot to SupportAssist you can wipe and reload the drive from the BIOS, it'll download Windows for you. It even lets you log into your Microsoft account to get your BitLocker recovery key and restore all your files from your dead partition.
I only know this because once every two weeks my corporate Dell laptop will BSOD, forget that it has a hard drive, and then continuously try to boot over HTTPS until I enter UEFI setup and fiddle with boot device order.
Its just for clean installs, but at work I can PXE boot a system and use a MS tool called Lite Touch to install Windows plus many software packages. It works pretty well. I can also PXE boot into some other operating systems and get my domain home directory. I should say, we're not using this project, but its the same concept.
Am I missing something or is there no documentation about what their distro/hardware support matrix looks like? Do I have to just boot into it and navigate the menus to figure that out?
There is ARM support as well in addition to i686/x86-64. Operating system versions are typically dropped as they go EOL upstream from the menu, we try and keep the menus up to date as changes and new versions are released.
~Given that it's already there (and presumably maintained) in the github readme, it might make sense to also provide this info on the docs site.~ Nevermind, I'd found the github link first, not sure how I missed it on the site.
What's the state of arm64 booting like? Last I looked at early boot process on arm (which was admittedly a while ago) it was kind of a mess w/o a broadly adopted standard like uefi and every processor/soc/board kind of did its own thing. Has that improved to the point where I can expect _any_ arm64 board to just work? Or do I need to worry about the specific hardware, too?
Arm booting is unfortunately still a mess, but at least for server-class machines there's been some adoption of SBSA/SBBR (https://en.wikipedia.org/wiki/Server_Base_System_Architectur...). Of course server-class machines are not the same as the cheap tat that everyone buys. You can install SBSA/SBBR-compliant firmware for your Raspberry Pi 4 (https://github.com/pftf) but it's not the default.
Most of my testing was just allocating an ARM machine on Equinix Metal as I didn't have much ARM hardware to test or qualify on. I've also gotten the bootloader and menu to work with an RPI4 but loading operating systems on one was a bit more challenging given reduced memory on the hardware.
We are definitely willing to add NetBSD if someone can demonstrate it working well with iPXE. It's come up several times and it's implementation works with pxelinux in a local setting but not so well with iPXE as the implementation linked looks for a specific file on a tftp source.
[1] https://ventoy.net/en/index.html