Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 09 Feb 2015 16:40:41 +0100
From:      Willem Jan Withagen <wjw@digiware.nl>
To:        Benjamin Kaduk <kaduk@MIT.EDU>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: Panic during fsck in bhyve VM
Message-ID:  <54D8D4F9.9070901@digiware.nl>
In-Reply-To: <alpine.GSO.1.10.1502091008500.3953@multics.mit.edu>
References:  <54D89A69.1000206@digiware.nl> <alpine.GSO.1.10.1502091008500.3953@multics.mit.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

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

--WjW

> -Ben Kaduk
> 
>> cpuid = 1
>> KDB: stack backtrace:
>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe02332b12b0
>> vpanic() at vpanic+0x189/frame 0xfffffe02332b1330
>> panic() at panic+0x43/frame 0xfffffe02332b1390
>> ufs_lookup_ino() at ufs_lookup_ino+0xecd/frame 0xfffffe02332b14b0
>> VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xf1/frame 0xfffffe02332b14e0
>> vfs_cache_lookup() at vfs_cache_lookup+0xd6/frame 0xfffffe02332b1540
>> VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xf1/frame 0xfffffe02332b1570
>> lookup() at lookup+0x5c5/frame 0xfffffe02332b1600
>> namei() at namei+0x526/frame 0xfffffe02332b16c0
>> vn_open_cred() at vn_open_cred+0xd5/frame 0xfffffe02332b1820
>> kern_openat() at kern_openat+0x257/frame 0xfffffe02332b19a0
>> amd64_syscall() at amd64_syscall+0x25a/frame 0xfffffe02332b1ab0
>> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe02332b1ab0
>> --- syscall (499, FreeBSD ELF64, sys_openat), rip = 0x800b09fba, rsp =
>> 0x7fffffffe868, rbp = 0x7fffffffe940 ---
>> KDB: enter: panic
>> [ thread pid 19 tid 100051 ]
>> Stopped at      kdb_enter+0x3e: movq    $0,kdb_why
>> _______________________________________________
>> freebsd-fs@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
>>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54D8D4F9.9070901>