ok...found the panic call here: sys/ufs/ufs/ufs_quota.c:451. From the
comment in the code: "On filesystems with quotas enabled, it is an
error for a file to change size and not to have a dquot structure
associated with it."
I do have quotas enabled on /home, but limits are only set for a
single user (no groups). Otherwise, I don't think I'm doing anything
crazy/out-of-the-ordinary. Clearly, the kernel got here, but I'm not
sure how.
sv01$ doas repquota /home
KByte limits File limits
User used soft hard grace used soft hard grace
root -- 398434 0 0 15 0 0
_syspatch -- 6032 0 0 1 0 0
stensonb -- 40656 0 0 1755 0 0
pic-uploader-- 864764 10000000 15000000 305 10000 15000
sv01$
sv01$ cat /etc/fstab
f10723e9888c49b1.b none swap sw
f10723e9888c49b1.a / ffs rw 1 1
f10723e9888c49b1.k /home ffs rw,nodev,nosuid,noatime,softdep,userquota 1 2
f10723e9888c49b1.d /tmp ffs rw,nodev,nosuid,noatime,softdep 1 2
f10723e9888c49b1.f /usr ffs rw,nodev,noatime,softdep 1 2
f10723e9888c49b1.g /usr/X11R6 ffs rw,nodev,noatime,softdep 1 2
f10723e9888c49b1.h /usr/local ffs rw,wxallowed,nodev,noatime,softdep 1 2
f10723e9888c49b1.j /usr/obj ffs rw,nodev,nosuid,noatime,softdep 1 2
f10723e9888c49b1.i /usr/src ffs rw,nodev,nosuid,noatime,softdep 1 2
f10723e9888c49b1.e /var ffs rw,nodev,nosuid,noatime,softdep 1 2
sv01$
On Tue, Mar 31, 2020 at 6:12 AM Bryan Stenson <[email protected]> wrote:
>
> Agreed...I'm not convinced it was due to being hosted on VMM...just
> wanted to include that as a data point (perhaps that detail is
> stressed too much here).
>
> I'm looking/learning about the "missing dquot" panic message now
> (brushing up on CVS, etc). :)
>
> After reboot, the filesystem fsck'd, and all seems to be well at this point.
>
> On Tue, Mar 31, 2020 at 6:09 AM Pratik Vyas <[email protected]> wrote:
> >
> > * Bryan Stenson <[email protected]> [2020-03-31 05:57:46 +0000]:
> >
> > >>Synopsis: panic on vm hosted with VMM - missing dquot
> > >>Category: unknown
> > >>Environment:
> > > System : OpenBSD 6.6
> > > Details : OpenBSD 6.6-current (GENERIC) #85: Sun Mar 29
> > >10:50:36 MDT 2020
> > >
> > >[email protected]:/usr/src/sys/arch/amd64/compile/GENERIC
> > >
> > > Architecture: OpenBSD.amd64
> > > Machine : amd64
> > >>Description: I noticed my VM was unresponsive, and upon accessing via
> > >>console, received the ddb prompt.
> > >
> > >>How-To-Repeat: unknown
> > >
> > >>Fix: unknown
> > >
> > >server9$ vmctl console 16
> > >Connected to /dev/ttypg (speed 115200)
> > >https://www.openbsd.org/ddb.html describes the minimum info required in bug
> > >reports. Insufficient info makes it difficult to find and fix bugs.
> > >ddb> trace
> > >db_enter() at db_enter+0x10
> > >panic(ffffffff81c52ce1) at panic+0x128
> > >chkdquot(fffffd80363fa968) at chkdquot+0xac
> > >ufs_quota_alloc_blocks2(fffffd80363fa968,20,fffffd801b174918,0) at
> > >ufs_quota_al
> > >loc_blocks2+0x2f
> > >ffs_alloc(fffffd80363fa968,23,230648,4000,fffffd801b174918,ffff8000149cd458)
> > > at
> > > ffs_alloc+0x11e
> > >ffs1_balloc(fffffd80363fa968,8c000,50,fffffd801b174918,1,ffff8000149cd550)
> > >at f
> > >fs1_balloc+0xc46
> > >ffs_write(ffff8000149cd5c0) at ffs_write+0x262
> > >VOP_WRITE(fffffd803aff95c0,ffff8000149cd650,3,fffffd801b174918) at
> > >VOP_WRITE+0x
> > >4f
> > >ktrwriteraw(ffff8000149ce4f0,fffffd803aff95c0,fffffd801b174918,ffff8000149cd710
> > >,ffff8000149cd6f0) at ktrwriteraw+0xf3
> > >ktrsyscall(ffff8000149ce4f0,3,18,ffff8000149cd7d0) at ktrsyscall+0x20c
> > >syscall(ffff8000149cd8a0) at syscall+0x1e8
> > >Xsyscall() at Xsyscall+0x128
> > >end of kernel
> > >end trace frame: 0x7f7ffffd6300, count: -12
> > >ddb>
> > >
> >
> > not sure if this is vmm (unless it's due to disk corruption?). Anything
> > else wrong after reboot?
> >
> >
> > --
> > Pratik
