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
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 t
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
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)
>> cras
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, std
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
[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-
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
>AES-X
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 th
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.
>pr
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 elsew
11 matches
Mail list logo