Ubuntu 26.04 Tutorial / Recover from Ubuntu Boot, Kernel, and Network Failures

Start Ubuntu recovery at the console: identify how far boot progresses, preserve logs and recent changes, and narrow the failure. An unreachable SSH service does not prove that the OS failed to boot. Investigate boot, kernel, networking, and application layers separately and reverse one relevant change at a time. For the related conditions and procedure, see Investigate Linux Failures with Logs. For the related conditions and procedure, see Reproduce Failures and Practice Evidence-Based Recovery.

Identify the failure stage and the safe scope

Preserve the state when possible and secure existing backups and unlock material. Do not deliberately damage production disks or networking for an exercise. Record time, exact errors, the last successful operation, and recent changes without including credentials or private keys.

Collect read-only evidence when login works

cat /etc/os-release
uname -r
systemctl --failed
df -h
lsblk -f
findmnt /
sudo journalctl --list-boots
sudo journalctl -b -p err --no-pager

If previous-boot records exist, compare them with sudo journalctl -b -1 -p err --no-pager. Missing historical logs do not prove an error-free boot. For a full disk, identify the cause and preserve relevant records before removing anything. Inspect surrounding times and individual units when error-only output lacks context.

Practice a bounded service failure and restoration on a clone

Run from the console of a lab clone isolated from its original. This new unit is not enabled at boot and does not delete data or change networking. Establish a successful baseline, introduce a false-command drop-in, then restore by removing only that file. This exercises service diagnosis, not an actual kernel or boot failure.

(
set -eu
unit=ubuntu-recovery-lab.service
file=/etc/systemd/system/$unit
drop=/etc/systemd/system/$unit.d
if sudo test -e "$file" || sudo test -L "$file" || sudo test -e "$drop"; then
    printf 'Lab unit already exists; choose a new name.\n' >&2
    exit 1
fi
sudo sh -c 'set -C; cat > "$1"' sh "$file" <<'EOF'
[Unit]
Description=Bounded Ubuntu recovery exercise
[Service]
Type=oneshot
ExecStart=/usr/bin/true
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
sudo systemctl start "$unit"
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo install -d -m 0755 "$drop"
sudo sh -c 'set -C; cat > "$1/10-failure.conf"' sh "$drop" <<'EOF'
[Service]
ExecStart=
ExecStart=/usr/bin/false
EOF
sudo systemd-analyze verify "$file"
sudo systemctl daemon-reload
if sudo systemctl start "$unit"; then
    printf 'Unexpected success: inspect the loaded unit.\n' >&2
    exit 1
fi
sudo systemctl show "$unit" -p Result -p ExecMainStatus
sudo journalctl -u "$unit" --since '5 minutes ago' --no-pager
)

Expect Result=success and ExecMainStatus=0 at baseline, then Result=exit-code and ExecMainStatus=1 after the deliberate failure. Distinguish successful inactive oneshot state from failure and compare timestamps/commands in the journal. Restore below only if this is the file just created and it has no intervening edits.

(
set -eu
sudo rm -- /etc/systemd/system/ubuntu-recovery-lab.service.d/10-failure.conf
sudo systemctl daemon-reload
sudo systemctl reset-failed ubuntu-recovery-lab.service
sudo systemctl start ubuntu-recovery-lab.service
sudo systemctl show ubuntu-recovery-lab.service -p Result -p ExecMainStatus
)

Confirm success/0 again. For complete cleanup, verify ownership and inactivity, remove only this lab unit and its empty drop-in directory, then reload systemd. Record this separately from the actual prior-kernel/recovery-mode decisions below.

Use a previous kernel after an update-related boot failure

If boot fails immediately after an update and GRUB plus an older kernel are available, select a previous kernel under Advanced options for Ubuntu from the console. Accessing GRUB varies with firmware, host, and timing; check the machine or VM’s console procedure. Encrypted disks still require unlocking.

If the previous kernel boots, record uname -r and compare update history, kernel logs, and relevant driver/DKMS state. That result alone does not establish the new kernel as the sole cause. Preserve the running kernel and a working fallback, repair the identified issue, and then verify normal boot.

Ubuntu Wiki’s Recovery mode guide describes GRUB recovery options and their prerequisites.

Identify the initial RAM disk infrastructure

Ubuntu 26.04 switches the default initial RAM disk infrastructure to Dracut, while existing initramfs-tools configurations may remain. During boot recovery, do not immediately run regeneration commands copied from another LTS guide: inspect the installed tools and boot artifacts first.

dpkg-query -W dracut dracut-core initramfs-tools 2>/dev/null
command -v dracut update-initramfs
ls -lh /boot

An installed tool does not by itself prove how the current boot image was built. Check the configuration and official recovery procedure for the selected kernel, encryption, LVM, or RAID, retaining a working kernel, console access, and backups before regeneration.

Ubuntu 26.04 Dracut transition

Inspect recovery mode before allowing writes

A recovery-menu root shell has powerful privileges and differs from an ordinary login. Inspect disk detection, free space, mounts, and the specific file to repair first. Consider the following only in the recovery shell when the root filesystem is read-only and a configuration repair actually requires writing.

findmnt /
mount -o remount,rw /

These commands omit sudo because the recovery shell runs as root. With corruption or I/O errors, stop repeated write attempts and prioritize data preservation and an appropriate rescue procedure. Do not run repair-mode fsck on a mounted filesystem or initialize an unidentified disk.

Recover after a network configuration change

ip -br address
ip route
resolvectl status
sudo netplan get
systemctl is-active NetworkManager systemd-networkd
sudo ss -lntp

From the console, identify the actual interface, managing renderer, and effective Netplan configuration. Compare the file changed most recently with its backup rather than adding another YAML file to override it. Check whether cloud-init or another tool generates the configuration.

When restoring the correct backup, preserve the current configuration too. After netplan generate succeeds, use sudo netplan try --timeout 120 with console access retained. Automatic rollback can fail; verify the resulting addresses, routes, DNS, and a new SSH connection. If networking works, investigate SSH keys, listeners, and UFW separately.

Consult the 26.04 netplan try manual for rollback limitations and verification requirements.

Preserve data and verify recovery

If the installed OS is unusable, consider a verified live/rescue environment. Identify encryption, LVM, and RAID before accessing disks, and avoid selecting the source as an installation destination. Do not guess generic GRUB-reinstallation or partition-recreation commands; use a procedure matching the actual layout and tested backups.

After recovery, verify reboot, a new SSH connection, services, application reads/writes, logs, and backups. Record what was reversed, what improved, unresolved questions, and evidence to collect if it recurs. Recovery is complete when normal operation is sustainable, not merely when a response first returns.