Drop support for dmraid dmraid is obsolete and isn't available with Debian trixie (current testing) and newer anymore. See https://bugs.debian.org/1056944, https://bugs.debian.org/864423 and https://bugs.debian.org/1034188 for details.
if multiple mountpoints avail, pick the first one
Improve easter egg for 20 years of grml.org Relevant changes: 1) Don't convert dates via date(1), but provide epoch seconds right away 2) Also use zsh's ${EPOCHSECONDS} instead of forking to date(1) 3) Display easter egg message with einfo iff we are within the birthday range 4) Don't display easter egg only on 2023-09-16 and one month later, but instead have the easter egg appear randomly, with diminishing probability as you get farther from the actual birthday 5) Don't display anything at all when booting with noeasteregg boot option Thanks: Christopher Bock and András Korn
Implement easter egg for 20 years of grml.org % whois grml.org | grep 'Creation Date' Creation Date: 2003-09-16T13:09:06Z Thanks: Christopher Bock for suggesting usage of lolcat
config_cpu: use lscpu for identifying CPU information On arm64 we don't have the CPU information in /proc/cpuinfo as expected by our config_cpu, so its output is broken: | # awk -F: '/^processor/{printf " Processor"$2" is"};/^model name/{printf $2};/^vendor_id/{printf vendor};/^cpu MHz/{printf " %dMHz",int($2)};/^cache size/{printf ","$2" Cache"};/^$/{print ""}' /proc/cpuinfo | Processor 0 is | Processor 1 is | [...] | Processor 13 is | Processor 14 is | Processor 15 is FTR: | # head /proc/cpuinfo | processor : 0 | BogoMIPS : 50.00 | Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs | CPU implementer : 0x41 | CPU architecture: 8 | CPU variant : 0x3 | CPU part : 0xd0c | CPU revision : 1 | | processor : 1 While with lspcu we get the information we're interested in: | # lscpu | grep 'Model name:' | Model name: Neoverse-N1 | BIOS Model name: virt-5.2 CPU @ 2.0GHz So instead of having some hackish /proc/cpuinfo parsing, let's rely on util-linux's lscpu(1). While at it, let's output only the number of present CPUs instead of listing every single one of them, given that there exist systems with >100 CPUs nowadays. :) Thanks: Christopher Bock and András Korn for feedback
imvirt/vmware: don't allow output of grep on stdout To clarify, output of virt-what executed inside a VM on a VMware cluster is `vmware`, and `VMware ESX Server` for imvirt. Thanks: András Korn
Replace deprecated vmware-detect with virt-what/imvirt As of git commit 0c1cd5d0cbee in grml-scripts we no longer ship our vmware-detect binary, so instead rely on virt-what and imvirt. Output of virt-what executed inside a VM on a VMware cluster is `vmware` and `VMware ESX server` for imvirt. Thanks: Christoph Biedl and András Korn for feedback
Drop support for bootlogd We no longer support non-systemd init systems like file-rc, one can run `journalctl -b` nowadays. There's no point in supporting bootlogd given that we don't even ship it any longer. Thanks: Roland Sommer for reporting
running_under_secureboot: update for efivarfs + new mokutil behavior CONFIG_EFI_VARS is no longer available since https://salsa.debian.org/kernel-team/linux/-/commit/20146398c4599147244ed3ffc54f38d07fb8dea3 (tagged initially as debian/5.10.1-1_exp1 + shipped with kernel package 5.10.1-1~exp1 and newer, incl. 5.10.0-12-amd64 as present in current Debian/bullseye). Therefore the kernel module efivars is no longer available on more recent Debian kernel systems, but efivarfs needs to be used instead. The behavior of mokutil also seems to have changed. On systems where SecureBoot is available but not enabled, it outputs "SecureBoot disabled", while no longer returning with an exit code other than 0. On systems where Secure Boot isn't supported (e.g. in VirtualBox) it reports "This system doesn't support Secure Boot" on stderr, with exit code 255. Verified with mokutil 0.3.0+1538710437.fb6250f-1 This work was funded by Grml-Forensic.
Demote unavailability of dmraid from error to warning only dmraid had its latest Debian upload in 2017, the last upstream release dates back to 2010 (see http://people.redhat.com/~heinzm/sw/dmraid/src/) and it has plenty of unresolved bugs. It's furthermore relevant for so called fake RAIDs only, something which is rather exotic and therefore Grml ISOs not including dmraid should just raise a warning, rather than an error message. Thanks to Sipwise for sponsoring my development time. See Sipwise internal ticket TT#121951
The Uni3-Terminus16.psf.gz font is shipped by console-setup-linux nowadays Package console-terminus doesn't exist as such and is only a virtual package (at least nowadays), provided by console-setup-linux
Do not run VirtualBox setup under enabled Secure Boot to avoid errors and startup delays The VirtualBox package from upstream isn't signed for usage with Secure Boot with the Debian kernel. When booting with Secure Boot enabled, then upstream's vboxdrv.service with its vboxdrv.sh executes all kind of Secure Boot related magic like: | /usr/bin/perl -w /usr/share/debconf/frontend /usr/sbin/update-secureboot-policy --new-key This fails and causes a noticeable delay during bootup. Therefore skip execution of VirtualBox setup within our config_virtualbox_setup() when detecting enabled Secure Boot mode, at least until we've a better solution for this. While doing so, move detection of enabled Secure Boot mode into a helper function to avoid DRY code. Thanks: Ralf Moll for the bugreport
Improve VirtualBox shared folders + support vboxdrv service The virtualbox shared folders code couldn't be skipped during runtime, so add support boot option "novboxsf" to skip shared folders setup. While at it reduce code complexity in config_virtualbox_shared_folders() (by returning when not running under virtualbox). Also do not hard code "grml" user to be added to vboxsf group, but rely on $fstabuser instead. If VirtualBox (not the guest additions, but the application itself) can be started on Grml live system, then the /usr/bin/VBox exectuable is present. The vboxdrv driver might not be loaded yet, take care of it via vboxdrv.service. Also add user to vboxusers group. To be able to easily skip it (via boot option "novbox") integrate in grml-autoconfig and not into systemd presets. This work was funded by Grml-Forensic.
VirtualBox shared folders: expect exact match for automation folder name The shared folder for automation usage (`automation` by default) should only be enabled if it matches exactly the expected name. A folder named 'automations' shouldn't trigger automation, so adjust egrep command line. This work was funded by Grml-Forensic.
VirtualBox shared folders: adjust check for detecting shared folder More recent VirtualBox versions provide output like: | 01 - automation [idRoot=0 writeable auto-mount host-icase guest-icase] While older VirtualBox versions listed only: | 01 - automation Adjust the grep command line, to support old and new VBoxControl output. This work was funded by Grml-Forensic.
lvm: start lvm2-lvmetad only if present + support lvm2-lvmpolld lvm2-lvmetad is gone since 2.03.01-1 (and its init script was actually dropped later in 2.03.02-2). Instead lvmpolld is available since 2.02.122-1. While at it improve formatting, as startup of lvm2-lvmpolld (and lvm2-lvmetad if present) displays a message on initial startup which gets in between the "Searching for logical volumes and enabling them:" and the display of present LVM devices, which isn't nice. So properly split them. Closes: grml/grml-autoconfig#10
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: 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. Also noticed that save-config wasn't properly handling the location of the rootfs and overlay mount points, adjusted while at it. Closes: grml/live-boot-grml#10
config_language: rely on console-setup for keyboard + font handling Our old approach with running loadkeys, setting console font and invoking unicode_start via grml-autoconfig is incomplete for nowadays' environments. We tried to fix that by changing the order in which we set up the fonts, runnning loadkeys and finally invoking unicode_start (see commit c820a66a69). But this changed only the behavior on tty1, the other consoles still had problems when trying to display unicode characters (see e.g. `systemctl status` output). Instead when running under systemd rely on console-setup, by assuming /etc/default/console-setup is set up as needed (implemented in grml-live >=0.33.4) and adjusting /etc/default/keyboard according to keyboard=.../lang=... boot options. Finally we invoke the console-setup service. (We might want to handle this outside of grml-autoconfig in the future, but this approach for now guarantees to execute this in the right order and not spit on the console at the end of the boot process). Closes: grml/grml-autoconfig#9, grml/grml#50 Thanks: Darshaka Pathirana for debugging this
brltty: start brltty service instead of invoking /lib/brltty/brltty.sh The /lib/brltty/brltty.sh script doesn't seem to work as such any longer to start the service. When starting brltty via `systemctl start brltty` it at least starts (I'm not sure it's actually working for users of braille devices., but don't know how to verify it on my own). Closes: https://github.com/grml/grml/issues/58
Ensure haveged is running before ssh service is invoked The random number generator might take quite some while until we reach state `random: crng init done`. If ssh service is started *before* crng is done then ssh service startup blocks system boot until enough entropy is available. By starting haveged (Linux entropy source using the HAVEGE algorithm) before ssh service we avoid this. Since haveged is in our GRMLBASE software selection we can assume that it's present by default. FTR, it might be useful to start haveged all the time, but before going that route let's try whether having it for SSH service is enough.