Hello Marc, 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)
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.
Using --config allows you to store all relevant settings in a git repo, for easier development of the settings.
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
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.
--mirror-XXX-security: you were describing a read-only system, so the security elements will be downloaded to the overlay, taking away memory.
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 :-)
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/420Additionally there is an open MR from dev-jam, about support for hdd images (which are currently not well tested)
There might be some modifications you can reuse.
Where would I place files that I need to be copied to one of the partitions of the image? I think that I at least need a config.txt and probably a cmdline.txt on the FAT32 partition.
The folders config/includes.chroot_after_packages and config/include.binary might be what you need.
With kind regards, Roland
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature