I have a habit of only quoting the relevant sections so as to keep the reply short and the lo exception is irrelevant in respect of the objection I raised.

Absence of evidence is not evidence of absence and the OP's problem is about boot delays caused by ifupdown so switching to NM does not solve that particular problem in any way, it just conceals it.

stfu

No, it says that it's not safe to allow an attempted update when the microcode module autoloads.

Is your system vulnerable to Spectre/Meltdown? Check the /sys values reported by the kernel.

^ Those commands are correct and the OP says it works.

Can we please see the content of /etc/network/interfaces and the output of ip link, thanks!

Please post the output of

grub-editenv list

See also https://www.gnu.org/software/grub/manua … ment-block

But then you have to remember what all the letter options do

The APT commands have lots of options because they are so powerful and can do so much, not sure why you're complaining about that.

Note also that the apt command consolidates the abilities of apt-get & apt-cache and provides a more "user-friendly" interface, it is now recommended over apt-get for Debian buster.

That version is ancient, it was last updated 2019-03-18 and so is full of holes.

If you want kernel 5 then try the Liquorix version, that should be compatible with Devuan:

https://liquorix.net/

I think so, yes. But I'm no expert

It would make more sense not to have it baked in because live updates would not be possible if it was.

The defaults entry should be fine, the kernel knows how to handle FAT filesystems.

This won't be much use 'cos I wrote it myself but here is my fstab:

/dev/nvme0n1p3 /    xfs  defaults        0 1
/dev/nvme0n1p1 /efi vfat defaults,noauto 0 0

As you can see I don't have the EFI system partition mounted automatically because of the fragile nature of FAT and also because it doesn't need to be mounted at all unless GRUB is being re-installed.

Here is how the kernel handles the defaults option:

E485:~$ grep nvme0n1p1 /proc/self/mounts 
/dev/nvme0n1p1 /efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 0
E485:~$

You can also try the genfstab(1) script from the arch-install-scripts package, that will generate an fstab for you (as the name suggests).

Btw I do have a swap partition but I rely on systemd to mount it automatically so I don't need an fstab line

And please note that the fs_file entry (the second field in fstab) should be set to none for swap partitions, at least according to fstab(5).

The Gentoo wiki says that CONFIG_EXTRA_FIRMWARE_DIR should be set to "/lib/firmware" and I think you need to add the actual firmware files to that directory.

If you can't get this working then you could try using the Arch Linux intel-ucode package — that includes a custom initramfs image that will load the µcode if it is added to grub.cfg like this:

   initrd /boot/intel-ucode.img

Just download the package, untar it and copy intel-ucode.img to /boot

OpenBSD is very good at maintaining support for older hardware because they don't try to cram new features into their kernel as fast as possible, unlike the Linux kernel which suffers regressions on an unfortunately regular basis.

@OP: your questions about OpenBSD are off-topic for these boards, perhaps open a thread over at daemonforums.org instead.

Yes.