4 ms·

I recommend netbooting the Pi off a server. Not only is it easy to back up and restore, the performance on small reads and writes is probably better than you ca

I recommend netbooting the Pi off a server. Not only is it easy to back up and restore, the performance on small reads and writes is probably better than you can expect from any mSD card, if the specs here are to be believed. Plus you don't burn out SD cards that cost at least half what the Pi does.

geerlingguy 9y ago
And as a bonus the Pi 3 B+ gets ~230 Mbps over LAN (whereas all the older models maxed out at ~93 Mbps), so netboot performance should be even better than in the past.
StavrosK 9y ago
Are there any good guides on how to do this? I never once got it working. Also, where do you persist data? NFS share?
- bscphil 9y ago
  Yeah, it's unfortunately not the easiest thing in the world. I suggest cloning a working Raspbian installation to your server, pointing tftp at /boot (with the "--secure" option set so as to allow relative paths). You can then set up a rw NFS share on / for the Pi to boot off of (and lock it down with your firewall). You also need to point the Pi to the server via DHCP, which you can do in dnsmasq like so: dhcp-option=43,Raspberry Pi Boot dhcp-option=66,$SERVERIP I wrote up a more complete guide here a while back: https://adamfontenot.com/post/how_to_netboot_a_raspberry_pi_3_from_a_linux_server_with_tftp_and_nfs https://adamfontenot.com/post/how_to_netboot_a_raspberry_pi_... The other really cool thing you can do with this is install qemu emulation support for arm on the server and then use systemd-nspawn to chroot into your Raspbian installation. Then for any commands that don't need access to the Pi's ports, you can run them directly on the server. It's really nice to do updates this way, much faster than looping them through the Pi and its slow processor. Love following your projects, by the way.
  - mxvzr 9y ago
    Thank you so much for posting these two options; The RPI kept sending TFTP requests to the machine running the DHCP server despite my attempts to specify another IP (the "official" documentation specifies pxe-service=0,"Raspberry Pi Boot" to which I added the filename & ip as per dnsmasq man page; same thing with dhcp-boot parameter)
    - emj 9y ago
      I do not know if this is an issue with RPI, but some crappy devices only support TFTP from the DHCP server, you can solve this with two dhcp servers or iptables port forwarding.
  - StavrosK 9y ago
    Ah that doesn't sound too bad, I should be able to get it up and running, thanks for the instructions! I have a new project that's almost finished that was a lot of fun to work on, writeup coming soon! Sneak peek, it's what produced these test photos: https://m.imgur.com/a/mDR8y https://m.imgur.com/a/mDR8y Thanks again!
hazeii 9y ago
Absolutely the way to go. We run loads of Pi's like this; older ones with an RO SD card holding the boot (so never get corrupted), later ones using the built-in PXE loader. Excellent for development as well; never be scared of doing a hard reset or Magic-Sysreq (this goes for PC's as well as Pis). It's unfortunate that the built-in watchdog doesn't work during boot and shutdown, so a hang at these points won't be recovered without cycling the power. This can be addressed with an actual hardware watchdog connected to the P6 header (so if it's not being poked every so often, it does a cold boot). The main issue for most home users is DHCP; normally the router provides DHCP and a lot of them are not compliant with the spec (making it tricky to set up a second DHCP just for netbooting). The solutions I know are using a separate network, or running your own DHCP for everything (my preferred solution).
fulafel 9y ago
You have to put absolute trust in the network in this scenario, not really acceptable architecture in 2018.

geerlingguy 9y ago

And as a bonus the Pi 3 B+ gets ~230 Mbps over LAN (whereas all the older models maxed out at ~93 Mbps), so netboot performance should be even better than in the past.

StavrosK 9y ago

Are there any good guides on how to do this? I never once got it working. Also, where do you persist data? NFS share?

bscphil 9y ago
Yeah, it's unfortunately not the easiest thing in the world. I suggest cloning a working Raspbian installation to your server, pointing tftp at /boot (with the "--secure" option set so as to allow relative paths). You can then set up a rw NFS share on / for the Pi to boot off of (and lock it down with your firewall). You also need to point the Pi to the server via DHCP, which you can do in dnsmasq like so: dhcp-option=43,Raspberry Pi Boot dhcp-option=66,$SERVERIP I wrote up a more complete guide here a while back: https://adamfontenot.com/post/how_to_netboot_a_raspberry_pi_3_from_a_linux_server_with_tftp_and_nfs https://adamfontenot.com/post/how_to_netboot_a_raspberry_pi_... The other really cool thing you can do with this is install qemu emulation support for arm on the server and then use systemd-nspawn to chroot into your Raspbian installation. Then for any commands that don't need access to the Pi's ports, you can run them directly on the server. It's really nice to do updates this way, much faster than looping them through the Pi and its slow processor. Love following your projects, by the way.
- mxvzr 9y ago
  Thank you so much for posting these two options; The RPI kept sending TFTP requests to the machine running the DHCP server despite my attempts to specify another IP (the "official" documentation specifies pxe-service=0,"Raspberry Pi Boot" to which I added the filename & ip as per dnsmasq man page; same thing with dhcp-boot parameter)
  - emj 9y ago
    I do not know if this is an issue with RPI, but some crappy devices only support TFTP from the DHCP server, you can solve this with two dhcp servers or iptables port forwarding.
- StavrosK 9y ago
  Ah that doesn't sound too bad, I should be able to get it up and running, thanks for the instructions! I have a new project that's almost finished that was a lot of fun to work on, writeup coming soon! Sneak peek, it's what produced these test photos: https://m.imgur.com/a/mDR8y https://m.imgur.com/a/mDR8y Thanks again!

hazeii 9y ago

Absolutely the way to go. We run loads of Pi's like this; older ones with an RO SD card holding the boot (so never get corrupted), later ones using the built-in PXE loader. Excellent for development as well; never be scared of doing a hard reset or Magic-Sysreq (this goes for PC's as well as Pis). It's unfortunate that the built-in watchdog doesn't work during boot and shutdown, so a hang at these points won't be recovered without cycling the power. This can be addressed with an actual hardware watchdog connected to the P6 header (so if it's not being poked every so often, it does a cold boot). The main issue for most home users is DHCP; normally the router provides DHCP and a lot of them are not compliant with the spec (making it tricky to set up a second DHCP just for netbooting). The solutions I know are using a separate network, or running your own DHCP for everything (my preferred solution).

fulafel 9y ago

You have to put absolute trust in the network in this scenario, not really acceptable architecture in 2018.