[UFS] Failing to fsck a USB flash disk

I have a USB flash drive that is reporting errors in phases 1 and 4 of fsck.

When unmounted or mounted, in read-only or read-write mode, with several combinations of CLI options, this USB flash drive refuses to cooperate. Basically fsck can not get past thinking the drive is in read-only mode - but I've mounted it specifically as read-write.

Suggestions on how to solve this? Thanks.

Code:
[cmd]# mount -w -t ufs /dev/da0s1 /media/usbflash[/cmd]
[CMD]# mount -v | grep da0s1[/CMD]
/dev/da0s1 on /media/usbflash (ufs, local, journaled soft-updates, writes: sync 2 async 0, reads: sync 2 async 0, fsid fd8da351dfa63be7)

[CMD]# fsck -f /dev/da0s1[/CMD]
** /dev/da0s1 (NO WRITE)
SETTING DIRTY FLAG IN READ_ONLY MODE

UNEXPECTED SOFT UPDATE INCONSISTENCY
** Last Mounted on /media/usbflash
** Phase 1 - Check Blocks and Sizes
UNKNOWN FILE TYPE I=321250
UNEXPECTED SOFT UPDATE INCONSISTENCY

CLEAR? no
...

[CMD]# fsck -p /media/usbflash[/CMD]
/dev/da0s1: NO WRITE ACCESS
/dev/da0s1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

I am running you MANUALLY, fsck! Hello?
 
What it means is that fsck(8) can't write to a mounted filesystem (except the root filesystem in read-only). Boot in single-user mode from the menu, then run fsck(8): fsck -tufs -y /dev/da0s1
 
I was hoping to avoid booting to single-user mode.

Sidetracking for a moment; if there was one thing I'd like to see different about FreeBSD, it'd be being able to do these types of things without rebooting, including resetting kern.securelevel for freebsd-update's, etc.

Alright, appreciate the info, I'll give it a shot next opportunity.

Thanks!
 
It looks like that did the trick. I now have all my files back and the filesystem is reporting proper disk space usage.
 
realtime said:
Sidetracking for a moment; if there was one thing I'd like to see different about FreeBSD, it'd be being able to do these types of things without rebooting, including resetting kern.securelevel for freebsd-update's, etc.

kern.securelevel is this way by design - if you were to enable it to be re-set after boot, it would enable a remote attacker to potentially reset it and make changes to things that kern.securelevel is intended to prevent.
 
Back
Top