Emask 0x409 media error

30 ноя 2017, 17:11

Тут имеет смысл попробовать запустить такую программу из консоли, и посмотреть — не пишет ли оно чего интересного.
А так же, интерес представляет содержимое файла /var/log/syslog

Что-то это подозрительно напоминает симптомы проблем с диском.

Некоторые программы перестали запускаться

30 ноя 2017, 17:15

$ pix
Ошибка шины
irina-mint@irina-mint

$ ffDiaporama
[17:14:04.799:INFORMATION] StartupDir /home/irina-mint
[17:14:04.799:INFORMATION] Try to find datas in /home/irina-mint/ffDiaporama.xml 0
[17:14:04.800:INFORMATION] Try to find datas in /home/ffDiaporama/ffDiaporama.xml 0
[17:14:04.800:INFORMATION] Try to find datas in /home/ffDiaporama/ffDiaporama.xml 0
[17:14:04.800:INFORMATION] Try to find datas in /usr/share/ffDiaporama/ffDiaporama.xml 1
[17:14:04.800:INFORMATION] Set working path to /usr/share/ffDiaporama
[17:14:04.804:INFORMATION] Search Raster mode in configuration file/usr/share/ffDiaporama/ffDiaporama.xml
[17:14:04.805:INFORMATION] Search Raster mode in configuration file/usr/share/ffDiaporama/ffDiaporama.xml
Set LogLevel to INFORMATION
[17:14:04.940:INFORMATION] Starting ffDiaporama 1.5
[17:14:04.942:INFORMATION] Loading application translation file . locale/ffDiaporama_ru.qm
[17:14:04.943:INFORMATION] Loading QT system translation file . locale/qt_ru.qm
[17:14:04.943:INFORMATION] Read configuration file /usr/share/ffDiaporama/ffDiaporama.xml
[17:14:04.962:INFORMATION] Read configuration file /usr/share/ffDiaporama/Devices.xml
[17:14:04.972:INFORMATION] Read configuration file /home/irina-mint/.ffDiaporama/ffDiaporama.xml
[17:14:04.976:INFORMATION] Read configuration file /home/irina-mint/.ffDiaporama/Devices.xml
[17:14:05.156:INFORMATION] Loading system icons.
[17:14:05.295:INFORMATION] Try to found avconv . found
[17:14:05.295:INFORMATION] Starting libav lib .
[17:14:07.297:INFORMATION] Reading directory content (

/)
[17:14:07.496:INFORMATION] Загрузка файла:1424980963_2115705965.gif
Ошибка шины

Источник

Сбой на системном SSD накопителе

vasek
Глядя на S.M.A.R.T. я критических ошибок не вижу — то что много ошибок чтения и имеются переназначенные сектора еще ни о чем не говорит (поле RAW_VALUE не стандартизовано и каждый производитель использует свои стандарты), главное, что столбец WHEN_FAILED пуст, здесь метода у всех стантартизована — сигнал об ошибке все расчитывают одинаково.
В части сообщений Libata error ….. ничего конкретного вытащить нельзя ….
media error — Software detected a media error ….(очень широкое понятие)
Сохрани важные данные, сделай полный S.M.A.R.T. (по времени будет больше часа . доведи до конца и ничего не делай. )
smartctl -t long /dev/sd. (или smartctl —test=long /dev/sd. )
ну и периодически анализируй динамику развития параметров S.M.A.R.T.

Смарт у меня вываливается в офф, я жду назначенное время, а потом:
Из оффа, кстати, комп в коматозном состоянии выползает — большинство функций не работают.
Полный лог ошибок

corner
Похожая ситуация с SSD Intel.
S.M.A.R.T. здесь, конечно, не помощник.
Тоже обновлял прошивку, оставлял 25% свободными при создании файловой системы.
Пробовал на разных компьютерах.
Решил проблему заменой диска на обычный.
Теперь жду, когда найдется накладная 🙂
Гарантия 5 лет 🙂 3 года в запасе 🙂

# 6 лет, 9 месяцев назад (отредактировано 6 лет, 9 месяцев назад)

yaa
A mandatory SMART command failed: exiting. To continue, add one or more ‘-T permissive’ options.

Насчет ошибки (не в курсе что у тебя, поэтому привожу полный перечень для проверки)
— smartmontools надеюсь установлен
— в некоторых BIOS требует подключения в BIOS
— проверить активирован ли SMART (# hdparm -I /dev/sda | grep SMART . должна быть звездочка)
— ~~если все имеется,~~ пробуй, что тебе советует вывод — add one or more ‘-T permissive’ options
— пробовать (дополнительно к опции T permissive) опцию ‘-d‘ . можно методом логического выбора
~~— ну и если usb , то возможно нет smart (все зависит от контроллера)~~

Вооот склероз. совсем забыл, что вывод SMART имеется. как всегда, пишу, а потом думаю.
PS. попробуй использовать /dev/sg. . как то встречалось, что иногда помогает..

# 6 лет, 9 месяцев назад (отредактировано 6 лет, 9 месяцев назад) Покапался у себя …. некоторые пробуют разные опции типа libata.force= и другие …. даю ссылку, где часть этих опций в одном месте. чел пробовал их методом тыка и проверял их действие
Плюс к этому свежая статейка на тему ошибки «failed command: READ FPDMA QUEUED»
Вряд ли это твое (вроде бы причина ее шлейф, источник питания), но на всякий случай ссылку оставляю.
PS. Давно хочу найти подробную расшифровку libata error, в принципе, на ихнем сайте имеется описание, но хотелось бы иметь подробное описание формата сообщений (всех полей)

Не смог получить внятного ответа от тестов поверхности.
После тестирования по опциям «. -l selftest. » и «. -l error. » выдаётся

Device does not support Self test logging
и
Error Counter logging not supported

После завершения тестирования ничего не работает (input/output error) приходится в жёсткую перезагружать компьютер

vasek
. попробуй использовать /dev/sg. . как то встречалось, что иногда помогает..

У меня вообще нет устройств /dev/sg*

По ссылкам ходил, но так и не понял — как их можно использовать. Перебирать ключи не рискнул.

# 6 лет, 9 месяцев назад (отредактировано 6 лет, 9 месяцев назад)

yaa
Device does not support Self test logging
и
Error Counter logging not supported

# 6 лет, 9 месяцев назад (отредактировано 6 лет, 9 месяцев назад) Так, по тесту поверхности вроде бы PASSED:

vasek
. для надежности можно перепроверить
# hdparm -I /dev/sd. и смотреть секцию Enabled Supported: . наличие звездочек

# 6 лет, 9 месяцев назад (отредактировано 6 лет, 9 месяцев назад)

yaa
То есть если «The previous self-test routine completed without error or no self-test has ever been run (а я его совершенно точно run)» причина не в физике, а в логике?

yaa
SMART overall-health self-assessment test result: PASSED

yaa
res 51/40:02:32:48:8a/00:00:00:00:00/40 Emask 0x409 (media error)

как уже писал расшифровку media error — Software detected a media error
Лечение программных ошибок советуют лечить сменой прошивки.

Знатокам SSD — заметил в выводе hdparm следующие не понятные для меня записи — проясните, если сможете.
— cache/buffer size = unknown
— не активирована опция Look ahead — предвыборка чтения (отключениеи этой опции в обычных HDD приводит к снижению быстродействия).
Это так на всех SSD и эти параметры ни очем не говорят и в SSD не имеют смысла?

UPD. yaa, не понял, а почему были проблемы с тестом.

vasek
не понял, а почему были проблемы с тестом.

Я сам не знаю. Запускаешь тест. Он выдаёт стандартное сообщение о продолжительности, реквизиты и пр.
Я предварительно тушу всё лишнее. Через обозначенное время смотрю результаты.
Так вот — вывод «smatrctl» работает. Остальное — даже reboot не работают «после выхода» из офф-лайна.
Может у меня «офф» какой-то неправильный?

Чудить начал. Сижу на дуал-буте. Запустил тест поверхности mini-tool — 6 сбойных секторов на том разделе, где Арч. На виндюке, кстати, всё нормально — он тоже на sdb сидит.

Источник

Emask 0x409 media error

20 янв 2017, 12:25

Подцепив диск к соседнему хосту при обращении к нему в dmesg нарисовалось следующее:

Ошибки чтения секторов на HDD

20 янв 2017, 13:13

Ошибки чтения секторов на HDD

20 янв 2017, 21:30

Диска биос больше не нашел

Зацепил обратно к другому десктопу — все гуд, только автоматом восстановилось несколько потерянных inode судя по dmesg:

Видимо пришла очередь прощаться с PSU . Комплексная проблема — коварная штука, вроде и хард был с unrecoverable секторами, так еще и БП чудит

Сейчас воткнул туда ноутбучный 2,5″ хард на 5400 rpm, которому мощей нужно поменьше — вот уже несколько часов работает, зараза

Ошибки чтения секторов на HDD

20 янв 2017, 21:43

Ошибки чтения секторов на HDD

20 янв 2017, 21:48

Ошибки чтения секторов на HDD

20 янв 2017, 21:49

Ошибки чтения секторов на HDD

20 янв 2017, 21:52

Ошибки чтения секторов на HDD

20 янв 2017, 21:57

Ошибки чтения секторов на HDD

20 янв 2017, 22:06

KVF , не, напрямую к розетке. Входное конечно там можно замерить, но сомневаюсь что дело снаружи.
Перекочевал этот БП с основного десктопа, где до апгрейда тоже чудили этот хард и его полутеровый ровесник (с учетом их возраста я спокойно бы воспринял гибель), но ссдшка без хардов работала норм, а те могли на лету отвалиться, тогда на hdd был /home и /var, а на ssd корень со всем остальным — в dmesg явно было видно потерю девайса и переинициализацию оборудования.

Не исключено что этим насилием и заработал битые сектора, с которых чегодня начал.

Источник

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

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

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

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

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

sudo cast torvn77

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

а что говорит SMART? А после прогона полного SMART self-test?

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

не фанат btrfs, но btrfs поверх lvm, который поверх luks такое себе. Если luks не расшифровал, то все.

ata1.00: failed command: READ FPDMA QUEUED

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

На 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

lvm нету. Напрямую на luks

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

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

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

SMART overall-health self-assessment rest result: PASSED

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

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

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

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

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

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

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

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

Двойное резервирование данных, кажется, это по-умолчанию в btrfs

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

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

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

Ну не знаю, я всегда пишу эту опцию при форматировании раздела.

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

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

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

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

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

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

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

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

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

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

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

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

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

раздел около 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 только по указанию разработчиков (или если охота поэкспериментировать на копии образа ФС).

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

«Везде» — это как? Что именно ты пробовал запускать?

Тогда, возможно, всё и правда плохо.

cryptsetup luksDump /dev/sdXY :

blockdev —getsz /dev/mapper/foobar :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник