case "$(tty)" in
   /dev/tty1) exec startx /usr/bin/dwm ;;
   /dev/tty2) exec startx /usr/bin/i3 ;;
   /dev/tty3) exec startx /usr/bin/startxfce4
esac

^ That starts dwm if you log in at TTY1, i3 from TTY2 and Xfce from TTY3. You can even have all three running at the same time if you want :-)

EDIT: oops, no it didn't. Corrected.

I used https://git.savannah.nongnu.org/cgit/sy … /sysd2v.sh on the systemd unit file to generate this:

#!/bin/sh
# Generated by sysd2v v0.3  --  http://www.trek.eu.org/devel/sysd2v
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
    set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides:       ly display-manager
# Required-Start: $remote_fs
# Required-Stop:  $remote_fs
# Should-Start:   plymouth-quit-wait getty@tty2
# Should-Stop:    plymouth-quit-wait getty@tty2
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Description:    TUI display manager
### END INIT INFO
DAEMON=/usr/bin/ly
PIDFILE=/var/run/ly-sysd2v.pid
START_ARGS="--background --make-pidfile"

^ Copy that into a file at /etc/init.d/ly and run

# update-rc.d ly defaults

Then either reboot or attempt to start it manually with

# service ly start

Disclaimer: untested.

Off-topic: display managers are bloat so why not just add this line to ~/.profile instead:

[ "$(tty)" = /dev/tty1 ] && exec startx

^ That runs startx automatically if you log in to TTY1.

No, I mean that what was /dev/sda when grub.cfg was created has been assigned to /dev/sdb (or another device node) for the failed boot.

But then it wouldn't be possible to keep old kernel versions installed in case of a problem with the new one. Arch attempts to solve that problem by offering both a mainline and LTS kernel package but it's not perfect and there has been some discussion on their mailing lists about moving to versioned kernel images.

Actually their setting must be false by default because the native entries use UUIDs to identify the root partition in the kernel command line. I think the problem must be with os-prober, there are a few old bug reports describing that and I seem to remember a recent post over at forums.debian.net with the same issue. I don't bother with os-prober myself though so I have no experience with it.

Spammy double-post time!

Copied the VM to bare metal and got it configured. The setup is beautiful — sway in Alpine used to have the setuid bit applied but now it relies on seatd instead (which is *much* better than the elogind bloat-monster). The memory usage looks high but that's because the machine has 32GiB of RAM, the same desktop on Arch is over 400MiB at a bare desktop just after boot.

They've even ported over systemd-boot (under it's old name of gummiboot) so I can use a unified kernel image signed with my SecureBoot keys & EFI_STUB booting. Very nice.

Now all I need is for the rtw89 driver to be added to their linux-edge kernel so my wireless card works. EDIT: it's been added for v5.16.7.

I love Alpine, it really is Linux done right (IMO).

So the other distributions all have root=/dev/whatever instead of the UUID, which is why the boot breaks — the block device identifier has changed so the correct root can't be found.

I think the best approach here would be to ditch os-prober completely and build your own multi-boot menu using /etc/grub.d/40_custom to call configfile (ie grub.cfg) in each of the distributions.

Here's an example for Devuan:

menuentry 'Devuan' {
   search.fs_uuid f203d9ec-a53c-4f33-ad2a-222cf8f8dbcd
   configfile /boot/grub/grub.cfg
}

Alternatively just build a complete menuentry, like this:

menuentry 'Devuan' {
   search.fs_uuid f203d9ec-a53c-4f33-ad2a-222cf8f8dbcd
   linux /vmlinuz ro quiet root=UUID=f203d9ec-a53c-4f33-ad2a-222cf8f8dbcd
   initrd /initrd.img
}

^ That uses the /vmlinuz & /initrd.img symlinks that always point to the current kernel version so it doesn't need to be updated after kernel upgrades.

Slackware has similar symlinks in /boot/vmlinuz, /boot/vmlinuz-generic & /boot/vmlinuz-huge with /boot/initrd.gz remaining unchanged regardless of kernel version.

The kernel & initramfs images for Artix are unversioned so they can also be called directly with no need to edit after updates.

No idea about SUSE though, sorry.

And to be clear: this is not a problem with Devuan and there is nothing the Devuan developers can do about it.

EDIT: looking again at the documentation you should check /etc/default/grub in the controlling system and make sure this is set:

GRUB_DISABLE_LINUX_UUID=false

^ That should make GRUB use root=UUID= in the linux line. It should be set by default but perhaps you have changed it to true for some reason. Remember to update the configuration afterwards:

# grub-mkconfig -o /boot/grub/grub.cfg

My apologies. I didn't mean to offend.

Thanks for the suggestion. I need spaces to line up the clock exactly on the centreline, tabs don't quite match. But I suppose it would be slightly cleaner to use mostly tabs with a few spaces:

printf "$(date +'%H∶%M')\t\t\t\t\t\t\t\t\t\t\t\t       %s%s\n" "$state" "$symbols"

Thanks again and apologies to the OP for the diversion.

I would have just

pkill X

Then logged in again.

If you're dropped to an initramfs shell then I don't think /etc/fstab has been read. The problem must be with the GRUB configuration. Please share that here along with the output of lsblk -f. Thanks.

Do you actually have any problems with the keyboard apart from the dmesg spam?

Could be a dodgy cable and/or connector.

Yup, looks like Chrome ate all the RAM. Next time drop to a TTY and use

pkill chrome

Or install earlyoom to kill it from user space before the kernel jumps in and messes things up. Linux really is shit at handling OOM events

EDIT: you do have swap, right? You need swap.

Got Slack:

Interesting release but the default Lilo configuration failed so I had to install GRUB from a chroot and the recommended install takes up ~16GiB, which is frankly ridiculous.

EDIT: for comparison I have an Alpine Linux VM using sway that I'm about to transfer to my hard drive that takes up 882MiB.