[HN Gopher] Netboot.xyz: your favorite operating systems in one ...
___________________________________________________________________
Netboot.xyz: your favorite operating systems in one place
Author : thunderbong
Score : 162 points
Date : 2024-08-19 19:19 UTC (3 hours ago)
(HTM) web link (netboot.xyz)
(TXT) w3m dump (netboot.xyz)
| maccam912 wrote:
| Since I won't get a better chance to find knowledgeable people:
| How exactly does iPXE work? Lets say I want to boot a random old
| PC from one of these images - does the bios need to have iPXE
| support? Or PXE? Or does it need to first boot into some local
| system first, which then goes out and gets the image to boot the
| rest of the way from?
|
| Then there's mention of DHCP and self hosting. Do I need to have
| some service running within my LAN first or can this go right out
| to some public server and boot from images there? How does DHCP
| factor in? I am in so far over my head on this but it seems
| interesting and something fun to try out.
| bongodongobob wrote:
| Read the docs, it's all there.
|
| Edit: Seriously? You click on docs and almost all of those
| questions are answered. It's 1 click away. Parent didn't even
| try.
| LoganDark wrote:
| Which docs? The netboot.xyz ones?
| bongodongobob wrote:
| Yes. It's one click away for the overview and the quick
| start is very good as well.
| notanormalnerd wrote:
| I found the netboot docs very hard to understand if you dont
| have a existing knowledge of PXE.
| teraflop wrote:
| There are a bunch of different options to "bootstrap" iPXE in
| the first place. Least invasive is probably to boot it from a
| USB drive. You can also set up a traditional PXE boot process
| using DHCP/TFTP on your network to "chain-load" iPXE (if your
| client's network card supports PXE), or you can even flash iPXE
| into the boot ROM on certain network cards.
|
| However you do it, once iPXE starts running, it will take
| control of the NIC and fetch the actual OS images that it needs
| from the internet over HTTP.
| Joe_Cool wrote:
| Some HP server UEFIs also support boot from http. So you can
| boot the .efi executable directly from the internet. For
| https you need to enroll the certificate first and it's a bit
| more involved.
|
| I am sure there are other implementations I have only seen it
| on HP servers so far.
| hmaxwell wrote:
| You can use netboot.xyz from a flash drive to boot various
| operating systems and utilities. Alternatively, PXE (Preboot
| Execution Environment) has been around for a while and works by
| allowing a network-capable device to boot from its network
| interface. A PXE-compatible network card requests a DHCP lease
| during the boot process, which provides the IP address of a
| TFTP (Trivial File Transfer Protocol) server and the file that
| needs to be loaded from the server.
|
| Typically, the network card contains a basic PXE kernel. To
| enhance this environment, you can chainload iPXE, which offers
| a broader range of features. iPXE allows for more advanced
| booting options, such as loading scripts or initiating an
| unattended installation directly from the network.
| mynameisvlad wrote:
| There's multiple ways to boot, including USB/ISO:
| https://netboot.xyz/docs/category/booting-methods
|
| Generally speaking, if you have iPXE already compiled and
| flashed onto your NIC, then you can follow these instructions:
| https://netboot.xyz/docs/booting/ipxe
|
| DHCP is only needed for getting an IP address. You can use the
| Docker image with the proper DHCP parameters to load it
| automatically when using PXE/iPXE:
| https://netboot.xyz/docs/docker
| breppp wrote:
| Roughly from memory iPXE is a bootable image that acts similar
| to a PXE BIOS, so you boot to that image like a regular disk.
| It acts like a bios by for example hooking your interrupts for
| storage reads.
|
| In order to find where the image is, you need some kind of
| discovery mechanism. This is where DHCP comes in. Remember this
| is all happening before you have an OS, so it has to be very
| bare bones
| NobodyNada wrote:
| PXE [0] is a standard for netbooting, typically implementated
| in the system's boot firmware. A PXE-compatible client sends a
| DHCP request on boot, to which the network's DHCP server
| responds with the IP address of a server to netboot from. The
| client will then connect to this server via TFTP, download an
| executable image file in the PXE format, and boot it. Using PXE
| on your own computer requires enabling PXE the firmware setup,
| setting up a TFTP server to serve the PXE image, and
| configuring your DHCP server to point to your TFTP server.
|
| iPXE [1] is an open-source implementation of PXE, and much more
| -- it's much more flexible, it supports additional protocols
| including HTTP(S) and DNS, it has configuration and scripting
| options, a basic command-line interface, etc. In order to run
| iPXE, you need to boot an iPXE image somehow -- e.g. from a MBR
| or EFI image on a disk drive or USB drive (or even over PXE, I
| guess). But because iPXE supports more protocols and more
| configuration, you don't need to set up TFTP and DHCP, and it
| can chainload into e.g. an EFI image or a Linux kernel instead
| of being limited to booting images in the PXE format.
|
| An example of iPXE in the wild is the Arch Linux netboot image
| [2]. They provide pre-configured iPXE images that display an
| interactive menu to select a mirror, download the Arch Linux
| installer, and boot it. (It's really convenient since you can
| just drop the UEFI image at "/efi/boot/bootx64.efi" on a FAT32
| thumb drive instead of having to download the whole installer
| image and 'dd' it onto the drive.)
|
| The submitted project, netboot.xyz, is a similar idea: a
| preconfigured build of iPXE that lets you interactively
| download and boot installers for many popular operating systems
| from a single image.
|
| [0]:
| https://en.wikipedia.org/wiki/Preboot_Execution_Environment
|
| [1]: https://ipxe.org/
|
| [2]: https://archlinux.org/releng/netboot/
| ddulaney wrote:
| > or even over PXE, I guess
|
| This is super common actually! Most built-in PXE only
| supports TFTP, which is pretty slow compared to TCP-based
| stuff. It can make sense to use the built-in PXE to grab a
| (small) iPXE image over TFTP, then have iPXE grab the (big)
| real image over HTTP(S). This is also useful if you want to
| store your main image on something like S3 that doesn't
| support TFTP.
|
| For a while I had a script that would create iPXE images
| dynamically on the fly with the correct HTTPS URL and auth
| information embedded in them.
| throw0101d wrote:
| > _A PXE-compatible client sends a DHCP request on boot, to
| which the network 's DHCP server responds with the IP address
| of a server to netboot from._
|
| Specifically there are particular DHCP options (66, 67) that
| tell the client about this, and the client software (PXE)
| understands them:
|
| * https://datatracker.ietf.org/doc/html/rfc2132
|
| * https://www.iana.org/assignments/bootp-dhcp-
| parameters/bootp...
|
| * https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-p
| a... (RFC 5970)
|
| And while the options previously were interpreted for TFTP
| use, newer PXE software now understands the use of
| "http[s]://" in the file name and use that instead of TFTP.
| gsich wrote:
| You usually chainload from normal PXE if you have hardware.
| anon291 wrote:
| So what I do here is that I have a local PXE server (it's a
| DHCP option on your router) that serves up iPXE with a
| preconfigured script to boot via HTTP off of netboot.xyz. So
| whenever I want to install linux on a new computer, I set the
| BIOS boot option to boot from PXE next boot and restart. In a
| few seconds, I am presented with my choice of linux
| environment.
|
| For my data center servers, I have it booting via PXE to an
| iPXE with a custom script to take a unique identifier from the
| host and build the corresponding configuration (NixOS). So
| essentially for that I define my NixOS configuration in a NixOS
| flake and plug the new host in and it will boot to the correct
| configuration. I actually don't have any OS installation on
| most of the hosts and share the nix store via NFS.
|
| I also keep an iPXE thumb drive around in case I need to do
| this for something not on my network. In that case, I insert
| the drive, boot from it, and then ask it to boot from
| netboot.xyz manually.
| alfiedotwtf wrote:
| If you want to see how all the magic happens, have a look at
| the code and docs from Debian's FAI (Fully Automated Install).
| Once you have a Debian FAI all setup, you can bootstrap your
| machine from zero every morning while you have your morning
| coffee
| mrinfinitiesx wrote:
| This is like Ventoy? I'll give it a try for when I re-do a flash
| drive. Can I put windows tools on here as well for removing
| spy/malware etc to fix PCs? With Ventoy I just make a dir and I
| can select them when the OS boots, but still boot every ISO image
| at post
| poikroequ wrote:
| Not quite the same. It sounds like netboot downloads the images
| from over the Internet. Whereas Ventoy you preload the images
| onto a flash drive ahead of time.
| inportb wrote:
| This is more similar to iVentoy, which implements PXE boot, but
| is closed source. netboot.xyz, on the other hand, requires boot
| images to be extracted and served in an iPXE-friendly format,
| which their CI/CD system does automatically. These solutions
| are good for facilitating OS installations across a fleet of
| computers on a network.
|
| But for system rescue purposes, Ventoy still wins. You bring
| your own boot images, which could be arbitrary ISOs, and don't
| have to worry about networking availability.
| criddell wrote:
| Why would you ever trust something like this that will helpfully
| pull images from the internet? I'm sure whomever is running it
| today is perfectly honest and none of their computers have been
| compromised, but there's no reason to expect it to stay that way,
| is there?
|
| Firewalling the application so that only local images are
| available seems like the only safe way to use this.
| nxobject wrote:
| If I read the the docs correctly, since source locations are
| printer, it's about as trustworthy as trusting "wget $ISO_URL"
| on your installation to not download anything malicious.
| Unfortunately what seems to be missing is a hash check after
| the fact - a missed opportunity since images are loaded to RAM
| anyway.
|
| (The limitation here is that you have to be able to load the
| installer image into RAM, which does exclude a lot of smaller
| nettop/thin/SoC clients unfortunately.)
| ForOldHack wrote:
| I may be totally missing something, but does this mean I can
| use a printer as a netboot? Still no morning coffee.
| geek_at wrote:
| you can selfhost it. It's mainly useful to boot and play with
| multiple different linux distros
| kayson wrote:
| Even if you self host it, some assets are still pulled from
| Github by default.
| LeonM wrote:
| > Why would you ever trust something like this that will
| helpfully pull images from the internet?
|
| How is that different than pulling an ISO image of your
| favorite distro, or using a package manager like apt?
|
| Yes, I know that Linux ISOs have checksums and apt uses digital
| signatures, but so does iPXE. The only difference here would be
| that for some reason you trust the websites of your Linux
| distro vendor, but not netboot.xyz?
| martinflack wrote:
| > you trust the websites of your Linux distro vendor, but not
| netboot.xyz
|
| Well... yeah... that's not that crazy of a position to take.
|
| Not saying there's anything wrong with netboot.xyz, but it's
| a question of how many cooks to let in the kitchen, and how
| many public eyes are on each cook.
| kelnos wrote:
| > _The only difference here would be that for some reason you
| trust the websites of your Linux distro vendor, but not
| netboot.xyz?_
|
| "Some" reason? I think I'd have a very good reason to place
| _much_ more trust in the Debian folks than some guy who runs
| some random netbooting website.
| akira2501 wrote:
| > How is that different than pulling an ISO image of your
| favorite distro, or using a package manager like apt?
|
| "Some iPXE builds do not support HTTPS connections. If you
| get an "Operation not supported" error message, run this
| instead:
|
| chain --autofree http://boot.netboot.xyz"
|
| Which.. think about that advice for a minute.
| mobilio wrote:
| I'm using this on some USB flash drive because save me to have
| few USBs with different Linux distros. Everything is downloaded
| from the internet and this make USB few megabytes only.
| EADDRINUSE wrote:
| netboot.xyz is neat. As it makes use of iPXE I would like to
| speak out a token of appreciation for those working on that
| project. It's such an essential building block in DC's around the
| globe that many are not aware of.
| elchief wrote:
| the list of available operating systems is here:
|
| https://netboot.xyz/docs/faq/#operating-systems
|
| looks like you can use it on aws / ec2:
|
| https://ipxe.org/howto/ec2
| ForOldHack wrote:
| I was looking for a alternative to VenToy... so I scanned all the
| embedded binaries... every last one... and its completely and
| utterly clean... but does not support windows, which is a minus
| only in my case, but an absolute godsend in all others. Not a
| single Linux I have ever used has been passed over.
|
| Brilliant work on a brilliant solution.
| louwrentius wrote:
| I'm experimenting on and off with PXE network booting.
|
| In my experience, TFTP is really slow (ancient UDP based
| protocol) and I'd like to do away with it. Unfortunately TFTP is
| still required to load something like iPXE to load the actual OS
| Kernel over HTTP, assuming iPXE isn't part of the NIC firmware or
| can't be configured to do so.
|
| Turns out that downloading over HTTP is just as slow (few MB/s)
| when using iPXE so I'm not sure what I'm gaining.
|
| Ideally HTTP boot is possible through the UEFI bios but it seems
| that this is common on servers, but not on clients? My HP 1L PCs
| don't have an option to boot over HTTP directly.
___________________________________________________________________
(page generated 2024-08-19 23:00 UTC)