Solved fsck -fy not fixing root drive

[Avery Freeman]

Hello,

I've been using a FreeBSD VM in ESXi 6.7 for recording TV (HDHomeRun) for at least the last year and have had great results

I recently upgraded to a new ESXi host and was cloning my VMs from the old E3 server to the new E5 server.

Upon cloning the FreeBSD VM, I noticed the clone had issues with FREE BLK COUNT(S) WRONG IN SUPERBLK according to # fsck -y - which worked as normal and marked /dev/da0p2 as clean. No problem.

The weird part is, the ORIGINAL VM on the E3 server is now doing the same thing - but fsck is NOT fixing it!

So far I have tried a few variations:

fsck -y
fsck -fy
fsck_ufs -fy /dev/da0p2

none of them do anything different - they scan the drive, give the same error, FREE BLK COUNT(S) WRONG IN SUPERBLK and that's it.

I am really upset because if I need to use my old host to record TV in the event of the new one failing, I will not have a fallback.

What can I do? Is it possible to boot from an install ISO and run some sort of repair software on the 'drive' while it's unmounted?

Thank you!

 

[SirDice]

Boot to single user mode, fsck(8) cannot fix certain errors if the filesystem is mounted read/write. In single user mode the filesystem is mounted read-only and fsck(8) will be able to fix it.

 

[Avery Freeman]

Boot to single user mode, fsck(8) cannot fix certain errors if the filesystem is mounted read/write. In single user mode the filesystem is mounted read-only and fsck(8) will be able to fix it.

Oh, yes, that's right - I forgot to reboot in single-user mode. Whoops, thank you!

Rather than do that, which would have been a lot easier, I booted from an installation ISO, dropped to shell and ran fsck -y /dev/da0p2 - I also fixed an error in /etc/fstab. So, that works too, but obviously much harder.

Thank you