Explore the use of rpi-imager on cli mode about pibuilder HOT 2 CLOSED

I wasn't aware of that so thanks.

My reaction, though, is that this probably raises more questions than the current arrangement.

Think about it like this. The basic structure of PiBuilder is:

1. You have an existing support host onto which you:

   • clone PiBuilder
   • do any PiBuilder-specific configuration
   • "burn" the starting image to your chosen media
   • transfer what PiBuilder needs to the boot volume

2. Move the chosen media to the Pi, apply power, run the scripts in order.

Everything in step 2 is a known quantity because, aside from things like Buster/Bullseye differences, I can assume that all Pis are pretty much alike.

That isn't true for step 1. It's all different depending on whether your support host is Linux, macOS or Windows.

My support host is a Mac. Both before and after the "burn" step is complete, the Mac sees the whole SSD as /dev/diskN where N is a digit that can really only really be determined reliably by running another tool like diskutil, and where guessing poorly means erasing something you didn't mean to clobber. Both Raspberry Pi Imager and BalenaEtcher GUIs "solve" that by presenting a device list.

After the "burn" step, the boot partition is /dev/diskNM where M is another digit and another trip to diskutil. But the Mac makes that bit easier by auto-mounting the boot partition as /Volumes/boot (although it can get hairy if you already have something mounted at that path).

On Windows, I presume there are similar schemes involving drive letters.

Your example for Linux assumes the second disk to mount will be at /dev/sdb with the boot partition turning up at /dev/sdb1 but still needing to be mounted, by hand, before the PiBuilder files can be transferred, right?

So, heaps of variation where I don't have the ability to test on Windows and where, while I could test on Raspbian, that's the only flavour of Linux I have available and that's just the tip of a veritable Linux iceberg.

It's sort of "I need to draw the line somewhere". Above the line is the user's responsibility, below the line I do my best to have PiBuilder take responsibility.

I hope that makes some kind of sense.

But, getting back to $HOME/.config/Raspberry Pi/Imager.conf, that might be Linux-specific. I've definitely run Imager on my Mac. $HOME/.config exists but nothing like Raspberry Pi exists within that.

On macOS, the basic GUI behaviour is to launch the app, choose the source image, choose the target volume, and click the button. That last step chucks up a security dialog and, fairly often, that's the app requesting permission to launch a helper with elevated privileges. If so, that could well be invoking rpi-imager --cli.

Assuming I'm not building a large house of cards on very little evidence, if rpi-imager --cli is indeed launched via the equivalent of sudo then $HOME will be root's home - which (mostly) doesn't exist on macOS. You can activate the root account if you wish but it's frowned upon. Thus, the reason why I'm not seeing an Imager.conf file on my Mac might be because there was nowhere to put it.

See what I mean about cans of worms lying about all over the place in the "above the line" environment. Makes me itch.

I've chopped and changed a bit in my own practices. I started with Balena Etcher, then switched to Raspberry Pi Imager because it seemed to be more reliable.

Recently, following on from the mechanisms added to Imager for user-other-than-pi and other means of setting up WiFi credentials etc, I've gone back to Etcher. I prefer the simplicity of having a sets of credential files (users and WiFi), all with properly-encrypted contents, where I move the combination I want into place before copying onto the boot partition. I think Imager has gotten too smart for its own good - certainly too smart for me. Really irks me if I boot a Pi and can't login because Imager has remembered something I did as a test two weeks ago where I've long forgotten the password. Very secure, of course. Bah!

from pibuilder.

Thanks for the time into the detailed reasoning, appreciate it.

Yes, I see your point about the multi-system setup. Writing (and testing) a good script that can reliably (and graciously in case of error) work in such a number of setups would definitely be too much of an enterprise

I am only worried about Linux usecase so I guess what I am looking for is something even faster, all CLI-based, including the burning process. But I may as well live with having to use the GUI for burning the image, not a big deal neither.

Actually, what I was also side-looking (in the sense that I got "side-tracking". Not native English speaker, so not sure I can say that? 🙃) whether installing some apt packages (those little CLI apps that make life easier on the shell: vim, ag, zsh, aliases, etc. ) was possible. I see that there's a a number of options and tools out there. For example:

Download a Rpi image (Fedora¹), mount it in the host computer, login as root into it, install stuff from repo packaging system (!), copy stuff on-to it, etc; and finally "burn" it into the flash card so you can boot the Rpi with the most up to date and customized system!

https://raspberrypi.stackexchange.com/questions/855/is-it-possible-to-update-upgrade-and-install-software-before-flashing-an-image

An equivalent is possible with RaspBerry's Bullseye:

https://raspberrypi.stackexchange.com/questions/855/is-it-possible-to-update-upgrade-and-install-software-before-flashing-an-image

This allows for pretty cool automations. This looks awesome, I think I will give it a try

https://github.com/cinderblock/RaspberryPi-Image-Edit

Other approach out there is this, but too me it looks right now a bit too much complex for what I want (and also don't want to get sidetracking now into installing this on Fedora -its debian based-)

https://github.com/RPi-Distro/pi-gen

from pibuilder.