Ошибка ввода-вывода при чтении данных с/dev/mapper/veracrypt1

Проблема, которую я имею, подобна, не может считать суперблок на/dev/mapper/veracrypt1 за исключением того, что устройство картопостроителя не может быть считано вообще. Базовый физический диск может быть считан. Т.е. Veracrypt может дешифровать зашифрованный контейнер, но не может возвратить единственный байт из него.

Более конкретно:

  • Сервер Ubuntu 18.04 с четырьмя дисками, полностью зашифрованными с Veracrypt 1.23.
  • Одному диску не удается смонтироваться после потерь мощности.
  • Не мог быстро выяснить что не так с неисправным диском, я воссоздаю veracrypt раздел и перекопировал данные по нему.
  • После вторых потерь мощности двум дискам не удается смонтироваться. Тот же как прежде, и другой.
  • Из двух сбоев сначала у каждого есть зашифрованный раздел того, и другой полностью шифруется. (Таким образом, у них есть другая установка.)
  • Veracrypt монтируют, что сбои из-за не могут считать суперблочную ошибку.
  • Монтирование с --filesystem=none опция работает и предоставляет доступ к устройству картопостроителя.
  • Заканчивание /dev/mapper/veracrypt1 не может быть осмотрен, ни зафиксирован с нормальными инструментами mke2fs, e2fsck так как это не может быть считано вообще.
  • Даже dd от /dev/mapper/veracrypt1 сбои. В то время как попытка системного журнала заполняется с FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE, Sense Key : Medium Error [current] и Add. Sense: Unrecovered read error - auto reallocate failed сообщения.
  • dd от базового устройства жесткого диска /dev/sde или /dev/sdb1 работы без проблем и позволяют чтению войти целого диска, это - зашифрованный вид.

Я подозревал некоторый отказ оборудования, но:

  • УМНЫЕ отчеты оба неисправных диска никогда не имели никаких проблем. Они могут также быть считаны, как упомянуто выше.
  • Неисправные диски подключены к различным картам SATA, и оба - единственный диск, подключенный к их соответствующей карте.

Я мистифицирован. Какие-либо идеи, что могло бы идти и что попробовать?

0
задан 31 January 2019 в 16:06

1 ответ

Оказывается, что это был случай дефектной памяти.

Я заметил случайно выглядящие катастрофические отказы различных сервисов в системном журнале и начал подозревать, что это была паника ядра порождение перезагрузки, которая вызвала повреждение файловой системы.

Замененный модуль памяти и внезапно Вы могли читать из зашифрованного контейнера и зафиксировать файловую систему, как проинструктировано в, не может считать суперблок на/dev/mapper/veracrypt1.

Также включенный по левую сторону судна для ловли дампов ядра для будущего.

0
ответ дан 26 October 2019 в 10:11

Другие вопросы по тегам:

Похожие вопросы: