Re: Building debian-live for Raspberry Pi
Hi Roland,
your mail brought me back on track with this background project.
On Thu, Sep 04, 2025 at 02:33:02PM +0200, Roland Clobus wrote:
On 26/08/2025 20:53, Marc Haber wrote:
I am trying to build a live image for the Raspberry Pi. The idea is
to have a write protected system that I can use to protect my GnuPG
key. Target medium is an M.2 SSD in an USB enclosure that has a
write-protect switch.
live-boot additionally has some kernel commandline options to mark the
filesystems read-only: 'read-only' (components/0020-read-only)
That will only protect the system once it is running, but yes, I'll make
a note to use that. But I'll probably have a second medium that can be
written to.
I have not quite understood some of debian-live's details yet.
When am I supposed to delete everything and start over again with lb
config, and when is it okay to edit files in config/? From what I
understand, some settings of lb config can result in multiple
changes inside config, so I am probably safer off by starting over
every time again until I know better what I am doing, right?
Although initially the lb sub-steps were designed to be independent,
there currently is no test to validate/ensure that.
Doing a complete rebuild ensures that there are no remaining artifacts
of a previous build.
I preferably use 'sudo lb clean --purge;lb config;sudo lb build' when
I have a config prepared, and can recycle that.
Otherwise: 'sudo lb clean --purge;rm -fr * .*;lb config --config
mygitURL;sudo lb build' for a fully clean build.
lb config --config git pulls the entire tree from git and I can have
arbitrary things committed there? That is neat as well. I bet you have a
nifty .gitignore as well that allows me to commit the important parts of
the config tree while ignoring the things are are just used to build?
To speed things up, you'll need either your local mirror (which you
appear to have) or a proxy. See also the Wiki page I wrote:
https://wiki.debian.org/ReproducibleInstalls/LiveImages
More speed-up: use /dev/shm
The build process is very much CPU-bound when doing it inside qemu-user.
Neither the SSD nor the Network is an issue here. And yes, I have an
apt-cacher-ng in my home network (at least when I am at home).
I currently use this shell script to initiate build:
...
--apt-recommends false: I wouldn't activate that early during the
image building investigations, as the recommends are quite often
really helpful. You can turn that on after the basic structure of your
live system is finished.
That is good advice.
--mirror-XXX-security: you were describing a read-only system, so the
security elements will be downloaded to the overlay, taking away
memory.
But otherwise I would have a read-only system that even still has
security vulnerabilities that were already fixed on the date the image
was built? Or am I missing something?
I am currently using this on an amd64 system with qemu-user-binfmt.
Is that a valid way to build a live image?
Yes, but cross-building is slow. There is a huge optimalisation gain
possible, but my development time is limited :-)
I understand. So I'm probably better off with moving images.
Can I influence the partitioning that live-build puts into the hdd
image?
See also the open MR from josch, for building for the MNT Reform (also arm):
https://salsa.debian.org/live-team/live-build/-/merge_requests/420
Also, good reading. Made a few ndes from there.
Additionally there is an open MR from dev-jam, about support for hdd
images (which are currently not well tested)
But hdd-images do work, dont they?
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Reply to: