Or just use a bind mount as already suggested above, as it won't have this problem to begin with.

OTOH, if you don't want anything written to it, why not just 'chattr +i .xsession-errors'? That's kind of what the immutable attribute is for.

We did, until somebody decided to remove console scrollback... A change which royally pisses me off, because I use the console TTYs on a daily basis, and now I have to add screen or tmux to the mix just to get a usable interface.

On top of that nonsense, the systemd crowd is currently pushing to have no console TTYs at all by default, because "the gui should be the primary interface"
Thankfully the latter madness has not (yet) infected the few remaining "old school" distros that actually offer meaningful choice beyond "systemd + GNOME + wayland + pipewire, or GTFO".

On the abomination that is GTK3 (and CSDs), this patchset goes a fair way to making it at least somewhat usable and removing the worst of the mobile-UI junk.
It's still bad mind, but if the choice is between sticking to unmaintained GTK2 stuff or eviscerating GTK3 with mushrooms and an ever-growing list of my own "revert $idiotic_change" patches, I guess I'll take the latter. Grudgingly.

Could be much worse, the Windows installer will simply overwrite any other bootloader without prompting, and you'll need to fix it manually from a live distro.
In other news, so long as you have appropriate bootable recovery media (once known as a floppy disk with a linux bootloader on it, now a live distro on CD or USB drive), you're not "locked out" of anything.

The x86 boot process is complicated and somewhat fragile, and so (IMO anyway) is it's successor UEFI. This is why most proprietary operating systems offer the user no opportunity whatsoever to screw it up, by simply assuming there is only one OS installed.

Grub is at least nice enough to give you some control over it's installation and options to boot multiple operating systems, though in absence of os-prober by default you will need to explicitly enable / configure the latter.
In any case, if you want multiboot, you'd do well to do at least some basic reading on how the boot process works and have a live USB handy to fix things if you need to.

FWIW I think the decision to disable os-prober by default is kinda silly, but it's not a big deal to re-enable it or otherwise add entries to the bootloader after the fact. There are comments in the relevant configuration files, and the documentation (either online or via man and info) is extensive.

Somewhat obviously, no. EFI System Partition, only relevant if you are using (U)EFI boot.

@czeekaj Any particular reason for necrobumping a 1.5 year old solved question with something almost entirely unrelated?

@torquebar As HoaS already commented, this is almost certainly due to os-prober using the unstable /dev/sdx names rather than UUIDs.
There are bug reports about it going back over a decade, with the conclusion that UUID support in the kernel can't be assumed, so os-prober shouldn't use it.
Then again os-prober is really just a bunch of shell scripts, so it shouldn't be particularly hard to change if it annoys you enough to do so.

The only thing you really "need" for a static-ip ethernet connection is a working NIC driver and ifconfig or ip (from net-tools and iproute2 respectively).
When you say "get an IP" I assume you mean over DHCP? If so, I suggest trying with a hand-configured or ifupdown managed static IP (i.e. dump networkmanagermangler) first, then moving on to manually invoking whatever DHCP client you're using with some appropriate --verbose or --debug flags to see what's going on.

Frankly, other than for laptops or tablets that move between wireless networks constantly (and even then only if you must have a shiny GUI) I find networkmangler more aggravation than it's worth. IME ditching it is step one in any network troubleshooting.

Are relevant only for wireless connections, and the former only for WPA encrypted wireless connections specifically.

Why should blindingly obvious false-positives from third-party software warrant an "official" response?
Do you expect official comment on bugs and deficiencies in every other random piece of software in existence as well, or is it just bugs in generic "anti malware" heuristics that warrant panic from everyone but the purveyor of such patterns?

This kind of pants-on-fire response to generic-pattern false-positives is an infuriatingly common waste of developer time, from people freaking out about one-man github projects tripping microsofts "uncommon software" filters, to anti-malware scanners trying to quarantine each other's pattern definitions, to generic matches on innocuous text files. It's all equally bullshit, and all a problem that needs to be dealt with by the anti-malware vendor (or an end-user whitelist), not the innocent party being smeared by these defective tools.

If you don't want ipv6 support, recompile your kernel without ipv6 support, obviously.
Otherwise, disable it as already explained.

FWIW current versions of YUMI use Ventoy under the customised menus anyway, all it really adds is the windows-based GUI setup utility. Whatever config it uses for Debian will almost certainly work for Devuan as well.

On the OP, if the intent is to gather evidence from a system (and we're not talking about professional clean-room hardware-level data recovery, which is well beyond the scope of a livecd/usb), the only thing the live system really needs to do is aquire a block-for-block (i.e. dd) image of the target disk in a verifiable manner, without mounting it r/w or otherwise tampering with it's contents.
Actual analysis can then be done on the image (or more likely a copy of it), with a conventional install that has access to any additional tools one might need.

Personally I tend to use PartedMagic (not a free download, but cheap enough or readily available through the usual back-channels) rescatux or clonezilla live for disk recovery and imaging, but really anything with decent hardware detection and dd and/or ddrescue preinstalled would do. That's pretty much any distro's livecd these days.

If I was motivated enough to go outside in the cold I'd check what exactly is on my recovery/utility drive, but if memory serves it's a yumi ventoy install with all of the above (multiple versions to accommodate ancient hardware), plus the Gentoo based fork/clone of systemrescuecd (I forget what it's called), UBCD, a couple of versions of hiren's boot disk, and install images for Devuan, Debian, Windows XP, Windows 10 and FreeDOS.

Ed. If you're looking for a live distro specifically geared for system forensics, CAINE might be worth a look. I haven't gone any further than a quick tire-kick in a VM as yet, but it looks like it does what it says on the tin and comes with pretty much every tool anyone could ever want.
It's Ubuntu based (unfortunately) and kinda slow, but I'll probably be adding it to my collection.

I haven't used kaffeine in about 500 years, but the bottom of the readme provides some hints WRT passing options to libvlc and/or setting the VDPAU driver.

I'm not downloading a 700MB file from such an unreasonably slow filehost.
That aside, your problem is likely down to hardware accelerated (VAAPI) decoding. Does VLC render the file correctly if you disable "Hardware-accelerated decoding" on the "Input/Codecs" settings page?

In 20+ years, I've never seen any distro say anything but "unsupported, at own risk" with regard to skipping releases on an in-place upgrade. Devuan and upstream Debian are not exceptions.
Why would you even try it, except as an experiment?

Well they appear to agree with my impression of the livedcd refracta "installer" at any rate. That hasn't improved since the last release.
Options are extremely limited, the "UI" presents as unprofessional and janky  - "do not close this terminal window", dialog box spam everwhere (at least one of which is empty, FFS) - it's exceedingly ugly, there's no way to navigate back to previous prompts, and it's ridiculously easy to skip steps or otherwise break it.

For my own use I don't really care (I'll just netinstall same as I always have), but as a first impression of the distro, particularly for new users not familiar with the script-based install processes some of us used a decade ago, refracta is awful.

The rest is just "It's mostly Debian, so unless you really want rid of systemd there's no reason to use it over Debian"... Which is a pretty fair assessment for most people IMO.
For those who do want to run something other than systemd, Devuan is one of only a few usable options.