Provision Raspberry Pi 4

**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 ( 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): - 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:, 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 :slight_smile:

1 Like

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…



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.