[FEATURE]: Set wifi region without wifi connection setup

[Rybec]

Is your feature request related to a problem? Please describe.

I'm developing a system where the default wifi connection is fully preconfigured (as an access point). Accessibility for inexperienced users is a critical priority. I don't expect most users will have sufficient knowledge or experience to change from one network connection to another or to manually set the wifi region. It is mandatory to set a wifi region for wifi to work at all though. If I preset the wifi region in the image itself, I'll have to make and serve one image for every region I expect the system to be used in. If the user sets the wifi region in Imager when setting up the MicroSD card, it requires a new wifi connection to be setup at the same time (and will not save the wifi settings when the fields are left blank), which will supersede the preset one and require the user to log onto the device and manually change networks (at the command line, as this is an ultra low power application that does not include a GUI). Ideally, any setup like this should happen in Imager, but it can't, because the wifi setup requires a new network to be added to set the wifi region.

Describe the solution you would like to see implemented

What I would like to see is the wifi region setting decoupled from the new wifi connection setup, so that the wifi region can be set without adding a new wifi connection. This way, I can deliver an image that does not have a region set, and the end user can set the region in Imager when installing the image, without having to setup a wifi network connection that will break the system.

Describe alternatives you've considered

Maintaining a long list of 700MB+ images, one for each wifi region. (Since I'm intending on hosting this on Github, this is not feasible.)

Limiting the use of this free, open source system intended to be accessible to the general population to people with sufficient technical expertise to change networks or change the wifi region from the command line. (I've already published a free tutorial on how to setup this system yourself, so people with these skills don't actually need the image at all and might prefer to do it themselves so that they can customize it. There's little point in making and distributing the image if it isn't accessible to people without cli proficiency.)

Limit this to a single default wifi region (the U.S., since that's where I am) and ask anyone outside of the U.S. who does not have the expertise to jump through the required hoops to use it legally in their own region to refrain from using the system entirely. (This is currently what I'm doing, because the people I know who want one of these all live in the U.S. and definitely do not have the skills to use it any other way. I'm considering doing a GB version as well, but I really don't want to deal with having to build multiple new images for every release, and I don't want to clutter the Github repo with a ton of massive files.)

Remove rfkill from the image to allow the wifi to work without a region set. (This has potentially serious legal implications, so I'm not going to do it.)

Additional context

I think that covers it. I've run into a ton of painful things working with pi-gen, and I'm not 100% certain the current build of my project works, but I think it is almost done, aside from this one particular hiccup.

Version

1.8.5

[tdewey-rpi]

Thanks for the submission, @Rybec

I'm inclined to accept this feature. You've provided a well-reason rationale and have obviously considered the alternatives, all of which I agree are at best unpalatable.

The path to implementation looks fairly straightforward - mostly just decoupling some controls in our presentation layer, and adjusting the customisation command writer accordingly.

Planned for next major release at the latest.

[tdewey-rpi]

Also, FWIW - have you looked at rpi-image-gen?

[Rybec]

First, thank you! I appreciate it. I hope it is useful to others as well, and not just my own project!

Second, I have not looked into rpi-image-gen. If it is better documented than pi-gen though, I would be happy to try it! I've worked out most of the challenges to my project in pi-gen, but I'm considering forking the original pi-gen and including the modifications for my own project in the fork so that others can make their own custom builds. If that would be significantly easier with rpi-image-gen, I would happily use it instead! The biggest issue I've had with pi-gen is lack of good documentation, so just better documentation would be a strong motive for me to switch.

[tdewey-rpi]

The intents of the two tools are slightly different:

• pi-gen is intended for use by Raspberry Pi engineers to create the variants of Raspberry Pi OS - and it serves us well in this challenge. As a result, it carries a range of implied knowledge (as you've discovered), but otherwise works well.
• rpi-image-gen is intended to be used by everyone (internal and external), and as we flesh it out, we're looking at migrating from pi-gen to rpi-image-gen. So if there's a documentation gap on that project, we're pretty keen to fix it.

You may find some of the changes you had to make in pi-gen are relatively standard workflows in rpi-image-gen.

[Rybec]

That sounds reasonable. I'll give it a try. If migrating isn't too complicated, it sounds like it should be the better choice long term.

On a side note: One big issue I ran into with pi-gen (that may also exist in rpi-image-gen) is the ability to run arbitrary stuff on first boot (it turns out firstboot.sh isn't great for this). I've found a way to do it that I think is reasonable. You can setup system wide cron jobs in /etc/cron.d/. I have a thing I need to do that can't be done during setup, as it requires a particular service to be running on the device that I don't want running on my host machine when generating the image. Because crontab files in /etc/cron.d/ can have whatever names you want, this allows for using @reboot to run them all on the first boot that gets to starting the cron service, and each one can delete itself after running the other jobs it contains, without affecting others that might need to stay there. (I don't have any that need to stay, but other applications could.) Anyhow, maybe rpi-image-gen already has some other mechanic for this, but if it doesn't, this is an option that could potentially be integrated into rpi-image-gen to make this easier in the future. The potential issue here is order of operations, but one source suggested doing something like @reboot sleep 30 && task_you_want_to_run to give a delay to allow whatever services need to up and running time to fully boot before running the task. (As with /etc/crontab, you need to specify the user each job will be run as, so it might look more like @reboot root sleep 30 && task_you_want_to_run, I think. I haven't finished building the first image that uses this, but it should work.) If rpi-image-gen already has a better way to do this though, I would be happy to know what it is!

Anyway, maybe this will be helpful, I don't know. Thanks for the advice! I really appreciate it.

[tdewey-rpi]

My natural preference for such things is to make use of systemd units - they'll fit better with the wider system, and you get some fairly fun powers.

There's a few unit conditions that might be helpful here: ConditionFirstBoot, and ConditionPathExists. You could use either to ensure you have a single-at-first-boot service, depending on your precise needs (I'd probably go with ConditionPathExists, as ConditionFirstBoot makes use of /etc/machine-id, which you may want to preserve across resets, etc).

Thankfully, making those work is fairly simply - just write a trivial debian package that would install the systemd unit, and you're away. I've used nFPM for such things in the past, as it's extremely straightforward to use.

[Rybec]

Interesting. I'll look into that as well. In the long run I really want this to be clean and smooth. I don't know how much more I'll want to do before this is fully mature, but there's definitely more in the works, and that makes maintainability important. (There's also more potential for devices that create their own APs to access content, control devices, and so on, so I may end up adapting this to other projects in the future as well.)