Сегодня обновление убило мой Arch Linux на старом ноутбуке, чему я очень сильно удивился. Никогда такого не было и вот опять. Но ситуация довольно интересная, поэтому я оставлю описание этой проблемы и её решение на всякий случай на этом форуме. Вдруг кто придёт из поисковика, а у него такая же хрень окажется. Может помогу кому. Итак, фотография ошибки:
Kernel panic – not syncing: No working init found
Вечером я просто обновился привычной всем командой yaourt -Syua и перегрузился в Windows (стоит в дуалбуте рядом с Fedora и Arch Linux) по делам. Ладно, вру, перегрузился чтобы поиграть в Half-Life и Unreal Tournament ’99. Поиграл на славу, снова решил загрузиться обратно в Arch Linux — получил ситуацию, которая запечатлена на фотографии выше.
Сначала я подумал, что каким-то неведомым образом слетел Fedora’вский grub, так как именно он обеспечивает мне, так сказать, «дуалбут» в три операционные системы: Windows 10, Arch Linux и Fedora 29. Загрузился в Fedora, выполнил привычные команды для восстановления grub’а и обновления его конфигурации:
grub2-install /dev/sda
grub2-mkconfig -o /boot/grub2/grub.cfg
Перегрузился снова, в меню grub’а выбрал Arch Linux — ситуация нисколько не изменилась. Тогда я решил, что при последнем обновлении слетели какие-то модули в ядре и из-за этого оно валится в панику. Снова загрузился в Fedora. Отмечу, что как же хорошо, что я её установил рядом и теперь не мучаюсь со всякими LiveUSB-флешками в подобных ситуациях, примонтировал rootfs от Arch Linux’а и с помощью скрипта arch-croot чрутнулся в него:
mount /dev/sda4 /mnt
./arch-chroot /mnt
Из лога пакетного менеджера /var/log/pacman.log я вычленил список пакетов последнего обновления, которые могли испортить мне ядро и initramfs:
upgraded device-mapper (2.02.184-3 -> 2.02.184-4)
upgraded lvm2 (2.02.184-3 -> 2.02.184-4)
upgraded virtualbox-host-dkms (6.0.4-4 -> 6.0.6-1)
upgraded virtualbox (6.0.4-4 -> 6.0.6-1)
При установке VirtualBox с помощью DKMS незаметно для пользователя собираются и устанавливаются некоторые модули ядра, на которые я и грешил, а потому переустановил эти пакеты заново:
yaourt -S device-mapper lvm2 virtualbox-host-dkms virtualbox
yaourt -S linux
На всякий случай само ядро, пакет linux, я тоже переустановил. Перезагрузился — ситуация нихрена не изменилась. Подумал, раз ядро паникует от init’а, может проблема в systemd? Его же всегда и все винят во всех бедах! В третий раз загрузился в Fedora, переустановил пакет systemd и перегенерировал initramfs:
yaourt -S systemd
mkinitcpio -p linux
Перегрузился, постучался в Arch Linux — проблема не ушла. Очень странно! Пришлось в четвёртый раз грузиться в Fedora и начать гуглить инфу по этой ошибке. Поисковый запрос «kernel panic not syncing no init found arch linux» сразу же привёл меня в тему на форуме Arch Linux, благодаря которой я и решил эту проблему: [SOLVED] Kernel Panic - not syncing. No working init found. Человек на том форуме столкнулся с похожей ситуацией.
Итак, восстановление работы поломанного Arch Linux’а и расследование почему так случилось, ибо проблемка-то и не очень уж тривиальная. Из темы на форуме Arch Linux, по ссылке выше тот человек перепробовал все действия, которые попробовал я и у него тоже не получилось сначала восстановить работоспособность системы. Потом знатоки на том форуме посоветовали ему выполнить команду:
pacman -Qkk filesystem
warning: filesystem: /usr/lib64 (No such file or directory)
Для определения различных ошибок в структуре файловой системы. Я тоже её выполнил и так же как и в той теме наткнулся на странную проблему со сущностью /usr/lib64, которая в нормальных условиях ожидаемо должна быть симлинком на /usr/lib. У меня же этот файл вообще отсутствовал, а у того человека на форуме вместо симлинка был пустой каталог.
Механизм возникновения проблемы
Итак, судя по сообщению пользователя Scimmia:
There’s been a number of people without /usr/lib64/. I’m guessing it’s because of a updated that was
--force’d. Don’t do that.
В pacman’е имеется какой-то странный баг или поведение, когда при опции --force или --overwrite нарушается структура файловой системы, в частности, имеется вероятность неведомым образом снести симлинк /usr/lib64 или вместо него создаётся пустая директория, как у того человека с форума. Судя по логу, я действительно обновлял какой-то пакет из AUR’а с этой опцией из-за того, что установка ругалась на какие-то существующие файлы и не придал этому значение после. Но самый цимес в том, что обновлял я этот пакет целых три месяца назад и этот --force и вылетел у меня из головы.
Что интересно, само отсутствие /usr/lib64 похоже никоим образом не влияет на работоспособность системы. Если бы что-то отвалилось и перестало работать сразу после обновления и перезагрузки, то было бы легче догадаться в чём же именно дело. Но этот симлинк /usr/lib64 в rootfs каким-то странным и неведомым способом влияет на построение образа initramfs, а поэтому Arch Linux рассыпался только спустя три месяца (sic!), когда прилетело обновление VirtualBox, которое обновило свои модули ядра и потребовало перегенерировать initramfs, генератор которого видя отсутствие симлинка /usr/lib64 тупо взял и сгенерировал мне кривой образ, из-за которого ядро посыпалось в панику.
Решение проблемы
Как уже понятно из рассказа — тривиальное, создать убитый симлинк заново, перегенерировать initramfs по новой:
cd /usr/
ln -s /usr/lib/ lib64
mkinitcpio -p linux
После выполнения этих команд Arch Linux загрузился как ни в чём не бывало и продолжил нормально работать.
Вердикт
Вот такая довольно странная и нетривиальная проблема меня посетила, которая «занесла меч над головой» и целых три месяца никак себя не проявляла. Если честно, даже не знаю, не найдя подобную тему на форуме Arch Linux, смог бы я найти решение или нет. Скорее всего нет и тупо бы снёс раздел с Arch Linux’ом, перенеся важные файлы.
А чем вы занимались сегодня ночью?
