How to update wifi after first boot? about raspberrypi-sys-mods HOT 13 CLOSED

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.

from raspberrypi-sys-mods.

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.

from raspberrypi-sys-mods.

This assume custom.toml is any (partial? full?) cloud-init file. I haven't gotten to digging that far yet.

from raspberrypi-sys-mods.

What would it take to support per-boot updates?

https://cloudinit.readthedocs.io/en/latest/explanation/events.html#apply-network-config-every-boot

from raspberrypi-sys-mods.

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.

from raspberrypi-sys-mods.

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?

from raspberrypi-sys-mods.

Not right now, no.

from raspberrypi-sys-mods.

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.

from raspberrypi-sys-mods.

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)

from raspberrypi-sys-mods.

Why would that be better than cloud-init?

from raspberrypi-sys-mods.

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.

• The underlying OS itself can also change. /boot has changed to /boot/firmware, but rpi-imager has /boot hard-coded everywhere. Network Manager doesn't use a static wpa_supplicant.conf file, so the previous approach doesn't work at all.
• It's not a standard way of doing things, so it leaves other distros out and requires rpi-imager to try to guess what the right way to do things is.
• Users will always want to do something more than whatever functionality we provide. If we keep extending things by dropping files into the boot partition we'll soon have to support 50 other files that can be added.
• Good luck making sure all of these options work in all the possible combinations

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.

from raspberrypi-sys-mods.

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

from raspberrypi-sys-mods.

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!

from raspberrypi-sys-mods.