Remove Grml release name from the boot options The Grml release name is shown on top of the additional boot option menu and also in front of every boot option. This limits the readable title length. We decided to remove it. Changed "German Settings" to "Load German Keyboard Layout" because that is what it does (i.e. it runs `grml-lang de`). Also changed the description of some entries as they were cut off, on the boot screen. Closes: grml/grml#10
templates/boot/grub/%SHORT_NAME%_options.cfg: fix missing quotes Followup fix for commit c0460ecbd48f54b5b1895b6fc576efa4ddb54e9e, missing quotes and causing GRUB to not display the menu, as it runs into "out of memory" situation when sourcing the file.
Unify boot options order The boot order and the naming of the isolinux boot menu and Grub boot menu were not in sync. I tried to standardize the boot menu entries, according to the proposal in https://github.com/grml/grml/issues/10#issuecomment-1625729783 Related: grml/grml#10
templates/boot/grub/addons: use chainloader instead of linuxefi As of grub2 2.12~rc1-1 the linuxefi module is no longer available: | grub2 (2.12~rc1-1) experimental; urgency=medium | | [ Julian Andres Klode ] | * New upstream version, 2.12~rc1 | * build-efi-images: Drop linuxefi, using new loaders now | [...] So loading the memtest EFI file then fails with: | error: can't find command `linuxefi'. Use chainloader instead, to boot into the memtest EFI.
Rework memtest handling, incl. usage of latest available memtest file If we try to copy the memtest86+.bin file as shipped with memtest86+ versions <=5.01-3.1, we either copy such an old file from the build directory (grml_chroot), or if that doesn't exist (e.g. because the memtest86+ package isn't installed), we might end up copying an old memtest file from the build host system instead. AS ${BUILD_OUTPUT}/boot/addons/memtest exists already then, we don't update the file any longer (e.g. from a more recent memtest86+ package), and therefore end up with an old and outdated memtest version in BIOS boot, while EFI boot provides a more recent memtest version. This is inconsistent and unexpected behavior. So instead try to use the most recent version of memtest86* files first, and only then fall back to the old memtest86+ <=5.01-3.1 file behavior. While looking into this, I also noticed that until memtest86+ versions <=6.10-2 it used to be named memtest86+x32.bin, while as of memtest86+ versions >=6.10-3 it's memtest86+ia32.bin instead. As we have version 6.10-4 in bookworm/stable and only pre-6 version 5.01-3.1 in e.g. bullseye/oldstable, let's skip any backwards compatibility for memtest86+x32.bin. Furthermore while at it, drop duplicate execution of `copy_addon_file memtest86+x64.bin /boot addons` and `copy_addon_file memtest86+x32.bin /boot addons` to avoid ending up with further duplicate files on the ISO. So related to https://github.com/grml/grml-live/issues/128, we now ship /boot/addons/memtest on each of grml64 + grml32, and respectively only /boot/addons/memtest86+x64.efi on grml64 only and /boot/addons/memtest86+ia32.efi on grml32 only. To rename the files into FAT16/8.3 compatible "/boot/addons/memtest", let's provide a proper return code from within copy_addon_file() if we couldn't find any matching file. Related to https://github.com/grml/grml-live/issues/128 Closes: https://github.com/grml/grml/issues/178
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
grml-cheatcodes.txt: document usage of bootfrom=/dev/disk/by-label* + drop deprecated tohd One can use bootfrom=/dev/disk/by-label/yourlabel or also isofrom=/dev/disk/by-label/yourlabel to avoid choosing the wrong block device. We dropped the tohd feature back in 2016 (see grml-autoconfig commit 0fb27bae), so drop it while at it. Thanks: Csillag Tamas
Use serial console with 115200n8 by default A baud rate of 9600 should no longer be a common default nowadays, so let's set it to 115200 by default instead. Thanks: anarcat Closes: https://github.com/grml/grml-live/issues/130
Secure Boot: update grub and shim binaries Quoting János Pásztor from https://github.com/grml/grml-live/pull/129: After 581da7443c68c362a7677c905ab5c63eb23c5b73 and using the `debian` style secure boot grml will not start on machines with secure boot enabled, but fails with a `signature verification error` After some investigation it turned out that we hit https://bugs.debian.org/925550 with our boot binaries. I have updated them from debian and managed to boot with them properly. While at it, switch from http://ftp.de.debian.org/ to https://deb.debian.org/ which has proper SSL certificate available. Thanks: János Pásztor <model87@freemail.hu> for bugreport and PR
Support Memtest86+ with UEFI Memtest86+ up and until v5.01-3.1 didn't provide (U)EFI support. Starting with v6.00, the file memtest86+.bin no longer exists, but instead there are: * /boot/memtest86+x32.bin * /boot/memtest86+x32.efi * /boot/memtest86+x64.bin * /boot/memtest86+x64.efi So let's start adding support for memtest86 with (U)EFI. Hopefully we don't need FAT16/8.3 compatibility any longer, so let's try using the files as-is. Closes: https://github.com/grml/grml-live/issues/109
GRUB templates: do not set root/chainloader but just exit for boot from next device This pretty much never works for me, while exiting GRUB switches to the next device in the boot order, so let's just "exit" GRUB and name the menu entries accordingly. Closes: https://github.com/grml/grml-live/issues/100
GRUB: drop loopback usage for balder10/FreeDOS. Looks like a relic from the bad, old days. It's certainly not needed any longer, since the initrd16 command can load the file just fine and newer grub versions are not able to load compressed files in such a manner, since the length (+2880) refers to the uncompressed size. Grub will see that the file is smaller than that and error out. If we were to give it the compressed size, decompression would fail due to the buffer being too small.