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

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

Не факт, что дело в btrfs. Такое чувство, что расшифровка диска ошибочная. Сомнительно, что btrfs посыпалась настолько, что даже утилиты восстановления не будут видеть тут btrfs

rafex
() автор топика

ata1.00: failed command: READ FPDMA QUEUED

ata1.00: status: { DRDY ERR } ata1.00: error: { UNC }

вполне недвусмысленно говорит, о том что диск умирает

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

На smartctl -s on -a /dev/sda SMART overall-health self-assessment rest result: PASSED

В таблице из бросающегося в глаза: Raw_Read_Error_Rate 0ю000b 096 096 062 Pre-fail Always - 262148 WHEN_FAILED везде - Reallocated_Sector_Ct 0 Offline_Uncorrectable 0

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

да. Это я сегодня задолбался с lvm, теперь везде мерещится

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

А smartctl -q errorsonly -H -l selftest /dev/ ничего не вывело.

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

походу уже позабывал все, что знал

SMART overall-health self-assessment rest result: PASSED

это после недавно сделанного -t long или он там просто что-то из далекой истории показывает?

Raw_Read_Error_Rate

а производитель какой? хотя на сигейтовский счетчик вроде не похоже

ну и там стандартное-глупое: а кабели подергать? вдруг у него питание отваливается под нагрузкой

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

Да, из далекой истории. Я первый раз использую smart.

Запустил с -t long. Через часа 4 завершится, как я понял. Потом пришлю данный. Спасибо.

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

@torvn77, ну-ка, кто там говорил, что Btrfs – лучшая ФС в мире?

Ничего не могу сказать по поводу написанного ТС, так как ни Luks ни шифрованием разделов не пользуюсь.
У меня просто отформатированный в BTRFS раздел и при форматировании я всегда указываю двойное резервирование метаданных.

А так корень у меня смонтирован с суровой опцией commit=3600

torvn77 ★★★★★
()

У тебя аппаратная проблема. Тащи весь smartctl -a.

legolegs ★★★★★
()

Проблема в ЖД, вероятно программная

Судя по логам - аппаратная.

Harliff ★★★★★
()
Ответ на: комментарий от torvn77

Прошу прощения за оффтопик, я по поводу краудфандинга консоли. Теоретически готов поучаствовать в финансировании, но на практике не могу это обсуждать из-за доступа в обсуждение только для высококармических юзеров. Очень надеюсь на появление темы (здесь или где-либо ещё), где можно будет обсуждать спасение консоли (и его финансирование) без кармы и без sms. А то получается как в анекдоте про лотерейный билетик.

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

«А если я кирпич вместо диска в слот вставлю, Btrfs работать не будет! Btrfs — гавно!»

intelfx ★★★★★
()
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

Может кто подскажет в чем конкретно беда. Неужели в самом диске?

Ты не поверишь…

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

Ну, поздравляю, повреждённый сектор пришёлся аккурат на суперблок.

Другой вопрос, почему btrfs думает, что на твоём разделе всего один суперблок. Какого размера раздел?

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Вот кстати, умеют ли инструменты этих хипсторских ФС работать с бэдблоками? Или обязательно придётся блок занулять (на месте или после ddrescue) перед fsck и надеяться на контрольные суммы и дубликаты суперблока?

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

Вот кстати, умеют ли инструменты этих хипсторских ФС работать с бэдблоками?

Что такое «работа с бэдблоками» в твоём понимании?

Или обязательно придётся блок занулять (на месте или после ddrescue) перед fsck и надеяться на контрольные суммы и дубликаты суперблока?

Занулять необязательно, чексумма не даст тебе прочитать мусор вместо полезных данных. А какие ещё варианты?

На всякий случай, в современном оборудовании управление бэдблоками полностью автономное. Работа с бэдблоками в стиле badblocks или mke2fs -l — это бесполезный архаизм.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 3)
Ответ на: комментарий от intelfx

раздел около 900Гб. Занято около 30ГБ. Сейчас выполняю smartctl --test=long /dev/sda, как завершу - попробую сам проанализировать результаты. Могу попробовать сюда написать ключевые моменты(если я смогу их определить) или немного помучаюсь с пересылкой инфы и скопирую весь лог. Если надо. Должны быть копии суперблока. Почему их нет - не знаю. Я не уверен, что там все еще структура btrfs сохранена. Может некая ошибка при расшифровки в следствии битого бита? Тем более он нормально принимает верный пароль, но после расшифровки выдает тот текст с ошибками ata1. Я не пробовал btrfs check --repair - боюсь совсем сломать ФС, если ее еще можно восстановить. Сейчас попробую хоть как-то понять статус ФС и видит ли хоть что-то btrfs

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

Насколько я понял, все три сектора с суперблоком не содержат суперлока. Везде дает Buffer I/O error on dev dm-1; logical block 16, async page read mount: /mnt: can't read superblock on /dev/mapper/btrfs Только номер блока меняется

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

раздел около 900Гб. Занято около 30ГБ.

Тогда копии суперблока должны быть обязательно.

Покажи вывод cryptsetup luksDump /dev/sdXY и blockdev --getsz /dev/mapper/foobar (где sdXY и foobar — твои блочные устройства).

И попробуй запустить по очереди btrfs check -s 1 /dev/mapper/foobar и btrfs check -s 2 /dev/mapper/foobar.

Я не пробовал btrfs check –repair - боюсь совсем сломать ФС

И правильно. Ни в коем случае. btrfs check --repair только по указанию разработчиков (или если охота поэкспериментировать на копии образа ФС).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от rafex

Насколько я понял, все три сектора с суперблоком не содержат суперлока. Везде дает 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 ★★★★★
()
Ответ на: комментарий от intelfx

cryptsetup luksDump /dev/sdXY:

Version:2
Epoch: 6
Metadata area: 16384 [bytes]
Keyslots area: 16744448 [bytes]
UUID:   ...
Label: (no label)
Subsystem: (no subsystem)
Flags: (no flags)

Data segments:
0: crypt
  offset: 16777216 [bytes]
  length: (whole device)
  cipher: aegist128-random
  sector: 512 [bytes]
  integrity: aead

слоты ключей

Токены

blockdev --getsz /dev/mapper/foobar:

1836482000

По суперблокам btrfs check -s 1 /dev/mapper/foobar дает:

using SB copy 1, bytenr 67108864
Opening filesystem to check...
Buffer I/O error on dev dm-1; logical block 16, async page read
Buffer I/O error on dev dm-1; logical block 16384, async page read
No valid Btrfs found on /dev/mapper/btrfs
ERROR: cannot open file system

и

using SB copy 2, bytenr 274877906944
Opening filesystem to check...
Buffer I/O error on dev dm-1; logical block 16, async page read
Buffer I/O error on dev dm-1; logical block 67108864, async page read
No valid Btrfs found on /dev/mapper/btrfs
ERROR: cannot open file system

Такие дела

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

Ну, что я могу сказать…

Либо у тебя побилось полдиска, либо сошёл с ума LUKS (но я не знаю, как он может сойти с ума так, чтобы успешно расшифровать том, но заваливать все запросы), либо тебе очень не повезло.

Попробуй пересчитать логические блоки на расшифрованном разделе в физические сектора на диске и прочитать сектора, соответствующие суперблокам, напрямую (с помощью hdparm --read-sector). Так ты хотя бы поймёшь, проблема с диском или выше. Формулу пересчёта сейчас не напишу, но если немного покурить маны и подставить в нужное место оффсет до данных из вывода cryptsetup luksDump, её можно вычислить.

Размер «logical block» — 4K, размер суперблока — тоже 4K, а размер физического сектора на своём диске смотри сам, вдруг у тебя там 4Kn (а cryptsetup настроен неправильно).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Похоже случайно прервал тест smartctl. Утром пришлю весь лог. Но по предварительным данным он норм. Причем вполне хорошее состояние. Попробую потом, после теста, прочесть напрямую. Думаю там не будет ошибок. Про пересчет логических блоков на физические сектора не понял. Погуглю что это значит и как сделать. Надеюсь найду.

Предполагаю, если бы cryptsetup был настроен неправильно, то он бы не работал до этого. Разве что сейчас настройки сбились. Посмотрю

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

Погуглю что это значит и как сделать. Надеюсь найду.

Это значит попробовать прочитать напрямую с физического диска сектора, соответствующие зашифрованным суперблокам. Если прочитаются — значит, проблема программная. Если нет — значит, диск побился.

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

Так, стоп.

Data segments:
0: crypt
 offset: 16777216 [bytes]
 length: (whole device)
 cipher: aegist128-random
 sector: 512 [bytes]
 integrity: aead

Ты настраивал LUKS с аутентифицированным шифрованием (cryptsetup luksFormat --integrity)?

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

Про прочитать напрямую - я понял. Я не понял про «пересчитать» Насколько я помню - да, было нечто подобное. Могу уточнить, если это критически важно. Но по памяти - было такое. Делал по гайду и посчитал тогда, что такая фича мне нужна.

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

Могу уточнить, если это критически важно.

Да.

Насколько я помню - да, было нечто подобное.

Значит (а также из последней строчки лога в шапке), новая гипотеза — побились у тебя метаданные (теги) аутентифицированного шифрования. Как побились — второй вопрос. Могли правда побиться сектора (результат длинного самотестирования в студию!), а могли просто последние записи потеряться, если была потеря питания.

Журнал от такого спасает, но если у диска глючные барьеры — то нет. --integrity с журналом хоть было или без?

В любом случае, пиши в список рассылки dm-crypt, приводи полные логи и полные дампы, мб есть решение. А может и нет.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от intelfx

Насколько я помню - без журнала. Журналирование слишком замедляло работу диска.

Есть где почитать про аутентифицированное шифрование и восстановление данных? Ну кроме первых страниц гугла.

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

Насколько я помню - без журнала. Журналирование слишком замедляло работу диска.

Ну вот тебе и ответ, оно там не просто так :) Сам себе данные и убил таким вот образом.

Есть где почитать про аутентифицированное шифрование и восстановление данных? Ну кроме первых страниц гугла.

Прямо про аутентифицированное шифрование и восстановление данных? Нет. Курить маны, копаться в исходниках, читать статьи по используемым алгоритмам шифрования, общаться с разработчиками.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

То есть мне надо или Использовать аутентифицированное шифрование с журналированием или вообще не использовать такое шифрование?

Ну я не готов потратить лучшие годы жизни на это, хоть данные, к сожалению, я не успел забэкапить, кажется. Точнее я стер некоторые бэкапы и не успел создать новые(библиотеку книг, хоть и важную для меня). Но мне, наверное, проще распрощаться с тему данными и установить систему снова. Быстрее будет, наверное, создать библиотеку заново, чем изучить тот стек данных, чтобы, возможно, расшифровать данные назад. Диск проверю и попрубую потом выполнить что-то из cryptsetup repair

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

То есть мне надо или Использовать аутентифицированное шифрование с журналированием или вообще не использовать такое шифрование?

Верно.

Ну ты напиши пост в список рассылки.

  • приложи логи ядра и дампы (полные, а не обрывки)
  • опиши ситуацию (btrfs поверх luks2 + integrity + no journal, electric power loss, ни один суперблок не читается)
  • задай простой вопрос («можно ли расшифровать данные, пусть и без гарантий целостности»).

Потом сделай копию раздела (зашифрованного, естественно) и жди ответа.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

Логи ядра? Если про var/log, то он зашифрован тоже. Если только про dmesg. Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300. Так что или так, напрямую восстановлю, или, если диск нормальный, перезапишу их с учетом прошлых ошибок. Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно. Даже с учетом, что мне интересно «как это все работает». Тем более, если я найду бэкап нужных данных, пусть немного и устаревший - заниматься этим не буду.

А что лучше, использовать integrity или нет? С журналом, судя по данному случаю. Неужели без него лучше восстановить данные? Шифровать диски из-за места жительства мне нужно, как и нормальное шифрование(а не для вида). А вот терять производительность из-за журналирования luks-ом в 2 раза не хотелось бы.

В любом случае, спасибо.

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

Логи ядра?

Да, dmesg — сразу после чистой загрузки, попытки примонтировать раздел и попытки прочитать резервные суперблоки (например, тем же btrfs check-ом).

Я бы давно скопировал раздел на другой диск и там уже копался пытаясь восстановить. Но раздел 900ГБ, а диски есть только на 500 и 300.

Ну блин, милчеловек, сами себя загнали в угол. Купить или одолжить терабайтник — не вариант? Да хоть в облако выгрузить, в тот же Backblaze (через s3ql с небольшим размером блока типа 10 MiB). Но всё равно рано или поздно придётся найти чистый диск, чтобы на него развернуть образ.

Я думаю, если ОЧЕНЬ сильно запариться, то восстановить можно, просто это будет очень долго и непомерно сложно.

Я ненастоящий сварщик, но просто с позиций общей логики кажется, что есть ровно два принципиально разных случая: либо содержимое «тегов» (authentication tags) является частью ключа и используется для расшифровки, либо наоборот, нужно только для проверки целостности.

В первом случае данные восстановить математически нельзя, во втором случае очень просто — достаточно вырезать или выключить код проверки этого тега.

А что лучше, использовать integrity или нет?

У тебя на уровне btrfs вычисляются контрольные суммы всех данных (но не криптографические). Если ты не защищаешься от атак с подменой шифротекста (chosen ciphertext attack), то dm-integrity тебе не нужно.

Неужели без него лучше восстановить данные?

Не понял. Без журнала или без dm-integrity? Без журнала всё плохо. А без dm-integrity всё хорошо, т. к. каждый сектор открытого текста соответствует ровно одному сектору шифротекста. В этом режиме таких проблем, как у тебя сейчас, возникнуть в принципе не может.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 4)
Ответ на: комментарий от intelfx

Если ты не защищаешься от атак с подменой шифротекста, то dm-integrity тебе не нужно.

Если эту атаку нельзя выполнить имея жесткий диск(утеря или изъятие, то есть ноутбук уже выключен), то не защищаюсь. А если это возможно с изъятым диском - нужно думать и оценивать риски. Я понимаю, это «chosen-ciphertext attack»? Если я правильно понял, без сравнения оригинала и шифра - невозможно взломать. А сравнивать имея диск без ключа - не получится.

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

Chosen ciphertext attack. Изъяли диск, что-то на него записали, вернули тебе, дождались, пока ты включишь, и каким-то образом узнали результаты дешифровки изменённых секторов (при этом не имея возможности узнать сразу ключ или все остальные данные). А потом изъяли диск ещё раз.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от intelfx

А вообще, если у тебя изъяли диск, вернули и заставили включить — то тебе без Secure Boot уже хана, потому что тебе могут подсунуть буткит, например.

/boot на LUKS это конечно да, но загрузочный сектор-то открытым текстом записан.

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

Ну и разумеется, это всё глубокое теоретизирование, никто писать буткиты или делать CCA на btrfs не будет, ну только если ты не Сноуден-2 в бегах от ФБР.

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

Ну, зная власть и отсутствие интереса у спецслужб - мой HDD никто мне не отдаст, майор своему сыну подарит, скорее. А если и вернут - карантин на месяц, даже если и изымут - ничего не изменится. Ну или новый HDD с копирование нужной информации на со старого HDD + dd нулями старого диска. Ну и потом использовать не для критической информации. Так что да, множно integrity не использовать, как мне кажется. А dm-integrity и от «отдать модифицированный диск» не спасет. Там, как я понимаю, пусть и с меньшим вариантом аттак, осуществить примерно тоже, но даже проще. Особенно если заберут весь ноутбук. Не говоря уже о взломе данных после кражи или утери ноутбука. Спасибо за разъяснения

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

А dm-integrity и от «отдать модифицированный диск» не спасет.

От CCA — спасёт. От атак evil maid-типа на boot chain — нет.

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

Да, об этом и подумал. Если изымут, то тут уже нужно считать весь диск ненадежным, и выкачивать данные через монтирование в другой системе, а не через запуск ОС внутри скомпрометированного диска. Тем более изымают весь ноутбук или ПК. Тут и подпись не поможет.

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

Кстати, Вы не в курсе,grub научился поддерживать luks2? В анонсах такое видел, но так и не дождался.

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

Не знаю. Я не использую GRUB2 или шифрованный /boot. У меня UEFI + Secure Boot с кастомными ключами.

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

Не факт, что дело в btrfs. Такое чувство, что расшифровка диска ошибочная. Сомнительно, что btrfs посыпалась настолько, что даже утилиты восстановления не будут видеть тут btrfs

Не знаю как сейчас, но много лет назад Btrfs могло убить диск так, что он вообще переставал определяться как диск.

mord0d ★★★★★
()
Ответ на: комментарий от intelfx

Что такое «работа с бэдблоками» в твоём понимании?

Здесь речь о том, чтобы сделать fsck, когда метаданные на в блоке, который не читается с девайса (стабильно возвращается ошибка как у ТС).

На всякий случай, в современном оборудовании управление бэдблоками полностью автономное.

Это заблуждение. Девайс не затрёт бедблок пока не получит от компьютера команду на запись в блок. А fsck не даст такую команду, пока не прочитает что в блоке. А диск не даст прочитать.

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

Здесь речь о том, чтобы сделать fsck, когда метаданные на в блоке, который не читается с девайса (стабильно возвращается ошибка как у ТС).

Как ты себе представляешь «сделать fsck», когда не читается суперблок (все его копии)? Нет суперблока — нет ФС, конец разговора.

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

Это заблуждение. Девайс не затрёт бедблок пока не получит от компьютера команду на запись в блок. А fsck не даст такую команду, пока не прочитает что в блоке. А диск не даст прочитать.

Сказанное тобой неверно. И вообще говоря при чём здесь fsck?

Если у тебя бэдблок в данных, то btrfs попытается его прочесть, не сможет и вернёт EIO. На этом месте пользователь удалит испорченный файл, после чего бэдблок станет относиться к свободному месту, а когда на это место рано или поздно попадёт новый файл, диск сделает реаллокацию.

Если у тебя бэдблок в метаданных, то btrfs попытается его прочесть, не сможет, пойдёт во вторую копию, прочитает вторую копию и восстановит первую копию из второй. На этом месте диск опять же сделает реаллокацию.

Ну и даже если бы это было верно, это не отменяет сказанного. Управление бэдблоками на стороне ОС — бесполезный архаизм.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.