Fancy ways to provision a RPI?

So:

1. Created a microSD with https://github.com/pftf/RPi3
2. dd'ed a Debian cloud image to an USB SSD. It turns out that if you dd a tar, it doesn't work, you need to use the raw image...
3. Well, that boots... but wait, screen goes black and does nothing?
4. Well, reboot a million times, then leave the RPI on accidentally for a while while you research... and login comes up (edit: it takes a good while...)
5. But (reasonably) there's no built-in usable user, you need to create it with cloud-init
6. Well, poke a bit in the image, try to set a plain text password for the default user, but for some reason it doesn't work. Funnily enough, the default user does not appear in /etc/{passwd,shadow}?
7. ... calling it a day, it's late

So technically this can work. My major issue, besides finding an easy way to provide cloud-init configuration (I'm leaning towards just adding stuff in /etc/cloud. You are supposed to only do that if you are a distro, but... why not?)... is that it would be nice to get this to work with no wired connection, and of course, who would ship wpa-supplicant or whatever in a cloud image? So probably will need to bake in a few .debs too... Maybe time to look into usermode ARM qemu and binfmt trickery to be able to do things comfortably in a chroot from my workstation.

OK, made some major progress today.

I have a command-line tool that can download cloud images, boot them using qemu-kvm, configuring port forwarding, etc. I've created a branch hardcoding aarch64 stuff and qemu. I can boot that, ssh in, then install firmware and network-manager. After that, I shutdown, convert the qcow2 image to raw, dd it to the external drive, boot the Raspberry with it... and I can log in at the console, configure wifi and get a network connection.

Now, scripting the installation of packages, configuring the wifi, and setting a persistent SSH tunnel should be reasonably straightforward. With that, I can dd in an image that will boot, and which I'll be able to access via SSH as long as it is connected to Internet (even on "foreign" networks, if I preconfigure wifi).

So with that, I should have a method to provision Raspberries without ever plugging anything other than power into them. And I guess I could store the image somewhere, so reprovisioning would be as easy as downloading the image and using a dd-like GUI tool to image.

Aaand further testing reveals ugly stuff. This was all to run newer bulds of TVHeadend on a Raspberry with a TV HAT, than the TVHeadend packages present on LibreElec.

Well, these packages are only available for Ubuntu (and I ran into some issues getting Ubuntu to work with this provisioning scheme)... and Debian 11, not 12. So I backtracked to Debian 11 and then...

The TV HAT needs some trickery that is not present on Debian, it's only on Raspberry PI OS.

So I could go back to Rasperry Pi OS- the legacy version, to get Debian 11... and do all provisioning manually... or swap the TV Hat with a USB tuner card I have in a different Raspberry.

I'll probably go to the later option, because I'd like to "publish" this provisioning method. It's quite pleasant.

Published the first part of this "method": https://github.com/alexpdp7/cloud-run

This is a tool I use to download cloud images and run them- it's quite handy. I added support for alternate architectures, using qemu CPU emulation. With this, you can boot the aarch64 Debian image you want, make changes, convert it, and dd it to a USB drive that can boot (with UEFI firmware), on a Raspberry.

Now, if I get some time, I'll automate the provisioning and some phone home capabilities... and publish that in a separate project.

And I succeeded now in running through the entire process by following instructions I posted to:


It would be possible to script everything so you could run a script with a few parameters; host name, wireless network configuration, etc. and get an image out.

Also, I haven't done the reverse tunnel yet.

Drizzt321 said:

Doesn't the RPi Flasher already offer ways to fill in and pre-set things like hostname, wifi config, user/pass, etc?

Unfortunately the latest Raspbian based off Bookworm did away with the /boot/wpa_supplicant.conf for auto-wifi setup. But there are some threads below for some ways others have done it. Likewise, the userconf.txt on first-boot to add appropriate user/pass, etc.

And also ways to run some commands on first boot, to do things like auto-update and auto-install certain stuff (or download a script from an endpoint, run it to do all that stuff).

Raspberry Pi Documentation - The config.txt file

The official documentation for Raspberry Pi computers and microcontrollers

www.raspberrypi.com

Click to expand...

Actually, the ^^ link I think only allows us you to do things via cmdline in the kernel boot, which is not very friendly...

Drizzt321 said:

Raspberry Pi Documentation - Configuration

The official documentation for Raspberry Pi computers and microcontrollers

www.raspberrypi.com

Click to expand...

^^ this one requires ethernet and being able to access the network the Pi is plugged to. It mentions the imager solution which adds wireless, though.

Drizzt321 said:

bookworm - what in place of wpa_supplicant.conf and dhcpcd.conf - Raspberry Pi Forums

forums.raspberrypi.com

Headless Wi-Fi setup without the RPi Imager: bootfs/wpa_supplicant.conf not supported since Bookworm

From the docs: Previous versions of Raspberry Pi OS made use of a wpa_supplicant.conf file which could be placed into the boot folder to configure wireless network settings. This is no longer poss...

raspberrypi.stackexchange.com

Click to expand...

Hah, one of those links points to future support for cloud-init, which is precisely what I'm trying to do.

I dunno, as I mentioned, I'm merely playing with this. I think the imager solution is the quick and easy one, and it'd be good enough for my purposes. However, I might spend this a bit, because it's interesting (it really applies to any kind of hardware- I think dd'ing the cloud image to any boot drive would work with less effort on other devices, such as a traditional x86 system). It also has some advantages like being able to test locally in a VM (albeit with ARM, it's very slow if your workstation is x86).

If I can package nicely this, and sort things out like a systemd service to reverse tunnel back into the system into a foreign network... I could deliver something useful. No one will ever use it, but what about the fun?

I am aware of Tailscale. I would rather avoid a third-party service. I could use Headscale, but I already have two VPN setups for different purposes that I could use. They are not as nice, but they are already set up and working.

I kinda like the idea of playing with ssh for this.

OK, I got the whole setup automated. I won't do an automated tunnel for now, but I got a script that downloads a Debian 11 cloud image (the software I want is not available yet for Debian 12), starts it up in qemu with emulation and does the whole setup:

• Configures my ssh key in a user account with sudo
• Installs all necessary Pi firmware (for wifi)
• Configures wifi networks from a file
• Also can run other scripts (I got one that does my provision, basically install PVR software)

Then it shuts down the VM and converts the VM image to raw format. You dd that to an external USB drive, and that's it.

That's good enough for my v1. The nice thing is that in theory this works for any kind of hardware- it would be even easier and faster on a conventional PC.

Oh, it won't be easy to do (everything is posted to the public repo above). There's a few things hardcoded to ARM64, but x86 should be easy. Plus, less packages to install, and most importantly: no CPU emulation.

I don't have any spare hardware to test. The main ugly thing is that whereas an external USB drive in a Pi is "reasonable", booting with an external USB drive on a conventional PC would be ugly.

Cloud images are really nice; they come with cloud-init, they are fully installed... I'm surprised they are not used more for bare metal. I suspect that hooking CloneZilla to PXE boot and dd an image would not be so difficult...