Date: Tue, 1 Aug 2017 22:59:00 +0200 From: Peter <pmc@citylink.dinoex.sub.org> To: freebsd-stable@FreeBSD.ORG Subject: 11.1-RELEASE: panic! acl_from_aces: a_type is 0x4000 Message-ID: <olqq2k$2560$1@oper.dinoex.de>
next in thread | raw e-mail | index | archive | help
This is mostly for the search engines, so others running into it may
find it easier to solve.
While updating some ports via "portupgrade", I got this panic:
Panic String: acl_from_aces: a_type is 0x4000
The phenomen was reproducible; it appeared while creating a backup
package from the "glib" port.
I checked readability of all concerned files, did a scrub on the pool,
but found no errors! As I was busy with other issues, I then neglected
the matter and simply deleted and reinstalled that port.
A couple days later, working on a different installation, I got the
exact same panic at the exact same point, while updating the "glib" port.
This time I looked closer into the matter.
According to "truss", the panic appears while "pkg" calls
__acl_get_link() on a specific file.
That file is readable.
The directory tree can be searched.
But it is not possible to do "ls -l" on the directory -> panic!
It is possible to send+recv the Filesystem: the error gets transported
to the new filesystem! (From ZFS view it seems to be legal payload;
only from FreeBSD file-handling view it is reason for panic.)
Finally, the file can be copied, unlinked, and recreated.
I did a thorough search and found a dozen other files on the system with
the same issue.
REMEDY:
-------
It seems that such flaws can lure undetected on a system for an
indefinite time. The only way to find them seems read all inode data,
via something like
#find -x `mount -t zfs | awk '{print $3}'` -type d -exec ls -la {} \;
ROOT CAUSE:
-----------
Not fully clear. It may be related to hardware (memory) flaws.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?olqq2k$2560$1>