Disks are fine, and nothing else happened after this event.

I repeat:

• different controllers

• different brands

• two different disks

• two different technologies: one HDD and one nvme

• more than 100GB have been loss, while the system has max theoretically up to 32GB of memory

but they all have in common EXT4.

So, I still suspect EXT4, but cannot prove this. Maybe I am totally wrong, but why EXT4? Well, there are some infamous known bugs:

- https://bugs.launchpad.net/ubuntu/+sour … bug/317781
- https://lore.kernel.org/lkml/50882787.3 … home.de/T/
- https://bugs.debian.org/cgi-bin/bugrepo … bug=785672

Unfortunately, Devuan team seems to be too small to handle this kind of issue.

Thanks to you two. At least I am not crazy!

Seems that we have to deal with it, but it is not a big deal.

Well I have finally tested the RAM; all memtest86+ tests are OK (4/4 pass).

Ok thanks, I did not know that this version doesn't work in UEFI mode :s

I tried the UEFI version with usb sticks, but, strangely, I still get a black screen… Even if, now the keyboard seems to react (led, etc…). But still nothing on screen.

As for memtester, it should be "less accurate" than memtest86+; indeed, I will have to allocate an amount of memory, leaving at least 2GB unchecked—mate takes ~1.2GB.

Can you help me to get my system in Legacy mode?

As an aside, do you have some links about how works EFI with Grub? How can I manage grubx64.efi entries under /boot/efi?
I tried efibootmgr but seems useless—some entries are rewritten at boot?

Well, here the fstab (I have removed the UUID):

UUID= /boot           ext4    defaults        0       2

UUID=  /boot/efi       vfat    umask=0077      0       1

#/dev/mapper/devuan_root /               ext4    errors=remount-ro 0       1
UUID= /               ext4    errors=remount-ro 0       1

#/dev/mapper/devuan_usr /usr            ext4    defaults         0       2
UUID= /usr            ext4    defaults         0       2

#/dev/mapper/devuan_var /var            ext4    defaults         0       2
UUID= /var            ext4    defaults         0       2

#/dev/mapper/devuan_tmp /tmp            ext4    defaults         0       2
UUID= /tmp            ext4    defaults         0       2

#/dev/mapper/nvme_crypt  /home           ext4    defaults        0       2
UUID= /home           ext4    defaults        0       2

#/dev/mapper/sde1_crypt /home/zero/public ext4    defaults        0       2
UUID= /home/zero/public ext4    defaults        0       2

Indeed, the two "faulty drives" are mount under /home—while the other drives are much "read-only".

As for wearing out my SSD. A new and better SSD like the Kingston A400 120GB will cost ~20€… while the SAMSUNG SSD 830 have cost me, more than 7 years ago, ~90€.

As I recall, the TBW of the SAMSUNG SSD 830 120GB is around 30—unfortunately, seems the specs file of this drive was among the vanished files that I definitively lost :s.

After more than 7 years, my SAMSUNG SSD 830 displays ~11GB of total writes… So, theoretically, it should last 14 more years…

So, wearing out my SSD is not a real problem.

Everything is "perfectly seated, and so on".

No strange noises, no dust (very clean inside), more than enough ventilated. I repeat for all tools, smartmontools included, everything is OK (even multiple/long tests).

Yes, I use some Ceres packages (mainly for lxc).

I have installed sigil from Devuan Ascii repository (0.9.7+dfsg-1). I did not used it before. Indeed, I switched from Debian to Devuan, after ~15 years, using mainly SID. (I used to use FreeBSD too).

I only try to start Sigil for the first time on Devuan. But it complains that it cannot run. As if it was unable to write anything on the nvme—when the bug occurred?

I suppose, but I do not affirm that EXT4 is the problem. Maybe the RAM is faulty, but seems strange, as:

• two diffrent disks

• more than 100GB have been loss, while the system has max theoretically up to 32GB of memory

To get corrupt, these data (files; folders; etc…), from these two disks, should have been "randomly loaded in the RAM" (say max 30GB) in more than three times (3*30 = 90GB), to get corrupted each time. How and why being loaded in the RAM?

Anyway, I will test the RAM as soon as I can.

Summary from bug#313

I could add that it's a "relatively brand new pc—2 months old" and that I have tried

• nvme-cli

• smartmontools

• Samsung Magician

All these tools say that EVERYTHING is OK, and strangely, Photorec do not find those files.

Finally, and this is I think very important, as I was not logged in any way as root (terminal, etc… or even used sudo…). Files that belonged to root user or other user/group have also vanished. Yet my user did not have any "super rights". So more than 100GB in two disks vanished instantly, not possible and too fast for a "rm" command—that I never did).