Closed jedahan closed 11 months ago
This assume custom.toml
is any (partial? full?) cloud-init file. I haven't gotten to digging that far yet.
What would it take to support per-boot updates?
https://cloudinit.readthedocs.io/en/latest/explanation/events.html#apply-network-config-every-boot
custom.toml
is just an experimental thing in case cloud-init doesn't work out. There are no plans to support it and it will be removed after cloud-init is added.
Outside of the specific implementation I mentioned (with custom.toml), is there generally a way to update the wifi settings after first boot via the sd card with cloud-init?
Not right now, no.
I should clarify that there's no supported way. There's nothing stopping anybody from implementing their own preferred scheme. Getting basic cloud-init functionality isn't too difficult and google should give plenty of examples. You can also tell systemd to run a specific script on startup by editing cmdline.txt and providing the script in the boot/firmware partition. That approach is how rpi-imager works, if you need a reference for how to do it.
Thanks for the context.
If I was interested in extending rpi-imager's firstrun.sh to create a supported way, anything else I should look out for? Where would be the most appropriate place for discussion and potential pull requests?
(Likely something as simple as cp /boot/*.nmconnection /etc/NetworkManager/system-connections && rm /boot/*.nmconnection
)
Why would that be better than cloud-init?
Just to add a bit of context, so it doesn't sound like I'm just dismissing a potential quality of life improvement for no reason..
When we had a few changes like turning on SSH or configuring wifi, dropping files into the boot partition was a quick and dirty solution. However, it has some drawbacks.
So should we update rpi-imager any time the OS changes and pray that all users always use the latest version? How would rpi-imager know what the right approach is?
custom.toml addresses only addresses the first point.
As a de-facto industry standard, cloud-init should address everything and will be a better long-term solution overall.
Yeah I’m happy to help with cloud-init if that’s the best way forward, just do not have experience with how it’s integrated with raspberry pi OS right now, so trying to figure out what’s needed to enable per-boot updates support, and how to get cloud-init to read updates from /boot
No help or discussion needed, it's all on the todo list already. It's just a matter of getting around to it. We've just launched the pi5 and the bookworm release, so as you can imagine, things are a bit busy right now.
I can't just merge proposed changes without fully understanding and testing them. This isn't something that can be rushed along.
Sorry for reviving this issue @XECDesign, but I just wanted to understand the situation a bit better. The initial config appears to be quite confusing at the moment.
If you use the official imager tool, it will generate /boot/firstboot.sh
which calls /usr/lib/raspberrypi-sys-mods/imager_custom
to configure the system, with fallback to doing things manually in case the imager doesn't exist. The imager will use raspi-config
for WiFi, while the fallback will just set /etc/wpa_supplicant/wpa_supplicant.conf
, which no longer works on Bookworm (12) according to official docs. Should I understand that the fallback is for the old Bullseye (11), and the "correct" way to do it for Bookworm (12) is via the imager? I've been reading some people successfully configure WiFi on Bookworm by just setting wpa_suppplicant.conf
, so I am a bit confused here...
And lastly, on the cloudinit
vs. custom.toml
part. it seems like the second init script /usr/lib/raspberrypi-sys-mods/firstboot
checks for a custom.toml
and passes it to /usr/lib/raspberrypi-sys-mods/init_config
if it exists. This script will then parse it and invoke the imager just like above. I saw no trace of cloudinit support, and no custom.toml is generated with the official imager. Should I understand that the former is not implemented yet, while the latter is just an experiment in case cloudinit support cannot be added?
Thanks a lot!
Should I understand that the fallback is for the old Bullseye (11), and the "correct" way to do it for Bookworm (12) is via the imager?
The fallback is for very old images which didn't have imager_custom
.
I've been reading some people successfully configure WiFi on Bookworm by just setting
wpa_suppplicant.conf
, so I am a bit confused here...
That doesn't have a chance of working on a Raspberry Pi OS Bookworm image, so there's probably some missing context.
Should I understand that the former is not implemented yet, while the latter is just an experiment in case cloudinit support cannot be added?
Yup, spot on.
It looks like
/boot/custom.toml
is applied on firstboot, but if I have an SD card of an existing image, and move from one location to another and want to update the wifi, can we have/boot/custom.toml
apply on every boot?