Good morning. Not sure about the question, there is systemctl in devuan. I usually do

$ sudo apt install task-ssh-server

to have ssh server installed and running.

EDIT:
Ooops, I messed this up entirely:  "... there is no systemctl in my devuan" is correct.

I would fix /etc/fstab first:
  a) the error in line 1
  b) temporary comment-out all non-linux filesystems

And try a live system (knoppix, or whatever you prefer) to confirm the hardware is ok.
Are there other OS'es, and if so do they show errors too?

Is it a new or an old installation?
If it is new one, I probably would just re-install. Or maybe trying to update to daedalus.

Of course not.
But this is what you get, when using the linked installation instructions on chimaera.

Let's say there was a temptation to suggest "wouldn't you like to do a dist-upgrade to daedalus?", instead of answering the question.

Some thoughts:
Correct BIOS time and non-fucntional RTC sounds contrary. Both are the same device, aren't they?

Debian shows correct time: Probably systemd-timesync forces a clock-update. ntpd could do so too with addional switches. google found e.g. https://askubuntu.com/questions/254826/ … -using-ntp

cat /proc/interrupts|grep -i rtc on my 97x-based mainboard looks almost equal, only one of the four zeros is not zero. Just to mention, whatever it means.

Thanks for the info - I was not aware of that possibilty.

At least there is nothing strange happening, as thought before.

Looks like they don't have a devuan repository. You may interchange 'chimaera' with 'bullseye' in 'nginx.list', using an edior or e.g.:

$ sudo sed -i 's/chimaera/bullseye/g' /etc/apt/sources.list.d/nginx.list

Most commercial DVDs are encrypted with "css" and decryption libraries are needed to play them.
I remember remarks on the vlc web site (dvdcss or decss). The DVD-player-software loads the library(s), if present. css is broken since years and some keys are public, even printed on T-shirts. Not sure about the current legal state, but I don't think this will ever make it into debian officially.

"non-free-firmware" was separeted in the upcomming Debian release.
It is the essential (non avoidable) part of non-free software, which is needed for some pieces of hardware to function at all.

Thanks for the input!

@UnixRocks, @steve_v
Then tigerVNC and x2go it is for the next tries.

@nixer
Thanks for the detailed description, Xephyr sounds very interesting. I need time to get used to the concept, currently the nested / recursive X-server creates a knot in my head. As you mentioned, specifying the correct DISPLAY sounds like challange.

All three suggestions can be used with ssh, which is great.

PS:
Yesterday, while trying to theme lightdm ... .
The arch wiki mentioned a test mode lightdm --test-mode --debug, which works using xephyr. lightdm.conf has a VNC section and there is the installble lightdm-remote-session-x2go debian package. First I thought these components were addressing the server-side function, but the x2go module seems to be client related. Anyway.

I did not know that the size of the image file would be the same, sorry.
However. The file system in the image file has become smaller. The last 7 GB are present, but unused by now - df will tell.

$ sudo mount -o loop HP.shrinkme.img /mnt
$ df

The error at restore using dd should not matter here. If you really want to be sure and write it again:

$ sudo ntfsclone -f -o /dev/sdb1 HP.shrinkme.img

The file system should be in a mountable condition. Probably it isn't ... .

Did you try to mount /dev/sdb1 ?
If you want back the shrinked 7GB HDD space, you still need to:

$ sudo ntfsresize -x /dev/sdb1

HDD situation:
There is the "master boot record" (mbr) and "partition start sector 2048" from the new installation, and the file system from the old installation (different mbr and "partition start sector 63") to fit the image size to the HDD space. I'm not aware of all implicit issues.
The disk itself will likely not boot. grub form the other disk may or may not be able to help ($ sudo update-grub).

Does the first version of the win7-install-cd the start-at-sector-63 partitioning? Think so, but not 100% sure. Probably, if you have such a install-cd, it may recreate the partition as before.
I'm not used to read chkdsk output.

Or just use the new installation and copy back all the files form the mounted image.

@guuml.dev1: Thanks for the reply (yes, long ago). There are "ä,ö,ü,ß". [AltGr] is onyl working, if xrdp uses an appropriate keymap too.

Update - a cleaner way to set a default keymap for xrdp:
Initially loaded is /etc/xrdp/km-00000000.ini. The file is not existing, so a link or copy can be made without interfering the installation. The issue occurred again on a new PC.
In my case:

$ sudo cp -a /etc/xrdp/km-00000407.ini /etc/xrdp/km-00000000.ini

After logging in, it is still a "us" or "en" keymap, but switching to "de" now fully works.

$ setxkbmap de

Thanks for posting the file size.

Testing:
Just dd'ed a small 100M partition using bs=13M to have a "fractional block count". Sizes of image-file and device are equal. Also tried dd with "bs=15M" and "bs=512", and pure cat. All image files are identical. On daedalus and on chimaera. No errors at all during creation and restore.

The main question is now:
Why is the image-file (104864062464 bytes) bigger than the partiton (104862842880 bytes)? How is this possible?

The partititon must have been shrinked after creating the backup image.
I don't see any other possibility.

EDIT:
fdisk -lbefore the reinstalltion of windows would be informative.
Older (windows-)partition schema start at sector 63 (not sector 2048) and there is a gap of 398 sectors (or 0.2 MB) between sda1 and sda2. This is 1.2 MB potential addional space for sda1. The image file is 1.1 MB bigger than sda1.