On Sun, Feb 02, 2020 at 10:43:37PM -0800, Vagrant Cascadian wrote: > On 2020-02-03, Paul Wise wrote: > > On Sun, Feb 2, 2020 at 5:51 PM Phil Endecott wrote: > > > > > Image-based installation methods are currently very hacky. After > > installing packages, you will have system-specific files created (like > > /etc/machine-id or OpenSSH private keys). The Debian live/cloud images > > have to workaround that by deleting the files after the install is > > created. Probably that set of deletions needs to be synced between > > Debian live/cloud and any future ARM images (not sure if they are > > synced yet). The correct way to do this would be for packages to have > > a "generically installed" state in dpkg/apt, which would prevent them > > from creating system-specific files. More info about this is in the > > linked discussions: > > > > https://wiki.debian.org/ReproducibleInstalls > > https://wiki.debian.org/SystemBuildTools#Discussions > > I have been meaning to explore making live images for arm devices using > the concatenateable images method used by debian-installer. Though, that > method has limitations too, as some devices load files off of a > partition, some off of raw device offsets, some a combination of those > methods. Some require MBR partition tables, some require GPT... it's a > big world out there. The great thing about standards, is...
Andre Przywara made a nice talk at FOSDEM 2019 about booting on multiple devices using the same image: https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/ When GPT [0] is limited to 4 partitions it fits in the envelope of MBR. With fdisk it's possible to create such configuration, I could try to add the needed support to the D-I if that opens to new combinations. Regards, Dom [0] https://en.wikipedia.org/wiki/GUID_Partition_Table -- rsa4096: 3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13 ed25519: FFB4 0CC3 7F2E 091D F7DA 356E CC79 2832 ED38 CB05
