What does that mean, exactly?

Some UEFI firmware implementations are so broken that they will only start Windows' bootmgfw.efi loader. There are workarounds for that though.

See also https://www.rodsbooks.com/efi-bootloade … ive-naming

Yes: https://www.debian.org/releases/stable/ … ecure-boot

Yes. EDIT: but some UEFI firmware implementations won't allow it even though it is part of the official specification.

No.

The Devuan installer should use /boot/efi (not "/BOOT/EFI") for the EFI system partition. GRUB's core.img (grubx64.efi) is stored on the ESP rather than the disk (or partition) itself for UEFI systems.

Check by using

findmnt -o target,source /boot/efi

Or

grep '/boot/efi ' /proc/self/mounts

Because the UEFI version of GRUB doesn't store anything directly on the disk. What used to go on the MBR[0] for non-UEFI boxen is now stored on the EFI system partition instead. So adding a block device (eg, /dev/sda) to the UEFI grub-install command has no effect whatsoever and is ignored. For the UEFI grub-install command the --efi-directory= option performs the equivalent function.

[0] For disks with an MS-DOS partition table. If the disk has a GUID partition table then a BIOS boot partition is needed to hold GRUB's core.img for non-UEFI systems.

Well the systemd developers certainly aren't shy about adding new features (although this pales in comparison to the kernel devs) but they also like to keep systemd as modular as possible so if they wanted a service to control updates then I would expect them to announce systemd-updated. The systemd-sysext service is aimed towards boxen that are specifically designed not to be updated at all in the conventional sense.

And as with almost all systemd features it can be easily disabled and prevented from ever being used with

# systemctl mask systemd-sysext.service

Or by using this command on the system image so it isn't ever loaded at all:

# ln -s /dev/null /etc/systemd/system/systemd-sysext.service

EDIT: from my Arch system:

% apropos systemd|grep update
systemd-system-update-generator (8) - Generator for redirecting boot to offline update mode
systemd-update-done (8) - Mark /etc/ and /var/ fully updated
systemd-update-done.service (8) - Mark /etc/ and /var/ fully updated
systemd-update-utmp (8) - Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-update-utmp-runlevel.service (8) - Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd-update-utmp.service (8) - Write audit and utmp updates at bootup, runlevel changes and shutdown
systemd.offline-updates (7) - Implementation of offline updates in systemd
%

Sup.

It only allows for extensions to /usr & /opt (at the moment) so any "forced updates" could only be applied to those directories, which would limit them to themes, fonts & icon sets. Anyway the paradigm is intended to be used with immutable system images, which would preclude permanent upgrades.

Is the linux-image-amd64 metapackage installed in both systems?

EDIT: or linux-headers-amd64.

Why not? What happens when you comment-out the wtmp & btmp stanzas?

https://salsa.debian.org/debian/logrota … otate.conf

The EFI system partition should be FAT-formatted and have the "boot,esp" flags applied (partition code "EF00" if you're using gdisk). 100MiB should be plenty but some older systems need 512MiB so just make it the same size as the one you already have.

I'm not sure how the installer will cope if presented with multiple ESPs but I would try mounting the one you want to be used under /boot/efi in the installer, that's where the grub-install command will presume the ESP to be located unless told otherwise.

Test with run-parts using root rather than your normal user. Root should have the /sbin directories in PATH, unlike your normal user. Note that either sudo -i or su - (the dash is important) are needed to obtain a root shell with the correct PATH.

You can't shutdown or reboot from the chroot environment. You should have exited the shell and used the installer menu to shutdown.

Did you check that /dev/sda1 was assigned to the EFI system partition before running the commands?

What is the output of efibootmgr -v now?

Check the logs and system mail. I don't use {ana,}cron in Debian so I might not be much help here (sorry).

Can we see the output of this command (as root):

# crontab -l