When a Linux server does not come back after a reboot, the fastest way to fix it is to know which stage of the boot failed. The firmware, the GRUB bootloader, the kernel with its initramfs and finally systemd each have their own failure modes and their own tools. In this tutorial you will walk through every stage on Ubuntu 24.04, learn how to measure and inspect a boot, and recover from the most common failures: a broken /etc/fstab, a bad kernel or initramfs, a service that blocks the boot and a lost password.

Prerequisites

To follow this tutorial you need:

  • A server running Ubuntu 24.04 LTS, for example a CubePath VPS.
  • A non-root user with sudo privileges.
  • Access to the server console, not just SSH. When a boot fails, SSH is not available; on a CubePath VPS use the VNC console in the control panel.
  • For the chroot recovery in Step 6, a way to boot a rescue environment or an Ubuntu live ISO.

Step 1 - Understanding the boot stages

A modern Ubuntu server boots in this order:

  1. Firmware (BIOS or UEFI) initialises the hardware and loads the bootloader, from the first sectors of the disk (BIOS) or from the EFI System Partition mounted at /boot/efi (UEFI).
  2. GRUB reads /boot/grub/grub.cfg, shows the menu and loads the kernel (/boot/vmlinuz-*) and the initramfs (/boot/initrd.img-*) into memory, passing the kernel command line.
  3. The kernel initialises the CPU, memory and built-in drivers, then unpacks the initramfs as a temporary root filesystem.
  4. The initramfs loads the storage drivers needed to find the real root filesystem, mounts it and hands over control.
  5. systemd (PID 1) mounts the remaining filesystems from /etc/fstab, starts services and reaches the default target, usually multi-user.target on a server.

Knowing the last message you saw tells you where to look: a grub rescue> prompt is a bootloader problem, a kernel panic about the root device is a kernel or initramfs problem, and a prompt that says You are in emergency mode is a systemd problem, most often a filesystem in /etc/fstab.

Check whether your server booted with UEFI or legacy BIOS, because recovery commands differ:

[ -d /sys/firmware/efi ] && echo "UEFI" || echo "BIOS"

BIOS

Many virtual machines still boot with legacy BIOS; physical servers usually use UEFI.

Step 2 - Measuring the boot with systemd-analyze

systemd-analyze reports how long each stage of the last boot took:

systemd-analyze time

Startup finished in 2.114s (kernel) + 9.873s (userspace) = 11.988s
graphical.target reached after 9.841s in userspace.

To see which units took longest to start, use blame:

systemd-analyze blame | head -n 5

5.912s systemd-networkd-wait-online.service
1.204s cloud-init.service
 812ms snapd.seeded.service
 544ms apt-daily-upgrade.service
 301ms systemd-journal-flush.service

blame shows start time per unit, but units start in parallel, so a slow unit does not always delay the boot. To see the chain of units that actually determined when the default target was reached, use critical-chain:

systemd-analyze critical-chain

In its output, the time after @ is when a unit became active and the time after + is how long that unit took to start. Units near the top of the chain with a large + value are the ones worth optimising.

Finally, confirm which target the server boots into by default:

systemctl get-default

graphical.target

On Ubuntu cloud images graphical.target simply pulls in multi-user.target, so this is normal even without a desktop.

Step 3 - Reading the logs of a failed boot

Ubuntu 24.04 stores the journal persistently in /var/log/journal, so after you recover a server you can read the logs of the boot that failed. List the recorded boots first:

journalctl --list-boots

IDX BOOT ID                          FIRST ENTRY                 LAST ENTRY
 -2 5b1d3f6a2c9e4e0f8a7b6c5d4e3f2a1b Mon 2026-09-21 08:12:03 UTC Tue 2026-09-22 10:44:17 UTC
 -1 8c2e4a6b0d1f4c3e9a8b7c6d5e4f3a2b Tue 2026-09-22 10:44:40 UTC Tue 2026-09-22 10:47:02 UTC
  0 d3f5b7a9c1e24f6a8b0c2d4e6f8a0b1c Tue 2026-09-22 10:52:18 UTC Thu 2026-09-25 09:30:11 UTC

Index 0 is the current boot and -1 the previous one. Show only messages of priority err or worse from the previous boot:

journalctl -b -1 -p err

To see only kernel messages (the same content dmesg showed at the time), add -k:

journalctl -b -1 -k -p warning

List the units that failed in the current boot:

systemctl --failed

  UNIT              LOAD   ACTIVE SUB    DESCRIPTION
● mnt-data.mount    loaded failed failed /mnt/data

1 loaded units listed.

Then read the log of that specific unit:

journalctl -b -u mnt-data.mount

These four commands answer most "why did it not boot" questions without guessing.

Step 4 - Managing kernels and the initramfs

Every installed kernel has a matching initramfs in /boot:

ls -1 /boot/vmlinuz-* /boot/initrd.img-*

/boot/initrd.img-6.8.0-79-generic
/boot/initrd.img-6.8.0-83-generic
/boot/vmlinuz-6.8.0-79-generic
/boot/vmlinuz-6.8.0-83-generic

Compare them with the running kernel:

uname -r

6.8.0-83-generic

Ubuntu keeps the previous kernel on purpose. If a new kernel fails, choose Advanced options for Ubuntu in the GRUB menu and boot the older one, as shown in Step 5.

The initramfs is rebuilt automatically when a kernel or a relevant package is installed. Rebuild it by hand after changing files it contains, such as /etc/modprobe.d/*.conf, /etc/initramfs-tools/modules or /etc/crypttab:

sudo update-initramfs -u -k all

update-initramfs: Generating /boot/initrd.img-6.8.0-83-generic
update-initramfs: Generating /boot/initrd.img-6.8.0-79-generic

To inspect what an initramfs contains, list its files with lsinitramfs:

lsinitramfs /boot/initrd.img-$(uname -r) | grep -E 'virtio|nvme' | head -n 5

usr/lib/modules/6.8.0-83-generic/kernel/drivers/block/virtio_blk.ko.zst
usr/lib/modules/6.8.0-83-generic/kernel/drivers/nvme/host/nvme-core.ko.zst
usr/lib/modules/6.8.0-83-generic/kernel/drivers/nvme/host/nvme.ko.zst
usr/lib/modules/6.8.0-83-generic/kernel/drivers/scsi/virtio_scsi.ko.zst

If the driver for your root disk is missing from the initramfs, the kernel cannot mount the root filesystem and stops with a panic or drops into the initramfs shell.

Step 5 - Booting into rescue or emergency mode

When a server does not reach its normal target, you can ask systemd for a smaller one by editing the kernel command line in GRUB. The change applies only to that boot.

On Ubuntu cloud images the GRUB menu is hidden by default. To show it, open the console, reboot, and hold Shift (BIOS) or press Esc repeatedly (UEFI) while the server starts. Then:

  1. Highlight the entry you want to boot and press e.
  2. Find the line that starts with linux and move to its end.
  3. Append one of the parameters from the table below.
  4. Press Ctrl+X or F10 to boot.
ParameterWhat you get
systemd.unit=rescue.targetSingle-user root shell, local filesystems mounted, no network services
systemd.unit=emergency.targetRoot shell with only / mounted read-only, nothing else started
break=mountShell inside the initramfs, before the root filesystem is mounted (Ubuntu initramfs-tools)
init=/bin/bashBash as PID 1, no systemd at all; use only when the others fail

Both rescue and emergency mode ask for the root password before opening a shell. On Ubuntu the root account is locked by default, and in that case you only see Cannot open access to console, the root account is locked and no shell. You have two options: set a root password in advance on servers where you want this safety net (sudo passwd root), or use init=/bin/bash, which does not ask for any password.

Once you are in the shell, check what failed and fix it. When you are done, continue the boot to the default target:

systemctl default

Or reboot:

systemctl reboot

Step 6 - Recovering from common boot failures

A broken /etc/fstab

A typo in /etc/fstab, or a disk that has been removed, is the most common reason a server stops in emergency mode. Get a root shell (the emergency prompt if root has a password, otherwise init=/bin/bash), remount the root filesystem read-write and open the file:

mount -o remount,rw /
nano /etc/fstab

Comment out or correct the failing line. For data disks that the system can boot without, add the nofail option so a missing disk no longer blocks the boot:

UUID=3f1c2a7e-5b8d-4e2f-9a6c-1d0e7b4f8a21  /mnt/data  ext4  defaults,nofail  0  2

Get the correct UUIDs with blkid. Before rebooting, let findmnt check the syntax and that every source device exists:

findmnt --verify

Success, no errors or warnings detected

Then reboot with systemctl reboot. If you are in an init=/bin/bash shell, run sync and then exec /sbin/init instead, because there is no systemd to reboot through.

A new kernel that does not boot

Boot the previous kernel from Advanced options for Ubuntu in the GRUB menu. Once the server is up, read the failed boot's kernel log with journalctl -b -1 -k. A common cause is an out-of-tree module (for example a DKMS driver) that did not build for the new kernel; dkms status shows which ones are missing. After fixing the cause, reinstall the kernel packages or rebuild the initramfs with sudo update-initramfs -u -k all and reboot into the new kernel.

A boot that waits a long time for the network

A message such as A start job is running for Wait for Network to be Configured means systemd-networkd-wait-online.service is waiting for an interface that never comes up, usually a secondary interface without a cable or DHCP server. Do not disable the service, since services that need the network rely on it. Instead, mark the interface as optional in its netplan file under /etc/netplan/:

network:
  version: 2
  ethernets:
    ens4:
      dhcp4: true
      optional: true

Apply the configuration:

sudo netplan apply

The next boot no longer waits for ens4.

A lost sudo password

If you cannot log in because nobody remembers the password of the sudo user, boot with init=/bin/bash as described in Step 5. You land in a root shell with the root filesystem mounted read-only. Remount it read-write and set a new password for your user (replace your_user):

mount -o remount,rw /
passwd your_user

Flush the changes to disk and continue booting with systemd:

sync
exec /sbin/init

A system that cannot boot at all

When GRUB itself is broken or the root filesystem needs repairs, boot a rescue environment or Ubuntu live ISO and work from there. Unmounted filesystems can be checked safely; replace /dev/vda1 with your root partition from lsblk:

sudo fsck -f /dev/vda1

To run commands inside the installed system (for example to reinstall GRUB or rebuild the initramfs), mount it and chroot into it. If /mnt/etc/fstab lists a separate /boot or /boot/efi partition, mount those under /mnt as well before entering the chroot:

sudo mount /dev/vda1 /mnt
for d in dev proc sys run; do sudo mount --rbind "/$d" "/mnt/$d"; done
sudo chroot /mnt

Inside the chroot, commands such as update-initramfs -u -k all and update-grub act on the installed system. Type exit and run sudo umount -R /mnt before rebooting. The GRUB-specific repair steps are covered in the guide on GRUB bootloader configuration and recovery.

Conclusion

You now know the five boot stages on Ubuntu 24.04, how to measure a boot with systemd-analyze, how to read the logs of a failed boot with journalctl -b -1, and how to use rescue mode, emergency mode and a chroot to recover. When a server fails to boot, start from the last message on the console and work back one stage at a time. As next steps, add nofail to non-essential mounts, take snapshots before kernel upgrades and learn to repair the bootloader itself with GRUB's rescue tools.