Fix systemd 'mount: / is busy' During Boot (Remount Root Failed)

You reboot and instead of a login prompt you get a wall of red text: Failed to start Remount Root and Kernel File Systems followed by mount: / is busy. Sometimes it drops to emergency mode. Sometimes it just sits there. Either way, systemd can't remount root as read-write, and you need to get in.

The error message is misleading. "busy" here doesn't mean a process is holding a lock on /. It means the kernel is rejecting the remount operation itself — usually because of a bad /etc/fstab entry. The kernel is already running with root mounted, and systemd is trying to redeem the mount options from fstab. If those options don't match reality, the remount fails and systemd gives up.

Here are the three causes I see most on the help desk, in order of frequency.

Cause 1: A second fstab entry for / that doesn't match the running kernel

This is the one that gets people. Someone edits /etc/fstab, adds a line for /, and doesn't realize the root filesystem is already mounted by the initramfs. When systemd-remount-fs.service runs, it tries to apply whatever options are in fstab to an already-mounted /. If the device, UUID, or filesystem type is wrong, or if the options conflict with what the kernel already used, you get:

[FAILED] Failed to start Remount Root and Kernel File Systems.
See 'systemctl status systemd-remount-fs.service' for details.
mount: / is busy

Common triggers: a distro upgrade that regenerated fstab with different UUIDs, a clone from another disk that kept the old disk's UUID, or an admin who added a duplicate / line to "set noatime" and got the UUID wrong.

The fix

1. At the emergency prompt, enter the root password (or boot a live USB if you don't have one set).
2. Remount root read-write so you can edit files: mount -o remount,rw /
3. Open fstab: nano /etc/fstab
4. Find every line where the second field is /. There should be exactly one. Delete the duplicates.
5. On the remaining line, verify the device matches what the kernel actually used. Check with findmnt / -o SOURCE,FSTYPE,OPTIONS or lsblk -f.
6. If the UUID is wrong, update it. Get the correct UUID with blkid.
7. Save, then run systemctl daemon-reload and reboot.

After the reboot, you should land at a normal login prompt. If you're still in emergency mode, run systemctl status systemd-remount-fs.service and read the "Process" line — it'll show you the exact mount command that failed and the error.

Tip: if the system boots fine but nags about this, it's because the initramfs has a stale copy of fstab. Regenerate with update-initramfs -u on Debian/Ubuntu or dracut -f on RHEL/Fedora.

Cause 2: The kernel command line sets root= to the wrong device

You can have a perfect fstab and still hit this. If the bootloader's root= parameter points to a device that's already read-only or that doesn't match the actual root, the remount will fail with the same busy message. I've seen this after moving a disk from SATA to NVMe (/dev/sda2 becomes /dev/nvme0n1p2), or after a BIOS update that shuffled device enumeration.

Another nasty variant: root is on LVM or LUKS, and the initramfs can't find the volume. The kernel falls back to something else, root mounts read-only, and the remount never works because the device path in root= is stale.

The fix

1. At the GRUB menu, press e to edit the boot entry.
2. Find the line starting with linux (or linuxefi on some distros).
3. Look at the root= parameter. Compare it against lsblk -f output from the emergency shell.
4. If it's wrong, edit it in place. Boot with F10 or Ctrl-X to test.
5. Once you're in, make it permanent: on Debian/Ubuntu run update-grub. On RHEL/Fedora run grub2-mkconfig -o /boot/grub2/grub.cfg (or /boot/efi/EFI/fedora/grub.cfg on UEFI systems).

Boot after the fix. You should see the normal boot messages scroll by without the red systemd failure. If you're using UUIDs on the kernel line instead of device paths (some distros default to this), make sure the UUID matches the current root partition. It's easy to miss when you've cloned a disk.

Cause 3: Filesystem corruption on root

Less common but worth checking. If the root filesystem has a dirty journal or actual corruption, the kernel mounts it read-only out of self-defense. The remount to read-write then fails with busy because the kernel refuses to go rw on a broken filesystem.

Signs this is your problem: the boot messages mention EXT4-fs error or XFS (dm-0): Corruption detected before the remount failure. You might also see journal recovery failed.

The fix

1. Do not mount root read-write. Leave it read-only.
2. Boot a live USB. Don't try to repair a mounted filesystem — you'll make it worse.
3. Identify the partition: lsblk -f. Say it's /dev/sda2.
4. Run a read-only check first: fsck -n /dev/sda2 for ext4, or xfs_repair -n /dev/sda2 for XFS.
5. If errors show up, repair. For ext4: fsck -y /dev/sda2. For XFS, xfs_repair without -n but note XFS needs a clean log — if the log is dirty, you may need xfs_repair -L, which wipes the log and can lose recent writes. Back up first if you can.
6. Reboot and see if the remount succeeds.

If fsck reports the filesystem is clean but you still get busy, the problem is almost certainly Cause 1 or 2, not corruption. Go back and check fstab and the kernel line.

Quick reference

Nine times out of ten, it's fstab. Open it, look for a / line you don't remember adding, and delete it. The other times, check the kernel command line before you assume the disk is dying.