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.

I'll waste my time fighting the search system for references just as soon as I see the same for claims of one specific wireless driver making a system more "private" or teddybears breaking WPA encryption.

Examples of people conflating the freedom to choose your init with general anti-establishmentarianism and standing up to "them" (whomever that means this week) shouldn't be too hard to find around here though. Guess I could revisit it, when I'm done arguing about python 3.12 targets in gentoo that is.

Fun fact, synaptic (2001) predates the introduction of the 'apt' command (2014). Also: mouse? where? *meow* I see no mouse (any more).

Well it doesn't work on my Slink box, therefore it doesn't exist

about:config, or about:support -> Profile Directory -> Open Directory -> screw about with user.js
Also see arkenfox and the like, for a wide range of tweaks you might want to implement.

Ed.

about:config, play with 'widget.gtk.overlay-scrollbars.enabled', 'layout.css.scrollbar-width-thin.disabled', and 'widget.non-native-theme.scrollbar.size.override'
I don't recall exactly which get you always-visible scrollbars of a usable size right now, but some combination will.

AKA a "meme generator" (many examples online), or something that can be done locally with pretty much any image editor.

Depends which desktop environment or window manager you're using. KDE Plasma for example has a "Media Frame" desktop widget that places resizeable images (or slideshows) on the desktop, on top of the wallpaper.
A similar DE agnostic result could be achieved with conky (read the docs wrt the "image" object) or a small shell script manipulating the window of [insert image viewer of choice here] with wmctrl and xprop to remove borders, set always below, and pin it to a specific position.

AFAICT, the OP wants to pin pictures (with captions) on top of the wallpaper, not replace it. Something akin to the old "desktop sticky notes" but with images.
The use of "icon" all over the place is thoroughly confusing.