Panic during fsck in bhyve VM

[Don Lewis]

On  9 Feb, Willem Jan Withagen wrote:
> On 9-2-2015 16:09, Benjamin Kaduk wrote:
>> On Mon, 9 Feb 2015, Willem Jan Withagen wrote:
>> 
>>> Hi,
>>>
>>> Probably due to too many hard-resets of the VM, but I've got the
>>> root fs of one of my VMs in a real bad state.....
>>> Even where recovery with fsck does not lead to the wanted result.
>>>
>>> Recovering might be interesting, but not essential since it is just
>>> a testing image.
>>>
>>> The traceback is below. I've saved the image, en getting it online
>>> is real easy.
>>>
>>> If this helps in getting UFS/fsck bugs fixed, I'll keep it.
>>> Otherwise it is going into /dev/null
>>>
>>> --WjW
>>>
>>>
>>> WARNING: WITNESS option enabled, expect reduced performance.
>>> Trying to mount root from ufs:/dev/vtbd0p2 [rw]...
>>> WARNING: / was not properly dismounted
>>> Enter full pathname of shell or RETURN for /bin/sh:
>>> # fsck /
>>> ** /dev/vtbd0p2
>>>
>>> USE JOURNAL? [yn] y
>>>
>>> ** SU+J Recovering /dev/vtbd0p2
>>> ** Reading 33554432 byte journal from inode 4.
>>>
>>> RECOVER? [yn] y
>>>
>>> ** Building recovery table.
>>> ** Resolving unreferenced inode list.
>>> ** Processing journal entries.
>>>
>>> ***** FILE SYSTEM MARKED CLEAN *****
>>> # df
>>> Filesystem   512-blocks     Used    Avail Capacity  Mounted on
>>> /dev/vtbd0p2   30450552 15277136 12737376    55%    /
>>> devfs                 2        2        0   100%    /dev
>>> # mount -rw /
>>> panic: ufs_dirbad: /: bad dir ino 1364363 at offset 512: mangled
>>> entry
>> 
>> This does not seem consistent with the subject line of the email.
>> 
>> The first thing to try is to run fsck without using the journal.
> 
> Oke,
> 
> You are correct that I worded the title badly.
> The system actually crashes right away after fsck and going to R/W for
> the disc.
> 
> I appreciate the input to running without journal.
> But there is very little I can find in the manualpages about that?
> fsck or fsck_ufs.

fsck is fine

> But I would expect fsck "to do the smart thing", and report errors
> during fixing. And otherwise return a correct FS.

If you tell fsck to use the journal, it assumes that the filesystem is
basically in good shape and it just needs to take care of the
transactions in the journal.  That way the the reboot is much quicker
because it doesn't have to wait for a full fsck.