Author: noisycoil Date: To: David A. Wheeler via Tails-dev CC: The Tails public development discussion list, David A. Wheeler Subject: Re: [Tails-dev] Tails for arm64 (with support for Apple Silicon)
Hi David,
Yes, I thought you'd already mentioned that. The quite long email I sent last week detailing some of the differences between the Apple Silicon and Raspberry Pi builds was also in response to you.
Something which I didn't address there is the possibility of cross-arch (!) images. Although I believe literally no distribution in human history has attempted something like this, I think that, paradoxically, building an arm64+x86_64 live image of Tails might be easier than building an image that works properly on two arm64 platforms with conflicting software requirements. If two platforms, one x86_64 and one arm64, boot via grub-efi at UEFI's removable path, then the latter is different for the two architectures (EFI/BOOT/BOOTAA64.EFI for arm64 and EFI/BOOT/BOOTX64.EFI for x86_64), so the two boot paths wouldn't conflict with each other and could coexist on the same medium. Each version of grub could then be configured to load the kernel and initramfs for its architecture, and live-boot (I think this is the right component) could be configured (or tweaked) to load the squashfs filesystem from an arch-specific path.
As for persistence, one could keep the behavior of arch-dependent and arch-independent files separate. For instance, one could share dotfiles, network configurations, greeter settings, etc. between architectures and create two separate "additional software" repositories on persistence storage, one for each arch.
A few downsides to this approach:
- It would double the size of the image, uselessly or almost so for most users
- It would require an almost-complete rewrite of the image-building process (live-build is unable to build this kind of arch-hybrid image)
- It still doesn't solve the issue of software incompatibilities between different arm64 hardware (see one of my previous emails for details on this), which of course has a higher priority and may not have a solution at all
- Sure as hell it would create a lot of issues as soon as, e.g., the system starts to store arch-dependent files as dotfiles (think of caches or binary config files!), and good luck to who has to deal with that
In the end it would probably be easier to make "Backup Persistent Storage" selective and allow the user to backup arch-independent files to a USB drive hosting a version of Tails for a different arch.
