I could get in only into 1 tty. I'll soon check what /etc/inittab says. Maybe something is still missing or Fujitsu's keyboard is a bit faulty.

It kind of made sense that i cannot get into root account by using "su -" if i enter wrong password too many times. But now i think that it could be unrealiable caps lock key/light also.

More successful attempt this time.
I can log in as root. And as a normal user.
But i cannot get into root account by saying "su -" (as a normal user). Have to add "man su" into my reading list to find out why.

Some of the weird behaviour can be explained by the absence of sudo. I had some scripts to automate some tasks. Those scripts required sudo and there was none. Also there were some dependencies that i missed. That's why netfilter-persistent didn't work.
It have become clear that last year when i previously tried Devuan netinstall, i didn't pay attention to that "sudo-situatopn". Root-on-lvm was more important.

X works. But the "pad" and external mouse don't. Are people still configuring X or does that happen automagically?

This time i think i try alternatives for slim and xfce. Lxdm seems to attract libavahi and libcups so maybe not that.

One thing i noticed while going through UEFI settings:it has been updated last ... december. So in theory that update could have complicated the process.

Now i have new stick for round #2. First I thought that i'll copy Daedalus into it. But i can't find SHA256SUMS or SHA256SUMS.asc in https://files.devuan.org/devuan_daedalus/installer-iso/ . What's up with that?
Maybe i''l stick to Chimaera for now  and confirm that the dvd's i have are intact before dd.

Lack of sudo was 1 thing that made me think that there's something wrong with install medium. Problems with /e/i.d/netfilter-persistent and stubby another.
I also find "Ubuntu-style-sudo or no sudo at all"-attitude bit childish. Or i'm just not that much into Manowar

Let's see how it goes this time.
It is not first time that i use Devuan/Debian netinst cd/dvd or expert mode. But it seems that i have been installing too much into easy hardware.

Oh yes, i found the lack of sudo weird, that's why i mentioned it. I thought that it would come with netinst, but after the installation i got complaints about that command. Didn't find /etc/sudoers either. So maybe the netinst disk was scratched or the stick was faulty or something completely different.

And netfilter-persistent not doing what it was supposed to, that was weird also.
I had a similar experience during 2008. Debian 4 install disk had kernel 2.6.18 which was not new enough for the hardware i had then. Had to wait until 2.6.24, if i remember correctly. That kernel co-operated with the hardware i had.

Maybe i'll try installing D again into that Fujitsu. But now it is not a good time for that.

For some reason "man crypsetup" sounds like a good idea in that situation. Or at least i don't think that gparted is the right tool. If i remember correctly there may be some options(with command cryptsetup) which have something to do with resizing.

I spent last night fighting with aforementioned combination. The actual install process went relatively easy. Copy contents of Devuan 4 netinst dvd into usb stick, with dd, after that when you finally manage to get into the boot menu, it is pretty straightforward. After the install there were all kinds of complications.

First i noticed that there is no sudo. Well, "Ubuntu-style sudo" is annoying but i would like to be able to say:"sudo /sbin/shutdown -h now" instead of "su -"+"/sbin/shutdown -h now". So i'll copy the .deb -file containg sudo and some other files from desktop to stick and from stick to laptop.
After some tweaking i decide it is time to "/sbin/ifup eth0" and after that "apt-get update;apt-get upgrade -u". Then apt starts to complain. I remember "oh yes, the iptables rules could be outdated, lets edit them so that the name servers of my ISP are included". Then "nefilter-persistent restart". Still apt complains. And i notice that the rules haven't changed. OK, i'll say "/usr/sbin/iptables-restore /etc/iptables/rules.v4" . Now the dns-rules are ok, apt doesn't complain.

When trying to install stubby there were some complaints. So i edit the configuration files and create necessary users. Something else caught my attention so i forgot stubby for a while,

Finally i get to log into x . I say "su -" so that i can do some things, including editing sudoers for that shutdown-thing. I can't get in as root. I guess i remember the password wrong. So i reboot with install stick and enter rescue mode and change the password. I have to do that 4 times in a row and still can't get in as root.
I can be clumsy sometimes but not that clumsy. And there were also an episode where something went wrong with grub. Not sure why, but i didn't get into grub menu. Fortunately i manage to enter commands to load grub.cfg from /boot-partition.

When the sun rises i have become so exhausted that i decide to go to sleep and continue fighting another day.
No sure if i got stubby working or not.

There were always something. But I like to think that the situation is not hopeless.
I already did some searching with Google and duckduckgo but haven't found anything useful yet.

UEFI settings are 1 line of investigation and commandline options another. And trying more recent version of Devuan the third.

Last weeks i have been mostly listening to My Dying Bride. For example:
https://www.youtube.com/watch?v=2P-vaGs8GRg  The Raven and the Rose (Live)
sounds interesting.

I have been planning to reinstall os to my desktop so when i get that done, i hope that all the weird behaviour goes away or i find out if my hardware is faulty.

I have taken account the path. I think the problem are some non-visible characters in the lists. Making the hash list in many parts seemed like a good idea for a while but now i'm not so sure anymore. Maybe i'll upload the full file or partials into pastebin some day.

https://www.youtube.com/watch?v=bjOG0meK-vk Junkhead (Alice In Chains)

beginning of song sounds a bit like Black Sabbath. Although singer is not Ozzy.

I'll answer to myself:it is possible.

Last night, while trying to distillate the essential parts of the problem, it seems that i was not precise enough. Noise is needed along with the signal.
Another try:

Try 1

mount /dev/sdaX /mnt/a -o ro
mount /dev/sdaY /mnt/b -o rw

cp /mnt/a/*.xx /mnt/b
cp /mnt/a/*.yy /mnt/b
cp /mnt/a/*.zz /mnt/b
cd /mnt/b
sha512sum ./* > sums.txt
sha512sum -c sums.txt

sha512sum says the files in the list are all OK
after that another round:

umount /mnt/a
rm -rf /mnt/b/*
mount /dev/sdaX /mnt/a -o ro
cd /mnt/a
sha512sum ./*.xx > part1.txt
sha512sum ./*.yy >> part1.txt
sha512sum ./*.zz > part2.txt
cp /mnt/a/*.xx /mnt/b;cp /mnt/a/*.yy /mnt/b;cp /mnt/a/*.zz /mnt/b;cp /mnt/a/part*.txt /mnt/b
cd /mnt/b
mv part1.txt sums.txt
cat part2.txt >> sums.txt
sha512sum -c sums.txt

and only .xx files receive OK from sha512sum -c .
.zz files are supposed to change more often than .yy files and .yy files are supposed to change more often than .xx - files. So it seemed like a good idea to split the file sums.txt in 3 parts. Or to be more precise, build the file sums.txt from 2 or 3 files.

I tried to look at those .txt files with hexdump. I may have found the characters that cause the problem with "sha512sum -c" but i haven't figured out how to get completely rid of them.