Netboot.xyz: your favorite operating systems in one place
netboot.xyz
netboot.xyz
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.
This "goal" would require a grand total of 2 changes.
> It works great for my use case of booting from a USB drive and I very much appreciate that it exists.
It's just like grubfm - a few files + a heuristic to use these with isos to make them bootable.
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.
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.
My email is my nickname at outlook dot com
I spent some trying to boot from it, couldn't get it work. Couldnt find any help anywhere, so went back to the old boring tools that just work.
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.
So when I wanted a clean slate, I would:
- turn on laptop
- reboot client machine
- make a coffee (or two)
- there is no step four.
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.
This is actually how we were booting our linux cluster nodes for the ATLAS project for the LHC while I worked at a physics lab.
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.
[0] https://netboot.xyz/docs/quick-start
[1] https://www.raspberrypi.com/documentation/computers/raspberr...
I mean, people agitate against `curl blah.xyz | sh` for a reason.
And this, by any measure, is much worse. Also: 'By default iPXE does not compile in HTTPS support'
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.
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 :)
I moved and I've been hard pressed to bother booting everything up and checking on it, and I have quite a lot of devices to manage
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.
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.
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.
https://github.com/OpenNetworkingFoundation/ipxe-build/blob/...
(link is to a repo I worked on that uses Docker to build iPXE with various options enabled, and also embed mTLS certs)
Alpine with lbu[0] seems like a perfect fit and looks IMHO less experimental. Also you can provide backups straight via iPXE[1].
Nonetheless, kudos for the slim ubuntu image :)
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. =)
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.
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.
They could even tie the availability of premium internet-booted tools to the service tag and get that sweet SaaS subscription money.
However they don't list the versions of each OS.
As for hardware support, I guess it's i686/x86-64 only?
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?
Seems like it would benefit both parties.
https://wiki.netbsd.org/tutorials/how_to_install__40__boot__...
I've done this successfully (locally).
I haven’t needed to do recovery disks, boot drives, rescue operations etc in so long. Back then it felt like I’d need to every few weeks.