systemd v257 requires the merging of /bin and /sbin tries to strong-arm distributions into another pointless filesystem layout change, by inserting scary-sounding messages to incite bug reports from clueless users.
FTFY^

In other news: The sky is blue, the sun rose in the east again, and Lennart is still an asshole.

xtrx-dkms is fixed in sid/ceres/unstable, either wait for somebody to punt it to backports or just do it yourself.

It literally took me longer to write this post than it did to find the information above.

Why? You're running an uncommon driver for uncommon hardware, on a backported kernel.
Expect this class of problem with new kernels and out-of-tree drivers.

usrmerge is a filesystem layout change, not some kind of "corporate" conspiracy. It's not really necessary and it breaks a bunch of old assumptions, but it's far from the end of the world. It sure doesn't need a "warning" for anyone who hasn't been living in a cave for the past 5 years.
It also has nothing whatsoever to do with 32bit support or non-x86 architectures.

OTOH, the only thing not adopting merged /usr really breaks is systemd (and compatibility with systemd-based distros), largely because that sprawling behemoth of feature-creep apparently can't keep it's tentacles out of things traditionally found under /usr and not needed to bring the system up... But that's not exactly a surprising development.

If it is indeed X using that much memory, xrestop may be of interest.

False positives, read /usr/share/doc/chkrootkit/README.FALSE-POSITIVES.gz (and the other documentation).

In /etc/rkhunter.conf, of course.

The first is a list of files you should check out and whitelist if they're benign.
The second is chkrootkit being dumb, and is explained in the documentation.
The third is irrelevant, because you are not running OSX.

You didn't mention how you copied the system. Did you preserve extended attributes (and in particular, POSIX capabilities)?
I have no idea how thunar handles user mounts these days (still GVFS?), but I wouldn't be at all surprised if there's a binary with CAP_SYS_ADMIN set to allow (un)mounting filesystems involved.

Dependence on cloud nonsense aside, this really comes down to crowdstrike's implementation:
* Falcon sensor is an old-school kernel driver (as opposed to running in a kernel VM, e.g. eBPF modules).
* It's also marked as boot-critical, so "safe mode" doesn't bypass it.
* It loads files (and potentially executable code too) from userland without sufficient input validation.
* It's written in C++, it's not memory-safe, and invalid data (in this case a bunch of literal nothing) in a definition update caused a null-pointer dereference.

IOW, this is a crowdstrike fuckup, and a pretty serious one at that. Whoever came up with the architecture for falcon sensor (at least on Windows) should be fired immediately.
Not only is this a fragile single point of failure, the apparent lack of input validation makes it a rootkit waiting to happen as soon as somebody manages to sneak in a compromised definition update.

There are ways to do something like this without producing a massive SPOF (or at least making it more easily recoverable), and this all stinks of arrogance and "infallibility culture" at crowdstrike.
Their big shiny selling point is "instant updates", and to achieve that they sidestepped driver validation and threw out decades of best-practice when it comes to running code in kernel space. This is ring-0 plug-n-play printer driver levels of "don't do that".
Perhaps it will wake their customers up to the peril of granting IDDQD rights to a bunch of chimpanzees.

AV vendors abusing their privs to do stupid things isn't remotely new, we've had gratuitous SSL tampering for years, we've had easily hijackable update mechanisms, and we've had products that decompress potentially malicious payloads in kernel-space, to mention just a few dumb ideas off the top of my head.
Surely by now somebody has realised that giving J.Random AV slinger god-mode in the name of "muh securitee" and "users are too stupid to be trusted" is a bad plan... Surely.

Because no installer default can satisfy everyone? It's your system, you get to choose the disk layout.

As for triggering hibernation from the CLI, that would be either 'loginctl hibernate' (if you have [e]logind installed, which IIRC is the default setup) or 'pm-hibernate' from the pm-utils package.

The only difference is that the librewolf download page gives you a lazy copy-paste command to run with a scrap of shell doing "if not [list of supported releases] then use ubuntu focal"... Which is something neither are in any way obliged to provide, and one anyone with two brain cells to rub together could implement themselves or fix manually by changing a single word in the resulting source line.

The reason you are getting flack for your post is that you are calling people "bumbling morons" for not spoon-feeding you. Grow up, and learn to deal with the fact that you are running a distribution with a small userbase and will need to make your own decisions when it comes to compatibility with third-party repositories.

So are people who get out of sorts and start slinging shit like a brat when they're not spoon-fed copy-paste solutions to every little thing.

Yes, expecting third-party developers to be aware of every derivative and which debian codenames it's compatible with is unreasonable. They're already providing you software for nothing, if you want to use their convenient repository too then figuring out which release is appropriate for your system is your problem.

Hell, librewolf doesn't "default to debian codenames" anyway. Had you made the effort to actually read that shell snippet you'd see they default to "focal" for any release not on their list, and that's not the right choice for devuan either.

To wit:

What, pray tell, is so "frustrating" about applying the same logic to mullvad, and setting the codename yourself in mullvad.list, or wherever else you choose to put the source definition?

As for what mulvad stuff you can "get to show up", how about you go look at the contents of the repository you added... Or perhaps you expect somebody else to take care of that for you (and call them morons if they don't) as well?

Zapper whining about "them", calling names, and crying "Oh, the huge manatee, this is terrible, won't somebody do something" rather than taking any kind of remotely productive action... What else is new

Further to^

Then any further testing is but a curiosity, because at the end of the day, differences you can't hear are irrelevant for anything you intend to listen to.

Human hearing sucks, and the vast majority of final reproduction equipment (i.e. speakers and their environment) sucks as well... because so long as the latter suck significantly less than the former, nobody will hear it and it doesn't matter.
Trivial differences in resampling are irrelevant, and unless you are doing digital mastering, so are bit depths >16 and sampling rates significantly above the Nyquist limit. Fight me.

No real reason, mostly just more familiarity.
For a security-focused appliance (e.g. router / server etc) I'd probably pick OpenBSD, but last time I played with the desktop usecase FreeBSD had better hardware support and was easier to get the software I wanted installed.