**Problem: can i provision Raspberry Pi 4 with Foreman ?
**Expected outcome: Successful provisionning of Raspberry Pi 4
**Foreman version: 1.23.1
**Distribution and version: Centos 7 1908 64bit
Can we provision a raspberry pi 4 using Foreman ?
If yes, please can you provide a tutorial link , instructions or keypoints ?
Hello, no you canāt. It does not makes sense.
What is your use-case? RPi provisioning is essentially copying a SD card, why would you want to do this over network? It will only be slower, just do it on your laptop or somewhere else, clone these images and put them into appliances. The problem is bootloader, RPi4 uses proprietary bootloader by Broadcomm (https://github.com/raspberrypi/firmware) and Foreman is able to manage network boot configurations of PXELinux, Grub, Grub2 and iPXE bootloaders. Unfortunately these will not work on custom ARM design board, at least I havenāt heard anyone being able to boot it.
If you want to use disk-less RPi just follow any tutorial which explains how to boot from network (note this is not provisioning it simply boots a NFS mounted root): https://hackaday.com/2019/11/11/network-booting-the-pi-4/ - Thatās actually the way Iād recommend, you save money for these SD cards and if you are on gigabit network it will be reasonably fast.
Hiya captainit,
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.
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. Foreman can do some portions of the management work, but provisioning is a problem, as per lzapās post.
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). A deployment over-the-air (or even on the workbench, prior to installation) would help us out immensely.
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.
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.
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. TFTP+NFS root also implies GSM data usage, so doesnāt fit our use case on both these fronts.
Only Raspberry Pi 3 B and 3B+ can do a PXE boot natively. Raspberry Pi 4 supports PXE boot through an updated (read: āunsupportedā?) replacement bootloader: https://blog.ronnyvdb.net/2020/05/10/howto-raspberry-pi-4-pxe-network-boot/, however this is more like an old-school TFTP+NFS diskless workstation boot. 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.
lzap also posted a hackaday link with a similar process and outcome.
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. remote system updates to resolve critical issues). Iām not holding my breath on this, though.
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.
Donāt get me wrong, but itās terrible idea. 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?
What makes me think that provisioning over network for RPi cluster is wasing of time is that there is an alternative approach. 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. Then you switch A with B, reboot and repeat. This is very safe, no PXE needed just HTTP.
I havenāt implemented this myself and Foreman does not support any of that, however itās something I would be targetting for. On Intels this can be done with grub and shellscripting, however there are tools for that (CoreOS, ChromiumOS etc). However on RPi there might be hidden dragons and boot limitations.
Also there is one huge issue, if you search for ārpi A/Bā it wonāt show you relevant results simply because there are hardware models named A, B or even A/B 
Hi lzap,
Because theyāre potentially over a thousand km away from the installer. Actually, the devices are on one continent and I (as the designer) am on another, so Iām having to rely on semi-skilled individuals to do the actual work.
There are a few approaches to resolving this and weāre looking at all of themā¦
Regards,
Ross
Okay, get back to us if you figure something out. I have RPi4 8GB myself and I can develop and test whatever is needed. Iād be more than happy to have any kind of RPi support in Foreman. Itās just I could not figure out anything for now.
I couldnāt agree more with the A/B part, especially when you need something reliable, when upgrading from one version to another. Didnāt most old Android phones also use that mechanism back in the days? I also believe that FreeNAS uses this mechanism for upgrading between version, though through ZFS snapshots.
I assume that you have taken into account SD card failure rates, if you write to it alot.
In any case, if you could use some way of provisioning the system all over, then you would still need to do a fresh install over that terrible internet connection you mention. Keeping a known good partition ought to save you that thousand km trip if an upgrade didnāt work and also mitigate against bad internet.
Depending on how your application is rolled out, another potential option could be to look into OSTree and its OTA and rollback features. In theory that should handle reverting to the last known working state after three unsuccessful boot attempts.
Then again it may not actually solve the problems you experience, as you didnāt exactly specify what issues arise with a running rpi that warrants a re-provision.
I assume that the initial installation of the equipment is done with a flashed card. If it is truly the initial step, then you would still need to know the MAC of the device to provision at first boot. If you canāt trust people to flash an SD card, I would doubt they would be able to find the MAC.
Note that I truly see your concern with losing access to a remote device. But it is interesting to know why A/B or OSTreee doesnāt solve the issue.
Because theyāre potentially over a thousand km away from the installer. Actually, the devices are on one continent and I (as the designer) am on another, so Iām having to rely on semi-skilled individuals to do the actual work.
The distance is definitely one important point and usually time = money. Is it efficient to let people cloning SD-cards on notebooks while they could work on more important tasks? Letting Foreman installing PIs seems to be a very good work simplification.
We also use a lot of PIs for tests, once they are set up with Raspbian (right now a manual step), Ansible kicks in to configure the required test setups we need. I bet we could also Foremans finish templates somehow to do that. Then the complete workflow would be automated.