Re: Armbian

[Domenico Andreoli <cavok@debian.org>]

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