docs: update instructions for basefile creation to include capabilities When creating the basefile via tar without `--xattrs --xattrs-include='*.*'`, the resulting basefile doesn't provide capabilities as used and needed for example by ping(8), also see https://bugs.debian.org/881829 While at it, also exclude /var/lib/apt/lists/ files, to further reduce the resulting basefile. Closes: https://github.com/grml/grml-live/issues/143
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
Drop file-rc support file-rc used to be the init system up and until including Grml stable release 2014.11, starting with beginning of 2016 Grml switched to systemd instead. The last Debian release that used to have file-rc available was Debian/stretch, which is EOL and we don't support it neither anymore. So, good riddance!
grml-live.txt: output dir mount options; manifold Explain that the output dir shouldn't be nodev, noexec or nosuid (some packages may fail to configure correctly with nosuid even if no problems are immediately apparent with the default builds). Improve the section on reverting manifold.
grml-live: isohybrid is the default, reflect that. While isolinux's "manifold" mode was used by default a long time ago, Grml switched to the isohybrid method in late 2011, mostly due to manifold being incompatible with UEFI systems. Documentation and configuration files weren't updated at that time, though. Do it now.
SW: use Debian kernel packages instead of our custom Grml ones Maintaining and keeping our linux-image-i386-grml + linux-image-amd64-grml packages requires manpower we currently don't really have. Instead let's see whether switching to the kernel packages provided by Debian fits our needs. (This might not be the case if we need different configuration options, defaults, extra patches or the release cycle doesn't fit for us, but it's worth a try, so let's find out.) See https://github.com/grml/grml/issues/139
Switch from aptitude to apt-get as package manager in package list So far we used "PACKAGES aptitude" to use aptitude as package manager. FAI's install_packages supports different commands (package managers) though, see `install_packages -H`: % install_packages -H | grep -e '^\s*aptitude ' -e '^\s*install ' aptitude aptitude -R -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confnew install install apt-get -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confnew --fix-missing install FAI versions until 5.3** support ignoring packages via: | PACKAGES install | | packagename- We can use that feature in the IGNORE class to avoid e.g. the installation of the partimage package which is currently unavailable in Debian/testing and therefore would fail the build (because of aptitude's #835372 behavior change). ** NOTE: FAI v5.3 is broken regarding this behavior, so we've to use FAI 4.3.1+deb8u1 from jessie to use that feature (at least until it's restored/fixed again).