Hi Lyndon,
> > I've never found any compelling reason in most uses to enable "atime",
> > except perhaps local mail (snip).
> When UNIX ran on PDP-11s and disk pack sizes were measured in the
> tens of megabytes, atime was very helpful in determining which files
> were likely candidates for
Am Mon, 8 Jan 2024 01:33:53 +0100 (CET)
Felix Reichenberger schrieb:
> > Hello,
> >
> > I've got a problem with recent CURRENT, running vnet JAILs.
> > FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET
> > 2024 amd64
> >
> > Main Host has IPFW configured and is open for
Am Sat, 13 Jan 2024 19:41:30 -0800
Rick Macklem schrieb:
> On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote:
> >
> >
> > Van: FreeBSD User
> > Datum: 13 januari 2024 19:34
> > Aan: FreeBSD CURRENT
> > Onderwerp: NFSv4 crash of CURRENT
> >
> > Hello,
> >
> > running CURRENT client (FreeBSD
Lexi Winter wrote on
Date: Thu, 11 Jan 2024 02:21:19 UTC :
> i'm having a recurring problem with poudriere that i hope someone might
> have an idea about.
>
> i'm building packages with poudriere on a system with 32GB memory, with
> tmpfs and md disabled in poudriere (so it's using ZFS only)
On Sat, Jan 13, 2024 at 12:39 PM Ronald Klop wrote:
>
>
> Van: FreeBSD User
> Datum: 13 januari 2024 19:34
> Aan: FreeBSD CURRENT
> Onderwerp: NFSv4 crash of CURRENT
>
> Hello,
>
> running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a:
> Sat Jan 13 18:08:32
> CET 2024
Van: FreeBSD User
Datum: 13 januari 2024 19:34
Aan: FreeBSD CURRENT
Onderwerp: NFSv4 crash of CURRENT
Hello,
running CURRENT client (FreeBSD 15.0-CURRENT #4 main-n267556-69748e62e82a: Sat
Jan 13 18:08:32
CET 2024 amd64). One NFSv4 server is same OS revision as the mentioned client,
other
On Sat, Jan 13, 2024 at 05:03:41PM +, void wrote:
>
> I've used this method with 13-stable and 14-stable, but wondered if
> maybe it was depreciated in 15-current. The showstopper is the error marked
> [2] which is within seconds followed by [3]. If it was just [1]
> then I could work around
On Sat, Jan 13, 2024 at 08:24:13AM -0800, bob prohaska wrote:
On Sat, Jan 13, 2024 at 03:26:19PM +, void wrote:
Hi,
I'm trying to use bsdinstall on
FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240111-a61d2c7fbd3c-267507.img
to install to usb3-connected HD, using the 'expert mode' for UFS,
On Sat, Jan 13, 2024 at 03:26:19PM +, void wrote:
> Hi,
>
> I'm trying to use bsdinstall on
> FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240111-a61d2c7fbd3c-267507.img
> to install to usb3-connected HD, using the 'expert mode' for UFS,
> after having initially booted from mmcsd.
>
> The goal
Hi,
I'm trying to use bsdinstall on
FreeBSD-15.0-CURRENT-arm64-aarch64-RPI-20240111-a61d2c7fbd3c-267507.img
to install to usb3-connected HD, using the 'expert mode' for UFS,
after having initially booted from mmcsd.
The goal is to boot to usb3 with freebsd on UFS filesystem, and to have
that
Ronald Klop:
> On 1/11/24 03:21, Lexi Winter wrote:
> > i'm building packages with poudriere on a system with 32GB memory, with
> > tmpfs and md disabled in poudriere (so it's using ZFS only) and with the
> > ZFS ARC limited to 8GB.
> My first guess would be that you are using a tmpfs tmp dir
On Jan 12, 2024, at 09:57, Doug Rabson wrote:
> On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote:
> ram_attach is based on regions_to_avail but that is a problem for
> its later bus_alloc_resource use --and that can lead to:
>
> panic("ram_attach: resource %d failed to attach", rid);
>
>
On Fri, Jan 12, 2024 at 6:15 PM Dag-Erling Smørgrav wrote:
> Tomek CEDRO writes:
> > I am reading this interesting discussion and please verify my general
> > understanding:
> > 1. There is a request for change in core OS / FS mechanism of file
> > access time (atime) because of problem with
On Sat, 30 Sept 2023 at 08:47, Mark Millard wrote:
> ram_attach is based on regions_to_avail but that is a problem for
> its later bus_alloc_resource use --and that can lead to:
>
> panic("ram_attach: resource %d failed to attach", rid);
>
> Unfortunately, the known example is use of EDK2 on
Tomek CEDRO writes:
> I am reading this interesting discussion and please verify my general
> understanding:
>
> 1. There is a request for change in core OS / FS mechanism of file
> access time (atime) because of problem with mailing application?
The atime mechanism is considered harmful by many
Am 2024-01-11 18:15, schrieb Rodney W. Grimes:
Am 2024-01-10 22:49, schrieb Mark Millard:
> I never use atime, always noatime, for UFS. That said, I'd never
> propose
> changing the long standing defaults for commands and calls. I'd avoid:
[good points I fully agree on]
There's one
Rodney W. Grimes wrote on
Date: Thu, 11 Jan 2024 17:15:19 UTC :
> > Am 2024-01-10 22:49, schrieb Mark Millard:
> >
> > > I never use atime, always noatime, for UFS. That said, I'd never
> > > propose
> > > changing the long standing defaults for commands and calls. I'd avoid:
> >
> > [good
On Thu, Jan 11, 2024 at 6:59 AM Mike Karels wrote:
> On 11 Jan 2024, at 7:30, Miroslav Lachman wrote:
>
> > On 11/01/2024 09:54, Tomoaki AOKI wrote:
> >> On Thu, 11 Jan 2024 08:36:24 +0100
> >> Alexander Leidinger wrote:
> >
> > [..]
> >
> >>> There's one possibility which nobody talked about
Olivier Certner wrote:
> Both the examples above prompt some straight objections on the current
> usefulness of "atime". First, unless you've disabled building the locate
> database in cron (enabled by default, on a weekly basis), access times on
> directories lose most of their usefulness.
> Am 2024-01-10 22:49, schrieb Mark Millard:
>
> > I never use atime, always noatime, for UFS. That said, I'd never
> > propose
> > changing the long standing defaults for commands and calls. I'd avoid:
>
> [good points I fully agree on]
>
> There's one possibility which nobody talked about
On 11 Jan 2024, at 7:30, Miroslav Lachman wrote:
> On 11/01/2024 09:54, Tomoaki AOKI wrote:
>> On Thu, 11 Jan 2024 08:36:24 +0100
>> Alexander Leidinger wrote:
>
> [..]
>
>>> There's one possibility which nobody talked about yet... changing the
>>> default to noatime at install time in fstab /
On 11/01/2024 09:54, Tomoaki AOKI wrote:
On Thu, 11 Jan 2024 08:36:24 +0100
Alexander Leidinger wrote:
[..]
There's one possibility which nobody talked about yet... changing the
default to noatime at install time in fstab / zfs set.
I fully agree to not violate POLA by changing the default
On Thu, Jan 11, 2024 at 02:21:19AM +, Lexi Winter wrote:
hi list,
i'm having a recurring problem with poudriere that i hope someone might
have an idea about.
i'm building packages with poudriere on a system with 32GB memory, with
tmpfs and md disabled in poudriere (so it's using ZFS only)
On 1/11/24 03:21, Lexi Winter wrote:
hi list,
i'm having a recurring problem with poudriere that i hope someone might
have an idea about.
i'm building packages with poudriere on a system with 32GB memory, with
tmpfs and md disabled in poudriere (so it's using ZFS only) and with the
ZFS ARC
On Thu, 11 Jan 2024 02:21:19 +
Lexi Winter wrote:
> hi list,
>
> i'm having a recurring problem with poudriere that i hope someone might
> have an idea about.
>
> i'm building packages with poudriere on a system with 32GB memory, with
> tmpfs and md disabled in poudriere (so it's using ZFS
On Thu, 11 Jan 2024 08:36:24 +0100
Alexander Leidinger wrote:
> Am 2024-01-10 22:49, schrieb Mark Millard:
>
> > I never use atime, always noatime, for UFS. That said, I'd never
> > propose
> > changing the long standing defaults for commands and calls. I'd avoid:
>
> [good points I fully
Am 2024-01-10 22:49, schrieb Mark Millard:
I never use atime, always noatime, for UFS. That said, I'd never
propose
changing the long standing defaults for commands and calls. I'd avoid:
[good points I fully agree on]
There's one possibility which nobody talked about yet... changing the
> On Jan 9, 2024, at 6:24 PM, void wrote:
>
> On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
>>
>> Was the kernel/utility built with IPv6? If not, that’s a general bug which
>> should be filed (which can be easily checked/avoided using the FEATURES(9)
>> subsystem)…
>>
hi list,
i'm having a recurring problem with poudriere that i hope someone might
have an idea about.
i'm building packages with poudriere on a system with 32GB memory, with
tmpfs and md disabled in poudriere (so it's using ZFS only) and with the
ZFS ARC limited to 8GB.
running poudriere
On Thu, Jan 11, 2024 at 1:50 AM Rodney W. Grimes wrote:
> > Olivier Certner wrote on
> > Date: Wed, 10 Jan 2024 10:01:48 UTC :
> > > What I'm saying is that, based on others' input so far, my own (long,
> > > even if not as long as yours) experience and some late reflection, is
> > > that
On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote:
> Please see/test: https://github.com/openzfs/zfs/pull/15732 .
Looks like that has landed in current:
commit f552d7adebb13e24f65276a6c4822bffeeac3993
Merge: 13720136fbf a382e21194c
Author: Martin Matuska
> Olivier Certner wrote on
> Date: Wed, 10 Jan 2024 10:01:48 UTC :
>
> > What I'm saying is that, based on others' input so far, my own (long, even
> > if not as long as yours) experience and some late reflection, is that
> > "noatime" should be the default (everywhere, all mounts and all
Olivier Certner wrote on
Date: Wed, 10 Jan 2024 10:01:48 UTC :
> What I'm saying is that, based on others' input so far, my own (long, even if
> not as long as yours) experience and some late reflection, is that "noatime"
> should be the default (everywhere, all mounts and all FSes), and that
On Wed, Jan 10, 2024 at 12:44 PM Lyndon Nerenberg (VE7TFX/VE6BBM)
wrote:
>
> Olivier Certner writes:
>
> > I've never found any compelling reason in most uses to enable "atime",
> > except
> > perhaps local mail but as addressed in other answers it is a relic of the
> > pa
> > st mostly
> On Jan 9, 2024, at 7:17 AM, void wrote:
>
> On Tue, Jan 09, 2024 at 12:24:40PM +, void wrote:
>> On Tue, Jan 09, 2024 at 10:24:53AM +, void wrote:
>>> On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
Was the kernel/utility built with IPv6? If not, that’s a
Olivier Certner writes:
> I've never found any compelling reason in most uses to enable "atime", except
> perhaps local mail but as addressed in other answers it is a relic of the pa
> st mostly irrelevant today. And its drawbacks are well known and can be seri
> ous.
When UNIX ran on PDP-11s
On Wed, Jan 10, 2024 at 6:36 PM Olivier Certner wrote:
> Both the examples above prompt some straight objections on the current
> usefulness of "atime". First, unless you've disabled building the locate
> database in cron (enabled by default, on a weekly basis), access times on
> directories
Hallo
Olivier Certner wrote in
<2367131.USjQqFH40Q@ravel>:
|> I would not exactly call this a gimmick.
|
|I wish I hadn't used that term since it attracts too much attention \
|on itself, making people forget it was part of a sentence that was \
|quite balanced and seemingly altering their
> > Again, I'm not opposing anyone from working on "relatime" if they
> > personally have a strong need and motivation. I'm not even asking for
> > removing the "atime" functionality, which can have its uses.
> >
>
> Yea, relatime has some interesting use cases: Is this binary / library in
> use
On Wed, Jan 10, 2024 at 3:01 AM Olivier Certner wrote:
> Hi Warner,
>
> > It has also been used for almost as long to see if log files have changed
> > if you set your MAIL variable to that. So not just for email...
>
> This seems to be an example in point of a "niche" scenario, both in terms
>
> This is an interesting type of argument.
Except this is not an argument to the main discussion, as apparently you
haven't understood?
This kind of response is disingenuous. Either you said too much, or you didn't
say enough.
--
Olivier Certner
signature.asc
Description: This is a
Van: Olivier Certner
Datum: woensdag, 10 januari 2024 11:01
Aan: Warner Losh
CC: freebsd-current@freebsd.org
Onderwerp: Re: noatime on ufs2
Hi Warner,
> It has also been used for almost as long to see if log files have changed
> if you set your MAIL variable to that. So not just for email...
On 1/9/24 22:09, Gleb Smirnoff wrote:
On Mon, Jan 08, 2024 at 10:40:52AM +0100, Jakob Alvermark wrote:
J> > > --- trap 0xc, rip = 0x...f80d97b78, rsp = 0x...
J> > > nl_send_one() at nl_send_one+0x18/frame 0xf
J> > > nl_send_group() at nl_send_group+0x1bc/frame
Hi Warner,
> It has also been used for almost as long to see if log files have changed
> if you set your MAIL variable to that. So not just for email...
This seems to be an example in point of a "niche" scenario, both in terms of
spread of usage (even then) and the fact that it's easy to get
Hi,
> I would not exactly call this a gimmick.
I wish I hadn't used that term since it attracts too much attention on itself,
making people forget it was part of a sentence that was quite balanced and
seemingly altering their judgement.
I think you're confusing the need and the mechanism (or
Am 09.01.24 um 21:40 schrieb Gleb Smirnoff:
Rainer,
On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote:
R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very
R> recent commit. The build and install went fine. After booting with new
R> base, I got a page
On Mon, Jan 08, 2024 at 10:40:52AM +0100, Jakob Alvermark wrote:
J> > > --- trap 0xc, rip = 0x...f80d97b78, rsp = 0x...
J> > > nl_send_one() at nl_send_one+0x18/frame 0xf
J> > > nl_send_group() at nl_send_group+0x1bc/frame 0xf...
J> > > _nlmsg_flush() at _nlmsg_flush+0x37/frame 0xf...
On Tue, Jan 9, 2024, 11:11 AM Steffen Nurpmeso wrote:
> rob...@rrbrussell.com wrote in
> <5f370bce-bcdb-47ea-aaa7-551ee092a...@app.fastmail.com>:
> |On Tue, Jan 9, 2024, at 05:13, void wrote:
> |> On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i
> |>> So, to me, at this
Rainer,
On Tue, Jan 09, 2024 at 09:23:54PM +0100, Rainer Hurling wrote:
R> I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a very
R> recent commit. The build and install went fine. After booting with new
R> base, I got a page fault with the following error:
Sorry for that,
I tried to update my 15.0-CURRENT box from n267335-499e84e16f56 to a
very recent commit. The build and install went fine. After booting with
new base, I got a page fault with the following error:
Kernel page fault with the following non-sleepable locks held:
shared rm netlink lock (netlink
On Tue, Jan 9, 2024 at 2:47 AM void wrote:
> I was concerned that email might not work right without atime.
> So far, it seems to be working OK.
>
Depending on how you define "correct". Deliveries won't be affected by
atime setting in any way; telling if you have new mail _may_ be affected,
On Tue, Jan 09, 2024 at 12:24:40PM +, void wrote:
On Tue, Jan 09, 2024 at 10:24:53AM +, void wrote:
On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
Was the kernel/utility built with IPv6? If not, that’s a general
bug which should be filed (which can be easily
On Tue, Jan 09, 2024 at 10:24:53AM +, void wrote:
On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
Was the kernel/utility built with IPv6? If not, that’s a general bug
which should be filed (which can be easily checked/avoided using the
FEATURES(9) subsystem)…
Cheers!
-Enji
On Tue, Jan 9, 2024, at 04:47, void wrote:
> On Mon, Jan 08, 2024 at 12:41:02PM -0800, Xin LI wrote:
>>On Sun, Jan 7, 2024 at 5:27 AM void wrote:
>>
>>> Hi,
>>>
>>> Does /var/mail still need atime?
>>>
>>> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
>>> rpi4/8BG which
On Tue, Jan 9, 2024, at 05:13, void wrote:
> On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i
>
>> So, to me, at this point, it still sounds more than a gimmick
>> than something really useful. If someone has a precise use case
>> for it and motivation, than of course please go
On Tue, Jan 09, 2024 at 09:47:59AM +0100, Olivier Certner wrote:i
So, to me, at this point, it still sounds more than a gimmick
than something really useful. If someone has a precise use case
for it and motivation, than of course please go ahead.
The only use-cases I [1] can think of are
On Mon, Jan 08, 2024 at 12:41:02PM -0800, Xin LI wrote:
On Sun, Jan 7, 2024 at 5:27 AM void wrote:
Hi,
Does /var/mail still need atime?
I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
rpi4/8BG which installs into one / . If it's mounted with noatime,
will it have
On Mon, Jan 08, 2024 at 01:07:30PM -0800, Enji Cooper wrote:
Was the kernel/utility built with IPv6? If not, that’s a general
bug which should be filed (which can be easily checked/avoided
using the FEATURES(9) subsystem)…
Cheers!
-Enji
world/kernel was built with WITHOUT_INET6= in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197921
Zhenlei Huang changed:
What|Removed |Added
CC||z...@freebsd.org
--- Comment #3
On Mon, Jan 8, 2024, at 14:41, Xin LI wrote:
>
>
> On Sun, Jan 7, 2024 at 5:27 AM void wrote:
>> Hi,
>>
>> Does /var/mail still need atime?
>>
>> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
>> rpi4/8BG which installs into one / . If it's mounted with noatime,
>> will it
On Mon, 8 Jan 2024 14:12:06 -0700
Warner Losh wrote:
> On Mon, Jan 8, 2024 at 1:41 PM Xin LI wrote:
>
> >
> >
> > On Sun, Jan 7, 2024 at 5:27 AM void wrote:
> >
> >> Hi,
> >>
> >> Does /var/mail still need atime?
> >>
> >> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
> >>
On Mon, Jan 8, 2024 at 1:41 PM Xin LI wrote:
>
>
> On Sun, Jan 7, 2024 at 5:27 AM void wrote:
>
>> Hi,
>>
>> Does /var/mail still need atime?
>>
>> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
>> rpi4/8BG which installs into one / . If it's mounted with noatime,
>> will it
> On Jan 7, 2024, at 6:29 AM, void wrote:
>
> Hi,
>
> on a rpi4/8GB, my rc.conf looks like so. It's an ipv4-only system on a LAN
> not directly connected to the internet
>
> hostname="generic.home.arpa"
> ifconfig_genet0="inet 192.168.1.199 netmask 255.255.255.0"
>
On Sun, Jan 7, 2024 at 5:27 AM void wrote:
> Hi,
>
> Does /var/mail still need atime?
>
> I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
> rpi4/8BG which installs into one / . If it's mounted with noatime,
> will it have consequences for /var/mail ?
It doesn't matter if you
David Chisnall wrote on
Date: Mon, 08 Jan 2024 17:12:06 UTC :
> On 8 Jan 2024, at 16:30, Tomoaki AOKI wrote:
> >
> > So it should be in ports to adapt for latest products more quickly than
> > in base, I think.
>
> We push out a new release of each of the -STABLE branches every 6 months
On Mon, Jan 8, 2024 at 10:37 AM Warner Losh wrote:
>
>
> On Mon, Jan 8, 2024 at 9:35 AM Kyle Evans wrote:
>
>> On 1/8/24 10:30, Tomoaki AOKI wrote:
>> > On Mon, 8 Jan 2024 08:18:38 -0700
>> > Warner Losh wrote:
>> >
>> >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber
>> >> wrote:
>> >>
>>
On Mon, Jan 8, 2024 at 10:30 AM Xin LI wrote:
> On Mon, Jan 8, 2024 at 7:19 AM Warner Losh wrote:
>
>> On Mon, Jan 8, 2024, 7:55 AM Christian Weisgerber
>> wrote:
>>
>>> We have FIDO/U2F support for SSH in base.
>>>
>>> We also have a group "u2f", 116, in the default /etc/group file.
>>>
>>>
On Mon, Jan 8, 2024 at 9:35 AM Kyle Evans wrote:
> On 1/8/24 10:30, Tomoaki AOKI wrote:
> > On Mon, 8 Jan 2024 08:18:38 -0700
> > Warner Losh wrote:
> >
> >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber
> >> wrote:
> >>
> >>> We have FIDO/U2F support for SSH in base.
> >>>
> >>> We also
On Mon, 8 Jan 2024 10:35:03 -0600
Kyle Evans wrote:
> On 1/8/24 10:30, Tomoaki AOKI wrote:
> > On Mon, 8 Jan 2024 08:18:38 -0700
> > Warner Losh wrote:
> >
> >> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber
> >> wrote:
> >>
> >>> We have FIDO/U2F support for SSH in base.
> >>>
> >>> We
On Mon, Jan 8, 2024 at 7:19 AM Warner Losh wrote:
>
>
> On Mon, Jan 8, 2024, 7:55 AM Christian Weisgerber
> wrote:
>
>> We have FIDO/U2F support for SSH in base.
>>
>> We also have a group "u2f", 116, in the default /etc/group file.
>>
>> Why do we keep the devd configuration (to chgrp the
On 8 Jan 2024, at 16:30, Tomoaki AOKI wrote:
>
> So it should be in ports to adapt for latest products more quickly than
> in base, I think.
We push out a new release of each of the -STABLE branches every 6 months and
can do ENs if a product ships and becomes popular in under six months. This
On 1/8/24 10:30, Tomoaki AOKI wrote:
On Mon, 8 Jan 2024 08:18:38 -0700
Warner Losh wrote:
On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber
wrote:
We have FIDO/U2F support for SSH in base.
We also have a group "u2f", 116, in the default /etc/group file.
Why do we keep the devd
On Mon, 8 Jan 2024 08:18:38 -0700
Warner Losh wrote:
> On Mon, Jan 8, 2024, 7:55〓AM Christian Weisgerber
> wrote:
>
> > We have FIDO/U2F support for SSH in base.
> >
> > We also have a group "u2f", 116, in the default /etc/group file.
> >
> > Why do we keep the devd configuration (to chgrp the
On Mon, Jan 8, 2024, 7:55 AM Christian Weisgerber
wrote:
> We have FIDO/U2F support for SSH in base.
>
> We also have a group "u2f", 116, in the default /etc/group file.
>
> Why do we keep the devd configuration (to chgrp the device nodes)
> in a port, security/u2f-devd? Can't we just add this
We have FIDO/U2F support for SSH in base.
We also have a group "u2f", 116, in the default /etc/group file.
Why do we keep the devd configuration (to chgrp the device nodes)
in a port, security/u2f-devd? Can't we just add this to base, too?
It's just another devd configuration file.
--
On 1/6/24 23:34, Poul-Henning Kamp wrote:
Addendum:
I have only installed the new kernel, userland is still from dec18.
(Even if that is the cause, we should not panic on bad syscall args.)
Poul-Henning Kamp writes:
With fresh current:
commit
> On Jan 8, 2024, at 1:50 AM, FreeBSD User wrote:
>
> Hello,
>
> I've got a problem with recent CURRENT, running vnet JAILs.
> FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET
> 2024 amd64
>
> Main Host has IPFW configured and is open for services like OpenLDAP on
Warner Losh wrote:
> See sys/conf/newvers.sh for the 'n' value we use in uname strings. It's a
> linear count of commits on the first-parent branch back to the start of the
> repo.
>
> Also, the dates usualy are first order correct and i use them for the stats
> i run. Though I've also just
Hello,
I've got a problem with recent CURRENT, running vnet JAILs.
FreeBSD 15.0-CURRENT #28 main-n267432-e5b33e6eef7: Sun Jan 7 13:18:15 CET 2024
amd64
Main Host has IPFW configured and is open for services like OpenLDAP on UDP/TCP
and ICMP
(ipfw is configured via rc.conf in this case, host
Hi,
on a rpi4/8GB, my rc.conf looks like so. It's an ipv4-only system
on a LAN not directly connected to the internet
hostname="generic.home.arpa"
ifconfig_genet0="inet 192.168.1.199 netmask 255.255.255.0"
defaultrouter="192.168.1.1"
sshd_enable="YES"
sendmail_enable="NONE"
Hi,
Does /var/mail still need atime?
I've installed a ufs2-based -current main-n267425-aa1223ac3afc on
rpi4/8BG which installs into one / . If it's mounted with noatime,
will it have consequences for /var/mail ?
--
Addendum:
I have only installed the new kernel, userland is still from dec18.
(Even if that is the cause, we should not panic on bad syscall args.)
Poul-Henning Kamp writes:
> With fresh current:
>
> commit e179d9739b1438ae9acb958f80a983eff7e3dce9
> Author: Michael Tuexen
>
With fresh current:
commit e179d9739b1438ae9acb958f80a983eff7e3dce9
Author: Michael Tuexen
Date: Sat Jan 6 21:31:46 2024 +0100
tcpsso: support TIME_WAIT state
I get an insta-panic as soon as any network interface comes up:
--- trap 0xc, rip =
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197921
Mark Linimon changed:
What|Removed |Added
Flags|mfc-stable12?, |
|mfc-stable11?
> On Jan 4, 2024, at 21:39, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>>
>>> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
>>>
>>> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
On Fri, 17 Nov 2023 14:31:02
On Thu, 4 Jan 2024 12:49:03 -0700
Warner Losh wrote:
> On Thu, Jan 4, 2024, 12:14 PM Jamie Landeg-Jones wrote:
>
> > Tomoaki AOKI wrote:
> >
> > >
> > > Or create database (key-value store would be sufficient) storing commit
> > > order (like r* of svn) and commit hash.
> > > I'm still not
On Thu, 04 Jan 2024 21:22:22 +0100, tue...@freebsd.org wrote:
>
> > On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
> >
> > On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
> >>
> >> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >>>
> >>> Hi,
> >>>
> >>>
> On Jan 4, 2024, at 18:52, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
>>
>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>>
>>> Hi,
>>>
>>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> On Nov
On Thu, Jan 4, 2024, 12:14 PM Jamie Landeg-Jones wrote:
> Tomoaki AOKI wrote:
>
> >
> > Or create database (key-value store would be sufficient) storing commit
> > order (like r* of svn) and commit hash.
> > I'm still not certain whether commit order or commit hash should be the
> > "key".
Tomoaki AOKI wrote:
>
> Or create database (key-value store would be sufficient) storing commit
> order (like r* of svn) and commit hash.
> I'm still not certain whether commit order or commit hash should be the
> "key". Possibly store hash as the key fisrt and store assigned MONOTONIC
> order
Brooks Davis wrote:
> The dates are just strings in the commits. There's no central commit
> queue to rewrite the commits with new dates. The project could someday
> implment such a thing, but we deemed anything like that out of scope for
> the first phase of the migration.
>
> I do fine it
On Thu, 04 Jan 2024 11:40:35 +0100, "Herbert J. Skuhra" wrote:
>
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >
> > Hi,
> >
> > On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> > >
> > > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
> > > >
> > >
> On Jan 4, 2024, at 15:22, Herbert J. Skuhra wrote:
>
> On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
>>
>>> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
>>>
>>> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
Hi,
On Fri, 17 Nov
> On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
>
> On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>>
>> Hi,
>>
>> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
>>>
On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
On Thu, 16 Nov 2023
John,
On 04.01.2024 09:20, John Kennedy wrote:
On Tue, Jan 02, 2024 at 08:02:04PM -0800, John Kennedy wrote:
On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote:
On 01.01.2024 08:59, John Kennedy wrote:
...
My poudriere build did eventually fail as well:
...
On Tue, Jan 02, 2024 at 08:02:04PM -0800, John Kennedy wrote:
> On Tue, Jan 02, 2024 at 05:51:32PM -0500, Alexander Motin wrote:
> > On 01.01.2024 08:59, John Kennedy wrote:
> > > ...
> > >My poudriere build did eventually fail as well:
> > > ...
> > > [05:40:24] [01] [00:17:20] Finished
On Thu, 04 Jan 2024 14:57:59 +0100, tue...@fh-muenster.de wrote:
>
> > On Jan 4, 2024, at 11:40, Herbert J. Skuhra wrote:
> >
> > On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
> >>
> >> Hi,
> >>
> >> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> >>>
>
On Fri, 17 Nov 2023 14:31:02 +0100, "Herbert J. Skuhra" wrote:
>
> Hi,
>
> On Fri, 17 Nov 2023 00:15:13 +0100, tue...@freebsd.org wrote:
> >
> > > On Nov 16, 2023, at 20:06, Herbert J. Skuhra wrote:
> > >
> > > On Thu, 16 Nov 2023 19:07:29 +0100, Olivier Cochard-Labbé wrote:
> > >>
> > >> On
On Wed, 3 Jan 2024 23:32:27 +
Brooks Davis wrote:
> On Wed, Jan 03, 2024 at 03:09:15PM -0800, Bakul Shah wrote:
> > On Jan 3, 2024, at 11:22???AM, Brooks Davis wrote:
> > >
> > > Nothing about dates is centralized in git, but some server side checks
> > > could be implemented on
On Wed, Jan 03, 2024 at 03:09:15PM -0800, Bakul Shah wrote:
> On Jan 3, 2024, at 11:22???AM, Brooks Davis wrote:
> >
> > Nothing about dates is centralized in git, but some server side checks
> > could be implemented on CommitDate. IMO we should require that
> > CommitDate be >= the previous
901 - 1000 of 138514 matches
Mail list logo
