Initial arm64 / aarch64 support
Relevant changes:
* arm64 (ARM64 in terms of FAI class) is considered a valid and
supported architecture within grml-live now; updated documentation,
configuration files and zsh completion accordingly
* arm64 was enabled as supported architecture in grml repositories
* the architecture specific grml-scripts + grml-scripts-core packages
got built for arm64 and uploaded to the grml-testing repository
* memtest86+ + syslinux aren't available on arm64, therefore move
memtest86+ to Recommends to avoid ending up with an `Arch: any`
package, also depend on either syslinux or syslinux-efi
* Software related changes in GRML* (other than the obvious
linux-image-arm64 and further arm64 specific packages):
* GRMLBASE:
- grml2usb is I386 + AMD64 specific for now (if we want to use
grml2usb on arm64 as well, we'd need to port it)
- grub-efi-amd64-bin, grub-efi-ia32-bin + grub-pc as well as
syslinux, syslinux-common + syslinux-utils all are also
I386 + AMD64 specific
* GRML_FULL:
- cciss-vol-status, cmospwd, cpuid, grub-pc-bin + ltrace all
are I386 + AMD64 specific (so not available for arm64)
- grml-terminalserver is I386 + AMD64 specific for now (at least
until we ported grml2usb for arm64)
* /etc/grml/fai/config/scripts/GRMLBASE/44-grub: invocation of
grub-mkimage is I386 + AMD64 specific (at least until we identify
whether there's an actual use-case for our generated
/boot/grub/core.img)
* /etc/grml/fai/config/scripts/GRMLBASE/45-grub-images: we use
/boot/bootaa64.efi for the EFI boot image name for arm64, though need
to skip the unavailable efi_uga module and also skipt the i386-pc
architecture, since grub on arm64 doesn't provide /usr/lib/grub/i386-efi
Known TODOs:
* decide official naming for Grml on arm64 (also keep e.g.
`update-grml-rescueboot -t small -a 64` in mind!)
* grml2usb isn't available for arm64 yet, and therefore also
grml-terminalserver isn't available for arm64
* when booting the resulting ISO inside an arm64 / aarch64, the default
terminal seems to start up as /dev/ttyAMA0 (instead of /dev/tty1, as
expected and handled via our getty@tty1.service)
* look into SecureBoot support
Development sponsored by netcup GmbH