0

Issue I'm having is similar to can't read superblock on /dev/mapper/veracrypt1 with the exception that mapper device cannot be read at all. Underlying physical disk can be read. I.e. Veracrypt can decrypt the encrypted container, but cannot return a single byte from it.

More specifically:

  • Ubuntu server 18.04 with four disks fully encrypted with Veracrypt 1.23.
  • One disk fails to mount after power loss.
  • Unable to quickly figure out what is wrong with the failed disk, I re-create the veracrypt partition and re-copy the data on it.
  • After second power loss two disks fail to mount. The same one as before, and another one.
  • Of the two failing, first one has one encrypted partition and the other one is completely encrypted. (So they have different setup.)
  • Veracrypt mount fails due to can't read superblock error.
  • Mounting with --filesystem=none option works and allows access to mapper device.
  • Resulting /dev/mapper/veracrypt1 cannot be inspected nor fixed with normal tools mke2fs, e2fsck since it cannot be read at all.
  • Even dd from /dev/mapper/veracrypt1 fails. While trying syslog is populated with FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE, Sense Key : Medium Error [current] and Add. Sense: Unrecovered read error - auto reallocate failed messages.
  • dd from underlying hard drive device /dev/sde or /dev/sdb1 works with no problems and allows reading of the whole disk in it's encrypted form.

I was suspecting some kind of a hardware failure but:

  • SMART reports both failed disks have never had any issues. They can also be read as mentioned above.
  • The failed disks are connected to different SATA cards and both are the only disk connected to their respective card.

I am mystified. Any ideas what might be going and what to try?

steelmonkey
  • 1

1 Answers1

0

Turns out it was a case of faulty memory.

I noticed random looking crashes of various services in syslog, and started to suspect that it was kernel panic causing the reboot which had caused the filesystem corruption.

Replaced the memory module and suddenly you could read from the encrypted container and fix the filesystem as instructed in can't read superblock on /dev/mapper/veracrypt1 .

Also enabled apport to catch core dumps for the future.

steelmonkey
  • 1