-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explore the use of rpi-imager on cli mode #6
Comments
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:
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 After the "burn" step, the On Windows, I presume there are similar schemes involving drive letters. Your example for Linux assumes the second disk to mount will be at 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 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 Assuming I'm not building a large house of cards on very little evidence, if 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! |
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 (Fedora1), 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! An equivalent is possible with RaspBerry's Bullseye: 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 Footnotes
|
Hi,
apologies as I don't have too much time to investigate this now, but this sounds like something you might be interested in. Probably you already know but rpi-imager has a cli mode that would be useful for even more automation
This is what i am doing to burn an image to SD card
rpi-imager --cli --debug Descargas/2022-09-06-raspios-bullseye-armhf.img.xz /dev/sdb
HOWEVER: It doesn't seem to have an option to point to the file which stores the advanced options that allows to define user, enable ssh, wifi, etc. This file is
$HOME/.config/Raspberry Pi/Imager.conf
. Not sure why Raspberry pi does not provide an option to point to this file?In any case, it would always be possible to first burn it like this then use the "old" method for configuring ssh, etc, that you also describe on this repo.
The text was updated successfully, but these errors were encountered: