Fixing 'Mounting from ufs:/dev/... failed' at FreeBSD Boot

When FreeBSD reaches mountroot>, firmware and the loader have already found and started a kernel, but the kernel could not mount the configured root filesystem. The failed string—such as ufs:/dev/ada0p2 or zfs:zroot/ROOT/default—identifies the attempted filesystem type and provider. It does not by itself distinguish a missing controller driver, renamed device, stale loader setting, damaged filesystem, or unavailable ZFS pool.

Preserve the failed specification and list visible providers

Photograph the full error, including errno and the vfs.root.mountfrom value. At the mountroot> prompt, ? lists disk-like providers the kernel can currently see:

mountroot> ?

If the expected disk is absent, typing another UFS path cannot repair it. Check cabling, power, controller mode, device failure, and whether the kernel contains or loaded the controller driver. A kernel upgrade followed by ENODEV may indicate that the new kernel and its modules do not match or that a required module was omitted.

If the provider exists under another enumeration name, a temporary root can be entered using the exact syntax reported by the prompt:

mountroot> ufs:/dev/ada1p2

This is a recovery boot, not the final fix. Confirm the filesystem type and partition before trying it. Error 19 is ENODEV, but other errno values can indicate a filesystem or permission/format problem; do not generalize every mountroot failure as a missing device.

The kernel prompt is not a normal shell. Commands such as zpool import, gpart, and fsck are unavailable there. If the correct root cannot be mounted, boot trusted installation media and use its Live CD shell.

Inspect loader state before the kernel starts

At the loader prompt, enumerate boot-visible devices and loaded modules:

OK lsdev -v
OK lsmod
OK show vfs.root.mountfrom
OK show currdev

For ZFS, lszfs can inspect datasets visible to the loader. A pool visible to rescue tools but invisible to the loader can indicate missing boot support, incompatible pool features, stale bootcode, or an incomplete disk set.

FreeBSD’s loader normally derives the root from /etc/fstab on the device from which it loaded, unless configuration overrides it. Search /boot/loader.conf and its included files for an explicit vfs.root.mountfrom. An old manual override can keep pointing at ada0p2 after the actual root moved to nda0p2 or a GPT label.

Booting -s changes the mode after root mounts; it does not bypass an unmountable root. The loader’s -a option explicitly asks the kernel which root to mount and is useful when providers are visible:

OK boot -a

If the current kernel lost a driver, a previously installed kernel may restore access:

OK unload
OK set kernel="kernel.old"
OK boot-conf

Use only a known matching kernel/modules directory. Mixing a new kernel with old modules can create a second failure.

Repair UFS configuration from rescue media

From a Live CD, identify rather than guess:

gpart show -p
fstyp /dev/ada0p2
gpart list

Mount the verified UFS root read-only first and inspect its configuration:

mkdir -p /mnt/root
mount -o ro /dev/ada0p2 /mnt/root
cat /mnt/root/etc/fstab
grep -R 'vfs.root.mountfrom' /mnt/root/boot

If the filesystem will not mount read-only, preserve data and use fsck_ufs according to its manual; a label change will not repair filesystem corruption. If it mounts, replace volatile device nodes with an existing GPT label or filesystem label where appropriate. To label an existing GPT partition, use the documented gpart modify workflow after backing up partition metadata—gpart add creates a new partition and is not the command for relabeling an existing one.

Make /etc/fstab and any explicit loader override agree. Avoid keeping two independent root specifications unless there is a documented need. Before rebooting, verify the label appears under /dev/gpt in the rescue environment and that the target kernel includes GEOM label support.

Diagnose ZFS root at the pool and dataset layers

For ZFS, boot rescue media with ZFS support and inspect without forcing an import:

zpool import
zpool status

If the pool requires import, use an alternate root such as -R /mnt and avoid -f, rewind, or pool upgrade options until ownership and health are understood. A pool last active on another host may legitimately require administrative intervention; forcing it on two systems risks corruption.

The root string names a dataset, not merely a pool:

zfs:zroot/ROOT/default

Confirm that dataset exists, its mountpoint and canmount properties match the boot-environment layout, and the pool’s bootfs property identifies the intended root where used. A destroyed or renamed boot environment can leave the loader pointing at a dataset that no longer exists even though the pool imports cleanly.

If the pool was recently upgraded, older bootcode may not understand its features. Follow the target FreeBSD release notes for updating EFI or BIOS boot components; do not copy arbitrary bootcode or enable more pool features during recovery.

Verify hardware and persistence after the recovery boot

Once the system boots, inspect the storage path and configuration that actually succeeded:

mount
gpart show -p
sysctl vfs.root.mountfrom
freebsd-version -kru

Review dmesg for controller resets, timeouts, or devices that appeared only after a delay. A corrected label cannot compensate for a failing drive. Check ZFS pool health or UFS diagnostics and complete a backup before returning the machine to service.

Then reboot once under console observation. The incident is closed only when the persistent loader/fstab configuration selects the right root without manual input. The essential separation is: loader visibility, kernel driver visibility, provider identity, filesystem health, and root specification are five different layers, and mountroot> tells you only that they did not converge.

Related:

Sources: