Re: usermod: group 'systemd-journal' does not exist (only with FAI script)
Revisiting this since I got the same error again even after fixing the root directory permission bits. When I switched from using `$ROOTCMD` calls to plain `chroot` calls it fixed the issue. It seems that `$ROOTCMD expands to use `unshare` which for some reason doesn't play well with a BOOKWORM chroot. -- Markus From: linux-fai on behalf of Markus Rexhepi-Lindberg Sent: Friday, September 15, 2023 11:47 To: fully automatic installation for Linux Subject: Re: usermod: group 'systemd-journal' does not exist (only with FAI script) I got similar errors for Bookworm which turned out to be wrong file permissions for / (top directory) in the basefile I created for Bookworm. I think it was 0700 while it should be 0755. -- Markus From: linux-fai on behalf of Laura Smith via linux-fai Sent: Friday, September 15, 2023 11:31 To: linux-fai@uni-koeln.de Cc: Laura Smith Subject: usermod: group 'systemd-journal' does not exist (only with FAI script) Diese Nachricht wurde eingewickelt um DMARC-kompatibel zu sein. Die eigentliche Nachricht steht dadurch in einem Anhang. This message was wrapped to be DMARC compliant. The actual message text is therefore in an attachment.
Re: usermod: group 'systemd-journal' does not exist (only with FAI script)
I got similar errors for Bookworm which turned out to be wrong file permissions for / (top directory) in the basefile I created for Bookworm. I think it was 0700 while it should be 0755. -- Markus From: linux-fai on behalf of Laura Smith via linux-fai Sent: Friday, September 15, 2023 11:31 To: linux-fai@uni-koeln.de Cc: Laura Smith Subject: usermod: group 'systemd-journal' does not exist (only with FAI script) Diese Nachricht wurde eingewickelt um DMARC-kompatibel zu sein. Die eigentliche Nachricht steht dadurch in einem Anhang. This message was wrapped to be DMARC compliant. The actual message text is therefore in an attachment.
Re: pvscan in udev rules - buster vs bullseye
Hi,
I was affected by the same issue and the suggested patch fixed it.
Thank you Andrew.
Can we add this to FAI? I assume it can be added to fai-make-nfsroot.
Cheers!
--
Markus
From: linux-fai on behalf of andrew bezella
Sent: Wednesday, September 7, 2022 12:07:05 AM
To: fully automatic installation for Linux
Subject: pvscan in udev rules - buster vs bullseye
hello -
i had been experiencing a problem trying to use a bullseye netboot to
reinstall a server's os. the same configuration worked with a buster
netboot.
when a logical volume exists on a metadevice then that lv was being
activated soon after the completion of `mdadm --assemble --scan --
config=/tmp/fai/mdadm-from-examine.conf`. this caused the subsequent
`mdadm -W --stop` loop to fail when it reached that md:
(CMD) mdadm -W --stop /dev/md5 1> /tmp/RhKvizyXZk 2> /tmp/DrTvcNhaf6
Executing: mdadm -W --stop /dev/md5
(STDERR) mdadm: Cannot get exclusive access to /dev/md5:Perhaps a
running process, mounted filesystem or active volume group?
mdadm -W --stop /dev/md5 had exit code 1
(STDERR) mdadm: Cannot get exclusive access to /dev/md5:Perhaps a
running process, mounted filesystem or active volume group?
Command had non-zero exit code
eventually i found the udev rule that triggers the difference. to
revert to the older behavior i copied /lib/udev/rules.d/69-lvm-
metad.rules into /etc/udev/rules.d and applied the following patch:
--- /srv/fai/nfsroot/bullseye-amd64/etc/udev/rules.d/69-lvm-metad.rules.orig
2021-02-22 13:39:14.0 -0800
+++ /srv/fai/nfsroot/bullseye-amd64/etc/udev/rules.d/69-lvm-metad.rules
2022-09-01 19:22:52.426117170 -0700
@@ -75,8 +75,7 @@
ENV{SYSTEMD_READY}="1"
-TEST!="/run/systemd/system", GOTO="direct_pvscan"
-TEST=="/run/systemd/system", GOTO="systemd_background"
+GOTO="systemd_background"
LABEL="systemd_background"
further down it is noted that the direct_pvscan mode is not used and
should be removed. but it seems that since there is no systemd in
fai's bullseye nfsroot it currently is the default. in buster the
method for invoking pvscan is apparently selected at build time and
defaults to systemd_background. if/when FAI migrates to systemd this
may raise its head again.
hope this helps if someone else has a similar issue.
andy
--
andrew bezella
internet archive
Re: GRUB_EFI/10-setup missing --force-extra-removable option?
From: linux-fai on behalf of CSCI Technician Sent: Wednesday, September 1, 2021 22:40 > In scripts/GRUB_EFI/10-setup the final "else" clause does not include > the "--force-extra-removable" option for the "grub-install" command; the > other clauses do have this option. Is this a bug or is there a reason I > don't understand? > If the missing option is intentional, other than customizing this fai > script, any suggestions on a good solution for fixing this in my config? I know that the grub-install version for Ubuntu does not support the "--force-extra-removable" option. Maybe that last else case is intended to cover Ubuntu? -- Markus
Re: grub-install failing while kernel 5.10 and GRUB_EFI
> While upgrading my FAI image to 5.10.1 it also updated the kernel to > the latest one from buster-backports (as expected per my NFSROOT > configuration) which currently is '5.10.0-0.bpo.3-amd64'. While doing > this I noticed that new installs that are using EFI was not booting > after FAI had run. The `grub-install` stage flagged with the > following warning message. This was fixed in version 5.10.3 by Thomas Lange [1]. Thanks Thomas! [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=986820 -- Markus
grub-install failing while kernel 5.10 and GRUB_EFI
Hi,
While upgrading my FAI image to 5.10.1 it also updated the kernel to
the latest one from buster-backports (as expected per my NFSROOT
configuration) which currently is '5.10.0-0.bpo.3-amd64'. While doing
this I noticed that new installs that are using EFI was not booting
after FAI had run. The `grub-install` stage flagged with the following
warning message.
```
grub-install: warning: EFI variables are not supported on this system..
```
This points to that either '/sys/firmware/efi/vars' or
'/sys/firmware/efi/efivars' is not available, I'm not sure which one.
After some investigation I can conclude that '/sys/firmware/efi/vars'
is not available for the kernel version 5.10 while it is for kernel
version 4.19 during a FAI `install`. See the output bellow.
== 4.19 kernel ==
root # echo ${FAI_VERSION}
5.10.1
root # echo ${FAI_ACTION}
install
root # uname -r
4.19.0-14-amd64
root # grep -w CONFIG_EFI_VARS /boot/config-$(uname -r)
CONFIG_EFI_VARS=m
root # grep -A1 "task_updatebase" ${LOGDIR}/fai.log
Calling task_updatebase
Updating base
root # ls /sys/firmware/efi/efivars | wc -l
0
root # ls /sys/firmware/efi/vars | wc -l
35
root # ls -1 ${FAI_ROOT}/sys/firmware/efi/efivars/ | wc -l
0
root # ls -1 ${FAI_ROOT}/sys/firmware/efi/vars/ | wc -l
35
root # cat ${LOGDIR}/shell.log
...
= shell: GRUB_EFI/10-setup =
ainsl: appending to /target/etc/default/grub: GRUB_DISABLE_OS_PROBER=true
Installing for x86_64-efi platform.
Installation finished. No error reported.
Grub installed on /dev/sda = (hostdisk//dev/sda)
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.19.0-14-amd64
Found initrd image: /boot/initrd.img-4.19.0-14-amd64
Found memtest86+ image: /memtest86+.bin
Found memtest86+ multiboot image: /memtest86+_multiboot.bin
Adding boot menu entry for EFI firmware configuration
done
GRUB_EFI/10-setupOK.
...
== 5.10 kernel ==
root # echo ${FAI_VERSION}
5.10.1
root # echo ${FAI_ACTION}
install
root # uname -r
5.10.0-0.bpo.3-amd64
root # grep -w CONFIG_EFI_VARS /boot/config-$(uname -r)
# CONFIG_EFI_VARS is not set
root # grep -A1 "task_updatebase" ${LOGDIR}/fai.log
Calling task_updatebase
Updating base
root # ls -1 /sys/firmware/efi/efivars | wc -l
0
root # ls -1 /sys/firmware/efi/vars | wc -l
ls: cannot access '/sys/firmware/efi/vars': No such file or directory
0
root # ls -1 ${FAI_ROOT}/sys/firmware/efi/efivars/ | wc -l
0
root # ls -1 ${FAI_ROOT}/sys/firmware/efi/vars/ | wc -l
ls: cannot access '/target/sys/firmware/efi/vars/': No such file or directory
0
root # cat ${LOGDIR}/shell.log
...
= shell: GRUB_EFI/10-setup =
ainsl: appending to /target/etc/default/grub: GRUB_DISABLE_OS_PROBER=true
Installing for x86_64-efi platform.
grub-install: warning: EFI variables are not supported on this system..
Installation finished. No error reported.
Grub installed on /dev/sda = (hostdisk//dev/sda)
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.19.0-14-amd64
Found initrd image: /boot/initrd.img-4.19.0-14-amd64
Found memtest86+ image: /memtest86+.bin
Found memtest86+ multiboot image: /memtest86+_multiboot.bin
done
GRUB_EFI/10-setupOK.
...
== CONFIG_EFI_VARS ==
It seems that the 'CONFIG_EFI_VARS' kernel option has been disabled by
the Debian folks for at least the kernel version 5.10 [1] and might be
the reason why '/sys/firmware/efi/vars' is not populated.
Manually mounting `efivarfs` worked for me though I'm not sure if it is
the correct way of doing it. See the output bellow for the hook that
I'm using in my ${FAI} config.
== Workaround hook ==
root # cat ${FAI}/hooks/configure.GRUB_EFI
#!/bin/bash
# Mount efivarfs. Needed for 'scripts/GRUB_EFI/10-setup'.
# Check that we are actually running in EFI mode.
if [ -d /sys/firmware/efi ]; then
mount -t efivarfs efivarfs ${FAI_ROOT}/sys/firmware/efi/efivars
fi
== updatebase ==
While looking through the FAI source code I stumbled upon the
updatebase library which seems to be bind mounting `sysfs` while
${FAI_ACTION} is set to `install`. Should the above hook be implemented
in the updatebase library as well perhaps? It seems that manually
mounting efivarfs is encouraged [2].
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979299
[2] https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt
--
Markus
Re: Remove a defined class
> > Is it possible to remove a defined class during a install?
> Uuuuh. It may be possible but in 2006 we already had this questions
> https://lists.uni-koeln.de/pipermail/linux-fai/2006-November/004613.html
Thanks, I did not manage to find that thread.
> The clean way would be to write a hook with suffix .sh (then it is
> sourced). This hook must remove the class from $LOGDIR/FAI_CLASSES and
> also redefine the shell variable $classes. We use this command in FAI
> for setting $classes
> classes=$(< $LOGDIR/FAI_CLASSES)
This worked out well. I now use the following hook to append _EFI to a
disk class which was defined during task_defclass. My disk classes
always start with HD_ and a BIOS and EFI version of them exists were
the EFI version always ends with _EFI (which makes it scriptable in
this case).
#!/bin/sh
sFaiClassFile="FAI_CLASSES"
sInitDiskClass="$(grep -E "^HD_" ${LOGDIR}/${sFaiClassFile})"
# Check if a EFI based disk class has already been defined, if so exit.
if (echo "${sInitDiskClass}" | grep -qE "^HD_.*_EFI$"); then
exit 0
fi
if [ -e "${FAI}/disk_config/${sInitDiskClass}_EFI" ]; then
# Remove inital disk class.
sed -i '/^HD_/d' ${LOGDIR}/${sFaiClassFile}
# Redefine inital disk class and append _EFI to it.
echo "${sInitDiskClass}_EFI" >> ${LOGDIR}/${sFaiClassFile}
# Redefine the classes variable.
classes=$(< ${LOGDIR}/${sFaiClassFile})
else
echo "A '${sInitDiskClass}_EFI' disk_config was not found. Falling back to
initial disk_config '${sInitDiskClass}'."
exit 0
fi
--
Markus
Remove a defined class
Hi, Is it possible to remove a defined class during a install? `echo CLASS_NAME` defines a class and puts it in $LOGDIR/FAI_CLASSES. Is it enough to just remove the entry from that file to make it not defined? I would like to remove a class being defined via a class script with another class script being run after the first one during task_defclass. This is due to the classes being defined are fetched from a database using a script. I would like to act on the classes being fetched and redefine them if needed. This is originally intended to switch between BIOS and EFI disk classes based on the firmware the computer booted with. -- Markus
