> 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?

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.

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

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.

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?

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?

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.

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.

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