State of netbooting Raspberry Pi in 2021
blog.alexellis.io
blog.alexellis.io
I've setup manufacturing stations for this and I've never been able to find truly robust gang-programmers for sdcards. Luckily my stuff was all low volume so it wasn't a serious problem.
But it seems like there's no "manufacturing grade" gang programmers for sdcards. The stuff that is out there is just infinitely re-branded chinese "white-label" hardware-- just a lot of different "vendors" for a few different models of the basically the same hardware.
My suspicion for there not being good options for gang-programming of sdcards is that savvy consumer manufacturers have realized what a headache it is to support sdcards in their products from the factory and thus opt to make the sdcard the customer's responsibility. In other words, they ship their products without sdcards and just require the customer to purchase the sdcard and program it if needed. I am not sure if my suspicions are justified, can anyone confirm if this is the case?
You can do a similar thing with microcontrollers - if you're buying sufficient volume the manufacturer will supply them with your program already on, saving you a manufacturing step.
https://github.com/pftf/RPi4 enables several alternatives, all faster and more reliable
* usb3 -> sata
* usb3 -> nvme
* iscsi
* ipxe
* netboot.xyz via pxe or usb
* usb thumbdrive
Yeah there are crappy ones but if you stick to ~2GB and decent vendors (like most people do) you're unlikely to deal with them.
https://boot.netboot.xyz/ipxe/netboot.xyz-rpi4-sdcard.img
Edit - ok I guess being airgapped would be one, fair enough!
Also, how is a usb thumbdrive better than a sdcard?
* NVMe (native)
* eMMC
(SATA can be used natively, too, but you can't yet boot from a SATA drive on the Pi.)
It's not that it is less, "3" is what you get if you take the character "8" and cut it in half vertically.
The explanation above was given by one of the Rancher staff members in one tech conference. It may be an alternative explanation that popped up with time.
In both the point is that k3s is "half of" k8s.
Netbooting a bare metal environment is quite straightforward for the PI 3 (dnsmasq has it all) and takes around 15-30 secs.
Can anyone comment on that?
I made hybrid systems where either the card is only used to boot the system and everything (root included) is loaded from a USB drive or where card is mounted R/O, there is small ramdisk for volatile data and only when upgrade/reconfiguration is needed you remount it r/w, do what you need and then remount it back r/o. In both those setups cards didn't fail for the last 3-4 years. With a standard SD card root-fs they lasted about 4-6 months.
I got tired of the inconvenience of having to rebuild the Pi installation and flashing SD cards, so now I boot my Pi4 directly from a USB attached SSD, no card on-board at all. I haven't looked back. Others seem to also be getting good result like: https://www.jeffgeerling.com/blog/2020/im-booting-my-raspber...
I'm curious what the headache was. K8S has shipped arm kubeadm and kubelet bins for quite a while.
I also don't understand how k3s, microkube and others claim to be "lightweight". Lightweight compared to what? Certainly not upstream kubeadm which is as lightweight a bootstrap as you can get.
> "Given how much I'd liked the Docker experience of "docker swarm init" and "docker swarm join", I decided to re-create a similar experience for K3s in the k3sup tool"
"kubeadm init" and "kubeadm join"
These components are all containerized already from upstream. Pulled and cached when you run "kubeadm init" via static pod manifests.
It seems trying to bundle these inside a non-upstream bootstrapper and running them out-of-band from kubernetes is what would add complexity and bloat.
For k3s, they explain what they do in their README:
https://github.com/k3s-io/k3s#how-is-this-lightweight-or-sma...
Is it price?
(Just to be clear, I think "having fun" is a fine excuse to do most stuff, but they're talking about "replacing usage of AWS" which sounds a hell of a lot like a serious business thingy)
I imagine such a thing would draw at least 200W? And pi's maybe 5 watts? So in theory, 30 - 40 pis vs a single server?
The pis also have an advantage in terms of redundancy. A single pi going down shouldn't be a problem and very easily replaceable.
Would be a really interesting article.
That being said, I am running a NAS and PiHole on a RPi4B right now and am happy. I am planning on turning an old laptop with busted hinges into a server with a nice housing though. I'm very interested how it's going to pan out :)
Edit: I had a 1U server with 2x intel CPUs (16 threads all in all I think?) with 32G RAM in 2012 or so and it didn't see much use. It was LOUD (small screaming fans that pushed air through the chasis) so it didn't see much use.
There are situations where the economics slightly favor the Pi, but they're fairly narrow with the current gen.
That’s why I use PIs and custom built a NAS with a supermicro mobo and an i3 (ECC compatible).
The rig the author has is bordering on the ridiculous side and can never match a Xeon, or Xeon cluster.
It should eliminate whatever timing-bugs you have and leave you in a more reliable (and scriptable!) pre-boot environment. What more do you need?!?
Both the RPi3 and 4 can be UEFI booted, so this is definitely a real-world option.
Links:
1. The pins are likely connected to a memory-mapped GPIO controller in the Broadcom SoC (you write a value to a special memory location, and the GPIO controller will physically change the voltage on the associated pin). While you can implement certain slow interfaces - UART is the typical example - purely in software using bit-banging, this approach only works as long as your desired interface speed is a lot slower than the CPU clock. For example: To implement a UART controller at 9600 Bd running on a 1 GHz CPU, you have over 100000 cycles for each symbol you send or receive. For 1000BASE-T, you are looking at a symbol rate of 125000000 Bd, so you'd have just 8 cycles for each symbol (and this is completely ignoring the line code used for 1000BASE-T, which the GPIO controller very likely doesn't support on a physical level).
2. If you want to run an interface faster than a few MHz, you have to be more careful on the electrical level to avoid reflections/impedance mismatch and other signal integrity issues. Essentially, you can't just hook up 2.54mm pin headers at gigabit speeds and expect everything to work fine.
3. Related to the two previous points: Almost all high-speed interfaces (including GbE, USB, HDMI etc.) use line codes at the physical level and/or use differential voltage signaling (LVDS/TMDS etc.) for transmission. The Pi's GPIO controller is very likely unable to send/receive data using differential standards. By the way, if you're interested in this topic: Most FPGAs (even entry-level FPGAs) support differential voltage standards in their IO blocks and even include special encoder/decoder blocks (for 8b/10b encoding).
> 2. If you want to run an interface faster than a few MHz, you have to be more careful on the electrical level to avoid reflections/impedance mismatch and other signal integrity issues. Essentially, you can't just hook up 2.54mm pin headers at gigabit speeds and expect everything to work fine.
Conversely, we got a gigabit out of a few wires, non-differential, on pin headers UltraDMA/ATAPI over distances of tens of inches, albeit with the insulation displacement connector able to put a ground between each wire on the ribbon to lower impedance a bit.
It would be nice to have some more capable interfaces multiplexed onto the pins. That's all I'm saying.
For that matter, an RJ45 doesn't have wonderful electrical characteristics, but it's a small impedance discontinuity at the ends of the circuit. Industrial uses put gigabit ethernet through all kinds of connectors. Gigabit Ethernet works in practice through a few inches of untwist and would work just fine through a pin header. Already not everything on the header is hooked up to a single GPIO controller-- some goes directly to the broadcom and some to an external GPIO controller on earlier PIs, I believe.
> I flashed each of the Raspberry Pis using the same SD card, then I could close the case and take a note of each MAC address and serial number for later on.
But if flashing SD cards, then why do we need network boot? Or, if we have network boot, why do we need to use SD cards?
TL;DR: no.
SBCs with uncomplicated boot loaders can get you to a shell prompt within one second of applying power; I imagine getting to a lightweight graphical environment in under 2 seconds is not hard. Doubtless you can reduce that a little with tweaking. That's a good deal faster than my car stereo, say.