I wanted to give this a try, but it seems my system may be too minimal in its current state. Is this because I don't have elogind installed? Do I need it?

mkdir: cannot create directory ‘/run/user’: Permission denied
mkfifo: cannot create fifo '/run/user/1000/GUISession23383/socket': No such file or directory

The install media might not have booted in UEFI mode. I've had this problem a few times. If you know how to access a shell prompt from the installer, you can run the command findmnt | grep efivars, You should see a line starting with /sys/firmware/efi/efivars. This is required to properly install grub-efi. If you don't see the line, then your system booted in legacy mode, and you can't install to EFI.

If the system didn't boot in UEFI mode, you may need to adjust your BIOS settings. Some systems have a legacy boot "fallback" option. I've had systems where the installer booted in legacy mode if legacy fallback was enabled, so I had to force UEFI boot only. I've also had issues with some USB media creation programs. The last time I used Rufus, it did not create EFI boot disks by default. I had to manually select the option from a drop-down menu.

Starting Apache httpd web server: apache2AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message

Open /etc/apache2/apache2.conf, go to the bottom, and add the line below. Don't actually use example.com. If you're running a public-facing server with a valid DNS entry, replace example.com with your domain. Otherwise, if you're just behind a home router with NAT, use the name on your local network, something like mycomputer.home.

ServerName example.com

I searched for some of your other errors. The temperature sensor is just typical boot log noise, in my opinion. Practically every system I've owned in the last 25 years has had a temperature sensor that either reported an error, reported bad data, or just wasn't detected at all. The ATA transfer error could be slowing down your disks, but I couldn't find a solution; you may just have to wait for a kernel patch.

OK, I have no idea what this is really about, but you have me curious. I checked three different Linux installations on ext4, and none had inodes 3-10 or 12. In every case, / was inode 2, /lost+found was inode 11, and everything else was inodes 13 & up. I can't find anything about this subject with any search engine.

[Edited to update testing info.] Thanks for sharing the script. I found it easy to read and to understand what it was doing, which is much more than I can say about many of the scripts included with Debian.

A note to anyone not running elogind: you will need to manually set the value of XDG_RUNTIME_DIR to a directory which you own to get the pipewire daemon to start successfully. It's not enough to use a system directory where you have write permissions, such as /tmp, you must actually own it. Something like /tmp/pw will work. [Edit: I initially said /tmp/pulse, but that already exists!] I'm not sure yet how pipewire handles exit; you may need to clean up after it. It's probably worth noting that the startup script did not pass through the error messages from pipewire to the terminal when it failed. I had to start pipewire manually to figure out why it was failing. If anyone else runs into trouble, I suggest you try that first.

After I fixed this issue, the three daemons started successfully, and I confirmed monitor audio was working in OBS Studio (obs requires PulseAudio support for monitoring.) The only drawback was routing: I only saw a single PA input and output (hello feedback!) Hopefully, that's something I can fix through the configuration files.

Did you check the mixer? The Mic channel is often muted (or set to 0 volume) when you first set up a new system with ALSA. I'm not sure what desktop you're using, but you should be able to at least open alsamixer in a terminal and check the mic channel.

I really began to suspect something had changed when I saw this header in /usr/lib/udev/hwdb.d/60-keyboard.hwdb:

# Note: The format of the "evdev:" prefix match key is a contract between the
# rules file and the hardware data, it might change in later revisions to
# support more or better matches, it is not necessarily expected to be a stable
# ABI.

The sheer number of posts about udev & hwdb I found across the web suggests it's a huge source of frustration for Linux users. I remember it took me hours to figure out that my rules needed to be indented by exactly one space. I can't think of another parser that brittle. Even Python is more forgiving! Someone tried to open a bug report about it several years ago, but Pottering himself closed it. He said it sounded "like a support issue!"

Thanks for the suggestion, I hadn't thought about checking with strace. At least I know now that udevadm hwdb --update is successfully opening and reading my .hwdb file:

I checked the trace for the udevadm trigger as well, but it didn't contain anything useful. I checked again to make sure I was using the right name for my keyboard, and it still appeared to be correct:

# udevadm info -a /dev/input/by-path/platform-i8042-serio-0-event-kbd 
    ...
    ATTRS{name}=="AT Translated Set 2 keyboard"

I believe usrmerge was already applied in Trixie before I started the migration to Excalibur. I remember checking for the symlinks shortly after installing Debian.

No argument here; I was only testing the PulseAudio version to help troubleshoot my issues with apulse and OBS Studio. I appreciate the detailed instructions for recompiling Firefox; however, there doesn't appear to be an equivalent way to coerce OBS into support ALSA for output monitoring. It seems this feature is only available if one installs PulseAudio or PipeWire, which is strange, as OBS supports ALSA input sources without issue.

Thanks for sharing that data point. I just tried using apulse with Firefox ESR on a Debian installation. (The Firefox packaged with mainline Debian no longer supports ALSA directly.) I observed exactly what you describe. It seems apulse is the source of the high latency. What's odd is that, according to the documentation, apulse simply wraps the ALSA mixing tools dmix, dsnoop, and plug. Logically, then, it would seem these tools must be the source of the latency.

I actually did find some discussions by people who claimed to have latency issues with the ALSA userspace utilities. Perhaps there is a buffer setting in these tools I can adjust. If that doesn't work, though, I may just give in and install PipeWire, as it appears more and more applications are coming to rely on it.

The problem is that you didn't specify whether you were asking about the three primary additive colors (i.e., the colors of light) or the three primary subtractive colors (pigment, dye, etc.) If the former, the answer would be red, green, and blue. If the latter, the most correct answer would be magenta, cyan, and yellow, although artists may say, red, blue, and yellow, which can serve as reasonable approximations.

I remember when a memory leak was found in a Rust application a while back, some Rust devs (or at least, people claiming to be Rust devs ) were actually shocked. They genuinely did not believe such a thing was possible. I didn't look too deeply into who these people were, but I truly hope they weren't working on anything important, as this attitude reflects a profound lack of basic understanding. It's fundamentally impossible to completely prevent all memory leaks in any language. Rust may be very good at minimizing them (I don't personally know, I haven't looked into it) but it's simply not possible for it to have entirely eliminated them.