LINUX.ORG.RU

Проблема с монтирование ЖД

 , ,


0

2

На ЖД 2 шифрованных раздела, boot на luks и root на luks2+btrfs. После аварийного отключения(с розетки) перестала запускаться система. Проблема в ЖД, вероятно программная. Первый, загрузочный, раздел расшифровывается и прекрасно работает. А корневой расшифровывается, но срази же выдает ошибку:

ata1.00: exception Emask 0x0 SAct 0x1000 SErr 0x40000 action 0x0
ata1.00: irq_stat 0x40000008
ata1: SError: { CommWake }
ata1.00: failed command: READ FPDMA QUEUED
ata1.00: cmd 60/08:60:70:cb:46/00:00:23:00:00/40 tag 12 ncq 4096
in
         res 51/40:08:70:cb:46/00:00:23:00:00/40 Emask 0x409 (media error) <F>
ata1.00: status: { DRDY ERR }
ata1.00: error: { UNC }
blk_update_request: I/O error, dev sda, sector 6512424 op 0x0:(READ) flags 0x0 phys_seq 1 prio class 0
device-mapper: integrity: Error on roading tags: -5
Buffer I/O error on dev dm-1, logical block 229560224, async page read
...

Вначале думал на повреждение суперблока, но восстановить через btrfs-tools не получилось(btrfs rescue super-recover <имя раздела с btrfs>):

Buffer I/O error on dev dm-1; logical block 16, async page read
Buffer I/O error on dev dm-1; logical block 16, async page read
No valid Btrfs found on /dev/mapper/btrfs
Usage or syntax errors

Предполагаю ошибку на уровне btrfs или luks. Но там и там попытка восстановление будет грозить полной потерей данных. Может кто подскажет в чем конкретно беда. Неужели в самом диске?

mount -t btrfs /dev/mapper/btrfs /mnt выдает:

Buffer I/O error on dev dm-1; logical block 16, async page read
mount: /mnt: can't read superblock on /dev/mapper/btrfs

Ответ на: комментарий от intelfx

Перестроение ФС с нуля, при нечитаемом дереве или даже суперблоке, из известных мне ФС умеет делать только reiserfs v3 (насчёт reiser4 не помню). Такая фича в btrfs тоже была бы очень полезна, но она не имеет никакого отношения к управлению бэдблоками.

fsck.reiser4 –build-fs вам в помощь. Перед этим делается dd_rescue на здоровый раздел (без бэдов).

anonymous
()

Тыква - она и есть тыква. Форматируй нормальной ФС. Будут и шансы вытащить свои данные.

anonymous
()
Ответ на: комментарий от anonymous

Не вижу проблем в btrfs. Система накрылась из-за шифрования. Об этом выше сказано. При этом, скорее всего, где-то там и был бэдблок. При этом реаллокаций у меня 0, выяснять бэдблок, который, вероятно, имеет программый бэдблок - не хочу. То есть есть несколько кандидатов по тестам, но это едва ли мне поможет восстановить данные. При этом критических данных есть бэкап, пусть и старый довольно. Виноват я, впрочем это и так очевидно, что не включил журналирования или в целом включил то специфическое шифрование. Если я не расшифрую - не восстановлю данные, для этого же и шифровал. Возможно я могу их расшифровать и восстановить, но это нужно будет непропорционально много затратить времени и ресурсов, быстрее восстановить утерянные данные. Вывод - нужно автоматизировать бэкапы, внимательнее использовать инструменты. Возможно я могу бы восстановить ОС с данными, но я ноль в криптоанализе и в целом в восстановлении данных. Мне нужно или скопировать их на другой носитель и там уже расшифровывать, или очень хорошо разбираться сейчас. Для первого нет физических возможностей в ближайшее время. Для второго - нет знаний. То и другое займет много времени, у меня будет мертвый ноутбук это время. Я мог бы использовать другой HDD и прочее, но там тоже свои минусы. В итоге, как я говорил, мне проще просто восстановить данные(то есть создать их), чем разбираться. Будет время - углублюсь в криптографию. Насколько я помню, там и шифры у меня специфические.

Тему можно закрывать, всем спасибо.

rafex
() автор топика
Ответ на: комментарий от rafex

Система накрылась из-за шифрования

Извините, а чем вам шифрование-то не угодило? Что этому LUKS-у подсунули, то он и проглотил.

anonymous
()
Ответ на: комментарий от anonymous

Извините, а чем вам шифрование-то не угодило? Что этому LUKS-у подсунули, то он и проглотил.

--integrity aead --integrity-no-journal при шифровании и отключение электричества убило. Я думал, когда шифровал, что при сбое смогу восстановить и мне не нужно еще одно журналирование. Но увы, не повезло. Сейчас забил нулями диск - ошибок не было. Да и в целом выглядит норм. Хотя я и не могу утверждать со 100 уверенностью, что дело именно в этом, но и для полного разбора(и восстановления) нужно чрезмерно много времени, ну для меня.

Не вижу причин винить btrfs в этом. Как что-то еще кроме стечения обстоятельств и мою недальновидность.

rafex
() автор топика
Ответ на: комментарий от rafex

Я думал, когда шифровал, что при сбое смогу восстановить

Если бы пользовались любой другой ФС из апстрима (ext4, xfs, reiser), то смогли бы.

anonymous
()
Ответ на: комментарий от rafex

В первом сообщении ядро явно пишет о проблеме на уровне команд к диску, а не на уровне шифрования и т.п.

Вы точно уверены, что с диска читаются данные? Банальный dd_rescue /dev/sda /dev/null нигде не останавливается, ошибок не выдаёт? Нужно делать именно на /dev/sda, а не на /dev/mapper/….

ValdikSS ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.