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.