Solved [SOLVED] fsck using “no” even with -y option

[rekabis]

Had my host OS go down in a strange way, and I have FreeBSD in a VM. System went down uncleanly, and corrupted several partitions. I managed to use fsck to clean a number of those partitions, but one in particular refuses to be cleaned.

Specifically, /var/www cannot be corrected because running fsck -y /var/www produces a “no” after every option. Such as,

CLEAR? no
SALVAGE? no
RECONNECT? no

and so on.

Not sure how to “force” fsck to work beyond using the -y option.

 

[rekabis]

Re: fsck using “no” even with -y option

Found a sufficient workaround - single user mode.

But holy hell does FreeBSD ever boot slowly in a Hyper-V VM! I mean, at least five minutes from start to login prompt, at minimum. Getting past the initial boot loader takes at least three of those minutes!

 

[trh411]

One way to solve this problem is to include the following lines in /etc/rc.conf:

background_fsck="NO"
fsck_y_enable="YES"

And reboot. Remove (or comment out) the "fsck_y_enable" line once the file system reports clean. Refer to rc.conf(5) for more info.

 

[wblock@]

fsck(8) can only correct partitions that are not mounted. Booting into single user mode is the easiest way to do that.

 

[trh411]

fsck(8) can only correct partitions that are not mounted. Booting into single user mode is the easiest way to do that.

I understand that, but this approach will still work. Whether or not it is "easier" than booting into single user mode could be argued based on circumstances. The /etc/rc.conf approach was recommended recently on the freebsd-stable@freebsd.com mailing list for someone who could not easily get to single user mode to clear up a panic caused by mangled UFS directories since he was running on a Google compute engine VM. Anyway, just wanted to put the approach in context. Not looking to start an argument. Plus it's good to have alternatives.

 

[wblock@]

Sorry, I didn't mean to argue with you, just trying to explain why it could not repair the problem initially.

 

[xtaz]

In theory as well if you use SU+J journalling it doesn't even need to do an fsck as it will just ditch the soft update buffer and recover from the journal.