Ubuntu Stuck on “Clean, Files, Blocks”? Start With These Checks

Seeing /dev/sda2: clean, ... files, ... blocks during boot can make it look like Ubuntu has stopped. But that line is normally a filesystem-check summary, not an error. It means the check found no filesystem errors requiring repair; it does not confirm that the whole disk is healthy or explain why boot stopped afterward.

The useful question is what still works. Start there before running repair commands.

First, check whether Ubuntu is actually stuck

Try switching to a text console with Ctrl+Alt+F3. If that does not work, try F4, F5, or F6. The key combination can vary by system.

• A login prompt appears: Ubuntu reached a usable console. The problem may be the graphical session, display manager, driver, or a service that failed later in boot.
• No console responds: You may be dealing with an earlier boot problem. Use recovery mode or a live USB to investigate.
• The message flashes by and boot continues: That is normal; there may be nothing to fix.

This quick split helps avoid treating the last visible line as the cause. A boot splash can hide later output, leaving an ordinary status message on screen while something else stalls.

If a text console works, inspect failed services

Log in at the console and ask systemd which units failed:

systemctl --failed

If a display manager such as gdm, gdm3, lightdm, or sddm appears, investigate that unit first. A guide to reading systemctl status output can help you interpret a specific service's state and decide what to check next.

You can also look for errors from the current boot:

journalctl -b -p err

-b limits the output to the current boot, and -p err filters for error priority and above. Look for messages that identify a service or graphics component rather than assuming every error caused the stall. For more filtering options, see this practical guide to using journalctl.

A graphics driver issue is one possible cause when the console works but the desktop does not. The right fix depends on the driver and kernel in use, so use the failed unit and boot logs to narrow the problem before changing drivers.

If no console responds, check disk space and mounts

Boot into recovery mode or start from a live USB. From there, check the root filesystem's available space and inodes:

df -h
df -i

df -h reports space usage; df -i reports inode usage. These are separate limits: a filesystem can have free disk space but run out of inodes, for example when it contains a very large number of small files.

Next, inspect configured mounts and the devices that actually exist:

cat /etc/fstab
findmnt
lsblk -f

An outdated UUID or a mount that cannot be reached may hold up boot. Compare the entries in /etc/fstab with lsblk -f, which shows block devices, filesystem types, and UUIDs. findmnt shows mounted filesystems. If you find a mismatch, confirm which device and mount point are involved before editing configuration.

Run a filesystem check only when there is evidence for one

A clean message alone is not a reason to run a repair. If space and mount configuration look right but you have evidence of filesystem trouble, check the filesystem from recovery mode or live media—and make sure it is unmounted first.

For an ext2/ext3/ext4 filesystem, the process looks like this:

umount /dev/sda2
sudo e2fsck -f /dev/sda2

Replace /dev/sda2 with the actual partition. Device names vary: SATA or SCSI partitions may look like /dev/sda2, while NVMe partitions may look like /dev/nvme0n1p2. Use lsblk -f to identify the right one rather than copying a device name from an example.

Do not run e2fsck on a mounted filesystem. If it proposes repairs, read the prompts before accepting them; avoid aggressive, non-interactive repair options as a first step. If the data matters and you are unsure what the proposed changes mean, back up what you can access before proceeding.

A practical order of operations

1. Try Ctrl+Alt+F3 (then F4–F6) to see whether a text console responds.
2. If it does, check systemctl --failed and journalctl -b -p err for clues.
3. If it does not, use recovery mode or live media to check df -h, df -i, /etc/fstab, findmnt, and lsblk -f.
4. Run a filesystem check only if the other checks and available evidence point toward filesystem trouble—and only while the target filesystem is unmounted.

The clean, files, blocks line says that a particular filesystem check found no errors requiring repair. It is often just the last visible message before the actual boot problem. Checking whether a text console works is the fastest way to decide which troubleshooting path to take.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.