Comments (2)
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:
-
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
-
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 (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
-
this is so cool, didn't know there was a Fedora ARM-based distro! And its supporting a number of Raspberry Pis indeed! ↩
from pibuilder.
Related Issues (8)
- Recommended repo tags HOT 1
- Script 04_setup.sh : "Could not resolve host: download.docker.com" HOT 3
- [Question] NTP Configuration as part of PiBuilder HOT 2
- Cannot install homeassistant-supervised HOT 6
- Raspberry Pi Randomly looses Network Connection HOT 8
- Autologin Issue HOT 9
- menu.sh fails when nodered is selected. HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pibuilder.