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
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
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.
GRUB: remove erroneous quotes around kernelopts kernelopts are used by grml-rescueboot to communicate kernel arguments from the host's grub to the grub within the grml ISO. E.g., the host grub boot entry will contains something like: kernelopts=" arg1 arg2 blacklist=foo etc " export kernelopts Currently, grub within the grml ISO will pass this entire string as one single argument to the kernel. Remove the quotes such that the arguments are interpreted as intended. Fixes https://github.com/grml/grml-rescueboot/issues/5
Provide setup files for EFI boot in netboot package The shim + grubnetx64 files need to be available via tftp, using for example a dhcpd configuration which includes: | # UEFI boot with DHCPv4 | option architecture-type code 93 = unsigned integer 16; | | subnet 10.42.42.0 netmask 255.255.255.0 { | next-server 10.42.42.2; | range 10.42.42.100 10.42.42.200; | | class "pxeclients" { | match if substring (option vendor-class-identifier, 0 ,9) = "PXEClient"; | if option architecture-type = 00:07 { | filename "shim.efi"; | } else { | filename "pxelinux.0"; | } | } | } ... or a dnsmasq configuration which includes: | domain-needed | bogus-priv | expand-hosts | domain=foobar.example.org | dhcp-range=10.42.42.100,10.42.42.200,6h | dhcp-option=1,255.255.255.0 # subnet mask | dhcp-option=3,10.42.42.1 # default gateway | dhcp-option=6,10.42.42.2 # domain name server | dhcp-option=28,10.42.42.255 # broadcast address | dhcp-option=42,10.42.1.3 # timeserver preference | dhcp-option=252,"\n" # proxy config | dhcp-match=BIOS,option:client-arch,0 | dhcp-boot=tag:BIOS,pxelinux.0 | dhcp-match=UEFI,option:client-arch,7 | dhcp-match=UEFI,option:client-arch,9 | dhcp-boot=tag:UEFI,shim.efi | dhcp-leasefile=/var/lib/misc/dnsmasq.leases | dhcp-authoritative or quoting from https://wiki.ubuntu.com/UEFI/SecureBoot/PXE-IPv6: | dhcp-boot=pxelinux.0 | dhcp-match=set:efi-x86_64,option:client-arch,7 | dhcp-boot=tag:efi-x86_64,bootx64.efi Then EFI boot via PXE with GRUB is supposed to work fine, while pxelinux provides PXE boot for BIOS based systems. This is related to the EFI boot support within grml-terminalserver, see commit 3154dc (`Support UEFI PXE boot with DHCPv4`). This work was funded by Grml-Forensic.
Refresh Secure Boot support, supporting new 'debian' method Secure Boot mode wasn't reliably working, e.g. failing to boot in EFI mode with disabled Secure Boot, but also hard to debug. Now with our move from our own Grml kernel packages to the official Debian kernel ones (which are signed and intended for usage with enabled Secure Boot) it makes sense to support a proper Secure Boot chain without hacks like we used to do (like relying on and old GRUB binary from Ubuntu which supported booting unsigned kernels). We do NOT enable Secure Boot support by default *yet* though, since we need to get more testing of this and right now we're in the middle of an RC version (2020.06-rc1) and the upcoming new stable version of Grml. Relevant changes: * minimize templates/secureboot/grub.cfg: while it's certainly nice to display only entries that are actually working under Secure Boot, it's annoying to have to maintain yet another place of boot menus. Also if something fails with detection of Secure Boot then it's annoying to have to debug this, instead let's display an error message, inform the user about it and ask for debugging information. Instead introduce a new GRUB theme (/boot/grub/grml-theme/sb-theme.txt) which displays a message that we're running in Secure Boot mode. While at it, unify indention in existing /boot/grub/grml-theme/theme.txt. * move templates/EFI/BOOT towards templates/EFI/ubuntu/BOOT/ to be able to support debian and ubuntu methods at the same time * ship GRUB binaries in templates/EFI/debian/, similar to the ones in templates/EFI/ubuntu * switch Ubuntu's grubx64.efi.signed from grubx64.efi.signed to gcdx64.efi.signed; they differ in what GRUB's $prefix variable is set to: * gcdx64.efi.signed uses boot/grub/ * grubx64.efi.signed uses EFI/ubuntu/ -> the code in grml-live itself was adjusted accordingly and this also enables us to generalize the Secure Boot methods debian + ubuntu to use the same code path * drop templates/boot/grub/grmlenv.cfg: everything what's relevant can be taken care of from inside templates/secureboot/grub.cfg, so let's avoid another indirection. We also moved the detection of Secure Boot into templates/secureboot/grub.cfg and reworked it: while Ubuntu's patches have a C function grub_efi_secure_boot(), there's no ready-to-use way to detect Secure Boot. But the wrmsr command is amongst the list of GRUB's disabled_mods and we can distingiush between exit code 18 (wrong invocation/argument usage) and 30 (Secure Boot forbits loading module). * mention secure boot method in execution prompt/summary to be aware of its (non) presence ahead of execution * update etc/grml/grml-live.conf to properly reflect current state of Secure Boot support Thanks: Jordan Uggla for feedback This work was funded by Grml-Forensic.
Add boot option pnet (Predictable Network Interface Names) We plan to use Predictable Network Interface Names by default. To make that switch easier we added a new boot option "pnet". The kernel command line option "net.ifnames=0" is currently in every boot option (except "pnet") but should be removed when Predictable Network Interface Names works for us. See: grml/grml#127
Switch default mount point from /lib/live/mount/medium to /run/live/medium In commit 0d878d3a679 of live-boot(-grml) ("Simplify mount point handling by using /run/live instead of /lib/live/mount") the mountpath of /lib/live/mount/medium was moved towards /run/live/medium. Commit c6a17c7b41b of live-boot(-grml) provides a backward compatibility rbind mount, but occasionally there seems to be a regression somewhere during boot (see https://github.com/grml/live-boot-grml/issues/10), and the rbind mount will be deprecated and removed before the bullseye (Debian 11) release. Layout changes over time: * /cdrom for old linuxrc approach * /live/image for initramfs layout until December 2012 * /lib/live/mount/medium for initramfs layout since December 2012 * /run/live/medium for initramfs layout since December 2018 Drop support for everything but /run/live/medium and /lib/live/mount/medium, while at it.