[dveeden2]

Back in the the day it was possible to boot Sun Solaris over HTTP. This was called wanboot. This article reminded me of that.

This was basically an option of the OpenBoot PROM firmware of the SPARC machines.

It looked like this (ok is the forth prompt of the firmware):

    ok setenv network-boot-arguments dhcp,hostname=myclient,file=https://192.168.1.1/cgi-bin/wanboot-cgi
    ok boot net

This doesn't only load the initramfs over the (inter)network but also the kernel.

https://docs.oracle.com/cd/E26505_01/html/E28037/wanboottask...

https://docs.oracle.com/cd/E19253-01/821-0439/wanboottasks2-...

[kotaKat]

Modern UEFI can do that too!

https://ipxe.org/appnote/uefihttp

[Andrex]

First thing I disable on a new PC.

[mywittyname]

I was going to say, booting from a random website image sounds like a terrible idea.

[michaelmior]

It's possible to require that any images used be signed using a specific key that is configured in the hardware ahead of time. Even if you don't do that, the same setup can be helpful for provisioning a bunch of machines without accessing any external network. You can configure a small box to act just as a DHCP server and to serve a machine image for network boot. Then you can have all the machines on this subnet automatically load that image as it is updated without the need for any further configuration on each device.

I've seen organizations do something similar to this for trade shows when they want a bunch of machines that visitors can interact with and don't want to have to keep them updated individually. Just update the image once and reboot each machine.

[xur17]

Ideally it would be possible to just specify an image url and a hash.

Or, even better, a magnet link.

[yjftsjthsd-h]

I dunno, I actually think a public key is better than a hash, because it lets you sign updated images without having to update things on the client. Obviously it should be user-controlled, but this feels like a legitimate use.

[thesuitonym]

Okay but why not just use PXE? Why does everything have to be HTTP?

[danudey]

Well, it kind of does. Normally, the PXE network booting will use DHCP (or bootp or whatever) to fetch the boot image location, then it will fetch that boot image. Historically, that has worked this way:

1. bootp says boot image is at <ip address>/path/to/img 2. PXE network stack fetches that image via TFTP (which is awful) 3. PXE network stack boots that image

In most cases, the boot image would be a chainloader like pxelinux, and that would fetch a config file which told it the kernel path, the initrd path, and the commandline, and then the user could choose to boot that image, and then pxelinux would fetch the files via TFTP (which is still awful) and boot them.

In this new, HTTP-based case, we replace each instance of "TFTP" with "HTTP", which we can authenticate (ish), which we can easily firewall, which doesn't have weird compatibility issues, and so on.

Note that, before now, you could replace pxelinux with iPXE, and iPXE could fetch files via HTTP (which is awesome), but you still had to fetch iPXE and its config file via TFTP.

Note that TFTP is an unauthenticated, UDP-based, extremely limited protocol which has almost no support for anything but the most basic "get this file" or "take this file" functionality. Being able to replace it is a joy and a wonder.

[throitallaway]

PXE is one layer higher than what you're thinking of. The old-school analog to HTTP in this case is TFTP, and it sucks.

[paulddraper]

You can do either

[Andrex]

Anyone know why this comment is collapsed by default?

[giancarlostoro]

I'm wondering if this is how we did a net install of a custom Distro back in a former job, but I don't recall. I just remember it being insanely easy to install the distro over the network, even on a VM.

[eichin]

if it was a decade ago, PXE/tftp booting was pretty common (at MetaCarta we shipped dell 2650/6650 servers around then, and while field upgrades were from DVD, the QA lab had some "synthesize keystrokes through a KVM to select netbooting" and then a tftpserver that had the image you wanted to install in a MAC address specific filename, so the machine picked up the intended image. We got the idea from another boston-area startup (Vanu Inc) that put similar Dell servers in software-configurable cellphone towers, iirc)

[bogota]

As far as i know most places are still using iPXE and Tftp to load an image with some custom provisioning framework.

It worked really well but I haven’t worked on large scale DCs for a few years now so maybe some new stuff happened

[bayindirh]

PXE is still the king in large DCs. I can install ~250 servers in 15 minutes with a single xCAT node over traditional gigabit Ethernet. Give another 5 minutes for post-install provisioning and presto!

Your fleet is ready.

[bogota]

Nice! That was my experience as well. Just wanted to make sure I wasn’t falling too far out of date while I switched to some MLops roles for a while.

[ClassyJacket]

I don't know about servers and stuff but I'm using PXE to image a Surface Pro right now.

[jpalomaki]

Booting over HTTP would be interesting for device like Raspberry. Then you could run without memory card and have less things to break.

[yjftsjthsd-h]

I would also prefer HTTP, but Pis can use PXE boot and mount their root filesystem over NFS already:) Official docs are https://www.raspberrypi.com/documentation/computers/raspberr... and they have a tutorial at https://www.raspberrypi.com/documentation/computers/remote-a...

[wang_li]

Once you have PXE you can do all the things -- NFS boot, HTTP boot, iSCSI boot, and so on. There are several open source projects that support this. I think the most recent iteration is iPXE.

[yjftsjthsd-h]

That's true, though I always have felt that if I needed PXE+TFTP to boot the bootloader I might as well just load a kernel+initrd from the same place and be done with it; I couldn't remove the TFTP requirement so anything else would just be extra things to configure. If UEFI can really do pure HTTP (as discussed upthread) then I may need to reevaluate. (Well, for Raspberry Pis I'll have to keep TFTP, but maybe in other contexts I can drop it)

[westurner]

iPXE: https://en.wikipedia.org/wiki/IPXE :

> While standard PXE clients use only TFTP to load parameters and programs from the server, iPXE client software can use additional protocols, including HTTP, iSCSI, ATA over Ethernet (AoE), and Fibre Channel over Ethernet (FCoE). Also, on certain hardware, iPXE client software can use a Wi-Fi link, as opposed to the wired connection required by the PXE standard.

Does iPXE have a ca-certificates bundle built-in, is there PKI with which to validate kernels and initrds retrieved over the network at boot time, how does SecureBoot work with iPXE?

[vlowther]

> Does iPXE have a ca-certificates bundle built-in, is there PKI with which to validate kernels and initrds retrieved over the network at boot time

For HTTPS booting, yes.

> how does SecureBoot work with iPXE?

It doesn't, unless you manage to get your iPXE (along with everything else in the chain of control) signed.

[lesuorac]

https://www.google.com/search?q=raspberry%20pi%20pxe%20booti...

There was an article recent for somebody doing it on an Orange Pi [1]. IIUC, you can have one RasPi with an SD Card (I use USB drives but w/e) to be the PXE server and then the rest can all network boot.

[1]: https://news.ycombinator.com/item?id=40811725

[AnimalMuppet]

Welcome back, diskless workstations! We've missed you... oh, wait, no, we really haven't.

This is technically neat, but... How often does the memory card break on a Raspberry? How often does the network break (either Raspberry hardware or upstream)? There are fewer things to break when you run from local hardware.

[Semaphor]

I'd say sd card failures are the most common rPI failures.

[BobbyTables2]

Only because people treat them like harddrives and stubbornly run desktop distos on them.

Keep log files and other things frequently written in RAM and the sdcard will last forever.

When was the last time an sdcard in a digital camera wore out?

[eek2121]

You are thinking about this wrong. Imagine having a single disk image for 100 Pis. Now imagine having to burn that image to a hundred MicroSD cards, now suddenly you want to update the disk image.

As others have said, you can also use PXE, but http is a bit easier to deal with.

There is a hosting company with something like 44k Raspberry Pis. Are you going to be the guy to update them?

[ssl-3]

That's one improvement, but network booting can also help us home-gamers who don't have a hundred Raspberry Pis that are all doing the same thing.

Many of us have a handful of Pis at home doing whatever they do, each with their own unique MicroSD card. In this configuration, every time the number of Pis doubles, the overall MTBF for their collective storage halves. Backups are a pain since each Pi is a unique and special snowflake, and are thus somewhat unlikely to actually get accomplished. When a MicroSD card does die, that Pi's configuration and all of the work that went into making it do whatever it likely disappears with it.

However, when booting over the network:

A handful of Pis are at home doing whatever they do, and booting from a reasonably-resilient NAS (eg a ZFS RAIDZ2 box) somewhere in the house (which is a great idea to have around for all kinds of other reasons, too). Adding more Pis does not decrease storage MTBF at all, since there is no MicroSD card to die. Backups become simple, since ZFS snapshots make that kind of thing easy even if each Pi's disk image is a unique and special snowflake. Space-efficient periodic snapshots become achievable, making it easy to unfuck a botched change -- just roll back to an hour ago or yesterday or whenever things last worked and by using that snapshot instead. Undetected bitrot becomes zero. Speeds (for many workloads) might even increase, since at least the Pi4 can handle wire-speed network traffic without any real sweat.

It's not a great fit for everyone, but it may result in a net long-term time savings for some of us folks here who tinker with stuff at home if enough steps are automated, and it seems likely to result in fewer frustrating surprises.

[paranoidrobot]

> How often does the memory card break on a Raspberry?

I have no data on this, only anecdata - since I've started being interested in the Home Assistant project, I've seen countless problems with people who've done an upgrade, rebooted their HA Pi and had some kind of Disk IO issue because the card died.

As I understand it, it's the constant logging to disk for logfiles and databases that ends up killing MicroSD cards. It seems to be particularly bad for clones and cheap ones off eBay/Amazon. It's still apparently a problem even for high quality "endurance" MicroSD cards.

[ssl-3]

Amusingly, most of the things I regularly use Raspberry Pi hardware for require a functional network as well as functional storage on that network.

If I were to netboot these things, then I'd have fewer points of failure than I do now.

[1vuio0pswjnm7]

I always put the rootfs in the kernel. It mounts on mfs or tmpfs. SD card is read-only. After boot, I can pull out the card. No need to boot over HTTP.

[mrgaro]

I remember the glorious AIX machines we had which could book from tape backups made with a simple "mksysbk" command. :)

[bastawhiz]

How slow was that?

[dspillett]

If it is pulling a filesystem from tape into memory and booting from that, it could be pretty quick. Reading sequentially from tape, if you are already at the right location which is easy if that location is the start of the tape, isn't particularly slow at all – non-sequential access is where tape storage becomes very slow due to massive latency in the physical mechanisms.

[unixhero]

"The network is the computer." It was a shortlived thing.

[anon35]

"Short-lived" depends on your perspective. Cloudflare owns the rights to that trademark now; because they believe their mission furthers that vision: https://en.wikipedia.org/wiki/The_Network_is_the_Computer (and John Cage, the Sun employee who coined the phrase, said he was fine with Cloudflare picking it up: https://spectrum.ieee.org/does-repurposing-of-sun-microsyste...)

[msh]

I guess Chromebook’s is the resurrection of the idea

[Teckla]

Thanks to Crostini, Chromebooks are also excellent local computing devices.

[bluGill]

Not really. Chromebooks don't use the LAN. They can run code locally, or on the server in a different timezone. However with Sun if you needed more CPU you could log into all the machines on your local network - all machines shared the same filesystem(NFS) and passwd (I forget this was), so using all the CPUs in the building was easy. It was unencrypted, but generally good enough until the Morris worm.

Of course moderns servers have far more CPU power than even the largest LANs back in 1986. Still those of use who remember when Sun was a big deal miss the power of the network.

[toast0]

> all machines shared the same filesystem(NFS) and passwd (I forget this was), so using all the CPUs in the building was easy.

Sun did this through NIS, originally Yellow Pages/YP, but name changed for trademarks.

When I worked at Yahoo, corp machines typically participated in an automounter config so your home would follow you around, it was super convenient (well, except when the NFS server, which might be your personal corp dev machine under your desk, went away, and there was no timeout for NFS operations... retry until the server comes back or heat death of the universe). They used a sync script to push passwords out, rather than NIS though --- a properly driven sync script works almost as fast, but has much better availability, as long as you don't hit an edge case (I recall someone having difficulty because they left the company and came back, and were still listed as a former employee in some database, so production access would be removed automatically)

[MisterTea]

That's because Sun just bolted stuff on to Unix. Bell Labs actually achieved that goal in Plan 9 which is still very much alive.

[prmoustache]

Grub can boot a kernel from http too.

[Iwan-Zotow]

https://unix.stackexchange.com/questions/228452/can-grub-loa...

[ktm5j]

I remember doing this to install Solaris while resurrecting an old sparcstation. Fun times!

[lanstin]

I didn't realize that. I booted over BootP many times but this is even cooler.