Fixing 'Mounting from ufs:/dev/... failed' at FreeBSD Boot
Your FreeBSD system drops into a mountroot prompt instead of booting. Here's how to diagnose which layer actually failed and get back to a working system.
You reboot a FreeBSD system and instead of a login prompt, you get dropped into a mountroot> prompt with a message like Mounting from ufs:/dev/ada0p2 failed with error 19. The kernel loaded, but it can’t find or mount the root filesystem it was told to expect.
What this actually means
Error 19 is ENODEV — the device the kernel was told to mount as root doesn’t exist as far as the kernel can currently see. This almost always means one of three things: the disk/controller changed (a drive was moved, replaced, or its driver isn’t loaded), the root filesystem specification in /boot/loader.conf or the loader’s vfs.root.mountfrom is stale, or (for ZFS root systems) the pool genuinely can’t be found or imported at this boot stage.
First: see what devices the kernel actually sees
At the mountroot> prompt itself, you can list currently-visible devices before doing anything else:
mountroot> ?This lists every GEOM provider the kernel currently recognizes. If your expected disk (ada0, nvd0, a ZFS pool) isn’t in that list at all, the problem is at the driver/hardware level, not a filesystem configuration mismatch — check that the disk is actually connected and that any needed storage controller driver is loaded.
If the device exists but under a different name
Hardware changes (moving a disk to a different controller, replacing a failed drive) commonly shift device names — what used to be ada0 might now enumerate as ada1. If you see your filesystem under a different name at the mountroot> prompt, you can boot with it directly:
mountroot> ufs:/dev/ada1p2Once booted, fix the persistent configuration so this doesn’t recur — either /etc/fstab’s root entry, or (if you boot with an explicit vfs.root.mountfrom in /boot/loader.conf) update that instead, ideally to reference the GPT label rather than a raw device node, since labels survive controller/enumeration changes:
# /boot/loader.conf
vfs.root.mountfrom="ufs:/dev/gpt/rootfs"If you’re on ZFS root and the pool won’t import
For ZFS-root systems, a failed mountroot is often a pool import problem rather than a UFS device-naming issue — check zpool import from the mountroot prompt’s limited shell, or boot into the loader and inspect available pools before the kernel even tries to mount:
OK lszfs zroot
OK boot -sBooting -s into single-user mode, once you do get a shell, lets you run zpool import manually and diagnose further with a full toolset available, rather than working from the very limited mountroot> prompt itself.
Preventing this going forward
The single most effective preventive measure is using GPT labels (gpart add -l labelname) or ZFS pool names instead of raw device paths (/dev/ada0p2) anywhere root filesystem configuration is specified — labels and pool names survive hardware reshuffling in a way bare device node names never will, which is exactly the class of failure this specific boot error represents.