Fixing Disk Mounting and BFS Volume Check Issues on Haiku
A secondary drive or partition won't mount, or Haiku reports filesystem inconsistencies on a BFS volume. Here's how to diagnose the mount failure and run BFS's own consistency check safely.
A drive that won’t mount, or a BFS volume reporting inconsistencies, is a distinct problem from Haiku itself failing to boot — this covers secondary volumes and non-boot-critical filesystem issues specifically.
Step 1: check whether the drive is detected at all
Terminal: listusb
Terminal: listdev
If the drive doesn’t appear in hardware listings at all, this is a device-detection problem — check device driver issues troubleshooting steps for the broader hardware-support angle, since it applies beyond just display drivers.
Step 2: check the disk’s partition table and filesystem type
DriveSetup (Haiku's disk utility, in Applications)
→ select the disk → view partition and filesystem info
Confirm the partition Haiku is trying to mount is actually formatted as BFS — a partition formatted for a different filesystem (NTFS, ext4) has entirely different mounting requirements and different failure modes than a BFS-specific problem.
Step 3: attempt a manual mount from Terminal for more detailed error output
mount -t bfs /dev/disk/... /desired/mount/point
Running the mount manually from Terminal, rather than relying on automatic mounting, often surfaces a more specific error message than a generic “couldn’t mount” dialog would.
Step 4: run BFS’s consistency checker
checkfs /dev/disk/...
checkfs is BFS’s built-in consistency-checking tool (conceptually similar to fsck on Unix-like systems) — it identifies structural inconsistencies in the B+tree indices and file records that make up a BFS volume.
Step 5: run checkfs with repair enabled if problems are found
checkfs -r /dev/disk/...
Only run repair on a volume you can afford to be wrong about — like any filesystem repair tool, checkfs -r makes a good-faith effort to fix structural inconsistencies, but a severely corrupted volume can theoretically lose data in the repair process. Back up anything accessible first if the drive has any readable content at all.
Step 6: check for a volume that mounts read-only unexpectedly
If a volume mounts successfully but appears read-only when it shouldn’t be, this commonly indicates checkfs detected inconsistencies serious enough that Haiku mounted defensively rather than risk further write-time corruption — treat this as a signal to run the check-and-repair steps above, not as a separate, unrelated problem.
Step 7: verify BFS attributes and indices survived the repair
lsindex /desired/mount/point
Since BFS’s live queries and attribute-based search depend on intact indices, confirming indices are still present and populated after a repair is worth doing specifically — a technically-mounted volume with index corruption can still cause query and Tracker-search misbehavior even once basic mounting succeeds.
Step 8: rule out a failing physical drive as the underlying cause
Repeated, recurring filesystem inconsistencies on the same physical drive — rather than a one-time event traceable to an unclean shutdown — point toward failing storage hardware rather than a BFS-specific software issue; running the manufacturer’s own drive diagnostic tool (from another OS if necessary) is worth doing before continuing to trust that drive with real data.
Why BFS’s own tooling, not generic disk utilities, is the right tool here
BFS’s B+tree-based indexing and attribute system is genuinely different from more common filesystems, which is exactly why it doubles as a lightweight database — but that same design means generic, filesystem-agnostic disk repair tools from other operating systems have no meaningful way to check or repair BFS-specific structures; checkfs is Haiku’s own tool built with direct knowledge of BFS’s actual on-disk format.