It also breaks your system 'cos it pulls in glibc from ceres... *slow handclap*

See also https://forums.debian.net/viewtopic.php?f=20&t=114130

So why does the Devuan libvirt-daemon package need stuff from backports?

apt info libvirt-daemon

And which other backports are installed?

aptitude search ~S~i~Astable-backports

(You might have to replace stable- with chimaera-.)

So I would check for any relevant man pages:

 $ apropos machine-id
machine-id (5)       - Local machine ID configuration file
systemd-machine-id-commit.service (8) - Commit a transient machine ID to disk
systemd-machine-id-setup (1) - Initialize the machine ID in /etc/machine-id
$

And then

man machine-id

To save you time:

So perhaps try that?

# ln -sf /var/lib/dbus/machine-id /etc/machine-id

Or just make one up and hope the machine-id Police don't come knocking...

EDIT: this may be worth a bug report to Devuan, looks like no package supplies that file since systemd is supposed to generate it. I think it popped up recently in another thread IIRC.

Is your login session okay?

loginctl session-status

Symlinking /dev/random to /dev/urandom is a better solution:

# /etc/udev/rules.d/00-random.rules
KERNEL=="urandom", PROGRAM+="/bin/rm -f /dev/random", SYMLINK+="random"

Reference: https://www.2uo.de/myths-about-urandom/

But the best solution is probably to switch from SLiM to a display manager that actually supports login sessions correctly.

Early KMS must be disabled for the logo to show; ewaller was just noting that this is suboptimal for Intel graphics.

Distro: Devuan

Or you could file a bug report for this against conky (upstream would be best, remember to test the latest release first to see if it's already fixed) or cut the information out of /etc/os-release but I really don't see the point of using a dynamic status indicator to display static information.

A pin priority of 100 would ensure that the package is kept updated from unstable, just as if it was a backport.

+1

@OP, if you want bleeding edge software just use unstable.

Yeah, they all do that mate. Theme SNAFU. Try another theme if you're allergic to error spam. Do you notice any actual problems?

I think the machine-id is supposed to be generated by systemd these days but you could symlink to to /var/lib/dbus/machine-id if you want a valid ID. See machine-id(5) for more on this.

Yes, that's right.

Yeah, well De{bi,vu}an is for experienced users so it doesn't need those hand-holding tools.

At least the bullseye installer now uses a @rootfs subvolume for btrfs; the old installer just used to dump the whole filesystem straight onto the root partition, which was irritating.

^ This is not clear.

*What* does not show these files? With which program are you attempting to view them?

What do you expect to see? What do you actually see? Please explain in as much detail as possible.

@OP: so boot into the snapshot from GRUB (change rootflags=subvol=@ to rootflags=subvol=btrfs/snap_20211015) but remember to either edit the / line in btrfs/snap_20211015/etc/fstab so that the subvol= bit is correct or just delete that line and set the parameters via /etc/default/grub instead.

Once booted into the snapshot mount the btrfs partition and move the snapshot:

# mount /dev/sdXY /mnt
# mv /mnt/@{,.orig}
# mv /mnt/btrfs/snap_20211015 /mnt/@

Then reboot again.

If that all works you can remove the original root subvolume:

# mount /dev/sdXY /mnt
# btrfs subvolume delete /mnt/@.orig # any nested subvolumes will have to be deleted first; rm -r might be quicker :-)