End kernel panic not syncing attempted to kill init exitcode 0x00007f00 как исправить

I got this issue with ubuntu 18.04, on upgrading my distro from 16.04 to 18.04, The boot process throws, Kernel Panic

e2fsck
sbin/init: No Such file or Directory
Kernel Panic - Not Syncing : Attempted to kill init !

In order to resolve this, I booted from Live Ubuntu 18.04 disk, then i replaced the contents of my filesystem directories

/bin & /sbin

with the corresponding content of the directories /bin & /sbin of stock filesystem of Live Ubuntu disk.

First find the disk partition which has the probelm in my case it was /dev/sda5 now boot from the live disk and mount /dev/sd5 with the Live Disk

open terminal and run the following commands to replace the contents

cp -r -i /bin /media/ubuntu/<name of your partition folder>
cp -r -i /sbin /media/ubuntu/<name of your partition folder>

example:

cp -r -i /bin  /media/ubuntu/cdfb882d-e33c-49b5-8965-fea541464686/bin/
cp -r -i /sbin /media/ubuntu/cdfb882d-e33c-49b5-8965-fea541464686/sbin/

shutdown the pc and reboot.

Done
Hope this may help!

switchroot: mount failed: No such file or directory. Kernel panic — not syncing: Attempted to kill init! Pid: 1. comm: init Not tainted 2.6.32-400.33.2.el5uek #1 Восстановить загрузку Linux, восстановить журнал EXT3/EXT4 ФС.

Когда становится скучно, то обычно чел. начинает искать себе каких-то приключений на свою пятую точку:) Вот мне на днях надоела стабильность моего локального сервера и мне захотелось какого-то «квеста» — и пошло поехало…

В линухах есть некая фича «Journaling Block Device layer» (ака JBD, процесс jbd2/sda2-8), которая на файловых системах EXT3/EXT4 занимается журналированием событий про данные с целью их дальнейшего восстановления в случае возможных сбоев в файловой системе.

На некоторых серверах, особенно со слабой скоростью доступа к диску (hdparm -t /dev/sda1), по показаниям iotop этот самый процесс jbd2/sda2-8 довольно часто дергает диск для записи в него параллельно с другими процессами выполняющими запись на диск, что вызывает всплески I/O Wait. Идея заключалась в том, чтобы полностью избавится от журнала и обслуживающего его процесса jbd2/sda2-8 (ps aux|grep jbd2).

Теоретически я знаю, что можно только сменить способ ведения журнала (data=journal, data=ordered, data=writeback), но полностью отключить журналирование и избавится от процесса jbd2/sda2-8 невозможно, но никогда не видел последствий этого замысла на практике — вот решил попробовать вовсе избавится от журнала и посмотреть чем это закончится;)

Долго ли коротко ли, вот нашелся рецепт:

Re: Resize journal on root filesystem
http://www.redhat.com/archives/ext3-users/2002-October/msg00026.html

> I’ve remounted my root filesystem as ext2, but still when I ‘tune2fs -O
> ^has_journal’ I get
> —-
> The has_journal flag may only be cleared when the filesystem is
> unmounted or mounted read-only.
> —-

Add the tune2fs command to rc.sysinit before the root filesystem fsck is run, then reboot the machine remotely.

В «рецепте» шла речь о изменении размера журнала на корневой файловой системе (Resize journal on root filesystem), для чего нужно его сначала удалить и создать заново с нужным размером, но создание нас не интересует — удаляем:)

После перезагрузки всё было хорошо и CentOS работала стабильно, но вот после второго reboot-а загрузка CentOS накрылась медным тазом с сообщением «switchroot: mount failed: No such file or directory» и иже с ним «Kernel panic — not syncing: Attempted to kill init!«:

switchroot: mount failed: No such file or directory
Kernel panic — not syncing: Attempted to kill init!
Pid: 1. comm: init Not tainted 2.6.32-400.33.2.el5uek #1

CentOS перестала загружаться и в однопользовательском режиме (aka single user mode), но меня это ничуть не расстроило ибо ж за что боролись на то и напоролись. Итак.., приступим к восстановлению.

Чтобы восстановить загрузку CentOS нам потребуется восстановить журнал EXT3/EXT4, а для этого нужен загрузочный/установочный диск и его режим «Rescue mode», для входа в который набираем linux rescue и жмем <Enter>.

После запуска выбираем язык и клавиатуру по умолчанию EN, отказываемся от настройки сети, нажимаем «Continue» ради интереса или просто «Skip» чтобы сразу выйти в консоль ибо «Continue» нам здесь всё равно не поможет.

Теперь же, когда мы в консоли, выполняем набор команд:

Сбой в загрузке CentOS с сообщением «Kernel panic — not syncing: Attempted to kill init!» может иметь различную природу происхождения, но когда никак не получается восстановить запуск ОС, то как вариант нужно попробовать восстановить журнал EXT3/EXT4, т.е. удалить и создать заново.

Аналогичные последствия с результатом «Kernel panic — not syncing: Attempted to kill init!» будут иметь место на любых дистрибутивах Linux в случае полного удаления журнала EXT3/EXT4 или же его возможного повреждения, но в нашем случае это был CentOS GNU/Linux.

Приведённый здесь рецепт по восстановлению журнала для EXT3/EXT4 должен работать и других GNU/Linux дистрибутивах, различаться могут способы загрузки в «Rescue mode».

Ссылки по теме:

• Chapter 26. Basic System Recovery
• 26.2. Booting into Rescue Mode
• Ext3 Filesystem Documentation
• Ext4 Filesystem Documentation