Dennis HilkLinux Fix LabDE

Boot, GRUB & systemd-boot

Kernel cannot execute a working init process

No working init found means the kernel could not start userspace; inspect root selection, the init binary and its interpreter from rescue media.

Editorial source review: Start with the evidenceShare this guide
On this page
  1. Symptoms & scope
  2. Possible causes
  3. Diagnose safely
  4. Evidence-guided next steps
  5. References & review
  6. Related problems

Symptoms & scope

  • Boot ends with Kernel panic - not syncing: No working init found.
  • The expected init exists on disk but its interpreter or required libraries may be missing.

Relevant environment

Linux at the kernel-to-userspace handoff, particularly custom images, interrupted package upgrades or incorrect init=/root= arguments.

Recognizable messages (synthetic examples)
Kernel panic - not syncing: No working init found. Try passing init= option to kernel.

Verify root and the init interpreter/dependencies before reinstalling the bootloader; the bootloader already handed control to Linux.

Possible causes

These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.

  • A wrong root or init= argument may select a filesystem without the intended init.
  • Missing dynamic loader/libraries, wrong architecture or a malformed custom /init script can prevent execution; file existence alone is insufficient.

Diagnose safely

Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.

Check 1

Use a correctly identified installed root at /mnt/sysroot; replace the path if its init location differs. This reads file type and symlink metadata.

file /mnt/sysroot/sbin/init

Interpret the result: Check architecture, symlink target and whether a script is intentional. A file command from live root without this path would describe the recovery system instead.

Check 2

Replace with the actual init ELF inside the mounted installation; readelf reads program headers without executing the damaged binary.

readelf -l /mnt/sysroot/usr/lib/systemd/systemd

Interpret the result: Check the requested interpreter path inside the installed root. A present init with a missing interpreter can fail as if the executable itself were absent.

Evidence-guided next steps

Remove an unintended init override

If the failed boot has an unintended init= or wrong root= value, use the boot menu’s temporary editor to restore the verified normal entry for one boot. Persist only the confirmed correction through the distribution’s source configuration.

Precautions: Do not use init=/bin/sh as a routine repair; it bypasses normal startup and may leave filesystems unsafe for edits. Verify the target root first.

Recovery / rollback: Discard the temporary menu edit or restore the saved boot configuration and choose an older working entry.

Did this solution help you?

Share this solution#

Restore init and its matching runtime packages

If the intended root is correct but init or its loader/libraries are missing, restore the distribution’s exact init and core runtime packages from a supported rescue/chroot procedure. For a custom initramfs, rebuild its /init and interpreter inclusion coherently.

Precautions: Do not execute unknown recovered binaries or use ldd on an untrusted image; readelf is safer for inspecting headers. Keep package versions coherent.

Recovery / rollback: Restore the saved package/image snapshot or previously working custom initramfs if reconstruction fails.

Did this solution help you?

Share this solution#

References & review

This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.