I have, once. I was not particularly impressed.

If we're talking about the desktop livecd, I expect that would be refracta installer.

Ditto.
I've never seen the traditional debian installer do anything funky either, but IME it's pretty trivial to screw up refracta, since it's really just a bunch of shell scripts, rsync, and yad/zenity.
There's no option go back if you miss something, precious little in the way of confirmation, and skipping or closing any of the random dialogs and terminal windows it spawns is likely to have it just truck on and copy the system regardless. i can totally imagine how one might end up in this kind of mess.
Perhaps I'm being unduly harsh here, but considering I was able to accidentally break the install process on my very first go (though not as badly as this example) it sure doesn't inspire much faith.

If the OP had provided proper reproduction steps, I might even be able to prove it too... oh well.

Random thought, I don't suppose we did anything... unexpected in the live session before running the installer, like, say mounting the existing /home filesystem somewhere?
It's just a thought mind, while I am looking at what I think is the current refracta scripts with one eye, I'm far too lazy to properly dig through that bunch of bash right now.

And another random thought, because I know HoaS just loves shellcheck...

shellcheck ./refractainstaller-gui | grep ^In | wc -l
143
shellcheck -S warning ./refractainstaller-gui | grep ^In | wc -l
52
shellcheck -S error ./refractainstaller-gui | grep ^In | wc -l
5

Ouch.
Yeah, I just use d-i. You should too.

If your install dates back to ascii (and you haven't let dpkg clobber the config files) you would have correct distro name, as this predates the fix getting lost and the package reverted to upstream Debian.

That's kinda my point WRT using ${distro_codename} instead of a hardcoded release. That's how Debian does it, and it allows unattended-upgrades to track the new release after a dist-upgrade with no manual changes to its configuration at all.

Ditto for the devuan-security line, I see no reason not to use ${distro_codename} there either, unless to create more packaging work.

I use "hack" and derivatives in their original meanings, always have.
Media droids conflating "hack" and "hacker" with the correct "crack" and "cracker" is not my problem, nor are ignorant muggles who do the same.

My problem with "Freedom Hacks" is the same problem I have with this board in general - a tendency to slap "freedom" on everything Devuan, as if it were some kind of philosophical fight against an oppressor, rather than a 90%+ Debian fork that retains support for multiple init implementations... Which is functionally what it is and always has been.
... That and it apparently being irresistible to preachers, rebels, "free thinkers", free speech advocates, conspiracy theorists and anti-establishment/anti-conformists in general.

Call that tutorial/howto sub something less ridiculous and I might be inclined... But not for this, because this is a packaging bug that got swept under the rug, plain and simple. It doesn't need a hack, it needs to be fixed.
Besides, if somebody needs a "freedom hack" post for a word replacement as obvious as this, I expect they probably need spoon-feeding and burping as well.

Sure. Unless everything has changed since I last used it, there's no requirement to actually use those functions though.

You can try and sell me on Wayland all you like, but until it does all the things X can do I really have very little use for it.

A simple framebuffer for the TTY? that I'll use, if infrequently. A rich networked display server for more complex GUI environments? cool.
Something in-between, whose primary targets appear to be "high refresh rate" (aka gaming woo) and better support for "devices"... Yeah, I don't really need that at all.

If Wayland was X+, I'd be keen. Right now it appears to be X- with a number of missing features, and were I to switch to it I'd end up running something in xwayland ~80% of the time anyway.
Why is replacing X with something that can't do all the things X can useful?

Debian/Devuan unstable is not a rolling release like Arch, it it a playground for new packages before they move to testing. Unstable and testing are not subject to the same quality control as stable, they can and do break at any time, and they are categorically not recommended for inexperienced users.

Do you actually need a 6.x kernel? Unless you have a very good reason for running 6.x, you're only setting yourself up for problems - particularly when coupled with third-party trash like nvidia's proprietary driver, and even more so with a bunch of patches nobody else here would touch with a long stick piled on top as well.

Even my non-mission-critical-canary gentoo desktop is still running 5.15. Why you ask? Because unless you have bleeding-edge hardware, there's nothing whatsoever to be gained from a shiny-new-shit kernel except aggravation.

This again? Seriously? Please keep your political trolling out of support threads.

I distinctly recall you stating that you were leaving...
Staying for a spot of trolling perhaps, or was that all just more melodrama in keeping with your OP?

A blanket "don't use" is a bit FUDish for me TBH. Like any 3rd party repository, the magnitude of the mess is largely dependent on what one installs and the sensibility of one's pinning.

Set up package priorities properly (i.e. everything but the specific packages you want pinned to -1) and there's no harm in installing a few things from deb-multimedia... As long as you avoid core media library replacements, they will most certainly make a mess.
Nothing a little apt-foo can't fix mind, but unless you really need, say, ffmpeg compiled with all the codecs possible, it's a situation best avoided.

Alternatively, simply installing the individual binary packages works fine as well, since they don't depend on anything else that isn't in the debian/devuan repos.

The first track is the iso9660 filesystem, in this case containing the game data files (it's just empty in the "music only" image).
Most games from the late 90's that included music used these mixed-mode discs, where the first track is mode 1 (CD-ROM) and the rest of the tracks are mode 0 (CD-DA) audio tracks. That way the music can be played by the drive's audio playback hardware without the CPU load of decoding, say, MP3 files.
If you put such a disk in a CD player it will actually try to play track 1 as audio... With somewhat unpleasant results. Your ripping software is smarter and will ignore it.

It's the same on any OS, you learn what software you like by trying it out or by word-of-mouth. You find windows easier because you have more experience with it.

Well you did pick the hard way, compiling it by hand in your home directory. Installing from the deb-multimedia repos is pretty painless (that's how I install it), and using dpkg to build a .deb package from the source shouldn't be much worse.
It's common practice on linux to install applications system-wide using the package manager, so it's not surprising that going against the grain will make things difficult. Had you built and installed a .deb package, it should have set up the udev rules and all that for you.

Of course if debian actually shipped the damn thing in their repos, there would be no hassle whatsoever. I really don't get the complete lack of interest from the maintainers on this particular package TBH, especially as the cdemu devs have gone so far as to include all the needed files already.

Understanding of CD formats, experience, and a little guesswork. Also extrapolation from the bin/toc example in the cdemu manual, where it demonstrates giving cdemu only the .toc filename and it figuring out loading the matching .bin by itself.
.ccd, .cue, and .toc are all "table of contents" files that define how to read the matching .bin or .img, it's pretty logical that you'd need to load that first. Simply opening the .ccd as text should make it obvious what it is and why you might need it.
.sub is subchannel data, and IIRC it's optional unless the disk actually uses a subchannel. Subchannels are most commonly used for supplimental data such as CD-TEXT (track titles), pre-emphasis data... or for copy-protection bullshit.

You need to load the .ccd file, not the .img. The .ccd contains the session and track information needed to determine the disk layout, without it you will get only the first (data) track, if anything.
Same with bin/cue format, you load the .cue file not the .bin.

steve@perdition ~/Incoming/groundzero/full $ unrar x quake2-ground_zero.rar 

UNRAR 6.12 freeware      Copyright (c) 1993-2022 Alexander Roshal

Extracting from quake2-ground_zero.rar

Extracting  ground.zero.ccd                                           OK 
Extracting  ground.zero.img                                           OK 
Extracting  ground.zero.sub                                           OK 
All OK
steve@perdition ~/Incoming/groundzero/full $ cdemu load 0 ./ground.zero.ccd
steve@perdition ~/Incoming/groundzero/full $ cdemu status
Devices' status:
DEV   LOADED     FILENAME
0     True       /home/steve/Incoming/groundzero/full/ground.zero.ccd
steve@perdition ~/Incoming/groundzero/full $ cdemu device-mapping
Device mapping:
DEV   SCSI CD-ROM     SCSI generic   
0     /dev/sr1   
steve@perdition ~/Incoming/groundzero/full $ cdparanoia -Q -d /dev/sr1
cdparanoia III release 10.2 (September 11, 2008)

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  2.    13234 [02:56.34]   124760 [27:43.35]    no   no  2
  3.    11662 [02:35.37]   137994 [30:39.69]    no   no  2
  4.    14547 [03:13.72]   149656 [33:15.31]    no   no  2
  5.    13307 [02:57.32]   164203 [36:29.28]    no   no  2
  6.    13487 [02:59.62]   177510 [39:26.60]    no   no  2
  7.    13418 [02:58.68]   190997 [42:26.47]    no   no  2
  8.    13054 [02:54.04]   204415 [45:25.40]    no   no  2
  9.    13878 [03:05.03]   217469 [48:19.44]    no   no  2
 10.    11145 [02:28.45]   231347 [51:24.47]    no   no  2
 11.    20568 [04:34.18]   242492 [53:53.17]    no   no  2
TOTAL  138300 [30:44.00]    (audio only)
steve@perdition ~/Incoming/groundzero/full $ cdemu unload 0

Looks fine to me. vOv

There are plenty of CD rippers. There are fewer drive emulators, because drive emulators are primarily used either for dealing with proprietary windows disk image formats or for piracy... Neither of which are a priority for free software.
CDemu works fine though, why do you need more than one virtual disk drive anyway?

I disagree. Finding the software needed to load those clonecd images was extremely easy, and I didn't even have to navigate the minefield of shitty websites, adware, crippleware, and malware I would have on windows.
The only "difficult" part is that debian doesn't package cdemu. That bit is plain ridiculous, it's been requested repeatedly over the years.

The above is for demonstration purposes only of course, and I absolutely did delete those pirated images when I was finished You should still buy the game on GOG.

Back in the day, devices had non-volatile memory to store firmware in. Then manufacturers found they could save a few cents.

For most things, yes.

The kernel and/or udev.
Generally speaking, the device driver requests firmware through the kernel API, and the kernel pulls it from disk. If the root filesystem is not yet mounted, this may be deferred and a udev trigger used to load it once it's available.

When the device driver is loaded, if possible. Where exactly this falls in the boot process depends on how the kernel and initrd were built - primarily whether the firmware files are in the initrd image or not.
(AKA, I could tell you how it works on gentoo, but I'm too lazy to dissect the devuan initrd to see if it's the same)
Obligatory kernel documentation link.

As for the refracta stuff, I have no idea. I dislike refracta intensely.

Indeed. The things that will kill li-ion cells the fastest are heat, repeated deep-discharges, and continuous trickle-charging... Two of which you will get in spades if you leave a machine plugged in with the EC set to maintain 100% charge.
If you intend to store a battery (functionally what an always-on-ac laptop is doing), you want it at 60-80% and as cool as possible. Often this means it's better to remove the battery entirely if the machine allows it.

This "battery care" behaviour is run by the embedded controller, it has it's own nvram and whatnot since it needs to handle charging when the machine is off etc.

Most laptops I have seen have manufacturer bloat software for tweaking charge behaviour, but without it windows will just go for maximum runtime. Consumers rate portables on runtime after all, and replacement batteries make money...

I've been using mc for ~20 years, and I've never heard of, needed, or wanted to scroll the filelist by "dragging" the mouse. The scrollwheel works fine.
TBH I primarily just use the keyboard though, that's what page up and page down keys are for, is it not?