Linux kernel panic not syncing что делать

Обновлено: 26.01.2025

24 окт 2020, 03:21

М.б. ошибся с разделом в котором необходимо задать данный вопрос.

[ OK ] Reached target Reboot
/shutdown: error while loading shared libraries: libininstring.so.2: cannot open shared object files: No such file or directory
Kernel panic - not syncing: Attempt to kill init! exit code=0x00007f00

60Hz
OpenGL: renderer: Mesa Intel HD Graphics 500 (APL 2) v: 4.6 Mesa 20.0.8
direct render: Yes
Audio:
Device-1: Intel Celeron N3350/Pentium N4200/Atom E3900 Series Audio Cluster vendor: ASRock driver: snd_hda_intel v: kernel bus ID: 00:0e.0
Sound Server: ALSA v: k5.4.0-52-generic
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: ASRock driver: r8169 v: kernel port: e000 bus ID: 02:00.0
IF: enp2s0 state: up speed: 100 Mbps duplex: full mac: <filter>
Drives:
Local Storage: total: 465.76 GiB used: 283.60 GiB (60.9%)
ID-1: /dev/sda vendor: Toshiba model: MQ01ABD050 size: 465.76 GiB
Partition:
ID-1: / size: 457.42 GiB used: 283.59 GiB (62.0%) fs: ext4 dev: /dev/sda2
Sensors:
System Temperatures: cpu: 58.0 C mobo: N/A
Fan Speeds (RPM): N/A
Info:
Processes: 173 Uptime: 34m Memory: 3.51 GiB used: 1000.7 MiB (27.8%)
Init: systemd runlevel: 5 Compilers: gcc: 9.3.0 Shell: bash v: 5.0.17
inxi: 3.0.38

Второй момент: Universe@Home отключить попробуйте тоже. Хоть оно ошибок не сыпет - зато может грузить машину по самые уши "в свободное время" провоцируя проявление косяка. Если после отключения симптомы пропадут - значит большая нагрузка железке/системе не дается.

Kernel panic при выключении или перезагрузке

24 окт 2020, 13:45

При не слишком продолжительной работе такого явления не возникает.

намекает на то, что проблема скорее всего завязана на железо. (Большая часть "плавающих" неисправностей на него завязана). Потому начинать диагностику надо с тестов памяти и диска, IMHO. А далее - можно попробовать замену ядра, может несовместимость с железом присутствует. И неплохо было бы глянуть полный вывод journalctl за всю длинную сессию, которая закончилась проявлением проблемы - возможно там что-то отмечается.

Чтобы получить лог сессии в файл: journalctl -b -1 > session.txt где "-1" - насколько предыдущих сессий отмотать назад. Т.е. просто -b без второго ключа - текущая сессия, -1 - предыдущая, -10 - десять загрузок назад.

Kernel panic при выключении или перезагрузке

24 окт 2020, 16:26

при выключении или перезагрузке системы перестает полностью отрабатываться команда shutdown. Ты вручную что ли выключаешь, перезагружаешь? Или нарукаблудил, скачал какую-то приспособу?

Kernel panic при выключении или перезагрузке

24 окт 2020, 17:49

Kernel panic при выключении или перезагрузке

24 окт 2020, 18:28

И неплохо было бы глянуть полный вывод journalctl за всю длинную сессию, которая закончилась проявлением проблемы - возможно там что-то отмечается. Взял 10 сессий. выложил на шару . По времени проявления, по моему, это была session4.txt, про другие - не помню когда проявлялось, м.б. 6-я и 7-я, врать не буду. По крайней мере, session4.txt с 18:31 до 02:10 Тогда, по моему, задумал перезагрузиться и на выходе, когда практически всё отработалось и экрану оставалось только моргнуть чёрным и показывать новый старт системы, получил затык с выводом дампа. Как раз это было после 02 часов. После этого в тщётном поиске возможной причины ошибки немного порыскал в Интернет и стал писать на форум.
Сначала грешил на железо, но потом вспомнил, что на предыдущей системе LM18 с ядром 4.15 такого безобразия, вроде бы, не наблюдалось. Железо представляет из себя безвентиляторный блок ноутбучной начинки с ноутбучным внешним БП. АКБ не имеется. Хотя, кто его знает, железо имеет свойство ломаться.

Kernel panic при выключении или перезагрузке

24 окт 2020, 19:22

Kernel panic при выключении или перезагрузке

24 окт 2020, 19:26

Загрузился с livecd, через gparted сделал check раздела.
По выводу обнаружилась 41 запись вида:
inode . extent tree (at level 1) could be narrower. Optimize? yes
Как пишут в англоязычных источниках, вроде бы, не смертельно. А в действительности что бы это значило?
По "Настройка - Диски - Тесты и данные SMART" выводит, что "Обновлено 2 минуты назад. Последняя самодиагностика завершена без ошибок". Перераспределённых секторов = 0. Но смущает 191 - кол-во ошибок в результате нагрузок при ударе или падении = 26. Это что, типа головки на пластины упали?

Kernel panic при выключении или перезагрузке

24 окт 2020, 19:39

Попробую вырубить вообще, тем более, что погоды не делает, так как имеется альтернатива в виде rclone . Попробую. Использование было связано с тем, что никакими способами: ни /etc/hdparm.conf , ни службой tlp не удалось победить периодическую парковку винчестера каждые 10-12 минут - "щёлк, щёлк" особенно слышно ночью (растёт 193 параметр SMART). А так, думал, пусть математические вычисления в интересах науки периодически дёргают винчестер, ежеминутно записывая на него промежуточные результаты и не давая ему парковаться.
Потестирую, отпишусь. Хотя, в связи со случайностью проявления, быстрого ответа не обещаю.

Kernel panic при выключении или перезагрузке

24 окт 2020, 19:50

Если бы упали - был бы запил, и кранты диску. Нет, это только фиксация от сенсора удара/движения - оно таки было, и превосходило допустимое для диска во время работы. Это не значит, что ему совсем плохо, это значит - что ему МОЖЕТ быть плохо по этой причине, т.к. производитель на такое не рассчитывал.
Использование было связано с тем, что никакими способами: ни /etc/hdparm.conf, ни службой tlp не удалось победить периодическую парковку винчестера каждые 10-12 минут - "щёлк, щёлк" особенно слышно ночью А покажите-ка вывод smartctl -x целиком. С одной стороны - винт ноутбучный, ему положено. А с другой, странный период парковки - раз в 10-12 минут? (Ключ именно -x а не -a).

Kernel panic при выключении или перезагрузке

24 окт 2020, 20:19

С одной стороны - винт ноутбучный, ему положено. А с другой, странный период парковки - раз в 10-12 минут? Да такая же картина и на втором аналогичном, но более продвинутом девайсе. Там системным SSD, а с такой же периодичностью паркуется второй HDD. Поэтому спасение используется в виде виртуальной Windows, которая крутится на HDD. К сожалению, на эти веники Toshiba фирменной утилиты не выпускалось, а использовать Windows уже религия не позволяет. Ничего себе простыня, 390 строк. Наверное, такой объём встраивать как то будет не совсем прилично, поэтому вывод там же - smartctl-x.txt

Kernel panic при выключении или перезагрузке

24 окт 2020, 20:38

Насколько я вижу - у железа проблемы с общением по data каналу. Редкие, но присутствуют. Система вынуждена периодически reset состояния делать для интерфейса винта, а это не слишком хороший признак, даже если ничего другого не проявляется. Но тут фиг поймешь где именно баг засел - это может быть как винт, так и кабель, и контроллер на материнке.

Тест же он у вас проходил только короткий. Попробуйте прогнать полный:
smartctl --test=long

Kernel panic при выключении или перезагрузке

24 окт 2020, 21:21

Плохо мне быть тупым
Запустил sudo smartctl --test=long /dev/sda > /home/minter/smartctl-test-long.txt
Содержание файла вижу. Написано, что тест займёт не менее 120 минут, но терминал возвратился в приглашение minter@H-4:

$
Результат упадёт в txt или я сделал неправильно?

Kernel panic при выключении или перезагрузке

24 окт 2020, 23:50

Ты сделал неправильно. Ничего никуда не упадет, т.к. smartctl ничего сам не тестирует, он только говорит прошивке диска что от него хотят, после чего прошивка сама занимается диском, по своему усмотрению, автономно. Тест будет выполнятся фоном, результат будет только в журнале SMART. По факту - сколько займет, зависит от того, будет ли диск чем-то еще заниматься или нет. Потом, когда закончит, результат можно будет посмотреть через smartctl -a и -x. Вот тогда уже можно в файл вывод отправлять.

Kernel panic при выключении или перезагрузке

25 окт 2020, 02:21

Тест д.б. завершиться в 01:23, команды давал после 02 час. По самостоятельному поиску нашёл, что результат можно посмотреть командой smartctl -l selftest /dev/sda ( источник ).
Пару минут назад выполнил smartctl -a и smartctl -x
Результаты выводов в файлах 2-smartctl-a.txt, 2-smartctl-l-selftest.txt, 2-smartctl-x.txt

И до кучи SMART 193 - 2 среза времени, ничем кроме браузера не дёргал с 22:52 :
22:55 - 14574
00:17 - 14585

Kernel panic при выключении или перезагрузке

25 окт 2020, 15:17

И до кучи SMART 193 - 2 среза времени, ничем кроме браузера не дёргал с 22:52 :
22:55 - 14574
00:17 - 14585

Для ноутбучного диска это нормально. Они так себя защищают от передвижений ноутбука, там парковка выставлена на небольшое время, и диск на это рассчитан. (300000-500000 циклов ресурса у самых дешевых моделей - норма).

А вот гораздо неприятнее вот это:

Особенно первая строчка. Диск "отваливается" с линии, возвращается (до того как фиксируется ошибка SATA), но через короткое время снова отваливается и так по кругу. Это не нормально. Для диска который более-менее в порядке - это значение обычно не превышает 500-1000, а чаще всего - и пары сотен. Точный смысл параметра производители не особо разглашают, но общий - тот что я описал. У вас он ОЧЕНЬ сильно завышен. Т.е. полностью здоровым диск считать нельзя. К сожалению, тут может еще влиять сам контроллер на материнке, так что на 100% диагноз только на этой основе не поставишь. В идеале - заменить диск, и посмотреть как себя будет вести SMART у замены.

Kernel panic при выключении или перезагрузке

25 окт 2020, 15:59

Дело в том, что если сам девайс был новый, то установленный в нём винчестер - б/у (племянник со своей IT работы подогнал после модернизации компов на предприятии). Изначально покупными были только корпус, материнка и проц. Мозги, винчестер и БП в комплекте не поставлялись - это б/у. Если к железу и были подозрения, то к винчестеру в первую очередь.
Сегодня установил cron на выключение в 08:30 Сессия была довольно-таки длинная - навскидку порядка 10-11 часов. Но выключился штатно, без проблем. Ещё попробую с недельку хорошо погонять, если будет проявляться, то попрошу племянника сменить мне жёсткий диск, тем более, по его словам, проблем с этим не имеется. О результатах отпишусь.

Kernel panic при выключении или перезагрузке

31 окт 2020, 13:48

Как и обещал, отписываюсь по результатам проверки.
За прошедшую неделю система все сессии отработала в штатном режиме. Причём одна из сессий имела продолжительноть более 17 часов, остальные - не менее 10-12 часов. Главный вывод – проблема комплексная, то есть программно-аппаратная.

1. Клиент pCloud. Имевший место случай являлся единичным. К тому же, клиент постоянно не работает. После старта системы с автозапуском pCloud через 10 минут клиент pCloud выключается через скрипт.

2. Universe@Home. По умолчанию в настройке клиента установлено значение "Использовать не более 100% времени ЦП". Это значение было изменено на 70%. Кроме того указано, чтобы за 3 минуты до выключения компьютера (по расписанию) служба BOINC останавливалась.
Вероятнее всего, при совпадении момента выключения системы и активного обращения Universe@Home к жёсткому диску имело место "отваливание" data канала диска. Как раз об этом и говорил slant : " . зато может грузить машину по самые уши "в свободное время" провоцируя проявление косяка ".

3. Сам винчестер, один из параметров которого " . У вас он ОЧЕНЬ сильно завышен. Т.е. полностью здоровым диск считать нельзя ".

По крайней мере, на будущее уже известны слабые места эксплуатируемого железа.

Хотелось бы ещё раз выразить признательность slant за потраченное на меня время при разбирательстве логов сессий и подробные разъяснения. Тему можно считать закрытой.

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

В линухах есть некая фича "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 невозможно, но никогда не видел последствий этого замысла на практике - вот решил попробовать вовсе избавится от журнала и посмотреть чем это закончится;)

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

> 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), для чего нужно его сначала удалить и создать заново с нужным размером, но создание нас не интересует - удаляем:)

Только после полного отключения блокировщика скриптов и рекламы на этом месте появится полезная подсказка/ссылка/код/пример конфигурации/etc!

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

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

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

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

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

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

Рекомендуемый контент

Вы не любите рекламу!? Напрасно!:) На нашем сайте она вовсе ненавязчивая, а потому для нашего сайта можете полностью отключить AdBlock (uBlock/uBlock Origin/NoScript) и прочие блокировщики рекламы! AdBlock/uBlock может препятствовать нормальной работе системы поиска по сайту, отображению рекомендуемого контента и прочих сервисов Google. Рекомендуем полностью отключить блокировщик рекламы и скриптов, а также разрешить фреймы (aka iframe).

Как мы это исправим?

Я не могу опубликовать ответ, так как мне не хватает представителя, но когда я получил эту проблему, я решил ее, загрузившись с USB-флешки, смонтировав основной раздел и раздел EFI , включив сеть и выполнив sudo apt-get install linux-image-generic обновление до последней версии. ядро.

Вам не хватает initramfs для этого ядра. Выберите другое ядро в меню GRUB в разделе « Дополнительные параметры» для Ubuntu и запустите, sudo update-initramfs -u -k version чтобы сгенерировать initrd для version (затем замените version строку версии ядра, например 4.15.0-36-generic ) sudo update-grub .

Что делать, если при выборе уникальной опции ядра, существующей для этой ОС (в случае мультизагрузки), отображается паника ядра, как можно запустить update-initramfs? Я не могу ввести Ubuntu System или Recovery Mode , как я могу выполнить эту команду, чтобы проверить, работает ли она?

Начните с livecd, откройте терминал

и теперь вы можете сделать update-initramfs и обновить-grub без ошибок.

Если вы не знаете свою версию. Использование:

И просто обновить Grub.

Перезагрузите вашу систему.

Я добавил sudo mount --bind /dev/pts /mnt/dev/pts и sudo mount --bind /sys /mnt/sys в моем редактировании; без этого update-grub2 жаловался. Ни одна из точек монтирования не существует, кроме первой / dev / sdax, если вы используете EFI. @knocte попробуйте ls /mnt/boot найти последнюю версию ядра. Или, если вы хотите сделать это правильно, прочитайте menuentry 'Ubuntu' от /mnt/boot/grub/grub.cfg Работал на Ubuntu 14.04! initrd Не хватало /boot . Вопрос: как это возможно, что файл просто исчез? Я не делал ничего, что казалось опасным.

В моей ситуации проблема была в том, что /boot емкость была 100%, поэтому последние 2 обновления ядра не были успешно завершены, поэтому при перезагрузке, когда GRUB2 выбрал последнее ядро, произошел сбой.

Я решил проблему путем загрузки самого старого установленного ядра и удаления некоторых неиспользуемых ядер с помощью aptitude. Используя aptitude , после того, как деинсталляция произошла, dpkg автоматически попытался настроить поврежденные пакеты, и на этот раз это удалось.

У тебя умирает init. После смерти процесса, указанного в параметре init для ядра ядро уходит в panic. Попробуй явно указать init=/bin/bash, init=/sbin/init etc.

А больше этой надписи ничего нет?

Выше сказали правильно, init умер (упал?).
Тем не менее, давайте посмотрим на фото экрана с паникой и, желательно, незадолго до нее.
Сколько памяти на машинке? Попробую воспроизвести загрузку в не-PAE варианте VirtualBox.

bormant ★★★★★ ( 14.04.17 00:40:16 )
Последнее исправление: bormant 14.04.17 00:42:21 (всего исправлений: 1)

Не помогает.
Интересно, что Slackware 13.1 устанавливается без проблем даже без принудительного указания huge.s.
Да, установка производится с DVD, если вдруг это принципиально.

Нормально устанавливаются Slackware 13.1 и текущий Debian 8.7.1 i386.

Поздновато :(
Не видно, что упало. Может видео в низком фреймрейте?

лучше лог, наверное, загрузки. /var/log/

Установка с DVD, система в конце виснет. Где смотреть лог?

Сорри, пролетело мимо. Тысячу извинений.

Еще попытка заснять:

Перед крашем все быстро пролетает, я не смог разглядеть.

Самое простое, что могу посоветовать предпринять, взять миниисо от 14.1, поставить наборы A, N, добавить AP/slackpkg, обновить не-smp ядро из 14.2 patches/packages, обновиться из 14.2.

Если начнет падать, что-то делать с этим, иначе доставить остальное.

Решил остановиться на Debian.
Установил консоль и сверху иксы и icewm. Летает как реактивный самолет.
Единственно, что напрягает - версия ядра в нем 3.16.0, а у меня не стартуют как раз дистрибутивы, идущие из коробки с четвертым ядром. Боюсь, что с выходом Debian 9 начнутся такие же проблемы.

И разве что-то помешает не менять версию?

Так проблеме и не в самом ядре. По логу загрузки происходит инициализация, запуск процесса init, падение процесса init. Поэтому ядру ничего не остаётся, кроме паники.
А вот почему падает init — вопрос отдельный.Есть в бинарники что-то, что проявляется именно в ваших условиях. Причины тому могут быть разные: ошибка в исходном коде, ключи сборки именно этого экземпляра, компилятор, которым собран init.

Причём, речь том init, что в установочной среде (/isolinux/initrd.img), а там это ссылка на busybox. То есть, дело даже не в самой системе, а только в busybox из установщика.

Поэтому возможен такой вариант.
Берёте установщик от 13.1 (подойдёт mini-iso от AlienBOB или штатный образ флешки из дистрибутива 13.1, или сам носитель с 13.1), на этапе SOURCE указываете ему, где лежат пакеты от 14.2.
В результате получите установленную 14.2.

Либо можете попробовать в /isolinux/initrd.img заменить busybox тем, что был в 13.1.

bormant ★★★★★ ( 17.04.17 08:33:53 )
Последнее исправление: bormant 17.04.17 08:34:24 (всего исправлений: 1)

Читайте также: