Linux exit code 0x00007f00

отладка ‘Паники ядра — не синхронизация: Предпринятый для уничтожения init!’

После принятия к обновлению ядра моя система прекратила функционировать. Команды на терминале (как ls , cd , и т.д.), не работали и возвратил сообщение об ошибке command not found , а также попытка использовать GUI для любого действия.

Я сильно закрыл компьютер, и после перезагрузки I (как и следовало ожидать) получил ошибку паники ядра:

Я не запаниковал (надейтесь, что Вам нравится игра слов), и искал возможные решения онлайн, среди которых я нашел:

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

• Не может загрузиться потому что: паника Ядра — не синхронизация: Предпринятый для уничтожения init!
• Диагноз: Пропавшие без вести /sbin/init файл
• Решение: Используйте LiveOS для поиска /sbin/init файл, попытка добавить его при пропавших без вести.

Моя ошибка подобна, как run-init команда не работает, но не потому что файл отсутствует. Так же к случаю OP, мой диск хорошо работает и если я получаю доступ к устройству от LiveOS, я могу найти все двоичные каталоги и файлы.

Ссылки относятся к различным системам, таким образом, я адаптировал решение следующим образом, после того как я запустил GRUB командная строка:

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

Вид несвязанных с паникой ядра, но объясняет, как загрузиться в однопользовательский режим из меню GRUB. Это предотвращает X Server от того, чтобы быть запущенным и надо надеяться позволил бы мне выполнять ядро.

В этой точке я нашел многих диагнозом, попробовал много решений, и ничто не работало.

Что я (думают I) понимаю:

• Ядро (и новый и старый, режим восстановления или не) имеет проблему при выполнении run-init команда.
• Это не имеет никакого отношения к моему HW, поскольку компьютер хорошо работает с LiveOS, и я могу использовать видеокарту, получить доступ к моему диску, использовать клавиатуру и мышь.
• Эта ошибка находится на ранних стадиях начальной загрузки, поскольку пытающийся загрузиться в однопользовательский режим не работает и предотвращение X server загружаться не имеет никакого эффекта.

Что я хотел бы понять, в порядке важности:

• Действительно ли возможно, что новая установка ядра перезаписывает / смешивает старое ядро?
• Кто-либо знает о чем-то, что я пропускаю / другие решения?
• Я делал ошибку в реализации вышеупомянутых решений?
• Есть ли что-нибудь, что я не попробовал, который прибывает первое, что пришло на ум?
• Я могу установить новое ядро, не форматируя все от консоли GRUB?
• Время это для переустановки ОС? (Если Вы не можете ответить на тех выше, я уже знаю ответ этому. ),

Дополнительные материалы для чтения

Источник

Linux exit code 0x00007f00

24 окт 2020, 03:21

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

При длительной (именно длительной) работе (6-8- часов и более) при выключении или перезагрузке системы перестает полностью отрабатываться команда shutdown. В сообщении на экране запись ссылается на libuninstring.so.2 Однако сама библиотека присутствует по пути /usr/lib/x86_64-linux-gnu При не слишком продолжительной работе такого явления не возникает.

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:
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

Вроде бы не только в 4-ой сессии встречается, но если дело доходит до дампа — значит явный косяк. Влияет или нет — тут только проверочным отключением проверять. Клиент для вот этого https://www.pcloud.com/ru/eu чудит, я так понял.

Второй момент: 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

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

24 окт 2020, 17:49

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

24 окт 2020, 18:28

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

24 окт 2020, 19:22

Вроде бы не только в 4-ой сессии встречается, но если дело доходит до дампа — значит явный косяк. Влияет или нет — тут только проверочным отключением проверять. Клиент для вот этого https://www.pcloud.com/ru/eu чудит, я так понял.

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

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

24 окт 2020, 19:26

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

24 окт 2020, 19:39

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

24 окт 2020, 19:50

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

24 окт 2020, 20:19

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

24 окт 2020, 20:38

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

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

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

24 окт 2020, 21:21

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

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

24 окт 2020, 23:50

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

Смущают записи:
# 3 Extended offline Aborted by host 90% 19216 —
# 4 Extended offline Aborted by host 90% 19216 —
Глубокий тест не прошёл? Хотя по незнанию 2 раза обрывал тест. Но 3-й глубокий тест должен был пройти.

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

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

25 окт 2020, 15:17

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

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

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

25 окт 2020, 15:59

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 за потраченное на меня время при разбирательстве логов сессий и подробные разъяснения. Тему можно считать закрытой.

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

Update System Crash — Kernel panic — NOT syncing: Attempted to kill init! exit code=0x00007f00

Update System Crash — Kernel panic — NOT syncing: Attempted to kill init! exit code=0x00007f00

Post by JagOverQueen » Wed Dec 28, 2016 10:27 am

After a attempted update of Mint Cinnamon the following «Panic» screen came up and the system is un-bootable.
How can I go about restoring to the previous system?

Ubuntu 17.3
. [47.309620] Kernel panic — NOT syncing: Attempted to kill init! exit code=0x00007f00
[47.309620]
[47.309700] CPU: 0 Pid: 1Comm: sh Tainted: G W 3.16.0-38-generic#52

14.04.1 Ubuntu
[47.309766] Hardware name: Toshiba Satellite c55-B/ZBWAA. Bios 1.70 12/11/2014
[47.309822] ffff 880035ccc380 ffff 880139417c48 ffff ffff8176534f ffff ffff81a76978
[47.309882] ffff 880139417ec0 ffff ffff8175d802 ffff 88010000010 ffff 880139417ed0
[47.309942] ffff 880139417e70 ffff ffff00000000 00000000007f00 ffff 8801394184a8
[47.310002] Call Trace:
[47.310092] [ ] dump_stack +0x45/0x56
[47.310071] [ ] panic +0xc8/0x1fc
[47.310112] [ ] do_exit+0xa57/0xa60
[47.310153] [ ] do_group_exit+0x3f/0xa0
[47.310196] [ ] sys_exit_group+0x14/0x1f
[47.310241] [ ] system_call_fastpath+0x1a/0x1f
[47.310365] Kernel offset: 0x0from 0xffff ffff81000000 (relocation range: 0xffff ffff80000000 — 0xffff ffffbfffffff
[47.310443] drm_kms_helper: panic occured, switching back to text console
[47.310508] —[end Kernel panic — not syncing: Attempt to kill init! exit code=0x00007f00
[47.310508]

Re: Update System Crash

Post by deepakdeshp » Wed Dec 28, 2016 3:46 pm

It is preferableble to make a fresh install from Mint17.3 to 18.
From Grub choose recovery mode and boot into another kernel, if you have more than one kernel installed in your system.

If it doesnt work,

As a test download Mint 18 and use live Mint session to find if Mint 18 works on your machine.

If I have helped you solve a problem, please add [ SOLVED] t o your first post title , it helps other users looking for help, and keeps the forum clean.
Regards,
Deepak

Mint 20.1 Cinnamon 64 bit with AMD A8/7410 / 8GB
Mint 20.1 Cinnamon AMD Ryzen3500U/8gb

Kernel panic — NOT syncing: Attempted to kill init!

Post by JagOverQueen » Sat Jun 24, 2017 8:59 pm

perhaps you could help with a different problem I’m having with a previous/different partition.

. [47.309620] Kernel panic — NOT syncing: Attempted to kill init! exit code=0x00007f00
[47.309620]
[47.309700] CPU: 0 Pid: 1Comm: sh Tainted: G W 3.16.0-38-generic#52

14.04.1 Ubuntu
[47.309766] Hardware name: Toshiba Satellite c55-B/ZBWAA. Bios 1.70 12/11/2014
[47.309822] ffff 880035ccc380 ffff 880139417c48 ffff ffff8176534f ffff ffff81a76978
[47.309882] ffff 880139417ec0 ffff ffff8175d802 ffff 88010000010 ffff 880139417ed0
[47.309942] ffff 880139417e70 ffff ffff00000000 00000000007f00 ffff 8801394184a8
[47.310002] Call Trace:
[47.310092] [ ] dump_stack +0x45/0x56
[47.310071] [ ] panic +0xc8/0x1fc
[47.310112] [ ] do_exit+0xa57/0xa60
[47.310153] [ ] do_group_exit+0x3f/0xa0
[47.310196] [ ] sys_exit_group+0x14/0x1f
[47.310241] [ ] system_call_fastpath+0x1a/0x1f
[47.310365] Kernel offset: 0x0from 0xffff ffff81000000 (relocation range: 0xffff ffff80000000 — 0xffff ffffbfffffff
[47.310443] drm_kms_helper: panic occured, switching back to text console
[47.310508] —[end Kernel panic — not syncing: Attempt to kill init! exit code=0x00007f00
[47.310508]

Re: Kernel panic — NOT syncing: Attempted to kill init!

Post by karlchen » Sun Jun 25, 2017 6:56 am

The problem «Kernel panic — NOT syncing: Attempted to kill init!» has been reported lots of times in this forum, in the Ubuntu forum, on Askubuntu and elsewhere, too.
Implies that you are not alone.
Also implies that searching for «Kernel panic — NOT syncing: Attempted to kill init!» is not totally unlikely to return a few helpful forum threads where the same problem has been reported and (hopefully) solved.
I admit I do not know the steps to solution off-hand.

Re: Kernel panic — NOT syncing: Attempted to kill init!

Post by karlchen » Sun Jun 25, 2017 7:02 am

Just found out that you had already opened a thread reporting the problem end of 2016: System Update Crash
That thread had only 1 reply and no follow up from your side.

Old and new threads will be merged.

Re: Update System Crash — Kernel panic — NOT syncing: Attempted to kill init! exit code=0x00007f00

Post by JagOverQueen » Mon Jun 26, 2017 5:59 am

Hi Guys,
As of date there has not been a resolve to this problem and I continue to search for a solution to resolve this problem.

Re: Update System Crash — Kernel panic — NOT syncing: Attempted to kill init! exit code=0x00007f00

Post by Mute Ant » Mon Jun 26, 2017 3:38 pm

«Attempt to kill init! exit code=0x00007f00» This just says the init process, PID=1 which on Mint is systemd, has hit an impossible-to-proceed error and quit, so the kernel quits too.

For me, there’s just too many binaries and interactions in the kernel+init+udev system to reverse-engineer a kernel panic. init is never supposed to give up, so it must be a really bad system error. That can be hardware, like RAM forgetting what was written, or the CPU losing track of what happens next. It might be software, I have had a kernel refuse to mount an ext4 partition even though the root file system was on ext4.

The path of least effort is to.
o Boot a Live Session of the OS you really want.
o Do the Memtest86+ option at boot to prove the RAM is behaving.
o Reboot into the Live Session and use the Disks accessory to prove the hard-drive is behaving. SMART and Read-Write benchmark are passive. Shred the drive to all-zeros doesn’t hurt, to retire any weak blocks.
o Install the Mint you want.

Источник