I'm afraid I don't have a RAID setup myself, but at a quick glance I would probably first try to follow these instructions

I.e. do that on the installer command line to begin with.
And make sure to save the configuration file(s) somewhere.

EDIT: Actually, the installer includes some functions for setting up RAID. You will need to use "expert" mode, and then in particular select the "mdcfg" option as additional component. At the partitioning stage there will then be some RAID setup options. I'm not yet totally sure how these work though.

EDIT: I'll take it back: the RAID setting up is available also with "default" mode. But you need to use the Manual option for partitioning so that you first partition the physical devices, and then use the "Configure RAID" option before finishing the partitioner.

Note that grub will only install on the one disk, which should be one of the physical disks. You may later also run grub-install onto the other disk(s) to make them separately bootable.

I think the last line in /var/log/dmesg should tell you how long time the last boot up took. And /var/log/dmesg.0 would be the previous boot. And successively /var/log/dmesg.N.gz the Nth boot before that (those files are in gzipped format though).

On that line, the first  number counting from the left is a time stamp of relative time in seconds with fractions since the kernel started to, as I believe, when the "boot finished".

how do you know which parameters it is using?

Eh?

deb.devuan.org is the mirror round-robin, which ultimately resolves to any one of the package mirror hosts.

There is no devuan SSL access for those but they of course provide whatever services they want in addition to the package mirror service for "http://deb.devuan.org".

.. keeping in mind of course that github nowadays is a Microsoft venture ..

Note that @Head_on_a_Stick jumped into the particular solution(s) of how to get the saved filesystem mounted at boot time onto /home, under on an assumption like that users Billy and Kate had their home directories saved at top level as /billy and /kate on the save partition.

Since I often find myself in some different situation (with old home directories somewhere down deeper on the save partition) I need to do a little bit more and different things.

Perhaps it's useful for the OP to first conceive the distinction between

• a partition which is a portion of a disk, and

• the filesystem a partition contains.

On bootup, the kernel sets up one selected partition's filesystem as root filesystem, and any other partition's filesystem gets mounted (as declared in /etc/fstab) onto some directory (to become that subdirectory tree). The pathnames of that second filesystem are then appended to the pathname prefix leading to the mount point.

For example, if the saved data gets mounted on a directory named /old, then it'll be accessible under the saved pathname following the prefix /old. In other words, if Biily's old home directory got saved as /home/billy on the save partition, then that will be found as /old/home/billy when that partition is mounted onto /old. Or it is found as /home/home/billy if the partition is mounted onto /home.

Thus, if Billy's home directory got saved as /billy on the save partition, then mounting that partition onto /home makes the saved directory accessible as /home/billy.

The home directory for a user is registered in the file /etc/passwd. This has one line for each user, with the line divided into parts separated by ":", and the second last part of a line tells the home directory for the user named as first part of the line.

In some other scenarios, such as when mounting the save partition onto /old because the save path is /home/billy on that partition, one might edit /etc/passwd to tell that billy has /old/home/billy as home directory.

And then, even in that scenario, it is possible to instead use an additional "bind mount" to make the path /old/home/billy (also) accessible as path /home/billy, and thereby avoid editing /etc/passwd. To do this you'll need two separate entries in /etc/fstab: one to mount the partition, and a second one to declare the bind mount.

There are several hurdles with using minimal-live for PXE boot, primarily that it still requires media access to the ISO.

The "best" I've been able to do is to add rdinit=/bin/sh to the APPEND line in pxelinux.cfg/default so as to enter a console shell instead of running the "normal" initrd:/init (though after having loaded and mounted the initrd filesystem). There you can discover that even the network interface driver modules are missing from the initrd, so there is not much to do with it.

I had better luck using desktop-live as a basis, and then also serve it over nfs.

• on the server, I mounted the ISO at /netboot/boot/desktop-live

• and set up the NFS service to export that path

• then changed pxelinux.cfg/default to use the menu lines:
  KERNEL ::boot/desktop-live/live/vmlinuz
  APPEND vga=788 initrd=::boot/desktop-live/live/initrd.img boot=live root=/dev/nfs nfsroot=/netboot/boot/desktop-live init=/bin/bash

Due to the init=/bin/bash parameter, it will enter a shell instead of running the post-pivot /sbin/init, so it's still not perfect. But the root filesystem could be extracted at the server end (rather than mounted) and then be changed appropriately so as to allow a normal /sbin/init start.

Note that the root filesystem comes from the squashfs on the ISO, so any changes need unpacking and repacking of that (with any changes); all other files of the ISO copy should be left as is.

***
*** Yes, the 5 posts got lost due to a technical mishap; the sysadmin will be replaced as soon as possible.
*** Apologies.
***

You might need to run /sbin/fsck -y /dev/sda2 or /sbin/fsck.ext4 -y /dev/sda2 to mount it rw.

Yes, that one you can start into "rescue"; just make sure you stop before partitioning.

A Debian live should also work if you can operate that without the broken keys; if you get a root prompt in a terminal, you might be able to do

# mkdir /A
# mou<TAB> /dev/sda1 /A
# chroot /A $(which passwd)

and then reboot into that system.
If the mou<TAB> is ambiguous a double <TAB> will yield the options for you to copy and paste from.
Note that maybe your root file system is not on /dev/sda1 of course .. you'll find out.

To undo the resulting badness of double newlines in those files you may use:

sudo sed '/^$/d' -i /var/lib/dpkg/info/*.list

That will still leave the previously missing final newline in /var/lib/dpkg/info/console-setup.list

In addition, given the original issue, I would also

sudo apt-get install --reinstall console-setup

unless I knew that I had been hand-editing those files sometime earlier (and could thus imagine that I had removed a final newline from at least one of them). in fact, that re-installation would have been  my first point of call well before venturing into willy-nilly hand editing in the dpkg database.

That looks fine and leads to the question whether the dbus daemon(s?), which is supposed to be the server end of that socket, is running at the time during bootup when something is expecting it.