🚑 Runbook: Server Won't Boot

Runbook: the server will not boot
journalctl -b -1 -p err; systemctl --failed; systemd-analyze blame

A server that does not come back after a reboot is the worst kind of outage, because the tools you normally use are the thing that is broken. This runbook is built around one idea: find out how far the boot got. Linux boots in stages (firmware, bootloader, kernel, initramfs, systemd), and the last message on the screen tells you which stage failed and therefore which fix to try. Most boot failures are one of five things: a bad entry in /etc/fstab, a broken or missing initramfs, a damaged bootloader, a full or corrupt root filesystem, or a kernel update that did not take.
Part of this page cannot be tried on a running machine, so it is split in two. The diagnostics that work on a booted system (reading the previous boot, finding slow or failed units, checking /etc/fstab before the reboot) are shown with real output from an Ubuntu 24.04 machine. The rescue procedures (GRUB prompt, initramfs shell, emergency mode, chroot from a live USB) are standard, widely used steps, shown without output because they need a broken machine or root on a rescue system. Where a screen is shown as an example it is marked as illustrative. Replace device names such as /dev/sda2 with your own, and read the section for your distribution (Debian and Ubuntu, or Red Hat family) where they differ.

  1. Do not power-cycle in a loop. Each failed boot with a damaged filesystem can add damage. Read the screen first and write down the last 20 lines (a photo of the console is evidence).
  2. Is it really down? Ping, then SSH, then the console (the hypervisor, the cloud serial console, the IPMI/iDRAC/iLO screen, or a monitor). A "dead" server is often up with a broken network.
  3. Did anything change? A kernel update, a disk added or removed, an edit to /etc/fstab, a resize, a power cut. The change is the cause 9 times out of 10.
  4. Take a snapshot of a VM or cloud disk before you start repairing. A repair that goes wrong becomes recoverable.
  5. Have a way in that does not depend on the broken machine: a live USB (same architecture, same distribution family if you can), the cloud provider's rescue mode, or a second machine to attach the disk to.

  1. Firmware (BIOS or UEFI) powers up hardware, finds a boot device. Failure: "No bootable device", "Operating system not found", a boot loop to the firmware setup
  2. Bootloader (GRUB, systemd-boot) shows the menu, loads the kernel and the initramfs. Failure: a "grub>" or "grub rescue>" prompt, "error: file not found", "unknown filesystem"
  3. Kernel starts, finds the hardware, looks for the root filesystem. Failure: "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"
  4. initramfs (a tiny temporary system) loads drivers, unlocks encrypted disks, assembles RAID and LVM, finds the real root. Failure: "(initramfs)" prompt, "ALERT! /dev/disk/by-uuid/... does not exist. Dropping to a shell!", "Gave up waiting for root file system device"
  5. systemd (PID 1) mounts filesystems from /etc/fstab, starts services until the default target is reached. Failure: "You are in emergency mode", "Welcome to emergency mode! ... Give root password for maintenance", a hang at "A start job is running for /dev/disk/by-uuid/... (1min 30s / no limit)"
The stage tells you where to look: the first three are fixed from outside the system (live USB or rescue), the fourth from the initramfs shell or a rescue system, the fifth often from the emergency shell itself.

If the machine boots, even slowly or after a manual fix, the journal remembers the failed boot. This needs a persistent journal (see the journalctl page); on Ubuntu it is persistent by default. List the boots and read the one before this:
$ journalctl --list-boots | wc -l
27
$ journalctl -b -1 -p err --no-pager | tail -20
$ journalctl -b -1 -n 3 --no-pager -o short-iso
2026-10-01T22:54:36-04:00 server1 systemd-shutdown[1]: Syncing filesystems and block devices.
2026-10-01T22:54:36-04:00 server1 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
2026-10-01T22:54:36-04:00 server1 systemd-journald[329]: Journal stopped
Those last three lines are how a CLEAN shutdown ends: systemd syncs the disks, stops the remaining processes and stops the journal. If the previous boot ends in the middle of ordinary messages, with no shutdown lines, the machine lost power or crashed (a kernel panic, a hard reset, a hang). Then the useful questions are what ran just before the end (journalctl -b -1 -n 100), whether the kernel logged errors (journalctl -b -1 -k -p err), and whether a crash dump exists (ls /var/crash /var/lib/systemd/pstore).
Is this boot clean? Three commands:
$ systemctl --failed
  UNIT LOAD ACTIVE SUB DESCRIPTION

0 loaded units listed.
$ systemctl get-default
graphical.target
$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-7.0.0-38-generic root=UUID=<uuid> ro quiet splash vt.handoff=7
--failed lists units that did not start, get-default says what systemd is booting towards (graphical.target on a desktop, multi-user.target on a server), and /proc/cmdline is the exact command line the kernel was given by the bootloader: the root= device, "ro" (mounted read-only at first, fsck, then remounted read-write) and the options. "quiet splash" hides the boot messages: on a server you want to see them, so remove both from GRUB_CMDLINE_LINUX_DEFAULT (see below).

Most boot failures can be caught before the reboot. Do these every time you change a mount, a disk or a kernel, and always on a remote machine you cannot walk up to.
1. /etc/fstab. A wrong line is the number one cause of "emergency mode". The fields are device, mount point, type, options, dump, fsck order:
$ grep -v '^#' /etc/fstab | grep .
/dev/disk/by-uuid/<uuid> / ext4 defaults 0 1
/dev/disk/by-uuid/<uuid> /boot/efi vfat defaults 0 1
/swap.img	none	swap	sw	0	0
Verify it without rebooting. findmnt --verify checks the syntax, that the mount points and sources exist, and the filesystem types (run it as root for the complete check; as an ordinary user, as here, it also prints warnings that it cannot read the devices):
$ findmnt --verify
0 parse errors, 0 errors, 4 warnings
/
   [W] cannot detect on-disk filesystem type (Permission denied)
/boot/efi
   [W] cannot detect on-disk filesystem type (Permission denied)
none
   [W] non-bind mount source /swap.img is a directory or regular file
   [W] cannot detect on-disk filesystem type (Permission denied)
"0 errors" is the line you want. A line such as "[E] unreachable on boot required source: UUID=..." or "[E] source ... does not exist" would have caused the failed boot. Then mount everything for real: sudo mount -a (it mounts every fstab entry that is not mounted yet and shows the same errors the boot would). Use UUIDs or LABELs (blkid, lsblk -f), not /dev/sdb1 names, which change when disks are added. For any mount that is not needed to boot (a data disk, a network share), add the option nofail (and for network filesystems _netdev, and x-systemd.device-timeout=10) so that a missing disk delays the boot by seconds instead of dropping you into emergency mode:
  UUID=...  /data  ext4  defaults,nofail,x-systemd.device-timeout=10  0  2
2. The kernels that are installed. Always keep an older working one to fall back to:
$ uname -r
7.0.0-38-generic
$ ls /boot | grep vmlinuz
vmlinuz
vmlinuz-6.17.0-40-generic
vmlinuz-7.0.0-31-generic
vmlinuz-7.0.0-34-generic
vmlinuz-7.0.0-38-generic
vmlinuz.old
(vmlinuz and vmlinuz.old are symlinks to the newest and the previous kernel.) Every kernel has a matching initrd.img-VERSION in /boot. If the initramfs of the newest kernel is missing or zero bytes, that kernel will not boot: sudo update-initramfs -u -k all (Debian and Ubuntu) or sudo dracut -f --regenerate-all (Red Hat family). The older kernels in the same list are your way out: choose one in the GRUB "Advanced options" menu.
3. The bootloader configuration. After changing /etc/default/grub or after a kernel change, regenerate it and look at the result:
$ grep -E '^(GRUB_TIMEOUT|GRUB_CMDLINE)' /etc/default/grub
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=0
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
With GRUB_TIMEOUT_STYLE=hidden and a timeout of 0 (the Ubuntu desktop default) the GRUB menu never appears: to reach it at boot, hold Shift (BIOS) or press Esc repeatedly (UEFI) right after the firmware logo. On a server, make the menu visible for a few seconds, and show the boot messages:
  GRUB_TIMEOUT_STYLE=menu
  GRUB_TIMEOUT=5
  GRUB_CMDLINE_LINUX_DEFAULT=""
then regenerate: sudo update-grub (Debian and Ubuntu), or sudo grub2-mkconfig -o /boot/grub2/grub.cfg (Red Hat family; on UEFI the file is /boot/efi/EFI/redhat/grub.cfg or the distribution's folder; check with the docs for your release).
4. On a UEFI machine, the firmware's own list of boot entries:
$ efibootmgr
BootCurrent: 0005
Timeout: 1 seconds
BootOrder: 0005,0000,0001,0002,0003
(first lines of the real output; the entries follow). BootCurrent is the entry that started this boot, BootOrder is the order the firmware tries them in. A server that "forgets" its boot entry after a firmware update or disk swap needs the entry recreated: sudo efibootmgr -c -d /dev/sda -p 1 -L "ubuntu" -l '\EFI\ubuntu\shimx64.efi', or grub-install again (see the live USB section).
5. Free space: a full / or /boot makes kernel updates fail halfway and leaves a kernel without an initramfs. df -h / /boot first (see the Disk Full runbook).

Symptoms: "No bootable device", "Reboot and Select proper Boot device", a blinking cursor, an immediate return to the BIOS or UEFI setup, or the machine boots a USB stick, a network PXE option or the wrong operating system.
  Look in the firmware setup (usually F2, Del, F10 or F12 at power-on) at the boot order and the list of detected disks. Is the disk there at all? If not, it is hardware: cable, controller, a dead disk, a RAID controller that lost its array, a cloud volume that was detached.
  Boot mode: a machine installed in UEFI mode will not boot if the firmware was switched to Legacy/CSM (and the other way round). Secure Boot can refuse an unsigned bootloader or kernel: try with it disabled to find out.
  The boot entry was lost (a firmware reset, a battery change): recreate it with efibootmgr or reinstall GRUB from a live system.
  Dual boot: Windows or a firmware update may have moved itself to the top of the boot order: reorder in the firmware, or sudo efibootmgr -o 0001,0000 from a running system.
  A removable disk or USB stick left in the machine took the first place in the boot order: remove it.
  Check the disk's health from a live USB: sudo smartctl -a /dev/sda (look for reallocated or pending sectors and "FAILING_NOW") and dmesg | grep -i -E 'I/O error|ata[0-9]'. A failing disk is cloned, not repaired: sudo ddrescue /dev/sda /dev/sdb rescue.map.

Symptoms: the machine stops at "grub>" or "grub rescue>" (the second is the more limited one), or at errors such as "error: no such partition", "error: file '/boot/grub/i386-pc/normal.mod' not found", "error: unknown filesystem". The bootloader cannot find its files: the partition moved or was resized, a disk was added or removed so the numbering changed, or the filesystem was damaged.
Illustrative session at the prompt (replace the numbers by what ls shows you):
  grub rescue> ls
  (hd0) (hd0,gpt2) (hd0,gpt1)
  grub rescue> ls (hd0,gpt2)/boot/grub
  (a listing of files means this is the right partition)
  grub rescue> set root=(hd0,gpt2)
  grub rescue> set prefix=(hd0,gpt2)/boot/grub
  grub rescue> insmod normal
  grub rescue> normal
At the full "grub>" prompt you can also boot by hand without the menu:
  grub> linux /boot/vmlinuz-6.17.0-40-generic root=/dev/nvme0n1p2 ro
  grub> initrd /boot/initrd.img-6.17.0-40-generic
  grub> boot
(TAB completes file names.) This only gets you running once. Once the system is up, repair GRUB properly:
  Debian/Ubuntu BIOS:  sudo grub-install /dev/sda && sudo update-grub
  Debian/Ubuntu UEFI:  sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu && sudo update-grub
  Red Hat family UEFI: sudo dnf reinstall grub2-efi-x64 shim-x64 && sudo grub2-mkconfig -o /boot/grub2/grub.cfg (older releases: /boot/efi/EFI/redhat/grub.cfg)
If you cannot even boot by hand, do the same from a live USB with the chroot method described below.

Symptoms: "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)", or "No init found. Try passing init= option to kernel", or the machine shows a stack trace and stops.
  Choose an OLDER kernel in the GRUB menu (Advanced options). If it boots, the new kernel or its initramfs is the problem: rebuild with sudo update-initramfs -u -k all and sudo update-grub, or remove the broken kernel (sudo apt remove linux-image-VERSION) and reinstall it.
  If every kernel panics: the root= device on the kernel command line is wrong or no longer there (a disk replaced, UUID changed after a restore or clone; compare /proc/cmdline and blkid), a driver for the disk controller or filesystem is missing from the initramfs (common after a move to a new VM type or a new storage controller), or the filesystem is badly damaged.
  A panic that appears long after boot has started (not at mount) is a hardware or driver fault: capture the text, check memory with memtest86+ (a boot menu entry on many systems), and look at /var/crash or pstore after the next boot.
  To read the whole panic, remove "quiet" from the kernel command line in the GRUB menu (press e on the entry, edit the line that starts with linux, then Ctrl+X to boot once with the change).

Symptoms: the screen ends at "(initramfs)" or says "ALERT! /dev/disk/by-uuid/... does not exist. Dropping to a shell!", "Gave up waiting for root file system device", or "fsck exited with status code 4. The root filesystem on /dev/... requires a manual fsck".
You are in a tiny busybox shell: there are few commands, no network and no editor, but enough to look around.
  (initramfs) cat /proc/cmdline              what root= the kernel was told to use
  (initramfs) ls /dev/disk/by-uuid           the UUIDs that exist: is the one from root= there?
  (initramfs) blkid                          disks and their UUIDs
  (initramfs) lsmod; dmesg | tail -30        what drivers loaded, what the kernel said about disks
  (initramfs) cat /proc/partitions           what partitions the kernel sees
If the root UUID is missing from the list: the disk is not detected (cable, controller, a missing storage driver), or the UUID in the GRUB configuration is outdated. If the disk is there and the filesystem is damaged, run the check by hand:
  (initramfs) fsck -y /dev/nvme0n1p2         repair the root filesystem; answer yes to repairs
  (initramfs) exit                           continue the boot
For LVM or RAID: lvm vgchange -ay and mdadm --assemble --scan inside the shell activate the volumes; then exit. For an encrypted root: cryptsetup open /dev/sda3 cryptroot, then exit. If a repair worked, reinstall the initramfs once the system is up (sudo update-initramfs -u -k all) and find out why it went wrong (the journal of the failed boot, a disk with errors).

Symptoms: "You are in emergency mode. After logging in, type "journalctl -xb" to view system logs, "systemctl reboot" to reboot, "systemctl default" or ^D to try again to boot into default mode.", and a prompt asking for the root password. Or a boot that sits at "A start job is running for dev-disk-by\x2duuid-... (1min 30s / no limit)" and then drops to emergency mode.
The cause is almost always a mount that systemd was told is required and cannot find or check. Log in (the root password, which is locked on many Ubuntu systems; in that case use a live USB or the "recovery mode" entry in the GRUB Advanced options) and ask the system:
  # journalctl -xb | tail -50                the failing unit and the reason
  # systemctl --failed                       which units failed (typically a mount: mnt-data.mount)
  # findmnt --verify                         does /etc/fstab make sense
  # mount -o remount,rw /                    emergency mode mounts / read-only: make it writable to edit
  # nano /etc/fstab                          fix or comment out the bad line, or add nofail
  # mount -a                                 test it
  # systemctl daemon-reload; systemctl default      go on with the normal boot (or reboot)
Typical findings: the UUID of a disk that was removed or a filesystem that was reformatted (fix with blkid, then correct the UUID), a typo in a line, a network share without nofail and _netdev that is not reachable yet, a filesystem needing fsck (run fsck -y /dev/DEVICE on it while unmounted), or a swap file or partition that no longer exists.
"rescue mode" (systemd.unit=rescue.target) is one step further than emergency mode: it mounts all local filesystems and starts a minimal set of services, so use it when emergency mode shows the system is mostly fine. Either one can be chosen once by adding systemd.unit=emergency.target or systemd.unit=rescue.target to the kernel command line in GRUB (press e, edit the linux line, Ctrl+X).

When the installed system cannot start itself, boot a live USB of the same family and work on the disk from outside. This is the method behind most repairs: it fixes GRUB, initramfs, fstab and passwords alike.
Debian/Ubuntu, UEFI, root on /dev/sda2 and the EFI partition on /dev/sda1 (check yours with lsblk -f):
  sudo mount /dev/sda2 /mnt
  sudo mount /dev/sda1 /mnt/boot/efi
  for d in dev dev/pts proc sys run; do sudo mount --bind /$d /mnt/$d; done
  sudo chroot /mnt
  (inside the chroot, you are "in" the installed system)
  grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
  update-grub
  update-initramfs -u -k all
  nano /etc/fstab                      or any other fix
  exit
  for d in run sys proc dev/pts dev; do sudo umount /mnt/$d; done
  sudo umount /mnt/boot/efi /mnt
  sudo reboot
For BIOS (legacy) machines skip the EFI mount and use grub-install /dev/sda. If / is an LVM volume: sudo vgchange -ay first and mount /dev/VG/LV. If it is encrypted: sudo cryptsetup open /dev/sda3 cryptroot first. Red Hat family: the same steps, but the final commands are dracut -f --regenerate-all and grub2-mkconfig -o /boot/grub2/grub.cfg (or the file in /boot/efi/EFI/...), and if SELinux is in use, create the file /.autorelabel before exit so the labels are repaired at the next boot.
Check the filesystem from the live system BEFORE you mount it if you suspect damage: sudo fsck -f /dev/sda2 (the live system does not have it mounted). Make an image first if the data is valuable: sudo dd if=/dev/sda of=/backup/sda.img bs=4M status=progress, or ddrescue for a disk with read errors.

You cannot press F12 on a cloud instance, but there are equivalents:
  Serial console or "get system log" in the provider's console: shows the boot messages, the GRUB prompt and emergency mode. Enable it BEFORE you need it (and add console=ttyS0 to the kernel command line if the image does not have it)
  Snapshot the disk, then attach it as a secondary disk to a healthy VM (a "rescue VM"): mount it under /mnt/rescue, fix /etc/fstab or the initramfs with chroot as above, detach, reattach as the boot disk
  Provider tools: AWS EC2 Serial Console and "EC2Rescue", Azure Serial Console and "az vm repair create", Google Cloud serial port and a rescue VM
  After a resize: the disk is bigger but the filesystem is not. Not a boot failure by itself, but df shows a full disk; use growpart and resize2fs (ext4) or xfs_growfs (XFS)
  A UUID that changed after a restore from a snapshot into a new disk is a common cause of "dependency failed for /data": fix the line or use nofail
  Always keep an independent way in: an SSH key on a second user, a documented console route, and snapshots taken before every kernel or boot change.

Not a failure but a frequent complaint: the machine boots, after minutes. systemd-analyze shows where the time went. Real output from the lab machine (a laptop with VirtualBox kernel modules, which is why one unit dominates):
$ systemd-analyze
Startup finished in 5.458s (firmware) + 3.980s (loader) + 2.667s (kernel) + 42.270s (userspace) = 54.377s
graphical.target reached after 42.239s in userspace.
$ systemd-analyze blame | head -4
27.386s vboxdrv.service
12.225s snapd.apparmor.service
 8.685s plymouth-quit-wait.service
 4.605s NetworkManager-wait-online.service
blame lists units by the time each took to start. It is not the whole story, because many start in parallel and the slow one may not delay anything. The critical chain shows what the final target waited for:
$ systemd-analyze critical-chain | sed -n '4,8p'
graphical.target @42.239s
└─multi-user.target @42.239s
  └─vboxweb-service.service @42.213s +24ms
    └─vboxdrv.service @14.806s +27.386s
      └─basic.target @14.426s
Read "@" as the time when a unit started and "+" as how long it took. Here the boot waited 27 seconds on vboxdrv.service, so that is where to look. Typical culprits: NetworkManager-wait-online.service or systemd-networkd-wait-online.service (waiting for a network that is not there: disable it on servers that do not need to wait, sudo systemctl disable NetworkManager-wait-online.service), an fstab line for a disk or a network share that is not reachable (add nofail and x-systemd.device-timeout=10), fsck of a large disk, cloud-init waiting on a metadata server, DNS timeouts, and services with a long start timeout. For the firmware and loader time (9 seconds here), only the firmware settings and the GRUB timeout matter.
Kernel and userspace time are also available as a graph: systemd-analyze plot > boot.svg and open the file in a browser.

This is a boot-time repair, not a break-in: it needs physical or console access, which is the same trust level as having the password. Protect the console and the bootloader accordingly (disk encryption and a GRUB password).
  1. Reboot, open the GRUB menu (Shift or Esc), highlight the entry, press e.
  2. On the line starting with linux add at the end: init=/bin/bash (or systemd.unit=rescue.target to be asked for the root password anyway). Ctrl+X boots with it.
  3. At the shell, the root filesystem is read-only: mount -o remount,rw /
  4. passwd root (or passwd USERNAME for a user), then sync.
  5. exec /sbin/init or reboot -f. (With init=/bin/bash, systemctl does not work: use reboot -f.)
Red Hat family: add rd.break to the linux line instead, then at the switch_root prompt: mount -o remount,rw /sysroot; chroot /sysroot; passwd; touch /.autorelabel; exit; exit.
If the disk is encrypted, none of this works without the disk password: that is the point.

No bootable device, or a loop into the BIOS            firmware: boot order, disk not detected, UEFI/Legacy mismatch, lost boot entry
grub> or grub rescue> prompt                          GRUB cannot find its files: ls and set root/prefix, then grub-install and update-grub from a running system or a chroot
error: file not found, unknown filesystem             a partition moved, resized or damaged; same repair as above, plus fsck
Kernel panic ... VFS: Unable to mount root fs         wrong root=, missing storage driver in the initramfs, damaged root filesystem: boot an older kernel, rebuild the initramfs
(initramfs) prompt, ALERT: ... does not exist         the root device is missing: blkid, ls /dev/disk/by-uuid, wrong UUID or no driver, or a manual fsck is needed
You are in emergency mode                             a required mount failed: journalctl -xb, findmnt --verify, fix or comment out the /etc/fstab line, add nofail
A start job is running for ... (no limit)            a device in fstab is not there: wait out the timeout, then fix fstab
Boot reaches a login prompt but the network is down   the interface name changed or the netplan/NetworkManager config is wrong: ip -br a, fix the config, then see the Network Troubleshooting page
Black screen after the splash, no login               graphics driver trouble (desktop): boot to multi-user.target (systemd.unit=multi-user.target), or choose the older kernel; on a server remove "quiet splash"
Boots after minutes                                    a slow unit: systemd-analyze blame and critical-chain
Boots fine, then fails after the next kernel update    the new kernel or initramfs is bad: boot the previous kernel, rebuild, keep two kernels
Filesystem mounted read-only after boot                an error was detected and the kernel remounted it read-only: dmesg | grep -i 'remount\|I/O error', then fsck from a rescue system and check the disk with smartctl
Everything looks right but it still fails            the disk may be failing: smartctl -a, dmesg I/O errors; clone with ddrescue before anything else

  Keep at least two kernels (do not run apt autoremove on the only working one), and check /boot has free space.
  After every change to fstab, run findmnt --verify and sudo mount -a before you reboot. Use UUIDs and nofail for non-critical mounts.
  Make the boot visible: GRUB menu for a few seconds, no "quiet splash" on servers, a persistent journal, and a serial or remote console set up and tested.
  Keep a live USB of your distribution, a documented rescue procedure, and a written list of device names, UUIDs and the partition layout (lsblk -f > layout.txt, saved off the machine).
  Back up the boot pieces: /etc/fstab, /etc/default/grub, and the partition table (sfdisk -d /dev/sda > sda.parttable).
  Test updates on a copy first, take a snapshot before kernel and bootloader updates, and reboot after them while you are watching, not on a Friday evening.
  Monitor disk health (smartd, smartctl) and free space on / and /boot, and alert on failed units (systemctl --failed) after each boot.
  Add a boot-time check to your monitoring: if a server is not back on the network within a few minutes after a planned reboot, someone looks at the console at once.

Find the stage first: the last message on the screen is the map. Firmware, GRUB, kernel, initramfs and systemd each have different fixes.
Read the previous boot (journalctl -b -1) if the machine comes up at all: a clean shutdown ends with "Journal stopped", a crash just stops.
Most failures are an /etc/fstab line: run findmnt --verify and mount -a before every reboot, and use nofail for anything not needed to boot.
Keep an older kernel, and know how to reach the GRUB menu on your machine (Shift or Esc, hidden by default on Ubuntu desktops).
Snapshot, or image the disk, before you repair: a rescue that goes wrong should still be recoverable.
Do not guess commands at a rescue prompt on a machine you cannot restore. Read, think, then type; and write down what you changed.