LINUX.ORG.RU

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

 , ,


0

1

Доброго времени суток. Совершенно ВНЕЗАПНО, без каких либо предпосылок, мой Debian 9 помер. Сперва вылетел браузер, затем KDE стало странно и дико себя вести, а потом и вовсе повисло. Перезагрузил системник кнопкой - и после загрузки получаю «Kernel Panic: not syncinc. Attemted to kill init» Загружаюсь в параллельно установленную бубунту, пытаюсь сделать chroot - но консоль выдает «chroot: failed to run command '/bin/bash': Accessing a corrupted shared library» Подскажите куда копнуть? Я совершенно не представляю что могло стать причиной такой аварии. Система установлена на SSD, ошибок файловой системы не обнаружил. Незадолго до аварии я перепрошивал роутер. Это последние действия на этой системе.

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

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 <устройство>

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

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

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

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

Из опыта:

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

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

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

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

ext4

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

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

sudo tune2fs -o journal_data,nodelalloc /dev/sda1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Deleted ()