Patch and reboot the base

Patch the base before adding data and services. A fresh install ships with weeks or months of pending fixes, and this is the cheapest moment to apply them: nothing depends on the machine yet.

The reboot that follows matters just as much. It proves the host can go down and come back without you standing at a keyboard.

Apply updates

sudo apt update
sudo apt upgrade

apt update refreshes the package lists. apt upgrade installs the new versions and shows you the list before touching anything. Read it once; on a fresh server it’s mostly base system packages.

Ubuntu Server also runs unattended-upgrades by default, which installs security fixes automatically in the background. That’s a good default. It covers security patches between your manual sessions, but it doesn’t replace them.

Check whether a reboot is needed

Some updates, like a new kernel, only take effect after a reboot. Ubuntu tells you explicitly:

test -f /var/run/reboot-required && cat /var/run/reboot-required

If the file exists you’ll see *** System restart required ***. No output means no reboot needed, but during this lab, reboot anyway. You want to rehearse it now, not during a real outage.

Reboot and verify the return

sudo reboot

Wait a minute, reconnect over SSH, and check the state:

uname -r
systemctl --failed
ip a
findmnt

uname -r should show the new kernel if one was installed. systemctl --failed should print 0 loaded units listed. The address should match your reservation, and every expected filesystem should still be mounted.

The failure mode

A remote-only machine that doesn’t come back is the risk here. Maybe the bootloader broke, maybe the network config didn’t survive. You find out only when SSH times out.

Keep a recovery route before rebooting a machine you can’t reach physically: console access, or someone who can press the power button. On a server in the same room this is a small thing. Make it a habit anyway, because it won’t always be in the same room.