> On Apr 6, 2023, at 3:56 AM, Hans Petter Selasky wrote:
>
> On 4/5/23 21:44, Hans Petter Selasky wrote:
>> On 4/5/23 20:23, Gleb Smirnoff wrote:
>>> What if we remove the CTLFLAG_VNET check from the code you posted above?
>>> I don't see anything going wrong, rather going right
>>>
>>>
Some existing changes in FreeBSD need not be appropriate to
openzfs but it is more likely that many of the same files
would eventually have some sort of change in openzfs's main
dealing with what FreeBSD has run into from the import.
Looking around, the following are the FreeBSD adjustments
in
On Apr 18, 2023, at 15:02, José Pérez wrote:
> El 2023-04-18 21:37, Mark Millard escribió:
>>> In this case it does because the value is "active". If it's "enabled"
>>> you do not need to do anything.
>> Well, if block_cloning is disabled it would not become active.
> [...]
>> So, in progressing
On Tue, Apr 18, 2023 at 5:04 PM Mark Millard wrote:
> On Apr 18, 2023, at 15:46, Warner Losh wrote:
>
> > Fun...
> >
> > I'm also fighting aarch64 issues...
>
> Of what kind? I've been able to use things as committed
> in FreeBSD (block_cloning never having been enabled but
> jumping from
On Apr 18, 2023, at 15:46, Warner Losh wrote:
> Fun...
>
> I'm also fighting aarch64 issues...
Of what kind? I've been able to use things as committed
in FreeBSD (block_cloning never having been enabled but
jumping from before the import to, effectively, after
the FreeBSD adjustments). But I
Fun...
I'm also fighting aarch64 issues...
Warner
On Tue, Apr 18, 2023, 4:45 PM Mark Millard wrote:
>
> https://github.com/openzfs/zfs/commit/d0cbd9feaf5b82130f2e679256c71e0c7413aae9
>
> does not seem to cover armv7, just aarch64. (FreeBSD disabled
> floating point for both armv7 and aarch64
https://github.com/openzfs/zfs/commit/d0cbd9feaf5b82130f2e679256c71e0c7413aae9
does not seem to cover armv7, just aarch64. (FreeBSD disabled
floating point for both armv7 and aarch64 but that is a
different change than above.)
I used:
El 2023-04-18 21:37, Mark Millard escribió:
In this case it does because the value is "active". If it's "enabled"
you do not need to do anything.
Well, if block_cloning is disabled it would not become active.
[...]
So, in progressing past the vintage that corrupt zfs data,
one could end up
José_Pérez wrote on
Date: Tue, 18 Apr 2023 16:59:03 UTC :
> El 2023-04-17 21:59, Pawel Jakub Dawidek escribió:
> > José,
> >
> > I can only speak of block cloning in details, but I'll try to address
> > everything.
> >
> > The easiest way to avoid block_cloning-related corruption on the
> >
El 2023-04-17 21:59, Pawel Jakub Dawidek escribió:
José,
I can only speak of block cloning in details, but I'll try to address
everything.
The easiest way to avoid block_cloning-related corruption on the
kernel after the last OpenZFS merge, but before e0bb199925 is to set
the compress property
After completing installworld and rebuilding python39 I do get the same error
as reported previouslyFilippo
On Tuesday, April 18, 2023 at 12:54:33 PM UTC, Mateusz Guzik
wrote:
On 4/18/23, Filippo Moretti wrote:
> Good morning, I run this versione of Frrebsd and
On 4/18/23, Filippo Moretti wrote:
> Good morning, I run this versione of Frrebsd and al
> py-* ports fail with the following message.sincerelyFilippo
>
> FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #6
> main-n261981-63b113af5706: Tue Apr 4 16:57:47 CEST 2023
>
;>> make build failed for textproc/py-pygments@py39
===>>> Aborting update
===>>> Update for textproc/py-pygments@py39 failed
===>>> Aborting update
On Tuesday, April 18, 2023 at 09:57:31 AM UTC, Felix Palmen
wrote:
* Marek Zarychta [20230418 11:41]:
&
> On 18 Apr 2023, at 09:46, Martin Matuska wrote:
>
> Btw. I am open for setting up a pre-merge stress testing
>
> I will check out if I can use the hourly-billed amd64 and arm64 cloud boxes
> at Hetzner with FreeBSD.
> Otherwise there are monthly-billed as well.
I can provide a bhyve VM
On Thu, 23 Jun 2022 11:15:55 -0600
Warner Losh wrote:
> On Sun, Jun 19, 2022 at 6:06 AM Michael Gmelin
> wrote:
>
> >
> >
> > On Fri, 21 May 2021 08:36:49 -0600
> > Warner Losh wrote:
> >
> > > On Fri, May 21, 2021 at 7:38 AM Ceri Davies
> > > wrote:
> > >
> > > > On Thu, May 20, 2021
* Marek Zarychta [20230418 11:41]:
> What is the culprit?
Most likely some leftovers from older package versions (so it's only a
problem when building in the live system. A clean jail won't have the
offending files).
> Removing blindly all py- packages for all af
> On 18 Apr 2023, at 11:12, Filippo Moretti wrote:
>
> Good morning,
>I run this versione of Frrebsd and al py-* ports fail
> with the following message.
> sincerely
> Filippo
Maybe this helps:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=269545#c6
W dniu 18.04.2023 o 10:46, Felix Palmen pisze:
* Filippo Moretti [20230418 08:12]:
File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py", line 31,
in
if isinstance(ob, importlib_metadata.MetadataPathFinder)
AttributeError: module 'importlib_metadata' has no
* Filippo Moretti [20230418 08:12]:
> File "/usr/local/lib/python3.9/site-packages/setuptools/_importlib.py",
> line 31, in
> if isinstance(ob, importlib_metadata.MetadataPathFinder)
> AttributeError: module 'importlib_metadata' has no attribute
> 'MetadataPathF
Good morning, I run this versione of Frrebsd and al py-*
ports fail with the following message.sincerelyFilippo
FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #6 main-n261981-63b113af5706:
Tue Apr 4 16:57:47 CEST 2023
Btw. I am open for setting up a pre-merge stress testing
I will check out if I can use the hourly-billed amd64 and arm64 cloud
boxes at Hetzner with FreeBSD.
Otherwise there are monthly-billed as well.
Cheers,
mm
On 17. 4. 2023 22:14, Mateusz Guzik wrote:
On 4/17/23, Pawel Jakub Dawidek
On 18. 4. 2023 3:16, Warner Losh wrote:
Related question: what zfs branch is stable/14 going to track? With 13
it was whatever the next stable branch was.
Warner
FreeBSD 14.0 is about to track soon-to-be-branched OpenZFS 2.2
22 matches
Mail list logo
