Re: ENOTCAPABLE returned without Capsicum

On 2021-May-16 11:48:24 +1000, Peter Jeremy via freebsd-stable wrote: >I am running 13-stable from a couple of weeks ago, without Capsicum >(neither CAPABILITY_MODE nor CAPABILITIES are specified in my kernel). >Despite this, I am getting Capsicum-related errors. As an example: &g

ENOTCAPABLE returned without Capsicum

I am running 13-stable from a couple of weeks ago, without Capsicum (neither CAPABILITY_MODE nor CAPABILITIES are specified in my kernel). Despite this, I am getting Capsicum-related errors. As an example: openat(AT_FDCWD, "/") will return ENOTCAPABLE. Rummaging around the sources, it seems

fileargs_init(3) doesn't work without CAPABILITIES (was: Re: tail(1) broken in 13-stable)

On 2021-May-06 19:07:23 -0400, monochrome wrote: ... >On 5/6/21 7:49 AM, Peter Jeremy via freebsd-stable wrote: ... >> server% tail /COPYRIGHT <&- >> Assertion failed: (procfd > STDERR_FILENO), function service_clean, file >> /usr/src/lib/libcasper/libcasper/servi

Re: tail(1) broken in 13-stable

On 2021-May-06 12:59:54 +0200, Mariusz Zaborski wrote: >Could you provide details how to reproduce this? > >On Thu, 6 May 2021 at 12:13, Peter Jeremy via freebsd-stable > wrote: >> >> Since updating from 12-stable to 13-stable, I've found that tail(1) >> crashes,

tail(1) broken in 13-stable

Since updating from 12-stable to 13-stable, I've found that tail(1) crashes, reporting: Assertion failed: (procfd > STDERR_FILENO), function service_clean, file /usr/src/lib/libcasper/libcasper/service.c, line 394. tail: unable to init casper: Socket is not connected unless all three of stdin,

Re: geli broken in 13.0-BETA4 and later on armv8

On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable >> > wrote: >> >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >> >>(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >> >>RK3399, arm64) has chan

Re: geli broken in 13.0-BETA4 and later on armv8

[Adding arm@ and making it clearer that this is armv8-only] On 2021-Mar-06 20:26:19 +1100, Peter Jeremy wrote: >On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable > wrote: >>Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >>(releng/13.0-n244592-

Re: geli broken in 13.0-BETA4 and later

On 2021-Mar-06 19:18:37 +1100, Peter Jeremy via freebsd-stable wrote: >Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 >(releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - >RK3399, arm64) has changed so that a geli-encrypted partition (using >

geli broken in 13.0-BETA4 and later

Somewhere between 13.0-ALPHA2 (c256201-g02611ef8ee9) and 13.0-BETA4 (releng/13.0-n244592-e32bc253629), geli (at least on my RockPro64 - RK3399, arm64) has changed so that a geli-encrypted partition (using AES-XTS 128) that was readable on 13.0-ALPHA2 becomes garbage on 13.0-BETA4. I've verified

Re: lots of "no such file or directory" errors in zfs filesystem

On 2021-Feb-23 11:30:58 -0600, Chris Anderson wrote: >nope, it led a pretty boring life. that zfs filesystem was created on that >server and has been on the same two mirrored disks for its lifetime. Does the server have ECC RAM? Possibly it's a bitflip somewhere before the data got to disk.

Re: svn commit: r362848 - in stable/12/sys: net netinet sys

TL;DR: Ensure you explicitly destroy all ZFS labels on disused root pools. On 2020-Jul-19 21:21:02 +1000, Peter Jeremy wrote: >I'm sending this to -stable, rather than the src groups because I >don't believe the problem is the commit itself, rather the commit >has uncovered a latent problem