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.
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
