iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The safest fix is to boot the VPS with its previous kernel, then repair the failed kernel’s initramfs, GRUB entry, packages, and filesystem. If no kernel reaches userspace, take a snapshot, attach the boot disk to a rescue VM, chroot into it, rebuild the boot files, check the filesystem offline, and reattach the disk. The panic means PID 1 (init or systemd) exited or could not be started; it identifies a failed userspace handoff, not one specific defect.
What “Attempted to kill init” means
A Linux boot has a critical transition from the kernel to userspace. The kernel starts the first userspace process, PID 1, normally /sbin/init (often linked to systemd). Microsoft’s kernel-panic guidance describes it plainly: “The init process is the first process to be started and should never exit.” If PID 1 cannot be executed, loses a required library, exits because of a crash, or cannot mount the root filesystem needed to start it, the kernel has no normal userspace to continue with and reports:
Kernel panic - not syncing: Attempted to kill init!The wording is therefore a symptom. It does not, by itself, tell you whether the initramfs is missing, GRUB selected the wrong root device, a package removed a loader, or the filesystem is damaged. The lines immediately before the panic and the kernel/initramfs pair selected by GRUB are more useful than the final panic line.
Likely causes on a VPS
Missing or unusable initramfs
An initramfs (also called an initrd) is the temporary filesystem loaded with the kernel. It contains the early userspace programs and drivers needed to discover storage, assemble RAID or LVM when applicable, unlock encrypted volumes, and mount the real root filesystem. A kernel package change can leave the image absent, empty, generated for a different kernel, or incomplete. Microsoft identifies an initramfs that was never generated as a direct cause of this boot failure.
#1 Best Overall
Check that the selected kernel and its initramfs are a matching pair. A kernel named, for example, vmlinuz-6.x.y should have the corresponding initrd.img-6.x.y or initramfs-6.x.y.img in /boot. A file existing is not proof that it contains the required storage driver, root-volume metadata, or correct configuration.
GRUB selected the wrong boot artifacts
GRUB can fail before Linux has a chance to repair itself. Common mistakes include a menu entry without an initrd line, a stale root=UUID=..., a root device name that changed after storage was reattached, or a manually edited entry pointing at an old kernel. If the kernel starts but cannot find the root filesystem, early userspace may eventually terminate PID 1 and produce the same panic.
Free tools Windows power users keep installed
One-click scans. No signup required.
Missing executable, loader, or init-system libraries
PID 1 must be executable and dynamically linkable. Deleting a core directory, interrupting a package transaction, or removing the systemd package can leave /sbin/init, its dynamic loader, or a required shared library missing. Red Hat troubleshooting examples include a missing dynamic loader and missing init-system libraries. The panic text alone cannot distinguish that situation from a broken initramfs.
Filesystem damage, a full disk, or storage I/O errors
An unclean shutdown, exhausted disk, or failing virtual-storage operation can corrupt metadata or prevent package and boot-image writes. Google Cloud’s boot-disk guidance specifically associates boot failures with unclean shutdowns, full disks, and I/O errors. A filesystem that cannot be mounted consistently may make a healthy kernel look like an init failure.
A genuine init or systemd crash
Sometimes the root filesystem mounts and PID 1 starts, then crashes. In that case, inspect the trace and messages immediately before the panic, plus the installed systemd and kernel versions. A library ABI mismatch, damaged configuration, or a package upgrade can terminate PID 1 after userspace has begun. Do not replace packages blindly until you know whether the failure occurs before or after the root mount.
Before changing the disk: preserve evidence
- Capture the console output. Save the serial-console transcript or provider boot diagnostics, including the kernel version, the selected GRUB entry, root-device errors, filesystem messages, and the final panic.
- Stop repeated automatic boots. Repeated forced restarts can make filesystem damage worse and erase useful context from a short console buffer.
- Record the intended boot layout. Note whether the VPS uses a separate
/boot, LVM, software RAID, encryption, UEFI, or legacy BIOS. Record the distribution and release and the kernel shown in the error. - Create a provider snapshot or backup. Google’s repair procedure recommends taking a snapshot before offline repair. Make the snapshot before mounting the disk read-write elsewhere or running a filesystem repair.
Keep the original snapshot until the repaired VPS completes a normal reboot and passes application checks. A disposable copy of the OS disk is preferable when the provider supports it.
Recommended Free Tools
Rank #2
Choose the recovery path
| Recovery path | When it fits | Advantages | What you need |
|---|---|---|---|
| Serial console and previous kernel | An older kernel remains in the GRUB menu and the provider exposes an interactive console | Fastest path; no disk detachment or chroot | Console access and a bootable older entry |
| Rescue VM and offline repair | No kernel reaches userspace or GRUB cannot load a working pair | Works without a functioning guest; allows package, boot-image, and filesystem repair from another system | Snapshot, a rescue VM, and provider support for attaching the OS disk |
Cloud interfaces differ, but documented procedures from Azure, Google Cloud, and AWS use the same pattern: stop or detach the affected instance as required, attach its OS disk to another Linux VM, mount it, bind the virtual filesystems, and chroot. Follow your provider’s exact detach and reattach sequence; never attach one filesystem read-write to two running systems at once.
Path 1: boot an older kernel and repair from the VPS
1. Interrupt GRUB and select the previous kernel
Open the provider’s serial console or equivalent boot console and reboot. During the brief firmware/GRUB window, press the key shown by GRUB (commonly Esc or Shift) to display the menu. Choose Advanced options, then an older kernel and its normal (non-recovery) entry. If it boots, do not immediately remove the failed kernel.
Microsoft describes this as the fastest online route when console access is available. If every entry panics or the menu is inaccessible, use the rescue-VM path instead.
2. Confirm the running kernel and inspect boot files
uname -r
ls -lh /boot
findmnt /boot
findmnt /Verify that /boot is mounted from the expected filesystem and has enough free space. Look for a kernel and a matching initramfs for the version that failed. If /boot is separate, a successful boot with it accidentally left unmounted can cause repairs to be written into the root filesystem rather than the real boot partition.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
3. Review the previous boot and package history
journalctl -b -1 -k
journalctl -b -1 -p err..alertOn a system that has only one recorded boot, use the current journal and the saved console output. Look for messages about “unable to mount root,” missing UUIDs, failed device discovery, “No such file,” dynamic-loader errors, or an init/systemd crash. Check the distribution package-manager history around the kernel update so you know which package transaction to reverse or repeat.
4. Repair Debian- and Ubuntu-family systems
Use the package tools from the installed release; do not copy a command intended for another distribution. First refresh package metadata and reinstall the affected kernel package if the transaction was interrupted. The exact package name is release-dependent, so use the package-manager history and installed package list to identify it. Then rebuild all installed initramfs images and regenerate GRUB:
Rank #3
sudo apt-get update
sudo apt-get install --reinstall linux-image-$(uname -r)
sudo update-initramfs -c -k all
sudo update-grubIf an image for a version already exists, the distribution may require an update operation rather than a create operation; use the release’s documented update-initramfs mode and watch for errors. If the kernel package itself is not installed, reinstall the complete image and modules package for that version instead of generating an initramfs around missing modules.
5. Repair Fedora- and RHEL-family systems
On systems using dracut, rebuild the image for the installed kernel and regenerate the GRUB configuration with the tooling and output path used by that release:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →sudo dnf reinstall kernel-core kernel-modules
sudo dracut --force --regenerate-all
sudo grub2-mkconfig -o /boot/grub2/grub.cfgSome UEFI layouts store the active configuration under the EFI system partition rather than the legacy BIOS path. Confirm the existing GRUB layout before writing a configuration file. If /sbin/init, the dynamic loader, or a systemd library is missing, reinstall the corresponding core packages before rebuilding the initramfs.
6. Verify before rebooting
- List
/bootand confirm the newly generated initramfs has a recent timestamp and corresponds to the intended kernel. - Inspect the generated GRUB menu and confirm it contains both the kernel and its initramfs.
- Check the root UUID in
/etc/fstaband the GRUB entry againstblkidoutput. - Ensure
/bootand the root filesystem are not full. - Review the rebuild output for missing firmware, storage drivers, or “cannot find” errors; do not reboot past an unexplained error.
Reboot once, with the console open. If the repaired entry fails, select the older known-good entry again and continue with offline repair rather than repeatedly forcing the new one.
Path 2: repair the disk from a rescue VM
1. Stop the VPS and attach a copy of its OS disk
Use the provider’s documented stop/detach operation, then attach the snapshot or a copy of the affected OS disk to a separate Linux rescue VM. AWS documents attaching the root volume to another running Linux instance; Azure documents the repair-VM approach. The device name in the rescue VM may differ from its original name, so identify it by size, partition table, and filesystem signatures rather than assuming /dev/sda.
2. Identify partitions, LVM, and filesystems
lsblk -f
sudo blkid
sudo pvs
sudo vgs
sudo lvsActivate LVM volumes if present using the rescue distribution’s normal LVM activation command. Identify the root filesystem, any separate /boot, and the EFI system partition. Do not run a filesystem checker while the target filesystem is mounted.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors3. Mount the target and bind the virtual filesystems
Mount the target root at a temporary directory, then mount its separate boot and EFI partitions at the paths expected by the installed system. Replace the example device names with the devices you identified:
sudo mount /dev/ROOT_PARTITION /mnt/target
sudo mount /dev/BOOT_PARTITION /mnt/target/boot
sudo mount /dev/EFI_PARTITION /mnt/target/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount --bind "$i" "/mnt/target$i"; doneIf the rescue VM uses different architecture or boot mode, avoid copying its configuration into the target. The bind mounts provide the target’s chroot with device nodes, process information, kernel interfaces, and runtime state needed by package and initramfs tools.
4. Enter the installed system safely
sudo chroot /mnt/target /bin/bash
export HOME=/root
export LC_ALL=C
mountpoint /proc
mountpoint /sys
mountpoint /runCheck that /etc/resolv.conf permits package downloads if you must reinstall packages. If networking from the chroot is unavailable, use locally cached packages or the provider’s documented method; do not replace the target’s resolver configuration permanently just to complete a repair.
5. Reinstall core packages and rebuild boot files
Inside the chroot, use the Debian/Ubuntu or Fedora/RHEL-family procedure above, but target the installed release rather than the rescue VM’s release. Reinstall the kernel package, init system, and loader packages when logs show they are missing or corrupted. Then rebuild every required initramfs and regenerate the target’s GRUB configuration. Check /boot from inside the chroot after each command.
A chroot does not make the rescue VM’s running kernel become the target’s kernel. It only changes which disk is treated as /; all package versions, boot mode, and mount points must match the installed VPS.
6. Exit, unmount, and detach cleanly
exit
for i in /run /sys /proc /dev/pts /dev; do sudo umount -R /mnt/target$i 2>/dev/null || sudo umount /mnt/target$i; done
sudo umount /mnt/target/boot/efi 2>/dev/null || true
sudo umount /mnt/target/boot 2>/dev/null || true
sudo umount /mnt/targetUse recursive unmount only when you understand which nested mounts it will remove. Confirm that no process still has the target mounted, then detach the disk cleanly from the rescue VM before reattaching it as the VPS boot disk.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Check and repair the filesystem offline
Filesystem repair is a separate step from rebuilding initramfs. Unmount the target filesystem from the rescue VM first. Run the checker appropriate to that filesystem and follow its prompts only after confirming the device is the target partition, not the rescue VM’s root disk.
- ext-family filesystems: use the corresponding
fsck/e2fscktool while unmounted. - XFS: use the XFS-specific checker and repair tools; do not substitute ext-family commands.
Investigate a full disk and inspect provider storage or I/O diagnostics when the checker reports read errors. If the filesystem cannot be made consistent, restore the snapshot to a new disk instead of repeatedly forcing boots or running destructive repairs against the only copy.
Reattach and validate the repaired VPS
- Detach the repaired disk cleanly from the rescue VM and reattach it as the VPS’s boot disk using the provider’s documented sequence.
- Open the serial console before starting the VPS and watch one complete boot.
- Confirm that GRUB selects the intended kernel and matching initramfs, the expected root UUID is found, and the root filesystem mounts.
- After SSH becomes available, check
uname -r,findmnt /,df -h, and the current boot journal. - Test application health, scheduled jobs, network routes, and any mounted data volumes.
- Keep the snapshot until the VPS has completed a normal reboot and the services have recovered.
Common failure branches
The older kernel is absent
Do not delete or overwrite the only remaining kernel. Use the rescue VM to reinstall a complete kernel package, generate its initramfs, and create a valid GRUB entry. Preserve the snapshot until that entry boots.
GRUB appears, but every entry says the root device is missing
Compare the UUID in the GRUB command line and /etc/fstab with blkid from the rescue VM. A provider reattachment can change device names but should not require guessing a new UUID. Correct the configuration only after confirming which partition is the actual root.
The initramfs rebuild reports a full /boot
Do not remove kernels at random. Boot the known-good kernel, inventory installed versions, retain at least one working fallback, and remove only obsolete packages using the distribution’s package manager. Then regenerate GRUB so it no longer lists deleted images.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →The chroot cannot install packages
Check DNS, the bind mounts, the target release’s package sources, and available disk space. If the VPS must remain isolated, copy verified packages into the rescue environment or use the provider’s offline repair method. Never run the rescue VM’s package manager against the mounted target without chrooting into the target.
Filesystem repair finds recurring errors
Recurring corruption after a clean repair points to an underlying storage or shutdown problem. Review provider I/O metrics and host events, replace the disk from a known-good snapshot when appropriate, and investigate why the VPS is losing power or exhausting storage.
Preventing a repeat panic
- Keep at least one older, known-good kernel until the replacement has booted successfully and survived a normal reboot.
- Monitor free space on
/and/boot; failed kernel transactions are more likely when either is full. - Take a snapshot before major kernel, bootloader, storage, or filesystem changes.
- Enable and test serial-console or equivalent out-of-band access before an outage.
- Record the provider’s disk-attachment and rescue-VM procedure while the VPS is healthy.
- Review package-manager and boot journals after kernel updates instead of assuming a successful package transaction means the initramfs and GRUB entry are usable.
When to stop repairing and restore
Restore the snapshot or rebuild the VPS when the filesystem checker cannot produce a consistent filesystem, storage errors continue, the only copies of core packages are corrupted, or you cannot verify which disk is the original. A controlled restore is safer than repeated write attempts against damaged media. Preserve the failed disk or a forensic snapshot if you need to investigate the original cause.
Quick Recap
Decision checklist
- Older kernel boots: inspect logs, reinstall the affected kernel, rebuild initramfs, regenerate GRUB, verify files, then reboot.
- No kernel boots: snapshot first, attach the disk to a rescue VM, mount and chroot, repair packages and boot files, check the filesystem offline, and reattach.
- Root UUID or init files are missing: correct the identified configuration or reinstall the specific core packages; do not infer the cause from the panic line alone.
- Storage remains inconsistent: stop destructive retries and restore from a known-good snapshot.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
