On Tue, May 14, 2024 at 9:09 AM Ryan Libby wrote:
>
> On Tue, May 14, 2024 at 1:14 AM Alexander Leidinger
> wrote:
> >
> > Am 2024-05-14 03:54, schrieb Ryan Libby:
> > > That was a long winded way of saying: the "UMA bucket" axis is
> > > actually "vm phys free list order".
> > >
> > > That
On Tue, May 14, 2024 at 1:14 AM Alexander Leidinger
wrote:
>
> Am 2024-05-14 03:54, schrieb Ryan Libby:
> > That was a long winded way of saying: the "UMA bucket" axis is
> > actually "vm phys free list order".
> >
> > That said, I find that dimension confusing because in fact there's
> > just
Am 2024-05-14 03:54, schrieb Ryan Libby:
That was a long winded way of saying: the "UMA bucket" axis is
actually "vm phys free list order".
That said, I find that dimension confusing because in fact there's
just one piece of information there, the average size of a free list
entry, and it
.
> >> https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/
> >>
> >> My goal was not comparing a specific change on a given benchmark, but
> >> to "have something which visualizes memory fragmentation". As part of
> &g
Am 2024-05-08 18:45, schrieb Bojan Novković:
Hi,
On 5/7/24 14:02, Alexander Leidinger wrote:
Hi,
I created some graphs of the memory fragmentation.
https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/
My goal was not comparing a specific change on a given
t;
>
> https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/
>
> My goal was not comparing a specific change on a given benchmark, but to
> "have something which visualizes memory fragmentation". As part of that,
> Bojans commit
>
Hi,
On 5/7/24 14:02, Alexander Leidinger wrote:
Hi,
I created some graphs of the memory fragmentation.
https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/
My goal was not comparing a specific change on a given benchmark, but
to "have something
Hi,
I created some graphs of the memory fragmentation.
https://www.leidinger.net/blog/2024/05/07/plotting-the-freebsd-memory-fragmentation/
My goal was not comparing a specific change on a given benchmark, but to
"have something which visualizes memory fragmentation"
FreeBSD Status Report First Quarter 2024
Here is the first 2024 status report, with 21 entries.
The New Year brings us many new interesting projects, such as the new libsys
that separates system calls from libc and libpthread or work on a graphical
installer for FreeBSD, which will help making
In my recent FreeBSD update activity, the following files blocked the "delete
old things" activity from from deleting the related old 17/ subdirectory tree
for clang:
-r--r--r-- 1 root wheel - 8378 Mar 2 19:39:47 2024
/usr/obj/BUILDs/main-CA76-nodbg-clang/usr/main-src/arm64.aarch
On Wed, Mar 6, 2024 at 10:56 AM Matthew L. Dailey
wrote:
>
> Posting a few updates on this issue.
>
> I was able to induce a panic on a CURRENT kernel (20240215), built with
> GENERIC-KASAN and running kern.kstack_pages=6 (default) after ~189
> hours. The panic message and backtrace are below -
Posting a few updates on this issue.
I was able to induce a panic on a CURRENT kernel (20240215), built with
GENERIC-KASAN and running kern.kstack_pages=6 (default) after ~189
hours. The panic message and backtrace are below - please reach out
directly if you'd like to have a look at the core.
points for snapshot generation.
>>
>> How about also the likes of:
>>
>> https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/
>>
>> for pkgbase (various "aarch64" replacements too)?
>
> yes, great idea, base_stabweek or similar is something I'd vote for.
How about also the likes of:
>
> https://pkg.freebsd.org/FreeBSD:15:aarch64/stabweek/
>
> for pkgbase (various "aarch64" replacements too)?
yes, great idea, base_stabweek or similar is something I'd vote for.
signature.asc
Description: PGP signature
Gleb Smirnoff wrote on
Date: Sat, 24 Feb 2024 04:32:52 UTC :
> More seriously speaking, I
> actually hope that in some future snapshots.FreeBSD.org will start using these
> points for snapshot generation.
How about also the likes of:
https://pkg.freebsd.org/FreeBSD:15:aarch64
Hi FreeBSD CURRENT users,
back in November I came up with a proposal of providing some stabilization
cadence to development of the main branch, also known as FreeBSD CURRENT. Here
is a video with the initial proposal and following discussion at VendorBSD
Conference (18 minutes):
https
On Tue, Feb 20, 2024 at 11:21 AM Matthew L. Dailey
wrote:
>
> Hi all,
>
> I induced a panic on my CURRENT (20240215-d79b6b8ec267-268300) VM after
> about 24 hours. This is the one without any debugging, so it only
> confirms the fact that the panics we've been experiencing still exist in
>
Hi all,
I induced a panic on my CURRENT (20240215-d79b6b8ec267-268300) VM after
about 24 hours. This is the one without any debugging, so it only
confirms the fact that the panics we've been experiencing still exist in
CURRENT. There was some disk issue that prevented the dump, so all I
have
On Mon, Feb 19, 2024 at 7:44 AM Matthew L. Dailey
wrote:
>
> Hi all,
>
> So I finally induced a panic on a "pure" ufs system - root and exported
> filesystem were both ufs. So, I think this definitively rules out zfs as
> a source of the issue.
>
> This panic was on 14.0p5 without debugging
Hi all,
So I finally induced a panic on a "pure" ufs system - root and exported
filesystem were both ufs. So, I think this definitively rules out zfs as
a source of the issue.
This panic was on 14.0p5 without debugging options, so the core may not
be helpful. The panic and backtrace are below
Hi all,
Before the week was out, I wanted to provide an update on this issue.
Last weekend, I installed two VMs with CURRENT
(20240208-82bebc793658-268105) - one on zfs and one on ufs - and built a
kernel with this config file:
include GENERIC
ident THAYER-FULLDEBUG
makeoptions DEBUG=-g
FreeBSD Status Report Fourth Quarter 2023
Here is the fourth 2023 status report, with 18 entries.
This is the last 2023 quarter. As you have probably noticed, this status report
comes later than usual and with fewer reports than the preceding quarter.
Indeed, please keep in mind that the last
I will do it as soon as I get all the necessary tools to turn on the
Raspberry Pi 4b. I was thinking that L4 worked like the old project
coLinux,where Linux ran as a list of processes under WIndows. In my sick
mind I'd thought that L4 allows FreeBSD to run as a list of processes with
the L4
On Feb 11, 2024, at 12:00, Mark Millard wrote:
> [Only replying to what I've subscribed to --and I dropped
> Warner as well.]
>
> On Feb 11, 2024, at 11:43, Mario Marietto wrote:
>
>> ok. But what does this mean ? That I can use whatever Linux distro I want ?
>>
[Only replying to what I've subscribed to --and I dropped
Warner as well.]
On Feb 11, 2024, at 11:43, Mario Marietto wrote:
> ok. But what does this mean ? That I can use whatever Linux distro I want ?
> Or even the FreeBSD world ?
Only to build L4Re.
The LR4e built will not conta
ok. But what does this mean ? That I can use whatever Linux distro I want ?
Or even the FreeBSD world ?
On Sun, Feb 11, 2024 at 7:59 PM Mark Millard wrote:
>
>
> On Feb 11, 2024, at 05:44, Mario Marietto wrote:
>
> > I'm trying to understand how to use the L4 Microker
On Feb 11, 2024, at 05:44, Mario Marietto wrote:
> I'm trying to understand how to use the L4 Microkernel with a FreeBSD
> userland. I've asked the same to a L4 developer,but he told me that he does
> not know FreeBSD,so I'm here to ask the same question. First of all
Hello to everyone.
I'm trying to understand how to use the L4 Microkernel with a FreeBSD
userland. I've asked the same to a L4 developer,but he told me that he does
not know FreeBSD,so I'm here to ask the same question. First of all I'm
sure that it can be done,because it is written clearly
On Fri, Feb 9, 2024 at 10:23 AM Matthew L. Dailey
wrote:
>
> I had my first kernel panic with a KASAN kernel after only 01:27. This
> first panic was a "double fault," which isn't anything we've seen
> previously - usually we've seen trap 9 or trap 12, but sometimes others.
> Based on the
t; >
> > A double fault is rather unexpected. I presume you're running
> > releng/14.0? Is it at all possible to test with FreeBSD-CURRENT?
>
> This is just 14.0-RELEASE, updated to p4. Haven't played with CURRENT
> before, but I'll give it a shot.
>
> >
>
t;v_mount)->nm_flag & NFSMNT_RDIRPLUS) != 0)
> + cache_purge(vp);
> +
> /*
> * Call ncl_bioread() to do the real work.
> */
> ... without it, I can panic.
This is not of interest to Matthew, since he is using Linux clients against a
Fr
ing,
>> but I don't have the expertise to know if this points to anything
>> specific. From the backtrace, it looks like this might have originated
>> in ipfw code.
>
> A double fault is rather unexpected. I presume you're running
> releng/14.0? Is it at all possible to test with F
the backtrace, it looks like this might have originated
> > in ipfw code.
>
> A double fault is rather unexpected. I presume you're running
> releng/14.0? Is it at all possible to test with FreeBSD-CURRENT?
>
> Did you add INVARIANTS etc. to the kernel configuration used here, o
sume you're running
releng/14.0? Is it at all possible to test with FreeBSD-CURRENT?
Did you add INVARIANTS etc. to the kernel configuration used here, or
just KASAN?
> Please let me know what other info I can provide or what I can do to dig
> deeper.
If you could repeat the test sever
I had my first kernel panic with a KASAN kernel after only 01:27. This
first panic was a "double fault," which isn't anything we've seen
previously - usually we've seen trap 9 or trap 12, but sometimes others.
Based on the backtrace, it definitely looks like KASAN caught something,
but I don't
ver side reading/writiing. It basically translates
>> > NFS RPCs to VOP calls on the underlying file system.
>> > As such, issues are usually either network fabric on one side
>> > (everything from cables to NIC drives and the TCP stack).
>> > Since you
> To be honest, NFS is pretty simple when it comes
> > to server side reading/writiing. It basically translates
> > NFS RPCs to VOP calls on the underlying file system.
> > As such, issues are usually either network fabric on one side
> > (everything from cables to N
e underlying file system.
> As such, issues are usually either network fabric on one side
> (everything from cables to NIC drives and the TCP stack).
> Since you are seeing this with assorted NICs and FreeBSD
> versions, I doubt it is network fabric related, but??
> This is why I'd su
On Fri, Jan 26, 2024, 7:32 PM Steve Kargl
wrote:
> I'm currently syncing src/lib/msun with my private libm
> repository where I do much of my hacking on libm issues.
> In looking at diffs, I see a few lingering RCS and
> $FreeBSD$ tags. For example, lib/msun/amd64/s_scalbnl.
Hi Steve,
On Fri, Jan 26, 2024 at 06:32:26PM -0800, Steve Kargl wrote:
> I'm currently syncing src/lib/msun with my private libm
> repository where I do much of my hacking on libm issues.
> In looking at diffs, I see a few lingering RCS and
> $FreeBSD$ tags. For example, li
I'm currently syncing src/lib/msun with my private libm
repository where I do much of my hacking on libm issues.
In looking at diffs, I see a few lingering RCS and
$FreeBSD$ tags. For example, lib/msun/amd64/s_scalbnl.S
contains
/* RCSID("$NetBSD: s_scalbnf.S,v 1.4 1999/01/02 05:15:40 kri
On Wed, Jan 17, 2024 at 3:54 PM Mario Marietto
wrote:
> Hello to everyone.
>
> I'm trying to copy the Chromebook's SNOW source files that have been included
> on the FreeBSD 11
> revision 269385 to the new FreeBSD 13 revision 373300. It has compiled
> correctly world,bu
Hello to everyone.
I'm trying to copy the Chromebook's SNOW source files that have been
included on the FreeBSD 11
revision 269385 to the new FreeBSD 13 revision 373300. It has compiled
correctly world,but when it
starts to compile the kernel,it gives a lot of "unknown option&qu
n 15, 2024 at 10:49 AM Mario Marietto
wrote:
> Hello.
>
> Do you have deleted forever the set of packages and ports for FreeBSD 11
> or you keep them stored in DVDs that I can buy or download for a small
> amount of money ? If yes,where ? To rebuild everything is out of my
> experti
Hello.
Do you have deleted forever the set of packages and ports for FreeBSD 11 or
you keep them stored in DVDs that I can buy or download for a small amount
of money ? If yes,where ? To rebuild everything is out of my expertise.
On Mon, Jan 15, 2024 at 7:15 PM David Chisnall wrote:
> On
’s one that’s 19 years old and has been largely dead
for several years.
> But let's change perspective for a moment,don't think about the ARM
> Chromebook. My question is : how to upgrade FreeBSD when it goes EOL.
Generally, run `freebsd-update`. This is a very different question from ‘
The ARM Chromebook is based on armv7,it is still recent. But let's change
perspective for a moment,don't think about the ARM Chromebook. My question
is : how to upgrade FreeBSD when it goes EOL. I ask this because there is a
huge difference here between FreeBSD and Linux. Today if you need to use
commit?id=9dfa2a54684978d1d6cef67bbf6242e825801f18
I have one of the "snow" Chromebooks. The warnings in the web page
https://wiki.freebsd.org/arm/Chromebook led me not to try FreeBSD.
None of the many bugs seemed likely to ever be fixed. I'm not using it
so I could try an experiment, but f
On Nov 29, 2023, at 12:21 PM, Manoel Games wrote:
>
> I am a new FreeBSD user, and I am using FreeBSD-CURRENT. How do I update the
> FreeBSD-CURRENT kernel, and is it done through pkg? I installed
> FreeBSD-CURRENT without src.
As a new user you should probably run a supported rel
I am a new FreeBSD user, and I am using FreeBSD-CURRENT. How do I update the
FreeBSD-CURRENT kernel, and is it done through pkg? I installed FreeBSD-CURRENT
without src.
In message <20231127172506.horde.iibmvttnl5om_j0h4cvd...@webmail.in-berlin.d
e>,
"Rolf M. Dietze" writes:
> Hi,
>
> might be that I am on the wrong list for this, since my Problem
> exists on 14.0Release.
>
> After an out of the box install of FreeBSD
be that I am on the wrong list for this, since my Problem
exists on 14.0Release.
After an out of the box install of FreeBSD 14.0 Release and following
https://forums.freebsd.org/threads/setting-up-common-desktop-environment-for-modern-use.69475/
I am stuck with CDE. CDE loads, dtlogin starts
s outlined in the link below, does work.
>
> Still, having an issue with dtspc upon startup, but CDE works fine
>
> /rmd
>
> Quoting "Rolf M. Dietze" :
>
> > Hi,
> >
> > might be that I am on the wrong list for this, since my Problem
> > exists
with dtspc upon startup, but CDE works fine
/rmd
Quoting "Rolf M. Dietze" :
Hi,
might be that I am on the wrong list for this, since my Problem
exists on 14.0Release.
After an out of the box install of FreeBSD 14.0 Release and following
https://forums.freebsd.org/threads/setti
e.
>
> After an out of the box install of FreeBSD 14.0 Release and following
>
> https://forums.freebsd.org/threads/setting-up-common-desktop-environment-for-modern-use.69475/
> I am stuck with CDE. CDE loads, dtlogin starts an presents the login
> or greeter window, but upon lo
Hi,
might be that I am on the wrong list for this, since my Problem
exists on 14.0Release.
After an out of the box install of FreeBSD 14.0 Release and following
https://forums.freebsd.org/threads/setting-up-common-desktop-environment-for-modern-use.69475/
I am stuck with CDE. CDE loads, dtlogin
Sat, Nov 25, 2023 at 4:41 AM Mario Marietto
> wrote:
>
>> Hello to everyone.
>>
>> we have just virtualized Debian 12 on our arm (32 bit) Chromebook. As
>> host / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It
>> works great. But our goa
On Sat, Nov 25, 2023 at 4:41 AM Mario Marietto
wrote:
> Hello to everyone.
>
> we have just virtualized Debian 12 on our arm (32 bit) Chromebook. As host
> / dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It works
> great. But our goal is different. We want to vir
Hello to everyone.
we have just virtualized Debian 12 on our arm (32 bit) Chromebook. As host
/ dom0 we have chosen Devuan 5,and for guest / domU,Debian 12. It works
great. But our goal is different. We want to virtualize FreeBSD as domU.
Can we have a working Xen PV network driver for a FreeBSD
3 151
% uname -a
FreeBSD mowa219-gjp4-8570p-freebsd 15.0-CURRENT FreeBSD 15.0-CURRENT
#3 main-n266317-f5b3e686292b-dirty: Thu Nov 9 12:49:29 GMT 2023
grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG
amd64
% grep -C 2 completed\ on /var/log/build
t; > >
> > > > > > Best regards,
> > > > > > Bapt
> > > > >
> > > > > freeradius looks like a TLS issue with openssl 3
> > > > >
> > > > > .
> > > > >
> > > > > gnu Radius was
is failing an so on?
> > > > >
> > > > > Best regards,
> > > > > Bapt
> > > >
> > > > freeradius looks like a TLS issue with openssl 3
> > > >
> > > > .
> > > >
> > > > gnu Ra
gt; > .
> > >
> > > gnu Radius was biuld by me and not a port.
> > >
> > > Trying to recode is a challenge.
> > >
> > > What is happening is that
> > >
> > > the so file is not being recognised so
> > > I ha
On Mon, Nov 06, 2023 at 09:04:14AM +0100, Baptiste Daroussin wrote:
> On Mon, Nov 06, 2023 at 12:50:43AM -0700, The Doctor wrote:
> > On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote:
> > > On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote:
> > > > On Sun, Nov 05, 2023
; freeradius looks like a TLS issue with openssl 3
> >
> > .
> >
> > gnu Radius was biuld by me and not a port.
> >
> > Trying to recode is a challenge.
> >
> > What is happening is that
> >
> > the so file is not being recognise
On Mon, Nov 06, 2023 at 12:50:43AM -0700, The Doctor wrote:
> On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote:
> > On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote:
> > > On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote:
> > > > On Fri, Nov 03, 2023 at
On Mon, Nov 06, 2023 at 08:43:05AM +0100, Baptiste Daroussin wrote:
> On Sun, Nov 05, 2023 at 12:11:06PM -0700, The Doctor wrote:
> > On Sun, Nov 05, 2023 at 10:32:44AM -0700, The Doctor wrote:
> > > On Fri, Nov 03, 2023 at 11:42:32PM +, Glen Barber wrote:
> > > > The fourth RC build of the
; o 14.0-RC4 aarch64 ROCK64
> > > o 14.0-RC4 aarch64 ROCKPRO64
> > > o 14.0-RC4 riscv64 GENERIC
> > > o 14.0-RC4 riscv64 GENERICSD
> > >
> > > Note regarding arm SD card images: For convenience for those without
> > > console access to the
> o 14.0-RC4 aarch64 RPI
> > o 14.0-RC4 aarch64 PINE64
> > o 14.0-RC4 aarch64 PINE64-LTS
> > o 14.0-RC4 aarch64 PINEBOOK
> > o 14.0-RC4 aarch64 ROCK64
> > o 14.0-RC4 aarch64 ROCKPRO64
> > o 14.0-RC4 riscv64 GENERIC
> > o 14.0-RC4 riscv64 GENERICSD
>
> o 14.0-RC4 aarch64 ROCK64
> o 14.0-RC4 aarch64 ROCKPRO64
> o 14.0-RC4 riscv64 GENERIC
> o 14.0-RC4 riscv64 GENERICSD
>
> Note regarding arm SD card images: For convenience for those without
> console access to the system, a freebsd user with a password of
> freebsd is availab
Steffen Nurpmeso wrote:
> You know the entire thread is moot as i think bapt@ has thrown
> away the BSD termcap years ago, if i recall correctly (i think
> i spoke up by then).
> I only answered because of the "great it is gone" thing.
Maybe I should have rephrased that as "it's great that we
Hello Thomas Dickey.
Thomas Dickey wrote in
:
|On Thu, Nov 02, 2023 at 06:58:55PM +0100, Steffen Nurpmeso wrote:
|> I do understand that a bit. Other than that plain termcap was so
|> small and i would assume essentially unchanged for decades, that
|> i do not. Termcap entries, yes. I
GENERICSD
Note regarding arm SD card images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access. Additionally,
the root user password is set to root. It is strongly recommended
to change the password
On Thu, Nov 02, 2023 at 06:58:55PM +0100, Steffen Nurpmeso wrote:
> I do understand that a bit. Other than that plain termcap was so
> small and i would assume essentially unchanged for decades, that
> i do not. Termcap entries, yes. I could imagine vt220, xterm,
> screen-256color, and take one
o do the same
job, which is annoying. (FreeBSD doesn't exist in a vacuum) As terminfo
exists, is supported, and has terminal entries that our termcap doesn't
have, it seems to be better to switch to that. I'm sure it would mean
less maintenance for the FreeBSD committers too.
If terminfo didn't exis
Baptiste Daroussin wrote:
> If you don't install (terminfo-db which nothing should pull in by default),
> then
> you are on the default behaviour which is termcap, this has been made like
> this
> on purpose, by default you have the behaviour you have always expected, and if
> you want another
d to start working, and so I doubted myself, but I must
> have messed up somewhere!
>
> What threw me about tcsh is it does mention terminfo in the man page and
> the source, so I wrongly assumed the problem wasn't there.
>
> Anyway, I'll raise it with the tcsh maintainers.
>
>
FreeBSD Status Report Third Quarter 2023
Here is the third 2023 status report, with 32 entries.
This is the summer quarter and thus it includes many interesting news from
Google Summer of Code. Of course, we also have our usual team reports and many
projects share with us their latest news. Much
, so I wrongly assumed the problem wasn't there.
Anyway, I'll raise it with the tcsh maintainers.
To the FreeBSD release folk, I think it's great that we're moving off termcap,
but is there a chance that base tcsh could be compiled with a private version
of the terminfo-less ncurses in time for 14
On Tue, Oct 31, 2023 at 10:59:48PM +, Jamie Landeg-Jones wrote:
> Jamie Landeg-Jones wrote:
>
> > switch to tcsh, and reinitialise terminal information:
> >
> > % setenv TERM dumb
> > % setenv TERM xterm
>
> % setenv TERM xterm-256color
>
> Apologies, it seems this doesn't affect plain
Jamie Landeg-Jones wrote:
> switch to tcsh, and reinitialise terminal information:
>
> % setenv TERM dumb
> % setenv TERM xterm
% setenv TERM xterm-256color
Apologies, it seems this doesn't affect plain "xterm", but it does at least
affect xterm-16color and xterm-256color.
Is this,
Hi!
The changes to FreeBSD base ncurses to use the terminfo db over termcap if it
exists have caused a few issues with tcsh, which doesn't seem to grok terminfo.
e.g. : install misc-terminfo
switch to tcsh, and reinitialise terminal information:
% setenv TERM dumb
% setenv TERM xterm
% echotc
> On Oct 29, 2023, at 1:22 AM, Warner Losh wrote:
>
>
>
> On Sat, Oct 28, 2023, 11:04 AM Zhenlei Huang <mailto:z...@freebsd.org>> wrote:
> Hi Warner,
>
> I see this from boot log of 14.0-RC3:
>
> > FreeBSD 14.0-RC3 #0 releng/14.0-n265368-c6cfd
On Sat, Oct 28, 2023, 11:04 AM Zhenlei Huang wrote:
> Hi Warner,
>
> I see this from boot log of 14.0-RC3:
>
> > FreeBSD 14.0-RC3 #0 releng/14.0-n265368-c6cfdc130554: Fri Oct 27
> 05:57:28 UTC 2023
> > ...
> > atrtc0: non-PNP ISA device will be removed from G
Hi Warner,
I see this from boot log of 14.0-RC3:
> FreeBSD 14.0-RC3 #0 releng/14.0-n265368-c6cfdc130554: Fri Oct 27 05:57:28 UTC
> 2023
> ...
> atrtc0: non-PNP ISA device will be removed from GENERIC in FreeBSD 14.
I guess atrtc(4) is still supported by FreeBSD 14.
So this shou
Please consider donating to help support my FreeBSD work:
https://www.gofundme.com/f/gjbbsd
https://paypal.me/gjbbsd
Love FreeBSD? Support this and future releases with a donation to
the FreeBSD Foundation! https://www.freebsdfoundation.org/donate/
GENERICSD
Note regarding arm SD card images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access. Additionally,
the root user password is set to root. It is strongly recommended
to change the password
On 16.10.2023 13.53, Ed Maste wrote:
On Sat, 7 Oct 2023 at 13:35, György Pásztor wrote:
Hi Glen,
The new betas broke the functionality to boot from ventoy.
Unfortunately the way Ventoy handles FreeBSD booting is somewhat
fragile and this sort of breakage is not surprising. I suspect
On 10/24/23 20:03, Rodney W. Grimes wrote:
On Mon, 23 Oct 2023 at 11:06, Rodney W. Grimes
wrote:
This is a regression of forms... I have been using ventoy to boot FreeBSD
since 12 or so and this is the first I have heard of a failure to boot
FreeBSD with Ventoy, so my ask is, what changed
> On Mon, 23 Oct 2023 at 11:06, Rodney W. Grimes
> wrote:
> >
> > This is a regression of forms... I have been using ventoy to boot FreeBSD
> > since 12 or so and this is the first I have heard of a failure to boot
> > FreeBSD with Ventoy, so my ask is, what
ventoy has only been working with freebsd since 12 or so, it was not
working before since I started using ventoy. Also ventoy won't boot the
new devuan release, for example. ventoy has to jump through hoops to get
some things to boot, so give it some time I guess.
On 10/23/23 11:06, Rodney W
On Mon, 23 Oct 2023 at 11:06, Rodney W. Grimes
wrote:
>
> This is a regression of forms... I have been using ventoy to boot FreeBSD
> since 12 or so and this is the first I have heard of a failure to boot
> FreeBSD with Ventoy, so my ask is, what changed in FreeBSD that broke
> On Mon, 16 Oct 2023 at 13:46, Gy?rgy P?sztor
> wrote:
> >
> >> I am interested in looking for a way to make Ventoy support more
> >> reliable, but that will not happen for 14.0.
> >
> > Is it depending on Ventoy?
>
> Yes, Ventoy needs to be u
On Mon, 16 Oct 2023 at 13:46, György Pásztor wrote:
>
>> I am interested in looking for a way to make Ventoy support more
>> reliable, but that will not happen for 14.0.
>
> Is it depending on Ventoy?
Yes, Ventoy needs to be updated for newer FreeBSD releases. For
GENERICSD
Note regarding arm SD card images: For convenience for those without
console access to the system, a freebsd user with a password of
freebsd is available by default for ssh(1) access. Additionally,
the root user password is set to root. It is strongly recommended
to change the password
On 2023-10-17 09:40:37, Kevin Bowling wrote:
The flash SLOG system took around 12 hours to complete freebsd-update
from 13.2 to 14.0-RC1. The system without the SLOG took nearly 24
hours. This was the result of ~50k patches, and ~10k files from
freebsd-update and a very pathological 'install
Kevin Bowling wrote on
Date: Tue, 17 Oct 2023 16:40:37 UTC :
> I have two systems with a zpool 2x2 mirror on 7.2k RPM disks. One
> system also has a flash SLOG.
>
> The flash SLOG system took around 12 hours to complete freebsd-update
> from 13.2 to 14.0-RC1. The system withou
Hi,
I have two systems with a zpool 2x2 mirror on 7.2k RPM disks. One
system also has a flash SLOG.
The flash SLOG system took around 12 hours to complete freebsd-update
from 13.2 to 14.0-RC1. The system without the SLOG took nearly 24
hours. This was the result of ~50k patches, and ~10k
On 10/16/23 9:54 AM, Ed Maste wrote:
On Thu, 12 Oct 2023 at 00:11, Cameron Katri wrote:
The FreeBSD-14.0-BETA5-arm64-aarch64-zfs.raw.xz (maybe others, I didn't
check) has a rc.conf with a ton of repeated lines. I tried looking at
why this would be, but the release scripts to create this image
On Thu, 12 Oct 2023 at 00:11, Cameron Katri wrote:
>
> The FreeBSD-14.0-BETA5-arm64-aarch64-zfs.raw.xz (maybe others, I didn't
> check) has a rc.conf with a ton of repeated lines. I tried looking at
> why this would be, but the release scripts to create this image went
> rig
1 - 100 of 7010 matches
Mail list logo
