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>