Wow, thirty minutes! I had no idea I was leaving my posts unfinished for that long. I often pause to look up references, test things in the terminal, etc. before posting, as I want to make sure my posts are accurate. It's easy to get sidetracked.

I understand the reasons for the time limit, and the desire to keep the site code simple. I wouldn't say it's a major inconvenience, I was just offering up another data point.

Devuan/Debian may not be set as the first entry in the EFI boot order. You can use efibootmgr to diagnose and fix this issue. Run 'efibootmgr' on the command line with no options to print the current configuration. You should see a line beginning with 'BootOrder:' followed by a list of numbers. There should also be a listing of boot entries, one per line, starting with 'Boot<number>* <name>'. Here's the output on my system, with only the entry for my main Devuan system shown: (The long string of x's is a censored UUID.)

$ efibootmgr
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0007,0001,0003,0005,0006,0004,0000,2001,2002,2003
[...irrelevant boot entries trimmed...]
Boot0007* debian        HD(1,GPT,xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,0x800,0x100000)/File(\EFI\debian\shimx64.efi)
[...more irrelevant entries trimmed...]

One of the boot entries should be your Devuan system; it will probably appear similar to the entry shown above. Its number should be first in the BootOrder list. If it isn't, then you can fix it with the 'efibootmgr -o' option. (The manpage for efibootmgr explains how.) If your Devuan system is already the first boot option, then your problem unfortunately lies elsewhere.

I came here to search for information on this issue because I noticed today that one of my Excalibur installations had 68 packages held back. Running a dist-upgrade would clear the holds, but would also remove dozens of packages without installing replacements. I'm not sure whether I should wait for this issue to be resolved, or run the dist-upgrade now before it gets any worse. Discussions around the web are confusing and contradictory. Some say to wait, while others say get it over with. Is anyone else dealing with this issue?

Update: The number of held back packages jumped to 120 today. If this continues, it may end up being easier to just reinstall these systems from scratch. I'm kind of surprised no one else is dealing with this issue. Maybe it's because I installed a lot of development libraries when I was building the latest version of GNUstep/libobjc2. I do have one system that has no held back packages at all, but there's almost nothing installed on it but the base system and a simple C+X11 toolchain.

PulseAudio can still emulate it, but virtually nothing uses it anymore. (I think NAS does, but NAS is itself a relic.) Pretty much every piece of Linux software written this millennium uses ALSA, either directly, or through an intermediary such as Pipewire or Jack.

ntpsec is the "default" time daemon that will be installed if you run 'apt install ntp'. There's also the aforementioned chrony, as well as openntpd, which comes from OpenBSD. I just install with ntpsec on my systems since it's the default, and I didn't have a pressing reason to use one of the others. IIRC setup was entirely automatic; I didn't need to edit any init scripts or config files. However, I did run 'dpkg-reconfigure tzdata' to set my correct time zone.

You need to install grub to the disk, not the partition, i.e., 'grub-install /dev/sda' not 'grub-install /dev/sda2'.

There are two versions of grub, grub-efi and grub-pc. The former is for UEFI systems, the latter for BIOS. I don't know how it works if you install Devuan with the automatic installer, but is it possible you got the wrong version?

You can find out whether the system is in UEFI mode by checking the contents of /sys/firmware/efi/efivars/. There should be a large number of files in there if the system is UEFI. If the efivars aren't there, it's not EFI. Some systems allow you to switch between UEFI and legacy BIOS boot in the BIOS setup menu.

Here's the full process for setting up a legacy BIOS boot partition: After creating the partition in gdisk (type EF02) enter the expert menu with the x command. Then issue the a (attributes) command, and select the BIOS partition number. An attribute menu will be printed. Select the 'hide from EFI' and 'legacy BIOS bootable' attributes (should be options 1 & 2.) Do not to format this partition.

Sometimes you can actually find a way to make those extra keys and buttons work yourself. I have an Alienware 18 laptop with a bunch of extra keys, and I was able to identify the keycodes with evtest. I then created a custom mapping at /etc/udev/hwdb.d/61-custom-keyboard.hwdb file to remap them to useful things, including keys the Alienware didn't include, such as SysRq. It's pretty easy once you get the keycodes. The hardest part is finding a keyboard definition that works, but you can usually manage by copying the definitions from the system files until you find one that works. It helps to use a lot of wildards. Mine looks something like this:

evdev:atkbd:dmi:bvn*:bvr*:bd*:svn*:pn*
 KEYBOARD_KEY_92=sysrq       # macro key 1
 KEYBOARD_KEY_93=scrolllock  # macro key 2

Note, however, that the keycode assignments must be indented with exactly one space, just as you see above. A tab, or a different number of spaces will not work! Here's everyone's favorite developer addressing this totally sane requirement.
https://github.com/systemd/systemd/issues/5677

I think the problem is you put a '&' on the command line between setting the variable and executing your script. I tested it myself. I created a minimal test script:

#!/usr/bin/bash
xterm -e "bash -c \"echo $TIME; read\""

Then I ran it like this:

$ TIME=3 countdown.sh

and it opened an xterm window and printed the number '3'.
Then I ran it your way, like this:

$ TIME=3 & countdown.sh

And it opened an empty window. I think when you insert a '&' it breaks up the simple command and makes it into two commands, so the variable is no longer set in the environment for the second command. It shouldn't be a problem to take out the '&' because setting a variable is non-blocking.

Is it possible it has a setup like MacBooks, where the extra speakers are "bass speakers" on LFE channels? You could try running a surround speaker test, something like this works on my MacBooks to sound all speakers separately:

speaker-test -Dsurround21:PCH -c 4

If you get an error about the device name being wrong, check the output of `aplay -L`:

$ aplay -L | grep -i surround21
surround21:CARD=PCH,DEV=0

If you actually do have subwoofers, there may be a way to turn them on with regular output. The MacBook has a control called 'Bass Speaker Playback Switch' that, when turned on, routes regular output to all 4 speakers. You could try `amixer controls` and look for something similar. Here's how I would find the control on a MacBook, and then turn it on.

$ amixer controls | grep -i bass
numid=4,iface=MIXER,name='Bass Speaker Playback Switch'
numid=3,iface=MIXER,name='Bass Speaker Playback Volume'
$ amixer cset numid=4 on
numid=4,iface=MIXER,name='Bass Speaker Playback Switch'
  ; type=BOOLEAN,access=rw------,values=2
  : values=on,on

Maybe there's something similar on your laptop.

Yes, I thought that log looked familiar. This post has an almost identical log, with X crashing out after loading the glamoregl driver. In the earlier thread, the radeon driver was next in the backtrace, but this user has the nouveau driver next. The other user seemed to be having issues with Mesa.

This is potentially an important point, especially with regard to tablet/touch PCs. For instance, the kernel still supports the Wacom serial tablet interface used in many older tablet PC displays. However, kernel support won't do you much good without X11 support, and the X11 devs removed support for these devices back in January of 2022. Many tablets sold in 2012 and earlier simply will not work with the versions of this driver bundled with the last few Debian/Devuan releases.