Kernel Panic и невозможность chroot'a в систему

Похоже, что умер ssd.

КДЕ не готов

SSD цел. Проверил его сейчас на другой машине под виндой парой тестовых утилит

Ну явно что-то с файлами или файловой системой.

А что за файловая система и вообще разметка?

Один раздел ext4, раздел bios-boot. Структура GPT

Может ты ошибся в командах перепрошивки роутера и повредил ФС?

Как оказалось, всё же виновата ФС. Но как она могла слететь? Пытаюсь восстановить суперблоки, перебирая значения из бекапов, но выхлоп только такой:

sunderland93@ubuntu-pc:~$ sudo e2fsck -b 11239424 /dev/sda
e2fsck 1.44.1 (24-Mar-2018)
e2fsck: Недопустимый аргумент при попытке открыть /dev/sda

The superблок could not be read or does not describe a valid ext2/ext3/ext4
ФС.  If the устройство is valid and it really contains an ext2/ext3/ext4
ФС (and not swap or ufs or something else), then the superблок
is corrupt, and you might try running e2fsck with an alternate superблок:
    e2fsck -b 8193 <устройство>
 or
    e2fsck -b 32768 <устройство>

The superблок could not be read

If the устройство

Божественно

а точно /dev/sda? может всё-таки /dev/sdaN (1..X)

Хм. Попробовал указать раздел. Из бекапа восстановил кучу блоков, но по-прежнему не работает chroot и паникует система. И снова пишет что повреждён суперблок

Скорее всего накопитель всё же повреждён. Эти ошибки не всегда возможно исправить. «Варианты» есть:

• плохо вставлен шлейф
• RAM сбоит
• перегревается контроллер SSD
• ...

Бывает, что «повреждение» проявляется не всегда или не сразу. Какие именно причины его вызывают пользователь может только гадать.

Из опыта:

• диск IDE — ошибки контроллера(?): при старте «низкое» напряжение 12V не стартует вообще; при работе бывают отказы (возможно перегревается или проблемы с питанием)
• на другом ПК RAM сбоила, хотя ОС сообщала о проблемах с диском
• SSD (на Asus) копируется с ошибками командой dd (1 или несколько проблемных участков размером 4..20 Kb). Проявлялось только при попытках забекапить носитель с помощью dd. ОС работает нормально, повреждений файлов не замечено.

Ну вообще поведение свойственное проблеме на уровня железа. Было такое на малине. В электрощите дернул автомат без дугогасителя, передал то что нужно, включил и оп, не загружается. Подключил моник kernel panic. Пихнул флешку в комп - суперблок поврежден. mkfs ок, после читаю, опять суперблок поврежден. dd на запись проходит, и читает. Но фс не создается и все тут. Пришел к выводу о том, что как-то хитро погорел либо сам контроллер либо его периферия.

Имхо нужно ддшить весь диск и пробовать mkfs на нем. Если получится, значит навернулась оригинальная фс. Если не выйдет, SSD на свалку.

Имхо нужно ддшить весь диск и пробовать mkfs на нем

ДД-шить всмысле затирать нулями, или просто копировать данные с него?

Но как она могла слететь?

Например, если ОЗУ испортилось. Прогони memtest.

ext4

Но как она могла слететь?

Эта фс меня много раз подводила, не сказать, что настолько много раз, как ффс из опенбсд (которая вообще одна из худших фс на данный момент и которой даже softdep нихрена не помогают), но тем не менее странных случаев с ext4 было достаточно. Настолько достаточно, что я теперь всегда делаю:

sudo tune2fs -o journal_data,nodelalloc /dev/sda1

и не понимаю людей, которые такого не делают. И упсы тут совсем непричём. Плевать на скорость, важна стабильность. А если под юзкейсы нужен uber вариант, то рекомендую перейти на zfs и забыть о линуксах.

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

ДДшить всмысле снимать зеркало с носителя, это первое правило работы с битыми дисками. Снимем образ, а потом пробуем чинить железяку. Суть в том, что dd либо снимает нормальный образ фс либо нет. Если снимает, значит его потом полюбому можно восстановить, по крайней мере на другой физический другой диск, если нет, то увы жопа.

Если там очень важные данные я бы сделал так. Снял бы образ с потенциального битого SSD на другой носитель. Затем бы прошелся по нему dd if=/dev/zero дабы затереть все нулями. Потом mkfs.что_у_тебя_за_фс. После этого смотрим что и как. Если фейл, то делаем разметку с разумным сдвигом. Затрудняюсь сказать с каким, там все зависит от конкретного ssd, нужно что бы был сдвиг > размера физического сектора памяти. Хрен знает как на ssd, не имел дело никогда с ними, на tf обычно 4096. Это нужно что бы исключить банальный косяк с битым физическим сектором в суперблоке (да мне известно что контроллер должен сам определять в теории битые сектора, но увы мы живем не в мире розовых пони...). Если и это не прокатывает, т е новоиспеченная фс не желает функционировать как надо, то тут вариантов остается не сильно много. Самый очевидный будет ткнуть диск в другой комп и попробовать там прописать новую фс. Желательно если подключение на материнку не жесткоразъемное использовать другой шлейф. На этом как мне кажется варианты с железом заканчиваются. Вернее как, дальше начитается уже экспериментальное шаманство, с прозвонкой цепей мультиметром и поиском легко чинимых косяков, вроде сдохших стабов, прогоревших индуктивностей и пробитых кондеров. Тут никаких рекомендаций я не могу дать, так как все это чисто творчество под пивко :)

В общем если все это не привело к результатам, констатируем - железка сдохла. Идем к образу. Берем свежий хард/ssd, ддшим образ на него. Ну или через лупбак образ фигачим. Пробуем по нему fsck. Если не помогло, то последний шанc - tesdisk. Пытаемся вытащить данные. Если testdisk говорит что ваше г..но непотребно, то дальше идет уже шаманство программерское. Ну у меня до такого никогда не доходило, либо на каком-то этапе оно чинилось, либо данные были не столь важны что бы так париться. В общем если там у тебя ключи для запуская ядерных ракет по вероятному противнику, то идешь в ашан, покупаешь там пару ящиков пива. Ну и после изучаем спецификацию на целевую фс, открываем Eclipse, VS, Idea или что-там тебе удобнее и вперед на отчаянные попытки вытащить хоть что-то полезно из образа безверменно почившего диска.

Ну собственно вот алгоритм решения проблемы. Это чисто мое субъективное мнение ибо я ни сколько не претендую на позицию спеца по этой теме...

Сделал бэкап диска Clonezilla. Образ проверил, ошибок не обнаружено. Далее при помощи Secure Erase очистил SSD, создал новую таблицу разделов (GPT) и попробовал создать ext4 на ней. Опять же - ошибок никаких. Раскатал ранее созданный образ обратно на этот SSD - и снова паника. На другом накопителе проверить не могу. Похоже что была похерена сама структура ФС, но почему же образ нормально снялся?

Так это побайтовая копия же, все ошибки заботливо скопированы тоже))

но почему же образ нормально снялся?

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

Да, действительно. Сейчас раздобыл прошлогодний бэкап, попробую развернуться с него. Жаль что так и не выработал привычки бекапить всё подряд регулярно

Сейчас раздобыл прошлогодний бэкап, попробую развернуться с него

Если это чисто система, то всё путём. Мог бы даже не морочится, а установить по новой. Но если там есть что-то помимо системы, можешь попробовать вытянуть это из последнего (с повреждениями) бэкапа с помощью magic.