Wow. I'm stumped. The chimaera snapshot iso boots in vbox in beowulf but not in chimaera?
Things to try:

Boot the iso in chimaera using qemu. You might need more that 1024mb of RAM.
qemu-system-x86_64 -m 1024 -cdrom snapshot.iso

Add 'set -x' to the top of /etc/init.d/saned to see if you get more information from the script.

There is no init script for colord, but there is a systemd service file. I don't know if the lack of an init script is the problem. Was there ever one for colord?

Not sure what to do with this. I'll ping jaromil. He's the maintainer of colord.

apt-file find colord-sane
colord: /usr/lib/colord/colord-sane       
colord: /usr/libexec/colord-sane

Here are error messages when trying to run the experimental version of wicd in chimaera.

$ wicd-gtk
Traceback (most recent call last):
  File "/usr/share/wicd/gtk/wicd-client.py", line 41, in <module>
    import gtk
ModuleNotFoundError: No module named 'gtk'

$ wicd-cli
Please use --wireless or --wired to specify the type of connection to operate on.
No operations performed.

$ wicd-cli --wired
No operations performed.

$ wicd-cli --wireless
No operations performed.

$ wicd-curses

Runs
I can connect and disconnect wired. Sometimes.
It sees the one router in the house, but doesn't see the second router, which is 2 meters away. It also sees my neighbor's router. Also, iwlist does see the router across the room.

Select my router from the list and press right-arrow to configure gives the following error message.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/gi/overrides/GLib.py", line 664, in <lambda>
    func_fdtransform = lambda _, cond, *data: callback(channel, cond, *data)
  File "/usr/share/wicd/curses/wicd-curses.py", line 1148, in call_update_ui
    self.update_ui(True)
  File "/usr/share/wicd/curses/wicd-curses.py", line 97, in wrapper
    return func(*args, **kargs)
  File "/usr/share/wicd/curses/wicd-curses.py", line 1161, in update_ui
    self.handle_keys(input_data)
  File "/usr/share/wicd/curses/wicd-curses.py", line 1039, in handle_keys
    self.diag = WirelessSettingsDialog(pos, self.frame)
  File "/usr/share/wicd/curses/netentry_curses.py", line 502, in __init__
    self.encrypt_types = misc.LoadEncryptionMethods()
  File "/usr/lib/python3/dist-packages/wicd/misc.py", line 368, in LoadEncryptionMethods
    parsed_template = _parse_enc_template(enctype.strip())
  File "/usr/lib/python3/dist-packages/wicd/misc.py", line 408, in _parse_enc_template
    cur_type["required"] = __parse_field_ent(parse_ent(line, "require"))
  File "/usr/lib/python3/dist-packages/wicd/misc.py", line 380, in __parse_field_ent
    for val, disp_val in grouper(2, fields, fillvalue=None):
  File "/usr/lib/python3/dist-packages/wicd/misc.py", line 655, in grouper
    return zip_longest(fillvalue=fillvalue, *args)
NameError: name 'zip_longest' is not defined

In addition to the possibility of unknown breakage, there is the possibility of security vulnerabilities that will never be fixed and probably not even reported.

I tried wicd-gtk and wicd-cli from experimental. The gtk program does not start. The cli program gives an error message. (I'd have to try it again to get the message, but I gave up after five minutes.)

HELP! Is there a python programmer in the house?

Yes. And it's almost there. The desktop theme is still partly broken and there may still be some bugs in the installer isos. I don't think there's much else that needs to be done. Oh yeah. Write the docs.

This package is in debian and devuan:
orphan-sysvinit-scripts

apt-file list orphan-sysvinit-scripts
orphan-sysvinit-scripts: /usr/lib/orphan-sysvinit-scripts/mapping
orphan-sysvinit-scripts: /usr/lib/orphan-sysvinit-scripts/update_init_d.sh
orphan-sysvinit-scripts: /usr/share/doc/orphan-sysvinit-scripts/README.Debian
orphan-sysvinit-scripts: /usr/share/doc/orphan-sysvinit-scripts/changelog.gz
orphan-sysvinit-scripts: /usr/share/doc/orphan-sysvinit-scripts/copyright
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/dirsrv
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/dirsrv.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/dnscrypt-proxy
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/dnscrypt-proxy.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/gpsd
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/gpsd.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/iwd
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/iwd.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/network-manager
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/network-manager.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/nftables
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/nftables.md5sum
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/tomcat9
orphan-sysvinit-scripts: /usr/share/orphan-sysvinit-scripts/tomcat9.md5sum

The commands I posted for you are from the release notes of refracta gnu/linux. I wrote that part about 10 years ago, and I've used it multiple times over the years. It really is just like mounting any other data partition.

On the other hand, if you try to share system files between two different systems, you'll probably run into some interesting problems we've never seen before. But that would happen with or without lvm.

I've booted a live-usb and mounted lvm many times. it's just like mounting any other block device, with a few extra commands. Once it's attached to the filesystem, you can read and write files as you normally would.

I've also mounted lvm from another installation on a different hard drive in the same computer. It works the same way.

A few extra commands. (Leave out the cryptsetup lines if your lvm is not encrypted.)

___ MOUNT/UNMOUNT ENCRYPTED LVM ___

sudo cryptsetup luksOpen /dev/sdxY label  # then run lvdisplay to get the vg name and lv name
sudo vgchange -a y <volume_group_name> 
mount /dev/mapper/<vg_name-lv_name>  <mountpoint> 

umount <mountpoint>
sudo vgchange -a n <volume_group_name>
sudo cryptsetup luksClose label

Install to the card like it's another hard drive. Make sure the bootloader gets installed to the mbr of that drive. If you want it to be uefi compatible, you will have to do some different things.

Once the installation is done and you know you can boot into it, copy the live-iso into that system and create a grub menu entry to boot the .iso file directly. See these:
https://dev1galaxy.org/viewtopic.php?id=2334
https://dev1galaxy.org/viewtopic.php?pid=6176#p6176

The only reason the live isos are named 'alpha' right now is because they were the first set that I uploaded. You can consider them to be betas. I will probably make new live isos in a week or two.

Here's a screenshot of the window in question.
https://transfer.sh/rg1/Screenshot_lxqt-first.png

The default window manager for lxqt is currently xfwm. Muffin is there because cinnamon was also installed. This window comes up on the first login to lxqt. I don't recall seeing it in a system that had only lxqt installed. In that case, I assume there was only one window manager installed, so there was no need to ask.

The only way "back" would be to kill the desktop that's in the middle of loading itself and restart the display manager to log into one of the other desktops. It's probably easier and safer to just press ENTER, let it load, and then log out. As it says on the screen, the choice can be changed later.

It might be a mismatch between versions of meld and gtk3. That's not a surprise, because gtk3 devs are notorious for changing APIs with every minor version, repeatedly causing problems for app developers.

Searching for one of the error messages, I found this:
https://gitlab.gnome.org/GNOME/meld/-/issues/224

If meld is working, I would ignore the error messages.

BTW, I can get the same "Error creating proxy..." message running meld as root from terminal in debian with cinnamon desktop.

Try xinomilo's suggestions. There's also probably a way to do it with pkexec, but I don't know how to do that.