#Raspberry pi freenas install#
#Raspberry pi freenas download#

On Intels this can be done with grub and shellscripting, however there are tools for that (CoreOS, ChromiumOS etc). I haven’t implemented this myself and Foreman does not support any of that, however it’s something I would be targetting for. This is very safe, no PXE needed just HTTP. Then you switch A with B, reboot and repeat.

#Raspberry pi freenas download#

This is called A/B installation, something that CoreOS or ChromiumOS does: You have two partitions A and B of the same size, you insert SD card with installed OS on A including auto-updating tools which can periodically check and download OS image to the other parittion. What makes me think that provisioning over network for RPi cluster is wasing of time is that there is an alternative approach. You want to insert an SD card with bits that would network-install an OS? Why don’t you simply insert an SD card with installed system? The degree of management possible through Foreman is better than none at all and we’re ‘resigned’ (in a way) to this limitation and we do use it to perform various package updates and configuration changes over-the-air.ĭon’t get me wrong, but it’s terrible idea. I’m not holding my breath on this, though. remote system updates to resolve critical issues).

#Raspberry pi freenas install#

If it was possible to deploy a base SD card image that simulated a PXE boot and did something ‘intelligent’, to install a local OS (perhaps to a USB device), then it might provide us with some utility (eg. Lzap also posted a hackaday link with a similar process and outcome. It might work for some, but unlikely to work for us, mainly due to variable connectivity speeds over-the-air to an NFS-mounted root FS. Raspberry Pi 4 supports PXE boot through an updated (read: “unsupported”?) replacement bootloader:, however this is more like an old-school TFTP+NFS diskless workstation boot. Only Raspberry Pi 3 B and 3B+ can do a PXE boot natively. TFTP+NFS root also implies GSM data usage, so doesn’t fit our use case on both these fronts.

Lzap’s suggestion of an NFS boot (NFS root FS) doesn’t help us, either, since GSM coverage is slow and variable in some locations and the RsPis must be autonomous and boot from local media. So - the prospect of saving a lengthy drive or the complexities around working with local contracted installers (with variable skillsets) is worth some further investigation. In addition to the immediately obvious issues already considered, interfacing with the local GSM modem adds an additional layer of complexity and would require a working TCP/IP stack with PPP support. A deployment over-the-air (or even on the workbench, prior to installation) would help us out immensely.

In our case, provisioning a new RsPi (or a swapout) involves driving up to 1,200km to install the device (or shipping it to a local installer).

Foreman can do some portions of the management work, but provisioning is a problem, as per lzap’s post. So - we have a use case that involves a nationally-distibuted network of Raspberry Pis talking to each other and to a central server deployment over GSM.

I’d be interested to see whether you managed to progress on this? Contrary to lzap’s assertion that RsPi provisioning “does not makes sense”, it would be of value to my organisation.