Update to the Release Engineering Team Roster

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

FreeBSD community,

It is with a heavy heart that I have decided to resign my role as the
Release Engineering Team Lead.

Colin Percival will take over this role, and I will act as his Deputy
Lead unless and until he finds a more suitable person to fill this role.

Regardless, I do not have any immediate plans to resign from the RE Team
as a whole, and though Colin has proved during the 13.2-RELEASE cycle
that he is fully capable of overtaking this role, I will remain active
on the team and will be available to him to provide any guidance or
insights as needed.

I personally want to thank Colin for accepting this role change.  I have
worked with Colin for several years directly, and indirectly, much
longer than I can remember.

As I am sure many of you all are aware, Colin served the Project as the
Security Officer for several years, and authored important utilities
used by many within the community, such as portsnap and freebsd-update.

I have sent and received acknowledgement from the Core Team of this
decision to step aside, which was well received and no objection to me
selecting Colin to be my successor had been posed.

Colin, thank you, again, for overtaking this role, and as we discussed,
I will be here to provide any needed guidance, insight, or information
as you need.  As I had mentioned to you, I do not have any immediate
plans to leave the Team, nor do I have any question in my mind that you
are the obvious successor to this role.

I am proud to be able to hand over the proverbial torch to you, and look
very much forward to your successes as the Release Engineering Team
Lead.

It has been an absolute pleasure to be able to serve you all to the best
of my abilities over the past several years.

With my very best regards to all involved in the Project, and nothing
but the best intentions of the Project in mind.

Glen

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmVX/MgACgkQAxRYpUeP
4pPLVg/9HW6nhw6EXTGqkrdibCkThurdasCqftkLSGrsABDj1AsErHbBnbO3W04G
KSVZ6Jw28JQNGUsprJwcAsJre8PXgL2iKOkIZTL31CYSBvQbfGEzIWTC+18oTQ6Q
d1uxqGcqoMcpPfFxSry8wnfxO7hYGabv38lPy2KipskCqq/3zVqsdVb6UxGdo+5Q
0sis6OVh8KhNdcgOu+RTZr194KJogsdqqGll4pOQNMv/Qpy5e9JOqHgVXueseUC8
6GDHa990VLF22+DLgq3qzVS0xGLIOM5MuC0EjWJEjaq5bANEzQX0SvMEKQEbGLrI
MjBXGoJGTreBMr0VbCewhuDIiYy7DU5dtohvXvCx+UoBryT9qU1RKmRyRxxp3hQ4
dcZUyZ3RarwmZfJBTs7ib2s9LztUlpyIRAU7gJ2vRKcegVTH/Fe1FuRZHOFHZf46
kzHeIygER3nitPtJj9ePQgq97F2WBjRDZ5MSzwNWsOMknsbUKekIB9xshbhxlUw8
5ZN61k3frKM/dOcnLulsNHFaMGJaodDsxMuTKhJCEHvHWLXOin66WrfuHKbeqzVf
LDgMCWiHcM0GwrtzXR/aITVZmwyg096gZw0NLXtlNadY+PyQrg8R83DmOKTk0fWo
MYaMnWBcZM78DviTaBPhcblMtB5/IqrbJzqnJqsnCBEW2Z29qgs=
=sYrP
-END PGP SIGNATURE-

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Glen Barber]

On Thu, Nov 16, 2023 at 09:22:52PM +, Jamie Landeg-Jones wrote:
> > Ok.  I do not know what exactly is your point, but releases are never
> > official until there is a PGP-signed email sent.  The email is intended
> > for the general public of consumers of official releases, not "yeah,
> > but"s.
> 
> Foe a recent new build, I just went to the ftp site to grab the latest rc,
> only to see 14.0-release there, so I grabbed and installed that, many
> hours before your original mail went out.
> 
> No biggy, I generally track stable, but does this mean we can't rely
> on the download sites without checking out the lists first? It's not
> like I was plaing sneaky by doing "guess the URL" or anything like that.
> 

No.  It merely suggests the release is not officially official yet.

Glen



signature.asc
Description: PGP signature

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Glen Barber]

And if there is a reason to reissue a release, the update will reflect such.

So to answer your latter question, yes.  Unless it needs to be replaced.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Nov 15, 2023, at 11:38 PM, The Doctor  wrote:
> 
> On Thu, Nov 16, 2023 at 12:30:30AM +0000, Glen Barber wrote:
>>> On Wed, Nov 15, 2023 at 08:39:39AM -0800, John Baldwin wrote:
>>> On 11/14/23 8:52 PM, Glen Barber wrote:
>>>> On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote:
>>>>> On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote:
>>>>>> On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote:
>>>>>>> On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote:
>>>>>>>> We are still waiting for a few (non-critical) things to complete before
>>>>>>>> the announcement of 14.0-RELEASE will be ready.
>>>>>>>> 
>>>>>>>> It should only be another day or so before these things complete.
>>>>>>>> 
>>>>>>>> Thank you for your understanding.
>>>>>>>> 
>>>>>>> 
>>>>>>> I always just installed my copy.
>>>>>>> 
>>>>>> 
>>>>>> Ok.  I do not know what exactly is your point, but releases are never
>>>>>> official until there is a PGP-signed email sent.  The email is intended
>>>>>> for the general public of consumers of official releases, not "yeah,
>>>>>> but"s.
>>>>>> 
>>>>> 
>>>>> Howver if you do a freebsd-update upgrade, you can upgrade.
>>>>> 
>>>>> Is that suppose to happen?
>>>>> 
>>>> 
>>>> That does not say that the freebsd-update bits will not change *until*
>>>> the official release announcement has been sent.
>>>> 
>>>> In my past 15 years involved in the Project, I think we have been very
>>>> clear on that.
>>>> 
>>>> A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT.
>>>> 
>>>> I mean, c'mon, dude.
>>>> 
>>>> We really, seriously, for all intents and purposes, cannot be any more
>>>> clear than that.
>>>> 
>>>> So, yes, *IF* an update necessitates a new freebsd-update build, what
>>>> you are running is *NOT* official.
>>>> 
>>>> For at least 15 years, we have all said the same entire thing.
>>> 
>>> Yes, but, if at this point we had to rebuild, it would have to be 14.0.1
>>> or something (which we have done a few times in the past).  It would be
>>> too confusing otherwise once the bits are built and published (where
>>> published means "uploaded to our CDN").  It is the 14.0 release bits,
>>> the only question is if for some reason we had a dire emergency that
>>> meant we had to pull it at the last minute and publish different bits
>>> (under a different release name).
>>> 
>>> Realistically, once the bits are available, we can't prevent people from
>>> using them, it's just at their own risk to do so until the project says
>>> "yes, we believe these are good".  Granted, they are under the same risk
>>> if they are still running the last RC.  The best way to minimize that
>>> risk going forward is to add more automation of testing/CI to go along
>>> with the process of building release bits so that the build artifacts
>>> from the release build run through CI and are only published if the CI
>>> is green as that would give us greater confidence of "we believe these
>>> are good" before they are uploaded for publishing.
>>> 
>> 
>> You are correct on all points.  If there were a need to re-roll 14.0, it
>> would indeed necessitate a release/14.0.1 tag.  Note, release/14.0.0 has
>> not yet been tagged, and I find it extremely unlikely that it will be
>> necessary to rebuild from a release/14.0.1 tag.
>> 
>> I also agree we cannot prevent people from downloading the images,
>> installers, whatever before the announcement.  That is the lovely race
>> condition with which we have to live at the moment.
>> 
>> My email was intended to be informative.  Period.
>> 
>> There were no suggestions that 14.0-RELEASE was not yet final.  And to
>> be fair, I had to personally deal with the fallout of a release "too
>> soon", notably 11.0-RELEASE

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Glen Barber]

Thank you for that.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Nov 15, 2023, at 11:17 PM, Rich Reynolds  wrote:
> 
> On 11/15/23 20:19, Pete Wright wrote:
>>> On 11/15/23 16:30, Glen Barber wrote:
>>> The alternative would be to say nothing at all.
>>> 
>>> Either way, it is a productivity, communication drain.  It is
>>> a lose-lose situation no matter how one looks at it given the above
>>> context.  We either get chastised for being "too open" into insights
>>> delaying an official announcement, or for being "not open enough" when
>>> there is silence from RE when a release does not meet its scheduled
>>> announcement date.
>> Glen I appreciate your transparency and the efforts you have done to keep 
>> everyone in the loop.  I think people get excited about new releases, which 
>> is probably a good thing.  IMHO i feel you've been striking a good balance.
>> As an operator these updates are really helpful for me as it allows me to 
>> adjust timelines on my end for updating my fleet of servers. You and the RE 
>> team do an incredible job - and personally I am thankful for the caution and 
>> common sense you all bring to this complex process.
>> Cheers,
>> -pete
>> -- 
>> Pete Wright
>> p...@nomadlogic.org
>> @nomadlogicLA
> +1 from a retired RE manager
> yet another hard thankless job in the development chain...
> 
> -- 
> When you beleve in things. that you don't understand,
> then you suffer, superstition ain't the way.
> Stevie Wonder - 1972
> 

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Glen Barber]

On Wed, Nov 15, 2023 at 07:19:39PM -0800, Pete Wright wrote:
> 
> 
> On 11/15/23 16:30, Glen Barber wrote:
> > The alternative would be to say nothing at all.
> > 
> > Either way, it is a productivity, communication drain.  It is
> > a lose-lose situation no matter how one looks at it given the above
> > context.  We either get chastised for being "too open" into insights
> > delaying an official announcement, or for being "not open enough" when
> > there is silence from RE when a release does not meet its scheduled
> > announcement date.
> Glen I appreciate your transparency and the efforts you have done to keep
> everyone in the loop.  I think people get excited about new releases, which is
> probably a good thing.  IMHO i feel you've been striking a good balance.
> 
> As an operator these updates are really helpful for me as it allows me to
> adjust timelines on my end for updating my fleet of servers. You and the RE
> team do an incredible job - and personally I am thankful for the caution and
> common sense you all bring to this complex process.
> 

Thank you very much, Pete, for your email on this.  It is appreciated by
all of us involved in FreeBSD releases.

Best regards,

Glen



signature.asc
Description: PGP signature

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Glen Barber]

On Wed, Nov 15, 2023 at 08:39:39AM -0800, John Baldwin wrote:
> On 11/14/23 8:52 PM, Glen Barber wrote:
> > On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote:
> > > On Wed, Nov 15, 2023 at 02:27:01AM +, Glen Barber wrote:
> > > > On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote:
> > > > > On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote:
> > > > > > We are still waiting for a few (non-critical) things to complete 
> > > > > > before
> > > > > > the announcement of 14.0-RELEASE will be ready.
> > > > > > 
> > > > > > It should only be another day or so before these things complete.
> > > > > > 
> > > > > > Thank you for your understanding.
> > > > > > 
> > > > > 
> > > > > I always just installed my copy.
> > > > > 
> > > > 
> > > > Ok.  I do not know what exactly is your point, but releases are never
> > > > official until there is a PGP-signed email sent.  The email is intended
> > > > for the general public of consumers of official releases, not "yeah,
> > > > but"s.
> > > > 
> > > 
> > > Howver if you do a freebsd-update upgrade, you can upgrade.
> > > 
> > > Is that suppose to happen?
> > > 
> > 
> > That does not say that the freebsd-update bits will not change *until*
> > the official release announcement has been sent.
> > 
> > In my past 15 years involved in the Project, I think we have been very
> > clear on that.
> > 
> > A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT.
> > 
> > I mean, c'mon, dude.
> > 
> > We really, seriously, for all intents and purposes, cannot be any more
> > clear than that.
> > 
> > So, yes, *IF* an update necessitates a new freebsd-update build, what
> > you are running is *NOT* official.
> > 
> > For at least 15 years, we have all said the same entire thing.
> 
> Yes, but, if at this point we had to rebuild, it would have to be 14.0.1
> or something (which we have done a few times in the past).  It would be
> too confusing otherwise once the bits are built and published (where
> published means "uploaded to our CDN").  It is the 14.0 release bits,
> the only question is if for some reason we had a dire emergency that
> meant we had to pull it at the last minute and publish different bits
> (under a different release name).
> 
> Realistically, once the bits are available, we can't prevent people from
> using them, it's just at their own risk to do so until the project says
> "yes, we believe these are good".  Granted, they are under the same risk
> if they are still running the last RC.  The best way to minimize that
> risk going forward is to add more automation of testing/CI to go along
> with the process of building release bits so that the build artifacts
> from the release build run through CI and are only published if the CI
> is green as that would give us greater confidence of "we believe these
> are good" before they are uploaded for publishing.
> 

You are correct on all points.  If there were a need to re-roll 14.0, it
would indeed necessitate a release/14.0.1 tag.  Note, release/14.0.0 has
not yet been tagged, and I find it extremely unlikely that it will be
necessary to rebuild from a release/14.0.1 tag.

I also agree we cannot prevent people from downloading the images,
installers, whatever before the announcement.  That is the lovely race
condition with which we have to live at the moment.

My email was intended to be informative.  Period.

There were no suggestions that 14.0-RELEASE was not yet final.  And to
be fair, I had to personally deal with the fallout of a release "too
soon", notably 11.0-RELEASE, where I thought a critical issue had been
addressed, but I was wrong.

My only point, in being overly open to the public on the delay, is that
we (the Release Engineering Team) are not yet ready to rubber-stamp this
as complete, as there are some outstanding items that are pending that
have not yet completed.

The alternative would be to say nothing at all.

Either way, it is a productivity, communication drain.  It is
a lose-lose situation no matter how one looks at it given the above
context.  We either get chastised for being "too open" into insights
delaying an official announcement, or for being "not open enough" when
there is silence from RE when a release does not meet its scheduled
announcement date.

Glen




signature.asc
Description: PGP signature

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Glen Barber]

Well, today is your yesterday, so we might not be ready for another more 
tomorrows your time, yesterdays, my time.  Or something.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Nov 15, 2023, at 2:39 AM, matti k  wrote:
> 
> On Wed, 15 Nov 2023 04:52:31 +0000
> Glen Barber  wrote:
> 
>>>> Ok.  I do not know what exactly is your point, but releases are
>>>> never official until there is a PGP-signed email sent.  The email
>>>> is intended for the general public of consumers of official
>>>> releases, not "yeah, but"s.
>>>> 
> 
>> That does not say that the freebsd-update bits will not change *until*
>> the official release announcement has been sent.
>> 
>> In my past 15 years involved in the Project, I think we have been very
>> clear on that.
>> 
>> A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT.
>> 
>> I mean, c'mon, dude.
>> 
>> We really, seriously, for all intents and purposes, cannot be any more
>> clear than that.
>> 
>> So, yes, *IF* an update necessitates a new freebsd-update build, what
>> you are running is *NOT* official.
>> 
>> For at least 15 years, we have all said the same entire thing.
> 
> Here I have been tracking 14.0 release candidates
> 
> Reminds me of when slashdot would announce a new release days before it
> was actually released and then someone would remind them of that
> 
> I am using an Australian mirror so will probably need to wait an extra
> day to be on the safe side  :-)
> 
> 
> 
> 

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Glen Barber]

On Tue, Nov 14, 2023 at 08:10:23PM -0700, The Doctor wrote:
> On Wed, Nov 15, 2023 at 02:27:01AM +0000, Glen Barber wrote:
> > On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote:
> > > On Tue, Nov 14, 2023 at 08:36:54PM +, Glen Barber wrote:
> > > > We are still waiting for a few (non-critical) things to complete before
> > > > the announcement of 14.0-RELEASE will be ready.
> > > > 
> > > > It should only be another day or so before these things complete.
> > > > 
> > > > Thank you for your understanding.
> > > >
> > > 
> > > I always just installed my copy.
> > > 
> > 
> > Ok.  I do not know what exactly is your point, but releases are never
> > official until there is a PGP-signed email sent.  The email is intended
> > for the general public of consumers of official releases, not "yeah,
> > but"s.
> >
> 
> Howver if you do a freebsd-update upgrade, you can upgrade.
> 
> Is that suppose to happen?
> 

That does not say that the freebsd-update bits will not change *until*
the official release announcement has been sent.

In my past 15 years involved in the Project, I think we have been very
clear on that.

A RELEASE IS NOT FINAL UNTIL THE PGP-SIGNED ANNOUNCEMENT IS SENT.

I mean, c'mon, dude.

We really, seriously, for all intents and purposes, cannot be any more
clear than that.

So, yes, *IF* an update necessitates a new freebsd-update build, what
you are running is *NOT* official.

For at least 15 years, we have all said the same entire thing.

Glen



signature.asc
Description: PGP signature

Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule

[Glen Barber]

On Tue, Nov 14, 2023 at 05:15:48PM -0700, The Doctor wrote:
> On Tue, Nov 14, 2023 at 08:36:54PM +0000, Glen Barber wrote:
> > We are still waiting for a few (non-critical) things to complete before
> > the announcement of 14.0-RELEASE will be ready.
> > 
> > It should only be another day or so before these things complete.
> > 
> > Thank you for your understanding.
> >
> 
> I always just installed my copy.
> 

Ok.  I do not know what exactly is your point, but releases are never
official until there is a PGP-signed email sent.  The email is intended
for the general public of consumers of official releases, not "yeah,
but"s.

Glen



signature.asc
Description: PGP signature

[HEADS-UP] Quick update to 14.0-RELEASE schedule

[Glen Barber]

We are still waiting for a few (non-critical) things to complete before
the announcement of 14.0-RELEASE will be ready.

It should only be another day or so before these things complete.

Thank you for your understanding.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

FreeBSD 14.0-RC4 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The fourth RC build of the 14.0-RELEASE release cycle is now available.

Installation images are available for:

o 14.0-RC4 amd64 GENERIC
o 14.0-RC4 i386 GENERIC
o 14.0-RC4 powerpc GENERIC
o 14.0-RC4 powerpc64 GENERIC64
o 14.0-RC4 powerpc64le GENERIC64LE
o 14.0-RC4 powerpcspe MPC85XXSPE
o 14.0-RC4 armv7 GENERICSD
o 14.0-RC4 aarch64 GENERIC
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

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 for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

A summary of changes since 14.0-RC3 includes:

o ISA and GIANT-locked driver removal has been delayed to FreeBSD 15,
  and system messages have been updated to reflect such.

o An update to OpenZFS correcting block cloning between encrypted and
  unencrypted datasets has been included.

o A fix for Hyper-V emulation within QEMU resulting in system crashes
  has been addressed.

A list of changes since 13.2-RELEASE is available in the releng/14.0
release notes:

https://www.freebsd.org/releases/14.0R/relnotes/

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 14.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-RC4/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-RC4/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/RC4
/aws/service/freebsd/amd64/base/zfs/14.0/RC4
/aws/service/freebsd/amd64/cloud-init/ufs/14.0/RC4
/aws/service/freebsd/amd64/cloud-init/zfs/14.0/RC4

FreeBSD/aarch64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/aarch64/base/ufs/14.0/RC4
/aws/service/freebsd/aarch64/base/zfs/14.0/RC4
/aws/service/freebsd/aarch64/cloud-init/ufs/14.0/RC4
/aws/service/freebsd/aarch64/cloud-init/zfs/14.0/RC4

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can
be installed by running:

% vagrant init freebsd/FreeBSD-14.0-RC4
% vagrant up

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64, i386,
and aarch64 systems running earlier FreeBSD releases.  Systems running
earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-RC4

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the 

FreeBSD 14.0-RC3 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The third RC build of the 14.0-RELEASE release cycle is now available.

Installation images are available for:

o 14.0-RC3 amd64 GENERIC
o 14.0-RC3 i386 GENERIC
o 14.0-RC3 powerpc GENERIC
o 14.0-RC3 powerpc64 GENERIC64
o 14.0-RC3 powerpc64le GENERIC64LE
o 14.0-RC3 powerpcspe MPC85XXSPE
o 14.0-RC3 armv7 GENERICSD
o 14.0-RC3 aarch64 GENERIC
o 14.0-RC3 aarch64 RPI
o 14.0-RC3 aarch64 PINE64
o 14.0-RC3 aarch64 PINE64-LTS
o 14.0-RC3 aarch64 PINEBOOK
o 14.0-RC3 aarch64 ROCK64
o 14.0-RC3 aarch64 ROCKPRO64
o 14.0-RC3 riscv64 GENERIC
o 14.0-RC3 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

A summary of changes since 14.0-RC2 includes:

o Test suite fixes.

o Support for IUTF8 in (s)tty has been added.

o Support for Realtek Killer E2600 has been added.

o Several kernel TLS updates have been added.

o OpenSSL has been updated to version 3.0.12.

o And other miscellaneous bug fixes and updates.

A list of changes since 13.2-RELEASE is available in the releng/14.0
release notes:

https://www.freebsd.org/releases/14.0R/relnotes/

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 14.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-RC3/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-RC3/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/RC3
/aws/service/freebsd/amd64/base/zfs/14.0/RC3
/aws/service/freebsd/amd64/cloud-init/ufs/14.0/RC3
/aws/service/freebsd/amd64/cloud-init/zfs/14.0/RC3

FreeBSD/aarch64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/aarch64/base/ufs/14.0/RC3
/aws/service/freebsd/aarch64/base/zfs/14.0/RC3
/aws/service/freebsd/aarch64/cloud-init/ufs/14.0/RC3
/aws/service/freebsd/aarch64/cloud-init/zfs/14.0/RC3

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can
be installed by running:

% vagrant init freebsd/FreeBSD-14.0-RC3
% vagrant up

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64, i386,
and aarch64 systems running earlier FreeBSD releases.  Systems running
earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-RC3

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install

It is 

FreeBSD 14.0-RC2 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The second RC build of the 14.0-RELEASE release cycle is now available.

Installation images are available for:

o 14.0-RC2 amd64 GENERIC
o 14.0-RC2 i386 GENERIC
o 14.0-RC2 powerpc GENERIC
o 14.0-RC2 powerpc64 GENERIC64
o 14.0-RC2 powerpc64le GENERIC64LE
o 14.0-RC2 powerpcspe MPC85XXSPE
o 14.0-RC2 armv7 GENERICSD
o 14.0-RC2 aarch64 GENERIC
o 14.0-RC2 aarch64 RPI
o 14.0-RC2 aarch64 PINE64
o 14.0-RC2 aarch64 PINE64-LTS
o 14.0-RC2 aarch64 PINEBOOK
o 14.0-RC2 aarch64 ROCK64
o 14.0-RC2 aarch64 ROCKPRO64
o 14.0-RC2 riscv64 GENERIC
o 14.0-RC2 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

A summary of changes since 14.0-RC1 includes:

o OpenSSH has been updated to version 9.5p1.

o OpenSSL has been updated to version 3.0.11.

o Various VFS-related fixes.

o OpenZFS has been updated to zfs-2.2-release.

o Support for ZFS-backed Azure images has been implemented.

o A crash with smartpqi(4) or mpi3mr(4) devices has been resolved.

o An issue building virtual machine images for GCE has been resolved.

o And various other miscellaneous fixes.

A list of changes since 13.2-RELEASE is available in the releng/14.0
release notes:

https://www.freebsd.org/releases/14.0R/relnotes/

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 14.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-RC2/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-RC2/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/RC2
/aws/service/freebsd/amd64/base/zfs/14.0/RC2
/aws/service/freebsd/amd64/cloud-init/ufs/14.0/RC2
/aws/service/freebsd/amd64/cloud-init/zfs/14.0/RC2

FreeBSD/aarch64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/aarch64/base/ufs/14.0/RC2
/aws/service/freebsd/aarch64/base/zfs/14.0/RC2
/aws/service/freebsd/aarch64/cloud-init/ufs/14.0/RC2
/aws/service/freebsd/aarch64/cloud-init/zfs/14.0/RC2

=== Vagrant Images ===

FreeBSD/amd64 images are not available for this build, and are expected
to be available next week.

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64, i386,
and aarch64 systems running earlier FreeBSD releases.  Systems running
earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-RC2

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run 

FreeBSD 14.0-RC1 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The first RC build of the 14.0-RELEASE release cycle is now available.

Installation images are available for:

o 14.0-RC1 amd64 GENERIC
o 14.0-RC1 i386 GENERIC
o 14.0-RC1 powerpc GENERIC
o 14.0-RC1 powerpc64 GENERIC64
o 14.0-RC1 powerpc64le GENERIC64LE
o 14.0-RC1 powerpcspe MPC85XXSPE
o 14.0-RC1 armv7 GENERICSD
o 14.0-RC1 aarch64 GENERIC
o 14.0-RC1 aarch64 RPI
o 14.0-RC1 aarch64 PINE64
o 14.0-RC1 aarch64 PINE64-LTS
o 14.0-RC1 aarch64 PINEBOOK
o 14.0-RC1 aarch64 ROCK64
o 14.0-RC1 aarch64 ROCKPRO64
o 14.0-RC1 riscv64 GENERIC
o 14.0-RC1 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

A summary of changes since 14.0-BETA5 includes:

o A race condition in swap_pager_swapoff_object() had been fixed.

o Various updates to the Linux KPI, 802.11, iwlwifi, and rtw88.

o And other miscellaneous fixes.

A list of changes since 13.2-RELEASE is available in the releng/14.0
release notes:

https://www.freebsd.org/releases/14.0R/relnotes/

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 14.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-RC1/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-RC1/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs are available in the Systems Manager Parameter
Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/RC1
/aws/service/freebsd/amd64/base/zfs/14.0/RC1
/aws/service/freebsd/amd64/cloud-init/ufs/14.0/RC1
/aws/service/freebsd/amd64/cloud-init/zfs/14.0/RC1

FreeBSD/arm64 EC2 AMI IDs are available in the Systems Manager Parameter
Store in each region using the keys:

/aws/service/freebsd/arm64/base/ufs/14.0/RC1
/aws/service/freebsd/arm64/base/zfs/14.0/RC1
/aws/service/freebsd/arm64/cloud-init/ufs/14.0/RC1
/aws/service/freebsd/arm64/cloud-init/zfs/14.0/RC1

=== Vagrant Images ===

FreeBSD/amd64 images are not available for this build.

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64, i386,
and aarch64 systems running earlier FreeBSD releases.  Systems running
earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-RC1

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install

It is recommended to rebuild and install all applications if possible,
especially if upgrading from an earlier FreeBSD release, for example,
FreeBSD 12.x.  Alternatively, the user can install misc/compat12x and
other compatibility 

FreeBSD 14.0-BETA5 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The fifth BETA build of the 14.0-RELEASE release cycle is now available.

Installation images are available for:

o 14.0-BETA5 amd64 GENERIC
o 14.0-BETA5 i386 GENERIC
o 14.0-BETA5 powerpc GENERIC
o 14.0-BETA5 powerpc64 GENERIC64
o 14.0-BETA5 powerpc64le GENERIC64LE
o 14.0-BETA5 powerpcspe MPC85XXSPE
o 14.0-BETA5 armv7 GENERICSD
o 14.0-BETA5 aarch64 GENERIC
o 14.0-BETA5 aarch64 RPI
o 14.0-BETA5 aarch64 PINE64
o 14.0-BETA5 aarch64 PINE64-LTS
o 14.0-BETA5 aarch64 PINEBOOK
o 14.0-BETA5 aarch64 ROCK64
o 14.0-BETA5 aarch64 ROCKPRO64
o 14.0-BETA5 riscv64 GENERIC
o 14.0-BETA5 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

A summary of changes since 14.0-BETA4 includes:

o An issue preventing binary upgrades using freebsd-update on earlier
  supported releases had been fixed.

o Several networking-related bug fixes had been addressed.

o Experimental support for Amazon EC2 cloud-init AMIs had been added.

o Several additional miscellaneous bug fixes and enhancements.

A list of changes since 13.2-RELEASE is available in the releng/14.0
release notes:

https://www.freebsd.org/releases/14.0R/relnotes/

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 14.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-BETA5/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-BETA5/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/BETA5
/aws/service/freebsd/amd64/base/zfs/14.0/BETA5
/aws/service/freebsd/amd64/cloud-init/ufs/14.0/BETA5
/aws/service/freebsd/amd64/cloud-init/zfs/14.0/BETA5

FreeBSD/aarch64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/aarch64/base/ufs/14.0/BETA5
/aws/service/freebsd/aarch64/base/zfs/14.0/BETA5
/aws/service/freebsd/aarch64/cloud-init/ufs/14.0/BETA5
/aws/service/freebsd/aarch64/cloud-init/zfs/14.0/BETA5

=== Vagrant Images ===

FreeBSD/amd64 images are not available for this build.

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64, i386,
and aarch64 systems running earlier FreeBSD releases.  Systems running
earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-BETA5

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install

It is recommended to 

Re: [UPDATE] FreeBSD 14.0-BETA3 Now Available

[Glen Barber]

Yes, there will at least be BETA5.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Sep 30, 2023, at 2:24 PM, Philip Homburg  wrote:
> 
> 
>> 
>> Note, releases from 13.2 and earlier are
>> still problematic due to a file name being replaced with a directory of
>> the same name.  A patch is being tested currently, and we hope to have
>> this resolved for 14.0-BETA4.
> 
> I tried upgrading from 13.2 to BETA4 and it seems that the issue is still
> there. Is there going to be another BETA?
> 

FreeBSD 14.0-BETA4 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The fourth BETA build of the 14.0-RELEASE release cycle is now
available.

Installation images are available for:

o 14.0-BETA4 amd64 GENERIC
o 14.0-BETA4 i386 GENERIC
o 14.0-BETA4 powerpc GENERIC
o 14.0-BETA4 powerpc64 GENERIC64
o 14.0-BETA4 powerpc64le GENERIC64LE
o 14.0-BETA4 powerpcspe MPC85XXSPE
o 14.0-BETA4 armv7 GENERICSD
o 14.0-BETA4 aarch64 GENERIC
o 14.0-BETA4 aarch64 RPI
o 14.0-BETA4 aarch64 PINE64
o 14.0-BETA4 aarch64 PINE64-LTS
o 14.0-BETA4 aarch64 PINEBOOK
o 14.0-BETA4 aarch64 ROCK64
o 14.0-BETA4 aarch64 ROCKPRO64
o 14.0-BETA4 riscv64 GENERIC
o 14.0-BETA4 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

A summary of changes since 14.0-BETA3 includes:

o A fix for a pnwerpc-related panic.

o Console output on Raspberry Pi 3B+ and 4B have been silenced at boot.

o A fix to freebsd=update(8) had been implemented to avoid restarting
  sshd(8) when updating the basedir.

o Support for hidraw(4) has been added.

o Several ZFS-related fixes.

o Several VFS-related fixes.

o Several miscellaneous fixes and driver updates.

A list of changes since 13.2-RELEASE is available in the releng/14.0
release notes:

https://www.freebsd.org/releases/14.0R/relnotes/

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 14.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-BETA4/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-BETA4/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/BETA4
/aws/service/freebsd/amd64/base/zfs/14.0/BETA4

FreeBSD/aarch64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/aarch64/base/ufs/14.0/BETA4
/aws/service/freebsd/aarch64/base/zfs/14.0/BETA4

=== Vagrant Images ===

FreeBSD/amd64 images are not available for this build.

=== Upgrading ===

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

Due to an issue where an existing file had been replaced by a directory
with the same name, binary upgrades from 13.2 and earlier using the 
freebsd-update(8) utility will not work.  A patch is currently in the
main branch, and expected to be included in supported release branches
before the next build.

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

The freebsd-update(8) utility supports binary upgrades of amd64, i386,
and aarch64 systems running earlier FreeBSD releases.  Systems running
earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-BETA4

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# 

[UPDATE] FreeBSD 14.0-BETA3 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Sep 22, 2023 at 10:50:08PM +, Glen Barber wrote:
> === Upgrading ===
> 
> Due to a known delay, freebsd-update(8) binary update builds are not yet
> ready for BETA3.  A separate email will be sent once they are available.
> 

Binary updates via freebsd-update(8) are now available for systems
already running 14.0-BETA.  Note, releases from 13.2 and earlier are
still problematic due to a file name being replaced with a directory of
the same name.  A patch is being tested currently, and we hope to have
this resolved for 14.0-BETA4.

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64, i386,
and aarch64 systems running earlier FreeBSD releases.  Systems running
earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-BETA3

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install

It is recommended to rebuild and install all applications if possible,
especially if upgrading from an earlier FreeBSD release, for example,
FreeBSD 12.x.  Alternatively, the user can install misc/compat12x and
other compatibility libraries, afterwards the system must be rebooted
into the new userland:

# shutdown -r now

Finally, after rebooting, freebsd-update needs to be run again to remove
stale files:

# freebsd-update install

Regards,

Glen

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/

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmUOe38ACgkQAxRYpUeP
4pO5xA//Zeg5TAYEhXYdEj7Nk3S46dmq7FgRcgns7wAyQlnNEA31fHCmG0B/aSg4
Ronzr4ed14KX7HUdbd5tsWmIleILH1dLJkmx/wlFOe4uzLC0Nm3zHEwrgn4w6GYj
4hZ67O7Pw/tUYDF57hYYrXWk0zYX90JJZ7nHc4o9f/i/kIIYI6o6MRKZjpuK+lmD
eGFgC22s/GR8iR4QC2I++SMDsKSpdOTAqkUo/oOmPPciWqfS8bYfg83i1IDXOmIk
VAOBPJ8yJpc6q3EgXFrCRDhFENPLdKG5qT85LinS1z8OS2AppPZ5kixUn2XRI0/Z
Nu+UVGEd9zX47wHqtsgjW4vjruHoTRKjFaDh3zJ8tLuX+Q8ZcPidA8JfRQmbqk+R
RHW/7gT8j4Nso9fosx0JrQCa3TJG7l7worGG89TtHvWTxPjACtyiE2ocIzDrEj4P
1OQfNPvUQ0fFjm3Di16fwVm8VIGlHq8M2eQho+4n25DvpwVOqiaFrXVdampm4Y2V
SnzLqczkR7dK4//sw5+OPK28aIFdaA443Xx6iiuD7DFYrCtxDVx7YDQXbcFdNoMA
QuuoV4kRrr+ZrieWX5OWBuzBeLuY9h6Xm0xxkKw42+gdZlU5Uvc0mSMstb7DdEqR
l0iMzOAIn2yF8a9Xvo8m+7vWXnODjrcyItNQCl5UVs9sujzu2lg=
=qYkR
-END PGP SIGNATURE-

Re: FreeBSD 14.0-BETA3 Now Available

[Glen Barber]

On Sat, Sep 23, 2023 at 08:16:47AM +0900, Yasuhiro Kimura wrote:
> I tried to update from 14.0-BETA2 to 14.0-BETA3 with freebsd-update(8)
> but it fails as following.
> 
[...]

-- begin quoted text ---
=== Upgrading ===

Due to a known delay, freebsd-update(8) binary update builds are not yet
ready for BETA3.  A separate email will be sent once they are available.
--- end quoted text 

Glen



signature.asc
Description: PGP signature

Update on 14.0-RELEASE

[Glen Barber]

We will likely need at minimum a fourth BETA build for the 14.0-RELEASE
cycle.

As was just announced, BETA3 is now available.  There are some known
outstanding issues:

1) freebsd-update(8) has previously failed to upgrade from 13.x and
   earlier due to a file name that had been replaced with a directory of
   the same name.  A patch for this is under testing.
2) FreeBSD arm64/aarch64 EC2 AMIs have been failing to build properly,
   presumably due to lang/rust build failures leading to the ec2-scripts
   package from being prevented to be available.  The last 15.0-CURRENT
   snapshots seem to have this resolved, so hopefully it is also
   resolved for what will eventually be the 'release_0' package set for
   14.0-RELEASE, but that is still over a week away.
3) There are no "official" FreeBSD base packages available.  I have been
   occupied with external factors preventing me from having cycles
   available to look into this without interruption, but I think I am
   going to err on the side of caution and have a manual package set run
   available via https://download.freebsd.org/ somewhere within the
   version, architecture, and machine type namespace.
4) Vagrant images fail to upload due to an incorrect target following
   the addition of ZFS images.  This is another issue where I have
   personally been blocked/blocking progress.
5) The 'ftp-stage' target does not currently account for ZFS virtual
   machine images.  I again have this in my queue.  I do not know if
   I necessarily care too much about this for 14.0-RELEASE, since all
   virtual machine images are within the 'Latest/' directory namespace
   for all builds, but I am intent on fixing it.
6) The ZFS-root EC2 AMIs panic a few seconds after booting, apparently
   due to memory corruption in ZFS.

Note regarding (3) above: this is not yet done, but the datasets in
which the builds were done are preserved.  I hope to have at least a few
hours this weekend to try to get binary packages for the FreeBSD base
system in place, wherever that ends up being.

Glen
On behalf of:   re



signature.asc
Description: PGP signature

FreeBSD 14.0-BETA3 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The third BETA build of the 14.0-RELEASE release cycle is now available.

Installation images are available for:

o 14.0-BETA3 amd64 GENERIC
o 14.0-BETA3 i386 GENERIC
o 14.0-BETA3 powerpc GENERIC
o 14.0-BETA3 powerpc64 GENERIC64
o 14.0-BETA3 powerpc64le GENERIC64LE
o 14.0-BETA3 powerpcspe MPC85XXSPE
o 14.0-BETA3 armv7 GENERICSD
o 14.0-BETA3 aarch64 GENERIC
o 14.0-BETA3 aarch64 RPI
o 14.0-BETA3 aarch64 PINE64
o 14.0-BETA3 aarch64 PINE64-LTS
o 14.0-BETA3 aarch64 PINEBOOK
o 14.0-BETA3 aarch64 ROCK64
o 14.0-BETA3 aarch64 ROCKPRO64
o 14.0-BETA3 riscv64 GENERIC
o 14.0-BETA3 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

A summary of changes since 14.0-BETA2 includes:

o A fix to gve(4).

o Several fixes related to Hyper-V.

o Fixes to cxgbe(4).

o A fix to zfsd(8).

A list of changes since 13.x is available in the releng/14.0
release notes:

https://www.freebsd.org/releases/14.0R/relnotes/

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 14.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-BETA3/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-BETA3/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/BETA3
/aws/service/freebsd/amd64/base/zfs/14.0/BETA3

FreeBSD/aarch64 EC2 AMI IDs are unavailable for this build.  The cause
is being investigated.

=== Vagrant Images ===

FreeBSD/amd64 images are not available for this build.  The cause is
being investigated.

=== Upgrading ===

Due to a known delay, freebsd-update(8) binary update builds are not yet
ready for BETA3.  A separate email will be sent once they are available.

== ISO CHECKSUMS ==

o 14.0-BETA3 amd64 GENERIC:
  SHA512 (FreeBSD-14.0-BETA3-amd64-bootonly.iso) = 
628186fb7330caf217fdf81cd7b7f3f749785d9d9b565c2fb08f8ba4cfd7cac93fc0ae75aecfc672004e6ecffa634aaa67948312a05db110f330f3c60cefc176
  SHA512 (FreeBSD-14.0-BETA3-amd64-bootonly.iso.xz) = 
f41f2e70214ef48042f899606e86cb9c23b8dbe43beb5c3b6a167e68766abeabc9ab9869ec1527f672f88ea55524c5cad9555ef607e7a7b5b598bb83ceb71af6
  SHA512 (FreeBSD-14.0-BETA3-amd64-disc1.iso) = 
5386bc3f0aba186b9f3f3dfc8f90d016fe670b7548cc75c3efbc9bf5b5151c323c8d15bada1dc0daa5f76ed587223b0afee6d686834987f35e51f90f6edc41f7
  SHA512 (FreeBSD-14.0-BETA3-amd64-disc1.iso.xz) = 
3a97aed101bd33e479308a738a26102eabd49fe1ec6279b3f765943eac5e96caf3bf3271c2281db82493cc42cdcbd59a3dba21d4a89aa1fde059561746b395df
  SHA512 (FreeBSD-14.0-BETA3-amd64-dvd1.iso) = 
83d141f777343bbc5f96c46ba6d8ab0ab60dd72448f85d7e11fa803209ccb2fa35e83ef687854f246ee128c71ba35232c736d3bbcc41bdb98fa8a16a03e3a65e
  SHA512 (FreeBSD-14.0-BETA3-amd64-dvd1.iso.xz) = 

FreeBSD 14.0-BETA2 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The second BETA build of the 14.0-RELEASE release cycle is now
available.

Installation images are available for:

o 14.0-BETA2 amd64 GENERIC
o 14.0-BETA2 i386 GENERIC
o 14.0-BETA2 powerpc GENERIC
o 14.0-BETA2 powerpc64 GENERIC64
o 14.0-BETA2 powerpc64le GENERIC64LE
o 14.0-BETA2 powerpcspe MPC85XXSPE
o 14.0-BETA2 armv7 GENERICSD
o 14.0-BETA2 aarch64 GENERIC
o 14.0-BETA2 aarch64 RPI
o 14.0-BETA2 aarch64 PINE64
o 14.0-BETA2 aarch64 PINE64-LTS
o 14.0-BETA2 aarch64 PINEBOOK
o 14.0-BETA2 aarch64 ROCK64
o 14.0-BETA2 aarch64 ROCKPRO64
o 14.0-BETA2 riscv64 GENERIC
o 14.0-BETA2 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

A summary of changes since 14.0-BETA1 includes:

o The Areca RAID driver has been updated to version 1.50.00.06.

o The libarchive library has been updated.

o A fix for the ZFS block_cloning feature has been implemented.

o Several linux(4) updates.

o Several manual page updates.

A list of changes since 13.x is available in the releng/14.0
release notes:

https://www.freebsd.org/releases/14.0R/relnotes/

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 14.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-BETA2/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-BETA2/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/BETA2
/aws/service/freebsd/amd64/base/zfs/14.0/BETA2

FreeBSD/arm64 EC2 AMIs are not available for this BETA build.

=== Vagrant Images ===

FreeBSD/amd64 images are not available for this BETA build.

=== Upgrading ===

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

Due to an issue where an existing file had been replaced by a directory
with the same name, binary upgrades from 13.2 and earlier using the 
freebsd-update(8) utility will not work.  The issue is being
investigated.

IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT IMPORTANT

The freebsd-update(8) utility supports binary upgrades of amd64, i386,
and aarch64 systems running earlier FreeBSD releases.  Systems running
earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-BETA2

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install

It is recommended to rebuild and install all applications if possible,
especially if upgrading from an earlier FreeBSD release, for example,
FreeBSD 

FreeBSD 14.0-BETA1 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The first BETA build of the 14.0-RELEASE release cycle is now available.

Installation images are available for:

o 14.0-BETA1 amd64 GENERIC
o 14.0-BETA1 i386 GENERIC
o 14.0-BETA1 powerpc GENERIC
o 14.0-BETA1 powerpc64 GENERIC64
o 14.0-BETA1 powerpc64le GENERIC64LE
o 14.0-BETA1 powerpcspe MPC85XXSPE
o 14.0-BETA1 armv7 GENERICSD
o 14.0-BETA1 aarch64 GENERIC
o 14.0-BETA1 aarch64 RPI
o 14.0-BETA1 aarch64 PINE64
o 14.0-BETA1 aarch64 PINE64-LTS
o 14.0-BETA1 aarch64 PINEBOOK
o 14.0-BETA1 aarch64 ROCK64
o 14.0-BETA1 aarch64 ROCKPRO64
o 14.0-BETA1 riscv64 GENERIC
o 14.0-BETA1 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/releases/ISO-IMAGES/14.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/14.0" branch.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, aarch64, and riscv64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/releases/VM-IMAGES/14.0-BETA1/

BASIC-CI images can be found at:

https://download.freebsd.org/releases/CI-IMAGES/14.0-BETA1/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMI IDs can be retrieved from the Systems Manager
Parameter Store in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/BETA1

FreeBSD/arm64 EC2 AMIs are not available for BETA1, and the cause is
being investigated.

=== Vagrant Images ===

FreeBSD/amd64 images are not available for BETA1.  The cause is being
investigated.

=== Upgrading ===

The freebsd-update(8) utility supports binary upgrades of amd64 and i386
systems running earlier FreeBSD releases.  Note, aarch64 binary updates
are expected to be available starting with BETA2, due to a configuration
error.  Systems running earlier FreeBSD releases can upgrade as follows:

# freebsd-update upgrade -r 14.0-BETA1

During this process, freebsd-update(8) may ask the user to help by
merging some configuration files or by confirming that the automatically
performed merging was done correctly.

# freebsd-update install

The system must be rebooted with the newly installed kernel before
continuing.

# shutdown -r now

After rebooting, freebsd-update needs to be run again to install the new
userland components:

# freebsd-update install

It is recommended to rebuild and install all applications if possible,
especially if upgrading from an earlier FreeBSD release, for example,
FreeBSD 12.x.  Alternatively, the user can install misc/compat12x and
other compatibility libraries, afterwards the system must be rebooted
into the new userland:

# shutdown -r now

Finally, after rebooting, freebsd-update needs to be run again to remove
stale files:

# freebsd-update install

== ISO CHECKSUMS ==

o 14.0-BETA1 amd64 GENERIC:
  SHA512 (FreeBSD-14.0-BETA1-amd64-bootonly.iso) = 
655b733d5897e741bde7d0a03ddc7893237dc468263303e5898d0590e6b7223354ce5554b9c6d1c9b6dc11d446e1804a7238382e0f5bbf59f8c54b9aed4e6ec0
  SHA512 (FreeBSD-14.0-BETA1-amd64-bootonly.iso.xz) = 
2ecf86e2f198e0f01a305f572cad987e0589e587cf9d2bebd0740c18de35e7272fe06dcfd2456c641c2924def75e734e91de28bb965b929556a842ad70923a4f
  SHA512 (FreeBSD-14.0-BETA1-amd64-disc1.iso) = 

Re: main [and, likely, stable/14]: do not set vfs.zfs.bclone_enabled=1 with that zpool feature enabled because it still leads to panics

[Glen Barber]

On Thu, Sep 07, 2023 at 11:17:22AM -0700, Mark Millard wrote:
> When I next have time, should I retry based on a more recent
> vintage of main that includes 969071be938c ?
> 

Yes, please, if you can.

Glen



signature.asc
Description: PGP signature

New FreeBSD snapshots available: stable/14 (ALPHA4) (20230901 4c3f144478d4)

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 14.0-ALPHA4 amd64 GENERIC
o 14.0-ALPHA4 i386 GENERIC
o 14.0-ALPHA4 powerpc GENERIC
o 14.0-ALPHA4 powerpc64 GENERIC64
o 14.0-ALPHA4 powerpc64le GENERIC64LE
o 14.0-ALPHA4 powerpcspe MPC85XXSPE
o 14.0-ALPHA4 armv7 GENERICSD
o 14.0-ALPHA4 aarch64 GENERIC
o 14.0-ALPHA4 aarch64 RPI
o 14.0-ALPHA4 aarch64 PINE64
o 14.0-ALPHA4 aarch64 PINE64-LTS
o 14.0-ALPHA4 aarch64 PINEBOOK
o 14.0-ALPHA4 aarch64 ROCK64
o 14.0-ALPHA4 aarch64 ROCKPRO64
o 14.0-ALPHA4 riscv64 GENERIC
o 14.0-ALPHA4 riscv64 GENERICSD

Note regarding arm/armv{6,7} 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, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Snapshots may be downloaded from the corresponding architecture
directory from:

https://download.freebsd.org/snapshots/ISO-IMAGES/

Please be patient if your local mirror has not yet caught up with the
changes.

Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .

=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 14.0-ALPHA4 amd64
o 14.0-ALPHA4 i386
o 14.0-ALPHA4 aarch64
o 14.0-ALPHA4 riscv64
o 14.0-ALPHA4 amd64 BASIC-CI

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout for UFS images is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  This is provided by the emulators/qemu port.

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  
-bios /usr/local/share/qemu/edk2-aarch64-code.fd 
-serial telnet::,server -nographic 
-drive if=none,file=VMDISK,id=hd0 
-device virtio-blk-device,drive=hd0 
-device virtio-net-device,netdev=net0 
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/snapshots/CI-IMAGES/

=== Amazon EC2 AMI Images ===

Amazon EC2 AMI images available for FreeBSD/amd64.

These AMI IDs can be retrieved from the Systems Manager Parameter Store
in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/ALPHA4
/aws/service/freebsd/amd64/base/zfs/14.0/ALPHA4

Amazon EC2 aarch64 AMI images are not available for this snapshot.

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:

% vagrant init freebsd/FreeBSD-14.0-ALPHA4
% vagrant up

== ISO CHECKSUMS ==

o 14.0-ALPHA4 amd64 GENERIC:
  SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-bootonly.iso) 
= 
be2a357b798b3a455da597bde4f89592eb73248cae7c61d613b523856c5f21b4e8607e9bb7f79eea74abab47cc0bb6007d6e207ef7fed558ad267c8162b6c8fe
  SHA512 
(FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-bootonly.iso.xz) = 
750595e6f51553b468eb47b2ab0003a326903edc80b793da84fef827ec67532a9abdecc406d117762fa638b0bc8f3d9105f8bbda566d9410444c474281414180
  SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-disc1.iso) = 
5546879f2af755060905aa78e8f573e20ff3e318c42f56595a7db816f19a219f0cd1e8cbf72da2761757ae21278e507f8e17221a30c83b805e944d4ac5ee4aae
  SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-disc1.iso.xz) 
= 
5168322946ed1a0a4ec69229eb51e798c037635aa849805d458a818d9930ece03a1d28b46c33987219074212c8ded60ba8ecbe3f5c06ed90718730b86351b7f1
  SHA512 (FreeBSD-14.0-ALPHA4-amd64-20230901-4c3f144478d4-265026-memstick.img) 
= 

Re: Possible regression in main causing poor performance

[Glen Barber]

On Mon, Aug 28, 2023 at 06:06:09PM -0700, Mark Millard wrote:
> Has any more been learned about this? Is it still an issue?
> 

I rebooted the machine before the ALPHA3 builds with no other changes,
and the overall times for 14.x builds went back to normal.  I do not
like to experiment with builders during a release cycle, but as we are
going to have 15.x snapshots available moving forward, I will not reboot
that machine next week in hopes to get some useful data.

If my memory serves correctly, mm@ has a pending ZFS import from
upstream for both main and stable/14 pending.  Whether or not that will
resolve any issue here, I do not know.

Glen



signature.asc
Description: PGP signature

New FreeBSD snapshots available: stable/14 (ALPHA3) (20230825 2af9390e54ed)

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 14.0-ALPHA3 amd64 GENERIC
o 14.0-ALPHA3 i386 GENERIC
o 14.0-ALPHA3 powerpc GENERIC
o 14.0-ALPHA3 powerpc64 GENERIC64
o 14.0-ALPHA3 powerpc64le GENERIC64LE
o 14.0-ALPHA3 powerpcspe MPC85XXSPE
o 14.0-ALPHA3 armv7 GENERICSD
o 14.0-ALPHA3 aarch64 GENERIC
o 14.0-ALPHA3 aarch64 RPI
o 14.0-ALPHA3 aarch64 PINE64
o 14.0-ALPHA3 aarch64 PINE64-LTS
o 14.0-ALPHA3 aarch64 PINEBOOK
o 14.0-ALPHA3 aarch64 ROCK64
o 14.0-ALPHA3 aarch64 ROCKPRO64
o 14.0-ALPHA3 riscv64 GENERIC
o 14.0-ALPHA3 riscv64 GENERICSD

Note, armv6 RPI-B images have been removed from the list of builds as
it is intended to be removed during the 14.0-RELEASE cycle.

Note regarding arm/armv{6,7} 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, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Snapshots may be downloaded from the corresponding architecture
directory from:

https://download.freebsd.org/snapshots/ISO-IMAGES/

Please be patient if your local mirror has not yet caught up with the
changes.

Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .

=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 14.0-ALPHA3 amd64
o 14.0-ALPHA3 i386
o 14.0-ALPHA3 aarch64
o 14.0-ALPHA3 riscv64
o 14.0-ALPHA3 amd64 BASIC-CI

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout for UFS is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  This is provided by the emulators/qemu port.

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  
-bios /usr/local/share/qemu/edk2-aarch64-code.fd 
-serial telnet::,server -nographic 
-drive if=none,file=VMDISK,id=hd0 
-device virtio-blk-device,drive=hd0 
-device virtio-net-device,netdev=net0 
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/snapshots/VM-IMAGES/

=== Amazon EC2 AMI Images ===

FreeBSD amd64 and aarch64 EC2 AMIs are available for both UFS and ZFS.

These AMI IDs can be retrieved from the Systems Manager Parameter Store
in each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/ALPHA3
/aws/service/freebsd/amd64/base/zfs/14.0/ALPHA3

/aws/service/freebsd/arm64/base/ufs/14.0/ALPHA3
/aws/service/freebsd/arm64/base/zfs/14.0/ALPHA3

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:

% vagrant init freebsd/FreeBSD-14.0-ALPHA3
% vagrant up

== ISO CHECKSUMS ==

o 14.0-ALPHA3 amd64 GENERIC:
  SHA512 (FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-bootonly.iso) 
= 
7c7dd389aba9de05bc5a44c3268541fc336aa2bd4ede294a98d913ff1a79776a1bf974a828c81fcc7e44351685b89c5d6154563baec6e8c11859e546b3ee8a79
  SHA512 
(FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-bootonly.iso.xz) = 
6a48dbddd901da8312a891a9f26309a443f9100dcbb88d9c78c20305917ba5da750de2d381e53118a704f88e83a29aec3d5365a87a37696ef01b98c6c08ab79b
  SHA512 (FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-disc1.iso) = 
f6903f80d8d6bf4498bc9df32d7d605e16061743fb7cd3935ed9aba337c18ac048c751443718bb395b8d20c178f31778f1057104ee225f0a4f7cbfa36563ddaa
  SHA512 (FreeBSD-14.0-ALPHA3-amd64-20230825-2af9390e54ed-265022-disc1.iso.xz) 
= 

HEADS-UP: stable/14 branched

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

No email was sent for the branch commit, presumably because I pushed the
branch and did subsequent changes (i.e., version numbers, etc.)
afterward.

The stable/14 branch has been created, from where the remainder of the
14.0 series will live.

Glen
On behalf of:   re@

Please consider donating to help support my FreeBSD work:
https://www.gofundme.com/f/gjbbsd
https://paypal.me/gjbbsd

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmTn5psACgkQAxRYpUeP
4pM7oQ//USj527XH8Gfy2r6VL1N6l/NI8z0Rc6cIZbYTANQ1DJol0IEFlHPP5Xl3
FZ3X0ukWIAa+pDtsPq1d6bYCBfEfZ87Jxhrw12fZWrdam0p84hC1fVuRWDXEqHe4
ecBePE8MLz4cX+mG4H4cqgyypIS6Wcg+ICqI3/TpitTK2oIzctHSh7Md0HCRzV6i
Rj5rGidyWz/tIgJSA6IHHkkTjXlvSBHRFkbVbiprkqcsSGCOa42j2kJxoHED3/S3
QPsKmjmpr2VhLjRBt+4R05phdkTXGcR1QZ4OdTd6Qo+JqGfo2j8dOXdS4awwh03v
oTqSfK7BN/Vwo/nNGoMerXhg7IL40T4WtNx9Z99b5YVOCszFbPI3YMbojWHE+jpZ
4GD5CFPh7BfroJ+/Soyoeujro+4y7FssM1FKBfwHQiZAmJVLDqVnDUmff6F5wc2X
ZfI1tawQl1e0IlFbc4fRku8HdwJn0esfGX7YiUFGnZEiX1EharHvFyhI8aUah0oO
CYnBFFMyqV5sbr4Rl1UwI9EfoZ/XfLjh6G1Rd2st33OpgpzFHV1ksjkfJjmFDOc6
JmYK9We9Ei+BopVYkyGCk8tbxRo4zbsmpL/phk9S3EYKgERDoWJ2scP4w0dKWEsf
oY2xvwR5yp2dZGCXMqqGPTJi/rd45KSQ3cgo86z8eGJcCUqXJlc=
=+xEe
-END PGP SIGNATURE-

Re: Possible regression in main causing poor performance

[Glen Barber]

On Fri, Aug 18, 2023 at 07:09:10PM -0700, Mark Millard wrote:
> Glen Barber  wrote on
> Date: Sat, 19 Aug 2023 00:10:59 UTC :
> 
> > I am somewhat inclined to look in the direction of ZFS here, as two
> > things changed:
> > 
> > 1) the build machine in question was recently (as in a week and a half
> > ago) upgraded to the tip of main in order to ease the transition from
> > this machine from building 14.x to building 15.x;
> > 2) there is the recent addition of building ZFS-backed virtual machine
> > and cloud images.
> > 
> > . . .
> > The first machine runs:
> > # uname -a
> > FreeBSD releng1.nyi.freebsd.org 14.0-CURRENT FreeBSD 14.0-CURRENT \
> > amd64 1400093 #5 main-n264224-c84617e87a70: Wed Jul 19 19:10:38 UTC 2023
> 
> I'm confused:
> 
> "the build machine in question was recently (as in a week and a half
> ago) upgraded to the tip of main in order to ease the transition from
> this machine from building 14.x to building 15.x"? But the above
> kernel is from mid July? (-aKU was not used to also get some clue
> about world from the pair of 140009? that would show.)
> 

Err, right.  I'm confused too, and apparently looked at a different
machine but copied 'uname -a' from the correct machine.  The kernel and
userland are always in sync on these machines.

  # uname -UK
  1400093 1400093

> > Last week's snapshot builds were completed in a reasonable amount of
> > time:
> > 
> > r...@releng1.nyi:/releng/scripts-snapshot/scripts # ./thermite.sh -c 
> > ./builds-14.conf ; echo ^G
> > 20230811-00:03:11 INFO: Creating /releng/scripts-snapshot/logs
> > 20230811-00:03:11 INFO: Creating /releng/scripts-snapshot/chroots
> > 20230811-00:03:12 INFO: Creating /releng/scripts-snapshot/release
> > 20230811-00:03:12 INFO: Creating /releng/scripts-snapshot/ports
> > 20230811-00:03:12 INFO: Creating /releng/scripts-snapshot/doc
> > 20230811-00:03:13 INFO: Checking out https://git.FreeBSD.org//src.git 
> > (main) to /releng/scripts-snapshot/release
> > [...]
> > 20230811-15:11:13 INFO: Staging for ftp: 14-i386-GENERIC-snap
> > 20230811-16:27:28 INFO: Staging for ftp: 14-amd64-GENERIC-snap
> > 20230811-16:33:43 INFO: Staging for ftp: 14-aarch64-GENERIC-snap
> > 
> > Overall, 17 hours, including the time to upload EC2, Vagrant, and GCE.
> > 
> > With no changes to the system, no stale ZFS datasets laying around from
> > last week (everything is a pristine environment, etc.), this week's
> > builds are taking forever:
> 
> My confusion may extend to this "no changes" status vs. the uname
> output identifying the kernel is from mid July.
> 

It is admittedly a month versus two weeks difference here.  My fault.

> > r...@releng1.nyi:/releng/scripts-snapshot/scripts # ./thermite.sh -c 
> > ./builds-14.conf ; echo ^G
> > 20230818-00:15:44 INFO: Creating /releng/scripts-snapshot/logs
> > 20230818-00:15:44 INFO: Creating /releng/scripts-snapshot/chroots
> > 20230818-00:15:45 INFO: Creating /releng/scripts-snapshot/release
> > 20230818-00:15:45 INFO: Creating /releng/scripts-snapshot/ports
> > 20230818-00:15:45 INFO: Creating /releng/scripts-snapshot/doc
> > 20230818-00:15:46 INFO: Checking out https://git.FreeBSD.org//src.git 
> > (main) to /releng/scripts-snapshot/release
> > [...]
> > 20230818-18:46:22 INFO: Staging for ftp: 14-aarch64-ROCKPRO64-snap
> > 20230818-20:41:02 INFO: Staging for ftp: 14-riscv64-GENERIC-snap
> > 20230818-22:54:49 INFO: Staging for ftp: 14-amd64-GENERIC-snap
> > 
> > Note, it is just about 4 minutes past 00:00 UTC as of this writing, so
> > we are about to cross well over the 24-hour mark, and cloud provider
> > images have not yet even started.
> > 
> > . . .
> 
> In:
> 
> https://lists.freebsd.org/archives/freebsd-current/2023-August/004314.html
> ("HEADS UP: $FreeBSD$ Removed from main", Wed, 16 Aug 2023)
> 
> Warner wrote:
> 
> QUOTE
> . . . , but there's no incremental building
> with this change, . . . Also: expect long build times, git fetch times, etc
> after this.
> END QUOTE
> 
> Might this be contributing? How long did those two
> "Checking out . . ." take? Similar time frames?
> 

Checkout times are negligible.  They are pristine environments, so there
are no delta resolutions, etc.  Everything is clean from the start.

Last week:
20230811-00:03:13   INFO:   Checking out https://git.FreeBSD.org//src.git 
(main) to /releng/scripts-snapshot/release
20230811-00:05:27   INFO:   Creating ZFS snapshot 
zroot/releng/14-src-snap@clone
20230811-00:05:33   INFO:   Checking out https://git.FreeBSD.org//ports.git 
(main) to 

New FreeBSD snapshots available: main (ALPHA2) (20230819 77013f29d048)

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 14.0-ALPHA2 amd64 GENERIC
o 14.0-ALPHA2 i386 GENERIC
o 14.0-ALPHA2 powerpc GENERIC
o 14.0-ALPHA2 powerpc64 GENERIC64
o 14.0-ALPHA2 powerpc64le GENERIC64LE
o 14.0-ALPHA2 powerpcspe MPC85XXSPE
o 14.0-ALPHA2 armv6 RPI-B
o 14.0-ALPHA2 armv7 GENERICSD
o 14.0-ALPHA2 aarch64 GENERIC
o 14.0-ALPHA2 aarch64 RPI
o 14.0-ALPHA2 aarch64 PINE64
o 14.0-ALPHA2 aarch64 PINE64-LTS
o 14.0-ALPHA2 aarch64 PINEBOOK
o 14.0-ALPHA2 aarch64 ROCK64
o 14.0-ALPHA2 aarch64 ROCKPRO64
o 14.0-ALPHA2 riscv64 GENERIC
o 14.0-ALPHA2 riscv64 GENERICSD

Note regarding arm/armv{6,7} 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, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Snapshots may be downloaded from the corresponding architecture
directory from:

https://download.freebsd.org/snapshots/ISO-IMAGES/

Please be patient if your local mirror has not yet caught up with the
changes.

Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .

=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 14.0-ALPHA2 amd64
o 14.0-ALPHA2 i386
o 14.0-ALPHA2 aarch64
o 14.0-ALPHA2 riscv64
o 14.0-ALPHA2 amd64 BASIC-CI

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  This is provided by the emulators/qemu port.

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  
-bios /usr/local/share/qemu/edk2-aarch64-code.fd 
-serial telnet::,server -nographic 
-drive if=none,file=VMDISK,id=hd0 
-device virtio-blk-device,drive=hd0 
-device virtio-net-device,netdev=net0 
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/snapshots/VM-IMAGES/

=== Amazon EC2 AMI Images ===

FreeBSD amd64 and aarch64 EC2 AMIs are available for both UFS and ZFS.
The AMI IDs can be retreived from the Systems Manager Parameter Store in
each region using the keys:

/aws/service/freebsd/amd64/base/ufs/14.0/ALPHA2
/aws/service/freebsd/arm64/base/ufs/14.0/ALPHA2

/aws/service/freebsd/amd64/base/zfs/14.0/ALPHA2
/aws/service/freebsd/arm64/base/zfs/14.0/ALPHA2

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:

% vagrant init freebsd/FreeBSD-14.0-ALPHA2
% vagrant up

== ISO CHECKSUMS ==

o 14.0-ALPHA2 amd64 GENERIC:
  SHA512 (FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-bootonly.iso) 
= 
02b4a7ba3a9520031607e6ebcbdf6cd142044aa1af40ad452c9d9793c5e70ebad94b13e679f5cb0aaa473e20f9da1f63b335b0cd25323aa03b14bd539b565ee1
  SHA512 
(FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-bootonly.iso.xz) = 
966041afcb3df8cc35063592d67ad146453783941bff80fa019d42df6e624dca2a8763940f20a7cc3857bf708e6f76e1420ed18af4a1d287cec004bdd31893ee
  SHA512 (FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-disc1.iso) = 
76f8ff46e679d4920cfe67179a587abdfd323e83c3e3f79f39678f6a956b888cf4a2a1962f9a0549a1fb481912ef41fb666bd518dc1775e90488c31b841d6aca
  SHA512 (FreeBSD-14.0-ALPHA2-amd64-20230818-77013f29d048-264841-disc1.iso.xz) 
= 
c61970abd7f2b7c0a81d5bf702e3cc65129843e3624b1a93a1476ffe535adb8dbb13378b3b049d2e742e47383c3f6bb3b2b0678977ee11873c0b50414070ea1e
  SHA512 

Possible regression in main causing poor performance

[Glen Barber]

I am somewhat inclined to look in the direction of ZFS here, as two
things changed:

1) the build machine in question was recently (as in a week and a half
   ago) upgraded to the tip of main in order to ease the transition from
   this machine from building 14.x to building 15.x;
2) there is the recent addition of building ZFS-backed virtual machine
   and cloud images.

Here is a bit of the history of the build machines:

- the second and first build 13.x and 14.x, respectively.  The third is
  (at the time it was purchased) newer than the other two, and
  significantly fast when it comes to weekly snapshots.  I'll refer to
  these machines as such: first, second, and third.

- The third machine will be eventually used to build 14.0-RELEASE.  The
  will first continue on main, where it will build 15.0-CURRENT
  snapshots.  The second will continue tracking 13-STABLE.

The first machine runs:
  # uname -a
  FreeBSD releng1.nyi.freebsd.org 14.0-CURRENT FreeBSD 14.0-CURRENT \
amd64 1400093 #5 main-n264224-c84617e87a70: Wed Jul 19 19:10:38 UTC 2023

Last week's snapshot builds were completed in a reasonable amount of
time:

  r...@releng1.nyi:/releng/scripts-snapshot/scripts # ./thermite.sh -c 
./builds-14.conf ; echo ^G
  20230811-00:03:11   INFO:   Creating /releng/scripts-snapshot/logs
  20230811-00:03:11   INFO:   Creating /releng/scripts-snapshot/chroots
  20230811-00:03:12   INFO:   Creating /releng/scripts-snapshot/release
  20230811-00:03:12   INFO:   Creating /releng/scripts-snapshot/ports
  20230811-00:03:12   INFO:   Creating /releng/scripts-snapshot/doc
  20230811-00:03:13   INFO:   Checking out https://git.FreeBSD.org//src.git 
(main) to /releng/scripts-snapshot/release
  [...]
  20230811-15:11:13   INFO:   Staging for ftp: 14-i386-GENERIC-snap
  20230811-16:27:28   INFO:   Staging for ftp: 14-amd64-GENERIC-snap
  20230811-16:33:43   INFO:   Staging for ftp: 14-aarch64-GENERIC-snap

Overall, 17 hours, including the time to upload EC2, Vagrant, and GCE.

With no changes to the system, no stale ZFS datasets laying around from
last week (everything is a pristine environment, etc.), this week's
builds are taking forever:

  r...@releng1.nyi:/releng/scripts-snapshot/scripts # ./thermite.sh -c 
./builds-14.conf ; echo ^G
  20230818-00:15:44   INFO:   Creating /releng/scripts-snapshot/logs
  20230818-00:15:44   INFO:   Creating /releng/scripts-snapshot/chroots
  20230818-00:15:45   INFO:   Creating /releng/scripts-snapshot/release
  20230818-00:15:45   INFO:   Creating /releng/scripts-snapshot/ports
  20230818-00:15:45   INFO:   Creating /releng/scripts-snapshot/doc
  20230818-00:15:46   INFO:   Checking out https://git.FreeBSD.org//src.git 
(main) to /releng/scripts-snapshot/release
  [...]
  20230818-18:46:22   INFO:   Staging for ftp: 14-aarch64-ROCKPRO64-snap
  20230818-20:41:02   INFO:   Staging for ftp: 14-riscv64-GENERIC-snap
  20230818-22:54:49   INFO:   Staging for ftp: 14-amd64-GENERIC-snap

Note, it is just about 4 minutes past 00:00 UTC as of this writing, so
we are about to cross well over the 24-hour mark, and cloud provider
images have not yet even started.

I am inclined to do two things:

1) Immediately run a subsequent snapshot build to see if it takes longer
   than 24 hours (my gut tells me it will);
2) Reboot the machine with no other changes, and immediately run this
   week's snapshot builds again (not to be public to avoid confusion).

Some interactive commands are significantly slower, such as systat,
vmstat, even top.  Creating a new window in tmux is also noticeably
slow.

Is there a third option I am overlooking in trying to identify the
drastic cause of this?

Thank you in advance.

Glen



signature.asc
Description: PGP signature

Re: Lacking "arminess" (was Re: New FreeBSD snapshots available) (OFF TOPIC)

[Glen Barber]

Ship it!

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Aug 13, 2023, at 2:39 PM, George Mitchell  wrote:
> 
> On 8/11/23 23:15, Glen Barber wrote:
>> [...]
>> It was discovered that due to human error (my own) the arm64 are, as
>> Colin put it very politely, are "lacking 'arminess'".  So, unfortunately
>> the arm64 AMIs for 14.0-ALPHA1 are incorrectly uploaded as amd64.
>> [...]
> Many years ago, one member of M.I.T.'s Tech Model Railroad Club had the
> annoying habit of assembling his model airplanes in the clubroom.  Soon,
> the club enacted a rule banning all objects capable of sustained flight
> from the club for a period o ninety-nine years and one day.  Thereafter,
> it became established procedure for the club to issue reprimands by
> declaring certain people "capable of sustained flight."
> 
> I now propose to express my displeasure with aspects of FreeBSD (which
> almost never happens, honestly!) by declaring them to "lack arminess."
> 
> My thanks to Glen Barber and Colin for creating this terminology.
> -- George
> 

Re: New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f)

[Glen Barber]

On Fri, Aug 11, 2023 at 08:53:12PM +, Glen Barber wrote:
[...]

> FreeBSD/aarch64 UFS EC2 AMIs are available in the following regions:
> 
[...]

> 
> FreeBSD/aarch64 ZFS EC2 AMIs are available in the following regions:
> 

[...]

It was discovered that due to human error (my own) the arm64 are, as
Colin put it very politely, are "lacking 'arminess'".  So, unfortunately
the arm64 AMIs for 14.0-ALPHA1 are incorrectly uploaded as amd64.

But you will receive a message stating it is the incorrect architecture,
which is better than passively failing.

Apologies for the inconvenience.

Glen



signature.asc
Description: PGP signature

New FreeBSD snapshots available: stable/14 (ALPHA1) (20230811 136fc495615f)

[Glen Barber]

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 14.0-ALPHA1 amd64 GENERIC
o 14.0-ALPHA1 i386 GENERIC
o 14.0-ALPHA1 powerpc GENERIC
o 14.0-ALPHA1 powerpc64 GENERIC64
o 14.0-ALPHA1 powerpc64le GENERIC64LE
o 14.0-ALPHA1 armv6 RPI-B
o 14.0-ALPHA1 armv7 GENERICSD
o 14.0-ALPHA1 aarch64 GENERIC
o 14.0-ALPHA1 aarch64 RPI
o 14.0-ALPHA1 aarch64 PINE64
o 14.0-ALPHA1 aarch64 PINE64-LTS
o 14.0-ALPHA1 aarch64 PINEBOOK
o 14.0-ALPHA1 aarch64 ROCK64
o 14.0-ALPHA1 aarch64 ROCKPRO64
o 14.0-ALPHA1 riscv64 GENERIC
o 14.0-ALPHA1 riscv64 GENERICSD

Note regarding arm/armv{6,7} 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, which it is strongly
recommended to change the password for both users after gaining
access to the system.

Snapshots may be downloaded from the corresponding architecture
directory from:

https://download.freebsd.org/snapshots/ISO-IMAGES/

Please be patient if your local mirror has not yet caught up with the
changes.

Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .

=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 14.0-ALPHA1 amd64
o 14.0-ALPHA1 i386
o 14.0-ALPHA1 aarch64
o 14.0-ALPHA1 riscv64
o 14.0-ALPHA1 amd64 BASIC-CI

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout for UFS is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  This is provided by the emulators/qemu port.

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  
-bios /usr/local/share/qemu/edk2-aarch64-code.fd 
-serial telnet::,server -nographic 
-drive if=none,file=VMDISK,id=hd0 
-device virtio-blk-device,drive=hd0 
-device virtio-net-device,netdev=net0 
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/snapshots/CI-IMAGES/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 UFS EC2 AMIs are available in the following regions:

  ap-south-2 region: ami-0ee95230becf80778
  ap-south-1 region: ami-03ad9777ff8bc0b6e
  eu-south-1 region: ami-0fdfdb9f7c3a58c46
  eu-south-2 region: ami-0ebed85d055e70b39
  me-central-1 region: ami-02c67cb3a99d57d57
  ca-central-1 region: ami-0d0bbdaefd0c0e181
  eu-central-1 region: ami-0a80119c6edde9265
  eu-central-2 region: ami-0a12f1c8e051dfae9
  us-west-1 region: ami-0ea4f8fce960ef2c4
  us-west-2 region: ami-09f3a6925f77e203e
  af-south-1 region: ami-0ef9719a1228e32a5
  eu-north-1 region: ami-02e6c8bc0ce909cbe
  eu-west-3 region: ami-0aa3da21b9907069a
  eu-west-2 region: ami-092c172d577027092
  eu-west-1 region: ami-04cd2017e63b5ebda
  ap-northeast-3 region: ami-077b46cc5d1c68523
  ap-northeast-2 region: ami-00aafa3de31692805
  me-south-1 region: ami-011ee7fb4001bf69f
  ap-northeast-1 region: ami-08ff003b6ff73de93
  sa-east-1 region: ami-052f0128aed100b4a
  ap-east-1 region: ami-05bcf396a33918e60
  ap-southeast-1 region: ami-0b56d17b45366f1bf
  ap-southeast-2 region: ami-01b1c6fd1bb35074d
  ap-southeast-3 region: ami-017073fdb4ae76333
  us-east-1 region: ami-029e7b689f77cce2c
  us-east-2 region: ami-0047bb65a2d73065f

FreeBSD/amd64 ZFS EC2 AMIs are available in the following regions:

  ap-south-2 region: ami-0d3f563d617979348
  ap-south-1 region: ami-03f77404c21fb5a25
  eu-south-1 region: ami-0731187e3d49f6795
  eu-south-2 region: ami-068b99a06abbe9a85
  me-central-1 region: ami-0904554cdebb1ddab
  ca-central-1 region: ami-0e96429bf976b35cb
  eu-central-1 region: ami-0cb9214edc051fc88
  eu-central-2 region: ami-0c4e6aad76680d64d
  

FreeBSD main snapshot status for 20230629

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

While we wait for the next package build to finish to address a problem
building this snapshots for main this week, we will be at least a few
days before the snapshot builds for this week.

Regards,

Glen

Please consider donating to help support my FreeBSD work:
https://www.gofundme.com/f/gjbbsd

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmSd2mkACgkQAxRYpUeP
4pMHyQ//RHh41zSH1M88KJ4C1ZVbGsiQP11SK03dNAMQxYZ96wFOe0NdLxISUHR7
tVqnxaPAvVDTBKNjWj8X949j63ePYHGK+6YyhqAB8/V4mORrozZzoCJVQaiPNbLI
ffzq05sv8mOHqJxJ3BlhyrvIaTZbhJlSroMXy0ct8e8Z/5MbgpwQzAZev9RaKh7Z
Ican/zPN6+uZSTyaQBxC/JHdb4UnwYma4GF9DuZCkkIcgbwIt/uqcl9yKM8oahF+
/+OzRS1v8Flz2zTDNivMBB2jw82yrqXOFCT3fq6z9J7OYfLRggdbcEGk//ghkKiU
nq3CZjeZrJr9FyQKCg9dRhbo9Ykymq0/DceAXrfRZFkA69kD9ehIWuleOOa7CKYc
MdqCzBlVFnC2RzzTWDKHcEaAxyrowIYNWvDh4UsHmHfwkfRXjhWsv4Oxdw5l7BnJ
8wbyABliDYlnXMM93FJtfQsS9q2LOtYCHnvWdDqIpzrhfqG2iGKFIMHKfkk0sMJr
KRyhMm1OLJQmRLqWhE0YLDAvgbxAOkSGDHcN0tacoe3E4eSPJdVirhcSUa8EocnQ
Omap7reM0Y/9Bk+b9ddHVXz1cp7goTT421nUuENVVfqGqE5yPj7ejX8eR+T6JBWF
4SCsvKLRskdq4C5U8MkCo945+AZKaEBfQrPnXPfg/bpv98h/fBU=
=TEzG
-END PGP SIGNATURE-

Updated 14.0-RELEASE schedule

[Glen Barber]

This is the updated schedule for the 14.0-RELEASE release cycle, which
will begin August 4, 2023.  The schedule for the release cycle is:

 head slush/KBI freeze:   August 4, 2023
 [... ALPHA builds ...]:  TBD
 stable/14 branch:August 18, 2023
 [... ALPHA builds ...]:  TBD
 releng/14.0 branch:  September 8, 2023
 BETA 1 build starts: September 8, 2023
 doc/ tree slush: September 10, 2023
 BETA2 build starts:  September 15, 2023
 BETA3 build starts:  September 22, 2023 [*]
 doc/ tree tag:   September 24, 2023
 RC1 build starts:September 29, 2023
 ports quarterly branch:  October 1, 2023
 RC2 build starts:October 6, 2023
 RC3 build starts:October 13, 2023 [*]
 RELEASE build starts:October 20, 2023
 RELEASE announcement:October 23, 2023
 Branch EoL:  October 31, 2028

 [*]   - If needed

The schedule is also be available on the FreeBSD Project website at:

  https://www.freebsd.org/releases/14.0R/schedule/

Thank you for your patience during the delay while we continue to bring
high quality releases.

And, of course, thank you to everyone involved in helping get us past
the blocking items for this release.

Glen
On behalf of:   re@

You can help me continue work on FreeBSD:
https://www.gofundme.com/f/gjbbsd



signature.asc
Description: PGP signature

Re: Delay in 14.0-RELEASE cycle and blocking items

[Glen Barber]

On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote:
[...]
> A more up-to-date schedule for the 14.0 release will be published in the
> near future, though nothing is yet set in stone.
> 
> Thank you for your patience, and for any help in getting us through
> these outstanding items.
> 

Just a quick update on this:  I am working on the updated draft schedule
for 14.0-RELEASE, and will send several teams internally for comments.

A new schedule should be expected to be available on the website and
announced on these mailing lists within the week, give or take a few
days.

Thank you again for your patience and the need for the delay.

And certainly not to be excluded - thank you to everyone who helped in
ironing out the issues blocking 14.0.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

Re: CURRRENT snapshot won't boot due missing ZFS feature

[Glen Barber]

On Thu, Jun 08, 2023 at 06:11:15PM +0200, Michael Gmelin wrote:
> Hi,
> 
> I didn't dig into this yet.
> 
> After installing the current 14-snapshot (June 1st) in a bhyve-vm, I
> get this on boot:
> 
>   ZFS: unsupported feature: com.klarasystems:vdev_zaps_v2
> 
> (booting stops at this point)
> 
> Seems like the boot loader is missing this recently added feature.
> 

Can you try today's snapshot?  They are propagated to most mirrors now.

Glen



signature.asc
Description: PGP signature

Re: Delay in 14.0-RELEASE cycle and blocking items

[Glen Barber]

On Mon, May 15, 2023 at 09:15:52PM +0200, Michael Osipov wrote:
> Glen,
> 
> do you see any chance to get this finally merged:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236204 ?
> 
> It seriously affects people (in enterprises) behind a proxy, curl will
> be a problem and py-requests is already a serious problem.
> 

I have bumped the bug, and pinged sef@ and cc'd re@ as a result.

I do not see a problem with it, as long as it is a proper fix.

Glen



signature.asc
Description: PGP signature

Re: Delay in 14.0-RELEASE cycle and blocking items

[Glen Barber]

On Wed, May 03, 2023 at 07:53:09AM +, Alexey Dokuchaev wrote:
> On Mon, May 01, 2023 at 06:14:49PM +0000, Glen Barber wrote:
> > ...
> > There is no feasible way we are going to make the branch point of
> > stable/14 in time, with that scheduled for May 12, 2023 with the above
> > points.  That said, this is not an all-inclusive list, but the more
> > major items on our radar at the moment.
> 
> Does this delay mean we might get Clang 16 in the base?
> 

Well, the delay really means we do not currently have OpenSSL 3 in base.

Glen



signature.asc
Description: PGP signature

Delay in 14.0-RELEASE cycle and blocking items

[Glen Barber]

According to the 14.0-RELEASE schedule, the code slush in main and the
freeze to the KBI for 14.0 was scheduled for April 25, 2023.  As some of
you may have noticed, that did not happen.

First, and most importantly for 14.0, is the status of the OpenSSL
update to version 3.  This in itself is reason to delay the schedule
until some tangible progress has been made.  Yes, some have expressed
interest in helping in this area, however at this moment, this is the
key blocker.

Second is the status of the branch and how it pertains to the recent
upstream merge from OpenZFS.  Although block_cloning is disabled by
default, there have been other regressions discovered (and fixed), but
as a whole, I do not feel that we have a solid understanding of the
regressions about which we do not know.

There is no feasible way we are going to make the branch point of
stable/14 in time, with that scheduled for May 12, 2023 with the above
points.  That said, this is not an all-inclusive list, but the more
major items on our radar at the moment.

A more up-to-date schedule for the 14.0 release will be published in the
near future, though nothing is yet set in stone.

Thank you for your patience, and for any help in getting us through
these outstanding items.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

Re: bsdinstall partition error when installing to nvme

[Glen Barber]

On Fri, Apr 22, 2022 at 11:04:29PM +0100, tech-lists wrote:
> Hi Glen,
> 
> On Fri, Apr 22, 2022 at 09:36:45PM +0000, Glen Barber wrote:
> > 
> > This may be related to:
> > 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263473
> 
> Do you think it'd be useful to the ticket if I added my
> error?
> 
> My context was a little different (current/14 and bsdinstall)
> 

Yes, please do, in case it is indeed related.

Glen



signature.asc
Description: PGP signature

Re: bsdinstall partition error when installing to nvme

[Glen Barber]

On Fri, Apr 22, 2022 at 10:31:31PM +0100, tech-lists wrote:
> Hi,
> 
> Attempting to install from:
> FreeBSD-14.0-CURRENT-amd64-20220421-b91a48693a5-254961-memstick.img
> 
> to brand-new hardware, the installer failed at the stage after where one
> selects partition schema (so, GPT in this case) and UFS filesystem
> with an error like (sorry to be paraphrasing this from memory as the
> hardware is no longer available)
> 
> "autopart failed -5"
> 
> I thought it might be down to it being a nvme stick. The hardware
> in question is Crucial;CT1000P5PSSD8 1TB. Is this a known issue
> with nvme? On that machine, this was the only "disk". Can
> nvme be used as the primary disk on FreeBSD?
> 

This may be related to:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263473

Glen



signature.asc
Description: PGP signature

Re: Considering stepping down from all of my FreeBSD responsibilities

[Glen Barber]

On Fri, Apr 01, 2022 at 06:56:27PM +0200, Patrick M. Hausen wrote:
> Hi all,
> 
> > Am 01.04.2022 um 18:38 schrieb Cy Schubert :
> > I had a different more sinister thought: Announcing that we've moved from 
> > BSDL to GPLv3 to be more like Linux.
> 
> Don't we need explicit consent from every contributor for such a major 
> license change?
> Shouldn't we start over from 1.1.5.1 in that case to keep the number of 
> people lower?
> 

You're joking, right?  If so, amusing.  If not, check the date...

Glen



signature.asc
Description: PGP signature

Re: Considering stepping down from all of my FreeBSD responsibilities

[Glen Barber]

On Fri, Apr 01, 2022 at 11:42:48AM -0500, Justin Hibbits wrote:
> On Fri, 01 Apr 2022 09:38:07 -0700
> Cy Schubert  wrote:
> 
> > In message <20220401064816.gs60...@eureka.lemis.com>, Greg 'groggy'
> > Lehey write
> > s:
> > > 
> > > --TSQPSNmi3T91JED+
> > > Content-Type: text/plain; charset=us-ascii
> > > Content-Disposition: inline
> > >
> > > On Friday,  1 April 2022 at  5:58:39 +, Alexey Dokuchaev wrote:
> > >  
> > > > On Fri, Apr 01, 2022 at 02:20:31PM +0900, Yasuhiro Kimura wrote:  
> > > >> Hi Glen,
> > > >>
> > > >> From: Glen Barber 
> > > >> Subject: Considering stepping down from all of my FreeBSD
> > > >> responsibilities Date: Fri, 1 Apr 2022 00:15:02 +
> > > >>  
> > > >>> Dear community,
> > > >>>
> > > >>> Given the mental toll the past two years or so have taken on
> > > >>> me, I have decided to step down from all of my "hats" within
> > > >>> the Project, and take some time to sort out what my future
> > > >>> looks like going forward.
> > > >>>
> > > >>> Happy April 1st.  I'm not going anywhere.  :-)  
> > > >>
> > > >> We are waiting for the announce of FreeBSD 2.2.10-RELEASE. :-)
> > > >>
> > > >> Cf.
> > > >> https://lists.freebsd.org/pipermail/freebsd-announce/2006-April/001055
> > > >>  
> > > .html  
> > > >
> > > > I don't think 2.2.10 is warranted.  
> > >
> > > Agreed.  The upgrade isn't sufficiently important.
> > >
> > > How about 2.2.9.1?  
> > 
> > I had a different more sinister thought: Announcing that we've moved
> > from BSDL to GPLv3 to be more like Linux.
> > 
> > 
> 
> Take it to the next level.  Since we're using git you can make the
> license change, do the commit, then send the commit email out, and it
> would have the valid hash and all.
> 

I was so very close to doing something similar, but I was more worried
about screwing up my local trees.

Glen



signature.asc
Description: PGP signature

Re: Considering stepping down from all of my FreeBSD responsibilities

[Glen Barber]

On Thu, Mar 31, 2022 at 06:18:16PM -0600, The Doctor wrote:
> On Fri, Apr 01, 2022 at 12:15:02AM +0000, Glen Barber wrote:
> > Dear community,
> > 
> > Given the mental toll the past two years or so have taken on me, I have
> > decided to step down from all of my "hats" within the Project, and take
> > some time to sort out what my future looks like going forward.
> > 
> > Happy April 1st.  I'm not going anywhere.  :-)
> >
> 
> Now for Linux and M$ to be a bad April Fools' joke.
> 

Damn, I did not think of that... :-)

Glen



signature.asc
Description: PGP signature

Considering stepping down from all of my FreeBSD responsibilities

[Glen Barber]

Dear community,

Given the mental toll the past two years or so have taken on me, I have
decided to step down from all of my "hats" within the Project, and take
some time to sort out what my future looks like going forward.

Happy April 1st.  I'm not going anywhere.  :-)

Glen



signature.asc
Description: PGP signature

Re: [RFC] Making mount_nfs to attempt NFSv4 before NFSv3 and NFSv2?

[Glen Barber]

On Tue, Jan 04, 2022 at 12:15:12AM +, Colin Percival wrote:
> On 1/3/22 10:51, Xin Li wrote:
> > [...]
> > So I think it makes sense to teach mount_nfs to attempt NFSv4, then
> > NFSv3 and NFSv2.  However, this might be a POLA violation and we would
> > like to know if there is any objections.
> 
> This seems like a sensible change of defaults to make in 14-CURRENT; please
> add an entry to RELNOTES so that users will be alerted to the change.
> 
> I don't think this should be MFCed.
> 

I am torn on the topic, and would like to hear feedback from others that
use NFS (I personally do not, so this change does not affect me).
I will agree with whatever is the outcome of the majority.

Glen



signature.asc
Description: PGP signature

Re: Building multiple kernels with "make release"

[Glen Barber]

It is on my list of things to look into next week.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Aug 20, 2021, at 4:10 PM, Alan Somers  wrote:
> 
> 
>> On Thu, Jul 29, 2021 at 12:43 PM Emmanuel Vadot  
>> wrote:
>> On Thu, 29 Jul 2021 00:13:54 +
>> Glen Barber  wrote:
>> 
>> > On Wed, Jul 28, 2021 at 06:00:28PM -0600, Alan Somers wrote:
>> > > On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz> 
>> > > wrote:
>> > > 
>> > > > On 28/07/2021 20:46, Juraj Lutter wrote:
>> > > > >
>> > > > >
>> > > > >> On 28 Jul 2021, at 20:37, Glen Barber  wrote:
>> > > > >>
>> > > > >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
>> > > > >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber  
>> > > > >>> wrote:
>> > > > >>>> Just on a hunch, could you try with adding 
>> > > > >>>> INSTALLKERNEL="${KERNEL}"
>> > > > to
>> > > > >>>> your release.conf?
>> > > > >>>>
>> > > > >>>> I now seem to recall some weirdness with this, but the exact 
>> > > > >>>> details
>> > > > >>>> elude me at the moment.
>> > > > >>>>
>> > > > >>>
>> > > > >>> Setting INSTALLKERNEL="GENERIC-NODEBUG"  during "make 
>> > > > >>> installkernel"
>> > > > >>> overrides whatever KERNCONF was set to.  But it still only 
>> > > > >>> installs one
>> > > > >>> kernel.  Trying to set that variable to a list doesn't work.
>> > > > >>
>> > > > >> Ok.  Give me a day or so to try to figure out what is (or isn't)
>> > > > >> happening here.  I do not recall any recent-ish changes that would 
>> > > > >> have
>> > > > >> caused this, and I am 95% certain it has worked in the past.
>> > > > >
>> > > > > According to Makefile.inc1:
>> > > > >
>> > > > > make installkernel KERNCONF=?KERN1 KERN2?
>> > > > >
>> > > > > should install KERN1 and KERN2. Similar goes for buildkernel.
>> > > > >
>> > > > > Or is there something I am missing?
>> > > >
>> > > > Does 'make installkernel KERNCONF=?KERN1 KERN2?' really install both
>> > > > kernels? Under which names?
>> > > > I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
>> > > > kernels are built by "make buildkernel" but only one installed by "make
>> > > > installkernel".
>> > > >
>> > > > To install other kernels I use:
>> > > >
>> > > > make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
>> > > >
>> > > > make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
>> > > >
>> > > 
>> > > Miroslav is right.  Despite the comment that Juraj found, "make
>> > > installkernel" only installs the first kernel listed in KERNCONF.
>> > 
>> > Good find.  I honestly thought this worked as expected versus as
>> > written.  In fact, I *thought* secondary, tertiary, etc. kernels were
>> > installed as /boot/kernel.KERN2, /boot/kernel.KERN3 (using the example
>> > above).
>> 
>>  You need to set NO_INSTALLEXTRAKERNELS=no for that to happens (yes the
>> variable name and double no sucks if anyone have a patch for that that
>> would be awesome).
>> 
>> > Although, I may be misremembering, and 'kernel.KERN2.txz' may be created
>> > instead, although not installed/extracted.  Though, we are going back at
>> > least seven years, and I do not even remember what I had eaten for
>> > dinner last night, so there's that...
>> > 
>> > Glen
>> > 
>> 
>> 
>> -- 
>> Emmanuel Vadot  
> 
>  NO_INSTALLEXTRAKERNELS=no works for "make installkernel".  However, it still 
> doesn't work with release.sh.  It seems there is work left to do.
> -Alan

Re: Building multiple kernels with "make release"

[Glen Barber]

On Wed, Jul 28, 2021 at 06:00:28PM -0600, Alan Somers wrote:
> On Wed, Jul 28, 2021 at 5:52 PM Miroslav Lachman <000.f...@quip.cz> wrote:
> 
> > On 28/07/2021 20:46, Juraj Lutter wrote:
> > >
> > >
> > >> On 28 Jul 2021, at 20:37, Glen Barber  wrote:
> > >>
> > >> On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> > >>> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber  wrote:
> > >>>> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}"
> > to
> > >>>> your release.conf?
> > >>>>
> > >>>> I now seem to recall some weirdness with this, but the exact details
> > >>>> elude me at the moment.
> > >>>>
> > >>>
> > >>> Setting INSTALLKERNEL="GENERIC-NODEBUG"  during "make installkernel"
> > >>> overrides whatever KERNCONF was set to.  But it still only installs one
> > >>> kernel.  Trying to set that variable to a list doesn't work.
> > >>
> > >> Ok.  Give me a day or so to try to figure out what is (or isn't)
> > >> happening here.  I do not recall any recent-ish changes that would have
> > >> caused this, and I am 95% certain it has worked in the past.
> > >
> > > According to Makefile.inc1:
> > >
> > > make installkernel KERNCONF=“KERN1 KERN2”
> > >
> > > should install KERN1 and KERN2. Similar goes for buildkernel.
> > >
> > > Or is there something I am missing?
> >
> > Does 'make installkernel KERNCONF=“KERN1 KERN2”' really install both
> > kernels? Under which names?
> > I have 3 kernels defined in KERNCONF in /etc/make.conf for years. 3
> > kernels are built by "make buildkernel" but only one installed by "make
> > installkernel".
> >
> > To install other kernels I use:
> >
> > make installkernel KERNCONF=KERN2 KODIR=/boot/kernel.KERN2
> >
> > make installkernel KERNCONF=KERN3 KODIR=/boot/kernel.KERN3
> >
> 
> Miroslav is right.  Despite the comment that Juraj found, "make
> installkernel" only installs the first kernel listed in KERNCONF.

Good find.  I honestly thought this worked as expected versus as
written.  In fact, I *thought* secondary, tertiary, etc. kernels were
installed as /boot/kernel.KERN2, /boot/kernel.KERN3 (using the example
above).

Although, I may be misremembering, and 'kernel.KERN2.txz' may be created
instead, although not installed/extracted.  Though, we are going back at
least seven years, and I do not even remember what I had eaten for
dinner last night, so there's that...

Glen



signature.asc
Description: PGP signature

Re: Building multiple kernels with "make release"

[Glen Barber]

On Wed, Jul 28, 2021 at 08:46:19PM +0200, Juraj Lutter wrote:
> 
> 
> > On 28 Jul 2021, at 20:37, Glen Barber  wrote:
> > 
> > On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> >> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber  wrote:
> >>> Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
> >>> your release.conf?
> >>> 
> >>> I now seem to recall some weirdness with this, but the exact details
> >>> elude me at the moment.
> >>> 
> >> 
> >> Setting INSTALLKERNEL="GENERIC-NODEBUG"  during "make installkernel"
> >> overrides whatever KERNCONF was set to.  But it still only installs one
> >> kernel.  Trying to set that variable to a list doesn't work.
> > 
> > Ok.  Give me a day or so to try to figure out what is (or isn't)
> > happening here.  I do not recall any recent-ish changes that would have
> > caused this, and I am 95% certain it has worked in the past.
> 
> According to Makefile.inc1:
> 
> make installkernel KERNCONF=“KERN1 KERN2”
> 
> should install KERN1 and KERN2. Similar goes for buildkernel.
> 
> Or is there something I am missing?
> 

Nope, I think you found what is missing.  I'll test changes to
release.sh tomorrow after tonight's snapshot builds are done.

Thank you for the hint.

Glen



signature.asc
Description: PGP signature

Re: Building multiple kernels with "make release"

[Glen Barber]

On Wed, Jul 28, 2021 at 12:05:25PM -0600, Alan Somers wrote:
> On Wed, Jul 28, 2021 at 11:57 AM Glen Barber  wrote:
> > Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
> > your release.conf?
> >
> > I now seem to recall some weirdness with this, but the exact details
> > elude me at the moment.
> >
> 
> Setting INSTALLKERNEL="GENERIC-NODEBUG"  during "make installkernel"
> overrides whatever KERNCONF was set to.  But it still only installs one
> kernel.  Trying to set that variable to a list doesn't work.

Ok.  Give me a day or so to try to figure out what is (or isn't)
happening here.  I do not recall any recent-ish changes that would have
caused this, and I am 95% certain it has worked in the past.

Glen



signature.asc
Description: PGP signature

Re: Building multiple kernels with "make release"

[Glen Barber]

On Wed, Jul 28, 2021 at 05:32:03PM +, Glen Barber wrote:
> On Wed, Jul 28, 2021 at 11:30:44AM -0600, Alan Somers wrote:
> > On Wed, Jul 28, 2021 at 11:28 AM Glen Barber  wrote:
> > 
> > > On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote:
> > > > On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote:
> > > > > Is it possible to build multiple different kernels and include them
> > > all in
> > > > > a release image?  release.conf says so.  But from experiment, what I
> > > see is
> > > > > that:
> > > > >
> > > > > * release.sh does pass both kernels in the KERNCONF variable to "make
> > > > > buildkernel"
> > > > > * "make buildkernel" dutifully builds both
> > > > > * BUT, "make installkernel" only installs the first kernel and ignores
> > > the
> > > > > rest
> > > > > * Only the first kernel ends up in the final image
> > > > > * It's not really clear where an alternate kernel should go, anyway.
> > > > > Probably someplace like /boot/kernel.debug , but release.conf doesn't
> > > > > provide a way to specify that.
> > > > >
> > > > > So is the "multiple kernels in release.conf" feature unfinished?  If
> > > so,
> > > > > does anybody have a good idea about the best way to finish it?
> > > > >
> > > > >
> > > https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32
> > > > >
> > > >
> > > > Last I was aware, based on a patch sent to me privately, I believe, it
> > > > should work.
> > > >
> > > > Let me take a look.
> > > >
> > >
> > > Oh, wait.  Are you using 'make release' or release/release.sh?
> > >
> > 
> > I'm using release.sh.  I thought that was just a wrapper for "make
> > release".
> 
> It is, I just want to make sure I'm looking in the right place(s).
> 

Just on a hunch, could you try with adding INSTALLKERNEL="${KERNEL}" to
your release.conf?

I now seem to recall some weirdness with this, but the exact details
elude me at the moment.

Glen



signature.asc
Description: PGP signature

Re: Building multiple kernels with "make release"

[Glen Barber]

On Wed, Jul 28, 2021 at 11:30:44AM -0600, Alan Somers wrote:
> On Wed, Jul 28, 2021 at 11:28 AM Glen Barber  wrote:
> 
> > On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote:
> > > On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote:
> > > > Is it possible to build multiple different kernels and include them
> > all in
> > > > a release image?  release.conf says so.  But from experiment, what I
> > see is
> > > > that:
> > > >
> > > > * release.sh does pass both kernels in the KERNCONF variable to "make
> > > > buildkernel"
> > > > * "make buildkernel" dutifully builds both
> > > > * BUT, "make installkernel" only installs the first kernel and ignores
> > the
> > > > rest
> > > > * Only the first kernel ends up in the final image
> > > > * It's not really clear where an alternate kernel should go, anyway.
> > > > Probably someplace like /boot/kernel.debug , but release.conf doesn't
> > > > provide a way to specify that.
> > > >
> > > > So is the "multiple kernels in release.conf" feature unfinished?  If
> > so,
> > > > does anybody have a good idea about the best way to finish it?
> > > >
> > > >
> > https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32
> > > >
> > >
> > > Last I was aware, based on a patch sent to me privately, I believe, it
> > > should work.
> > >
> > > Let me take a look.
> > >
> >
> > Oh, wait.  Are you using 'make release' or release/release.sh?
> >
> 
> I'm using release.sh.  I thought that was just a wrapper for "make
> release".

It is, I just want to make sure I'm looking in the right place(s).

Glen



signature.asc
Description: PGP signature

Re: Building multiple kernels with "make release"

[Glen Barber]

On Wed, Jul 28, 2021 at 05:26:50PM +, Glen Barber wrote:
> On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote:
> > Is it possible to build multiple different kernels and include them all in
> > a release image?  release.conf says so.  But from experiment, what I see is
> > that:
> > 
> > * release.sh does pass both kernels in the KERNCONF variable to "make
> > buildkernel"
> > * "make buildkernel" dutifully builds both
> > * BUT, "make installkernel" only installs the first kernel and ignores the
> > rest
> > * Only the first kernel ends up in the final image
> > * It's not really clear where an alternate kernel should go, anyway.
> > Probably someplace like /boot/kernel.debug , but release.conf doesn't
> > provide a way to specify that.
> > 
> > So is the "multiple kernels in release.conf" feature unfinished?  If so,
> > does anybody have a good idea about the best way to finish it?
> > 
> > https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32
> > 
> 
> Last I was aware, based on a patch sent to me privately, I believe, it
> should work.
> 
> Let me take a look.
> 

Oh, wait.  Are you using 'make release' or release/release.sh?

Glen



signature.asc
Description: PGP signature

Re: Building multiple kernels with "make release"

[Glen Barber]

On Wed, Jul 28, 2021 at 11:11:48AM -0600, Alan Somers wrote:
> Is it possible to build multiple different kernels and include them all in
> a release image?  release.conf says so.  But from experiment, what I see is
> that:
> 
> * release.sh does pass both kernels in the KERNCONF variable to "make
> buildkernel"
> * "make buildkernel" dutifully builds both
> * BUT, "make installkernel" only installs the first kernel and ignores the
> rest
> * Only the first kernel ends up in the final image
> * It's not really clear where an alternate kernel should go, anyway.
> Probably someplace like /boot/kernel.debug , but release.conf doesn't
> provide a way to specify that.
> 
> So is the "multiple kernels in release.conf" feature unfinished?  If so,
> does anybody have a good idea about the best way to finish it?
> 
> https://github.com/freebsd/freebsd-src/blob/7045b1603bdf054145dd958a4acc17b410fb62a0/release/release.conf.sample#L32
> 

Last I was aware, based on a patch sent to me privately, I believe, it
should work.

Let me take a look.

Glen



signature.asc
Description: PGP signature

Re: FreeBSD 13.0-RC5 Now Available

[Glen Barber]

Is it necessary to quote the *entire* email (including checksums)?

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Apr 4, 2021, at 4:50 PM, Alan Somers  wrote:
> 
> On Sat, Apr 3, 2021 at 9:34 AM Glen Barber  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> The fifth RC build of the 13.0-RELEASE release cycle is now available.
>> 
>> Installation images are available for:
>> 
>> o 13.0-RC5 amd64 GENERIC
>> o 13.0-RC5 i386 GENERIC
>> o 13.0-RC5 powerpc GENERIC
>> o 13.0-RC5 powerpc64 GENERIC64
>> o 13.0-RC5 powerpc64le GENERIC64LE
>> o 13.0-RC5 powerpcspe MPC85XXSPE
>> o 13.0-RC5 armv6 RPI-B
>> o 13.0-RC5 armv7 GENERICSD
>> o 13.0-RC5 aarch64 GENERIC
>> o 13.0-RC5 aarch64 RPI
>> o 13.0-RC5 aarch64 PINE64
>> o 13.0-RC5 aarch64 PINE64-LTS
>> o 13.0-RC5 aarch64 PINEBOOK
>> o 13.0-RC5 aarch64 ROCK64
>> o 13.0-RC5 aarch64 ROCKPRO64
>> o 13.0-RC5 riscv64 GENERIC
>> o 13.0-RC5 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 available by default for ssh(1) access.  Additionally,
>> the root user password is set to root.  It is strongly recommended
>> to change the password for both users after gaining access to the
>> system.
>> 
>> Installer images and memory stick images are available here:
>> 
>> https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/
>> 
>> The image checksums follow at the end of this e-mail.
>> 
>> If you notice problems you can report them through the Bugzilla PR
>> system or on the -stable mailing list.
>> 
>> If you would like to use Git to do a source based update of an existing
>> system, use the "releng/13.0" branch.
>> 
>> A summary of changes since 13.0-RC4 includes:
>> 
>> o COMPAT_FREEBSD32 fill/set dbregs/fpregs has been implemented for
>>   aarch64.
>> 
>> o Miscellaneous DTrace updates.
>> 
>> o An issue that could potentially affect some services to properly
>>   restart, notably Nginx, has been addressed.
>> 
>> o Miscellaneous networking fixes.
>> 
>> A list of changes since 12.2-RELEASE is available in the releng/13.0
>> release notes:
>> 
>> https://www.freebsd.org/releases/13.0R/relnotes.html
>> 
>> Please note, the release notes page is not yet complete, and will be
>> updated on an ongoing basis as the 13.0-RELEASE cycle progresses.
>> 
>> === Virtual Machine Disk Images ===
>> 
>> VM disk images are available for the amd64, i386, and aarch64
>> architectures.  Disk images may be downloaded from the following URL
>> (or any of the FreeBSD download mirrors):
>> 
>> https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC5/
>> 
>> The partition layout is:
>> 
>> ~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
>> ~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
>> ~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)
>> 
>> The disk images are available in QCOW2, VHD, VMDK, and raw disk image
>> formats.  The image download size is approximately 135 MB and 165 MB
>> respectively (amd64/i386), decompressing to a 21 GB sparse image.
>> 
>> Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
>> loader file is needed for qemu-system-aarch64 to be able to boot the
>> virtual machine images.  See this page for more information:
>> 
>> https://wiki.freebsd.org/arm64/QEMU
>> 
>> To boot the VM image, run:
>> 
>> % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
>> -bios QEMU_EFI.fd -serial telnet::,server -nographic \
>> -drive if=none,file=VMDISK,id=hd0 \
>> -device virtio-blk-device,drive=hd0 \
>> -device virtio-net-device,netdev=net0 \
>> -netdev user,id=net0
>> 
>> Be sure to replace "VMDISK" with the path to the virtual machine image.
>> 
>> BASIC-CI images can be found at:
>> 
>> https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-RC5/
>> 
>> === Amazon EC2 AMI Images ===
>> 
>> FreeBSD/amd64 EC2 AMIs are available in the following regions:
>> 
>>   af-south-1 region: ami-0fe76e3a8c6a8d108
>>   eu-north-1 region: ami-0fe9d5e3fd7bd2972
>>   ap-south-1 region: ami-0090069af2f905566
>>   eu-west-3 region: ami-042ea753bff8d6a9d
>>   eu-west-2 region: ami-08e035

FreeBSD 13.0-RC5 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The fifth RC build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-RC5 amd64 GENERIC
o 13.0-RC5 i386 GENERIC
o 13.0-RC5 powerpc GENERIC
o 13.0-RC5 powerpc64 GENERIC64
o 13.0-RC5 powerpc64le GENERIC64LE
o 13.0-RC5 powerpcspe MPC85XXSPE
o 13.0-RC5 armv6 RPI-B
o 13.0-RC5 armv7 GENERICSD
o 13.0-RC5 aarch64 GENERIC
o 13.0-RC5 aarch64 RPI
o 13.0-RC5 aarch64 PINE64
o 13.0-RC5 aarch64 PINE64-LTS
o 13.0-RC5 aarch64 PINEBOOK
o 13.0-RC5 aarch64 ROCK64
o 13.0-RC5 aarch64 ROCKPRO64
o 13.0-RC5 riscv64 GENERIC
o 13.0-RC5 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-RC4 includes:

o COMPAT_FREEBSD32 fill/set dbregs/fpregs has been implemented for
  aarch64.

o Miscellaneous DTrace updates.

o An issue that could potentially affect some services to properly
  restart, notably Nginx, has been addressed.

o Miscellaneous networking fixes.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC5/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-RC5/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0fe76e3a8c6a8d108
  eu-north-1 region: ami-0fe9d5e3fd7bd2972
  ap-south-1 region: ami-0090069af2f905566
  eu-west-3 region: ami-042ea753bff8d6a9d
  eu-west-2 region: ami-08e0358d71a41ce97
  eu-south-1 region: ami-0a1cb76bf83c3c49c
  eu-west-1 region: ami-0559fa7d3edc6e607
  ap-northeast-3 region: ami-04492324222abcb1b
  ap-northeast-2 region: ami-0e851ff1f260888fd
  me-south-1 region: ami-087ab54ec6e4d0cbb
  ap-northeast-1 region: ami-0796973b853fba5e0
  sa-east-1 region: ami-03f738fc556689a14
  ca-central-1 region: ami-05f22cba7be241fbe
  ap-east-1 region: ami-07ac68b5cc29039bc
  ap-southeast-1 region: ami-04a8c807e53f07e72
  ap-southeast-2 region: ami-097dc8195cad3a688
  eu-central-1 region: ami-013f760d364d2d6a7
  us-east-1 region: ami-0e5adeb6a86cb63c4
  us-east-2 region: ami-04aac5053216613b1
  us-west-1 region: ami-07a9e536124bc5cd3
  us-west-2 region: ami-0d590e9beb5038bd0

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-085df8d192daddc93
  eu-north-1 region: ami-035b8e0f104183bde
  ap-south-1 region: ami-0224f547eb20ded51
  eu-west-3 region: ami-092ad93b82e3a558a
  eu-west-2 region: ami-0567fa1f5daa6c238
  eu-south-1 region: ami-00615cebecc52f525
  eu-west-1 region: ami-0e2950449c94e05c8
  ap-northeast-3 region: ami-03b7571b4a4af049e
  ap-northeast-2 region: ami-0b570af0ee358ee72
  me-south-1 region: ami-0c57b43738fd4004b
  ap-northeast-1 region: ami-0e17a574439ffb174
  sa-east-1 region: 

Re: update to RC4 from RC3 shutdown regression

[Glen Barber]

On Wed, Mar 31, 2021 at 11:22:58AM -0500, Antonio Olivares wrote:
> On Wed, Mar 31, 2021 at 11:03 AM Glen Barber  wrote:
> >
> > On Tue, Mar 30, 2021 at 07:54:45PM -0500, Antonio Olivares wrote:
> > > Dear all,
> > >
> > > after updating to RC4 with
> > > # freebsd-update -r upgrade 13.0RC4
> > > When I shutdown, I get error messages AE_??? PCI
> > >
> > >
> > > Press any key to reboot
> > >
> > > It shutdown before from 13.0-BETA4 updated all the way to RC3. I can save 
> > > a
> > > screenshot if needed.  Thanks.
> >
> > Please do.
> >
> 
> Dear Sir,
> 
> I shutdown today to see if I got the same message, but I did not.  If
> I do encounter this again, I will do my best to save a screenshot and
> post it.
> 

Okay, thank you.

Glen



signature.asc
Description: PGP signature

Re: update to RC4 from RC3 shutdown regression

[Glen Barber]

On Tue, Mar 30, 2021 at 07:54:45PM -0500, Antonio Olivares wrote:
> Dear all,
> 
> after updating to RC4 with
> # freebsd-update -r upgrade 13.0RC4
> When I shutdown, I get error messages AE_??? PCI
> 
> 
> Press any key to reboot
> 
> It shutdown before from 13.0-BETA4 updated all the way to RC3. I can save a
> screenshot if needed.  Thanks.

Please do.

Glen



signature.asc
Description: PGP signature

Update to the 13.0-RELEASE schedule

[Glen Barber]

A small set of updates that we consider blocking the 13.0 release have
been brought to our attention.  As such, the 13.0-RELEASE schedule has
been updated to include a fifth release candidate (RC5).

The updated schedule is available on the FreeBSD Project website:

https://www.freebsd.org/releases/13.0R/schedule/

As usual, we will continue to consider critical bug fixes only for the
duration of this release cycle.

Thank you for your cooperation, and for your patience.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

FreeBSD 13.0-RC4 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The fourth RC build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-RC4 amd64 GENERIC
o 13.0-RC4 i386 GENERIC
o 13.0-RC4 powerpc GENERIC
o 13.0-RC4 powerpc64 GENERIC64
o 13.0-RC4 powerpc64le GENERIC64LE
o 13.0-RC4 powerpcspe MPC85XXSPE
o 13.0-RC4 armv6 RPI-B
o 13.0-RC4 armv7 GENERICSD
o 13.0-RC4 aarch64 GENERIC
o 13.0-RC4 aarch64 RPI
o 13.0-RC4 aarch64 PINE64
o 13.0-RC4 aarch64 PINE64-LTS
o 13.0-RC4 aarch64 PINEBOOK
o 13.0-RC4 aarch64 ROCK64
o 13.0-RC4 aarch64 ROCKPRO64
o 13.0-RC4 riscv64 GENERIC
o 13.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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-RC3 includes:

o A fix affecting scripted installations has been addressed.

o Several POWERPC fixes have been included.

o A memory leak in NETMAP_REQ_PORT_INFO_GET has been fixed.

o An issue with local-unbound and some IPv6 deployment has been fixed.

o Historical output range from random(9) has been restored to previous
  behavior.

o OpenSSL has been updated to version 1.1.1k.

o A fix for validation of RDNSS options has been addressed.

o Other miscellaneous items have been addressed.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC4/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0598efc4d694d3d37
  eu-north-1 region: ami-0ba85345dba9c4217
  ap-south-1 region: ami-08b78815520d5e928
  eu-west-3 region: ami-056898eac70857d45
  eu-west-2 region: ami-0593fcb0d3e06dda1
  eu-south-1 region: ami-074b99628c32d109e
  eu-west-1 region: ami-0b85ae6a98f6fbb1b
  ap-northeast-3 region: ami-0d06f2fc4b1ca0fd5
  ap-northeast-2 region: ami-0730e5682e0afbccd
  me-south-1 region: ami-030f1f4ab4868339d
  ap-northeast-1 region: ami-0ba9805e71b0ddf33
  sa-east-1 region: ami-0b060edf382ee6e23
  ca-central-1 region: ami-0a3a6b0c8659e1209
  ap-east-1 region: ami-083c466a2d391d0ad
  ap-southeast-1 region: ami-0b124fef3de549afc
  ap-southeast-2 region: ami-08cd3e9c6f03d3214
  eu-central-1 region: ami-05ad87609e537b55c
  us-east-1 region: ami-0f758483ef601fdcf
  us-east-2 region: ami-0e77d33c8d1d4ba5e
  us-west-1 region: ami-0a20405e1b44521b9
  us-west-2 region: ami-089b1a2186a5f51d9

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0446cae5a03c54d0e
  eu-north-1 region: ami-033132718a666d502
  ap-south-1 region: ami-08128caf0b8160a9f
  eu-west-3 region: ami-09aacfd0b957b8d0d
  eu-west-2 region: ami-0941404a735e5936b
  eu-south-1 region: ami-0dcb8d6c124df4ba5
  eu-west-1 region: ami-07a41bb3026de8bbc
  ap-northeast-3 region: ami-049d763015da87c72
  ap-northeast-2 region: 

Re: 13.0-RELEASE schedule update: PR 251866 (unable to boot some modern hardware)

[Glen Barber]

On Wed, Mar 24, 2021 at 12:42:46AM +, Graham Perrin wrote:
> On 23/03/2021 18:57, Glen Barber wrote:
> > At least one issue has been brought to our attention that affects new
> > installations, which as we currently have no precedent for re-rolling
> > ISOs and/or VM images post-release, warrant adding RC4 to the 13.0
> > schedule.
> > 
> > Please be advised that we are still only accepting critical changes
> > only, with the exception of a few post-RC3 requests for approval that
> > have trickled in.
> 
> …
> 
> I should probably plead for the essence of 
> <https://cgit.freebsd.org/src/commit/?id=b304cd9789ca7ff3df629af42a976450e8660a11>,
> very recently committed to stable/12, to be committed to releng/13.0 and
> main.
> 
> If I understand correctly, the effects of PR 251866
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251866> are not limited
> to vmware.
> 
> The same symptoms – essentially, unable to boot – are seen with (for
> example) HP ProBook 440 G7.
> 

This was merged to releng/13.0 in:

 commit 4d6047edb675e52b8fad57135ab3ded8e66d0dac
 Author: Warner Losh 
 Date:   Thu Dec 17 17:02:09 2020 +

Drop EFI_STAGING_SIZE back down to 64M

vmware can't cope with anything larger than 64MB. Drop this back to
64MB everywhere but arm.

I made the same mistake thinking it was not already merged to 13.x.

Glen



signature.asc
Description: PGP signature

13.0-RELEASE schedule update

[Glen Barber]

At least one issue has been brought to our attention that affects new
installations, which as we currently have no precedent for re-rolling
ISOs and/or VM images post-release, warrant adding RC4 to the 13.0
schedule.

Please be advised that we are still only accepting critical changes
only, with the exception of a few post-RC3 requests for approval that
have trickled in.

The updated remaining milestones of the 13.0 schedule have been
committed to the Project website and also follows:

 RC4 build starts:March 26, 2021
 RELEASE build starts:April 2, 2021
 RELEASE announcement:April 6, 2021

As always, thank you for your cooperation and hard work that went into
this release, and thank you to all that have helped test the BETAs and
RCs during this cycle.

Glen
On behalf of:   re@



signature.asc
Description: PGP signature

Re: FreeBSD 13.0-RC3 Now Available

[Glen Barber]

On Mon, Mar 22, 2021 at 01:39:06PM +0100, Goran Mekić wrote:
> Hello,
> 
> I see the RC3 in the "Latest News" but not here: 
> https://www.freebsd.org/releases/13.0R/schedule/
> I hope I'm writing to the proper channels/list about this.
> 

Fixed.  Thank you for the report.

Glen



signature.asc
Description: PGP signature

FreeBSD 13.0-RC3 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The third RC build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-RC3 amd64 GENERIC
o 13.0-RC3 i386 GENERIC
o 13.0-RC3 powerpc GENERIC
o 13.0-RC3 powerpc64 GENERIC64
o 13.0-RC3 powerpc64le GENERIC64LE
o 13.0-RC3 powerpcspe MPC85XXSPE
o 13.0-RC3 armv6 RPI-B
o 13.0-RC3 armv7 GENERICSD
o 13.0-RC3 aarch64 GENERIC
o 13.0-RC3 aarch64 RPI
o 13.0-RC3 aarch64 PINE64
o 13.0-RC3 aarch64 PINE64-LTS
o 13.0-RC3 aarch64 PINEBOOK
o 13.0-RC3 aarch64 ROCK64
o 13.0-RC3 aarch64 ROCKPRO64
o 13.0-RC3 riscv64 GENERIC
o 13.0-RC3 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-RC2 includes:

o A virtual memory list locking fix has been addressed.

o A fix for systems running under VirtualBox has been addressed.

o A fix in the service(8) utility has been addressed.

o The if_wg(4) pseudo driver has been removed.

o A fix to TSO for TCP/IPV6 has been addressed in the vtnet(4) driver.

o Several other miscellaneous fixes have been addressed.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC3/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-RC3/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0ad55ef28f5927282
  eu-north-1 region: ami-0fde22c6026e95a57
  ap-south-1 region: ami-06fd5c64b54c3e005
  eu-west-3 region: ami-093ba1f2661abd0be
  eu-west-2 region: ami-0803205f015f5ec14
  eu-south-1 region: ami-03e90955c75a8c809
  eu-west-1 region: ami-0d9313767b0b818fd
  ap-northeast-3 region: ami-0f25c989c843d8dbb
  ap-northeast-2 region: ami-0f27bdd4fd819bb6c
  me-south-1 region: ami-032ee25ad2976ad49
  ap-northeast-1 region: ami-0fb5829e3ff1f1b15
  sa-east-1 region: ami-0f66abb1219e00a5c
  ca-central-1 region: ami-062381d2a77db4a3d
  ap-east-1 region: ami-0d21456c4a5bd1384
  ap-southeast-1 region: ami-0519190624816cc77
  ap-southeast-2 region: ami-0805e040cf3167547
  eu-central-1 region: ami-0abb1093896437395
  us-east-1 region: ami-02f65312a05a1abfd
  us-east-2 region: ami-023106328f1d2d3c7
  us-west-1 region: ami-00802b96b8eec8b49
  us-west-2 region: ami-090a96d68eed457a1

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-04e1b958484d79c53
  eu-north-1 region: ami-09784ab80e6a9812f
  ap-south-1 region: ami-0641ef56dae855387
  eu-west-3 region: ami-0cc83c013292eb9ee
  eu-west-2 region: ami-033fa6488ab12698b
  eu-south-1 region: ami-02fe3008ea2757fed
  eu-west-1 region: ami-06fdd3bce845d8c96
  ap-northeast-3 region: ami-0afb61493a8eb593d
  ap-northeast-2 region: ami-0a81e284ff987ba61
  me-south-1 region: 

FreeBSD 13.0-RC2 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The second RC build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-RC2 amd64 GENERIC
o 13.0-RC2 i386 GENERIC
o 13.0-RC2 powerpc GENERIC
o 13.0-RC2 powerpc64 GENERIC64
o 13.0-RC2 powerpc64le GENERIC64LE
o 13.0-RC2 powerpcspe MPC85XXSPE
o 13.0-RC2 armv6 RPI-B
o 13.0-RC2 armv7 GENERICSD
o 13.0-RC2 aarch64 GENERIC
o 13.0-RC2 aarch64 RPI
o 13.0-RC2 aarch64 PINE64
o 13.0-RC2 aarch64 PINE64-LTS
o 13.0-RC2 aarch64 PINEBOOK
o 13.0-RC2 aarch64 ROCK64
o 13.0-RC2 aarch64 ROCKPRO64
o 13.0-RC2 riscv64 GENERIC
o 13.0-RC2 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-RC1 includes:

o Miscellaneous loader fixes.

o Fixes to if_wg(4) have been added.

o The growfs(8) utility has been updated to allow operating on
  read/write filesystems.

o Several ZFS fixes.

o Several TCP fixes.

o The bc(1) utility has been updated to version 3.3.3.

o An arm64 AES-XTS regression has been fixed.

o A fix for VLAN hardware filtering in ixl(4) has been fixed.

o The ice(4) driver has been updated to version 0.28.1-k.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC2/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-RC2/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-075584d5b26000fb4
  eu-north-1 region: ami-01bc9e74704057f84
  ap-south-1 region: ami-0482a65377ea03c8e
  eu-west-3 region: ami-089013cf606c3cef0
  eu-west-2 region: ami-074ec752c433390e3
  eu-south-1 region: ami-0fa2b27853fc18f1c
  eu-west-1 region: ami-08e5c85eec858fe9c
  ap-northeast-3 region: ami-0cd8f0feba156c1b8
  ap-northeast-2 region: ami-0f407f222ea20777f
  me-south-1 region: ami-0752247a4f4b7f1c5
  ap-northeast-1 region: ami-062b0b3b7c9be696d
  sa-east-1 region: ami-07ef18e5aa3e4b373
  ca-central-1 region: ami-064103ca013b74ee3
  ap-east-1 region: ami-0c86834fdbbd272aa
  ap-southeast-1 region: ami-07791074bad9e30f5
  ap-southeast-2 region: ami-0f9d5ee9afd3c9166
  eu-central-1 region: ami-036260c2bf5ffaab0
  us-east-1 region: ami-06df356662db1c1c0
  us-east-2 region: ami-0b81e7e91a55d8a44
  us-west-1 region: ami-0293a117e598e5d79
  us-west-2 region: ami-047216a21fe30e18f

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0f24d089d2383ba32
  eu-north-1 region: ami-06368e4701f2a8732
  ap-south-1 region: ami-0186094ac26aaab14
  eu-west-3 region: ami-0297345102a342c4c
  eu-west-2 region: ami-02ad08dcf7eb46940
  eu-south-1 region: ami-02c217018c44903b0
  eu-west-1 region: ami-0a13bb7013c52966d
  ap-northeast-3 region: 

FreeBSD 13.0-RC1 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The first RC build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-RC1 amd64 GENERIC
o 13.0-RC1 i386 GENERIC
o 13.0-RC1 powerpc GENERIC
o 13.0-RC1 powerpc64 GENERIC64
o 13.0-RC1 powerpc64le GENERIC64LE
o 13.0-RC1 powerpcspe MPC85XXSPE
o 13.0-RC1 armv6 RPI-B
o 13.0-RC1 armv7 GENERICSD
o 13.0-RC1 aarch64 GENERIC
o 13.0-RC1 aarch64 RPI
o 13.0-RC1 aarch64 PINE64
o 13.0-RC1 aarch64 PINE64-LTS
o 13.0-RC1 aarch64 PINEBOOK
o 13.0-RC1 aarch64 ROCK64
o 13.0-RC1 aarch64 ROCKPRO64
o 13.0-RC1 riscv64 GENERIC
o 13.0-RC1 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use SVN to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-BETA4 includes:

o An update to handle partial data resending on ktls/sendfile has been
  added.

o A bug fix in iflib.

o A fix to pf(4) for incorrect fragment handling.

o A TCP performance improvement when using TCP_NOOPT has been added.

o Several SCTP fixes and improvements.

o Several other miscellaneous fixes and improvements.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RC1/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-RC1/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-024a37d8ee55504a9
  eu-north-1 region: ami-0f7e6ef964131a5c5
  ap-south-1 region: ami-0da383cf93cddac9d
  eu-west-3 region: ami-0c2e5eecf725c8480
  eu-west-2 region: ami-07e739abd39787f83
  eu-south-1 region: ami-042c036041ab5c683
  eu-west-1 region: ami-02b72374c39f164f4
  ap-northeast-3 region: ami-06b158bab2dc009b8
  ap-northeast-2 region: ami-0fbcb7db014004a7f
  me-south-1 region: ami-0a5040da848631036
  ap-northeast-1 region: ami-0ea2e5573427aa49c
  sa-east-1 region: ami-0e8ca0e56ecd00395
  ca-central-1 region: ami-08503cd732e74743f
  ap-east-1 region: ami-0fa7c7d12cd5c992f
  ap-southeast-1 region: ami-0adc820ff9c36b582
  ap-southeast-2 region: ami-0f031e3027fe5ed45
  eu-central-1 region: ami-0685d9bbc37652517
  us-east-1 region: ami-0dc102bfa2a63a6c0
  us-east-2 region: ami-0d65407784cf103ac
  us-west-1 region: ami-0d676e4b02aeac56e
  us-west-2 region: ami-0f2f2e90ae8956750

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-00bc7809c32164ef7
  eu-north-1 region: ami-079c3b3939e1422f5
  ap-south-1 region: ami-09f83dd115907186c
  eu-west-3 region: ami-0b466ac2ccb1d9a17
  eu-west-2 region: ami-03127626a3b795617
  eu-south-1 region: ami-04b543c7eca712cb2
  eu-west-1 region: ami-04bec8381d23b2d33
  ap-northeast-3 region: ami-08ec822521c26b950
  ap-northeast-2 region: ami-08b8dd381dcc36d65
  me-south-1 region: ami-07253323150004fb7
  

FreeBSD 13.0-BETA4 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The fourth BETA build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-BETA4 amd64 GENERIC
o 13.0-BETA4 i386 GENERIC
o 13.0-BETA4 powerpc GENERIC
o 13.0-BETA4 powerpc64 GENERIC64
o 13.0-BETA4 powerpc64le GENERIC64LE
o 13.0-BETA4 powerpcspe MPC85XXSPE
o 13.0-BETA4 armv6 RPI-B
o 13.0-BETA4 armv7 GENERICSD
o 13.0-BETA4 aarch64 GENERIC
o 13.0-BETA4 aarch64 RPI
o 13.0-BETA4 aarch64 PINE64
o 13.0-BETA4 aarch64 PINE64-LTS
o 13.0-BETA4 aarch64 PINEBOOK
o 13.0-BETA4 aarch64 ROCK64
o 13.0-BETA4 aarch64 ROCKPRO64
o 13.0-BETA4 riscv64 GENERIC
o 13.0-BETA4 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-BETA3 includes:

o A possible race between jail_remove(2) and fork(2) had been fixed.

o An issue with the pf(4) osfp configuration had been fixed.

o An update to the ena(4) driver had been added.

o A bug fix to flex(1) had been addressed.

o Fixes for FreeBSD-SA-21:06.xen and FreeBSD-SA-21:03.pam_login_access
  had been addressed.

o A fix to ZFS to address a potential system crash if scrubbing after
  removing a slog device had been addressed.

o And other miscellaneous fixes.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA4/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/ftp/snapshots/CI-IMAGES/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-018ff0bbb489cc147
  eu-north-1 region: ami-0d254e869c98cee4c
  ap-south-1 region: ami-0fbf06953c56b6f0d
  eu-west-3 region: ami-052a22f0481d6b334
  eu-west-2 region: ami-015353db614403879
  eu-south-1 region: ami-00846500ffe1975b8
  eu-west-1 region: ami-0b515b56fa3b7332b
  ap-northeast-2 region: ami-06803a95877671551
  me-south-1 region: ami-08de3623ff267603a
  ap-northeast-1 region: ami-05161601758e32a63
  sa-east-1 region: ami-0d06cd4055c68ba45
  ca-central-1 region: ami-0d0388a8a169d558f
  ap-east-1 region: ami-0451191bad1ef9693
  ap-southeast-1 region: ami-0ebd0fd4279e33ec8
  ap-southeast-2 region: ami-05ade971900f558c0
  eu-central-1 region: ami-0ad78f12e0a41a4b0
  us-east-1 region: ami-0d05110d430079833
  us-east-2 region: ami-02da8e14277738938
  us-west-1 region: ami-01f37e43b49871d73
  us-west-2 region: ami-0f07edd632e38b962

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0967dd10e7b2b5dff
  eu-north-1 region: ami-09fb93f6c2c7109e5
  ap-south-1 region: ami-0034cc6c0c95e6f1c
  eu-west-3 region: ami-01b1667281c168197
  eu-west-2 region: ami-02ecf0f64094a745c
  eu-south-1 region: ami-07481931ee179e035
  eu-west-1 region: ami-07b117d18ce82445e
  ap-northeast-2 

FreeBSD 13.0-BETA3 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The third BETA build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-BETA3 amd64 GENERIC
o 13.0-BETA3 i386 GENERIC
o 13.0-BETA3 powerpc GENERIC
o 13.0-BETA3 powerpc64 GENERIC64
o 13.0-BETA3 powerpc64le GENERIC64LE
o 13.0-BETA3 powerpcspe MPC85XXSPE
o 13.0-BETA3 armv6 RPI-B
o 13.0-BETA3 armv7 GENERICSD
o 13.0-BETA3 aarch64 GENERIC
o 13.0-BETA3 aarch64 RPI
o 13.0-BETA3 aarch64 PINE64
o 13.0-BETA3 aarch64 PINE64-LTS
o 13.0-BETA3 aarch64 PINEBOOK
o 13.0-BETA3 aarch64 ROCK64
o 13.0-BETA3 aarch64 ROCKPRO64
o 13.0-BETA3 riscv64 GENERIC
o 13.0-BETA3 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-BETA2 includes:

o A fix to the virtual memory subsystem to honor the "noreuse" flag.

o A fix to arm64 systems to initialize the VFP control register.

o Multiple busdma fixes.

o A fix to address an ifa refcount leak during route addition.

o A fix to correctly handle CMCI capability reporting.

o A fix to wg(4) to fix incorrect allowed-IPs netmask.

o A fix to UDP6 to prevent a potential system crash.

o A fix to pf(4) to relax pf_rule_addr validation.

o OpenSSL has been updated to version 1.1.1j.

o A fix to ZFS raidz2/raidz3 not healing parity with two or more failing
  disks.

o A fix for a lock order reversal in the USB audio driver.

o The mrsas(4) driver has been enabled in the POWERPC64LE kernel by
  default.

o A fix to the vt terminal buffer size with small font.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA3/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-BETA3/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0fbbcd2c3267fdb5c
  eu-north-1 region: ami-09b419c84d8035657
  ap-south-1 region: ami-0b9e5822c99a9d42b
  eu-west-3 region: ami-02c16087ae9e61c71
  eu-west-2 region: ami-083656cf11da0f09c
  eu-south-1 region: ami-078a937e9bde952c3
  eu-west-1 region: ami-035e6799e50358f89
  ap-northeast-2 region: ami-0a7e40c5fb9734e99
  me-south-1 region: ami-02c180edc819c45cb
  ap-northeast-1 region: ami-00ab0fdc1f9707088
  sa-east-1 region: ami-063b47c24bfccd90d
  ca-central-1 region: ami-06d068df18efb05ff
  ap-east-1 region: ami-0756c5fa1640678b7
  ap-southeast-1 region: ami-0c037cbce65a200d4
  ap-southeast-2 region: ami-07cd0ea655ad3ce94
  eu-central-1 region: ami-03503b993076e619c
  us-east-1 region: ami-0fd411e67ec98cb5f
  us-east-2 region: ami-003c6fdec3c066f22
  us-west-1 region: ami-0855ceba9ed986ffc
  us-west-2 region: ami-0827f5791217ca8c6

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  

[RESENT] FreeBSD 13.0-BETA2 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[Resent with in-line PGP signature]

The second BETA build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-BETA2 amd64 GENERIC
o 13.0-BETA2 i386 GENERIC
o 13.0-BETA2 powerpc GENERIC
o 13.0-BETA2 powerpc64 GENERIC64
o 13.0-BETA2 powerpc64le GENERIC64LE
o 13.0-BETA2 powerpcspe MPC85XXSPE
o 13.0-BETA2 armv6 RPI-B
o 13.0-BETA2 armv7 GENERICSD
o 13.0-BETA2 aarch64 GENERIC
o 13.0-BETA2 aarch64 RPI
o 13.0-BETA2 aarch64 PINE64
o 13.0-BETA2 aarch64 PINE64-LTS
o 13.0-BETA2 aarch64 PINEBOOK
o 13.0-BETA2 aarch64 ROCK64
o 13.0-BETA2 aarch64 ROCKPRO64
o 13.0-BETA2 riscv64 GENERIC
o 13.0-BETA2 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-BETA1 includes:

o Issues with 32-bit builds have been fixed.

o Shared libraries have been updated following an update to ncurses.

o Support for kernel TLS offload has been added (off by default).

o The mlx5en(4) driver has been included in the amd64 GENERIC kernel by
  default.

o Documentation included on installation medium has been removed.

o A null pointer dereference has been addressed.

o Other miscellaneous bug fixes.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA2/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0cd9b838ce999e4da
  eu-north-1 region: ami-0b7f7bb5a04535325
  ap-south-1 region: ami-091087bf50b679cfa
  eu-west-3 region: ami-05d38ac18ad69fc6a
  eu-west-2 region: ami-02625f2da435eb23d
  eu-south-1 region: ami-0d49da591cd8e4e32
  eu-west-1 region: ami-052052f8c2d10e175
  ap-northeast-2 region: ami-0e71c47ca900c1cf9
  me-south-1 region: ami-089a3f87352043e3d
  ap-northeast-1 region: ami-01d99d95596d461e1
  sa-east-1 region: ami-0f10960dfb0228233
  ca-central-1 region: ami-08e4134e846f71613
  ap-east-1 region: ami-0c25f3c1e58a9feab
  ap-southeast-1 region: ami-0831e5a4c51639fed
  ap-southeast-2 region: ami-023a99fa54f7c0157
  eu-central-1 region: ami-07e7923a95c1dd1a5
  us-east-1 region: ami-064aa90f5b18374d4
  us-east-2 region: ami-0f34ced1ad10dc4b1
  us-west-1 region: ami-04aaae41e774ec8c9
  us-west-2 region: ami-01d4c6f4d6d119d39

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0d5fbef4111f8f91e
  eu-north-1 region: ami-0ee561474f61fdbb7
  ap-south-1 region: ami-00cab50f4d85a4d34
  eu-west-3 region: ami-069f5537063a990d2
  eu-west-2 region: ami-0d0a39a9ca57ca0f5
  eu-south-1 region: ami-0d961a55e0960ad76
  eu-west-1 region: ami-0492ee1dc3aafcdc1
  ap-northeast-2 region: ami-030714ec47663d2dd
  me-south-1 region: ami-0c4bcb0299e117dcc
  ap-northeast-1 region: 

FreeBSD 13.0-BETA2 Now Available

[Glen Barber]

The second BETA build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-BETA2 amd64 GENERIC
o 13.0-BETA2 i386 GENERIC
o 13.0-BETA2 powerpc GENERIC
o 13.0-BETA2 powerpc64 GENERIC64
o 13.0-BETA2 powerpc64le GENERIC64LE
o 13.0-BETA2 powerpcspe MPC85XXSPE
o 13.0-BETA2 armv6 RPI-B
o 13.0-BETA2 armv7 GENERICSD
o 13.0-BETA2 aarch64 GENERIC
o 13.0-BETA2 aarch64 RPI
o 13.0-BETA2 aarch64 PINE64
o 13.0-BETA2 aarch64 PINE64-LTS
o 13.0-BETA2 aarch64 PINEBOOK
o 13.0-BETA2 aarch64 ROCK64
o 13.0-BETA2 aarch64 ROCKPRO64
o 13.0-BETA2 riscv64 GENERIC
o 13.0-BETA2 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

A summary of changes since 13.0-BETA1 includes:

o Issues with 32-bit builds have been fixed.

o Shared libraries have been updated following an update to ncurses.

o Support for kernel TLS offload has been added (off by default).

o The mlx5en(4) driver has been included in the amd64 GENERIC kernel by
  default.

o Documentation included on installation medium has been removed.

o A null pointer dereference has been addressed.

o Other miscellaneous bug fixes.

A list of changes since 12.2-RELEASE is available in the releng/13.0
release notes:

https://www.freebsd.org/releases/13.0R/relnotes.html

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, i386, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA2/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0cd9b838ce999e4da
  eu-north-1 region: ami-0b7f7bb5a04535325
  ap-south-1 region: ami-091087bf50b679cfa
  eu-west-3 region: ami-05d38ac18ad69fc6a
  eu-west-2 region: ami-02625f2da435eb23d
  eu-south-1 region: ami-0d49da591cd8e4e32
  eu-west-1 region: ami-052052f8c2d10e175
  ap-northeast-2 region: ami-0e71c47ca900c1cf9
  me-south-1 region: ami-089a3f87352043e3d
  ap-northeast-1 region: ami-01d99d95596d461e1
  sa-east-1 region: ami-0f10960dfb0228233
  ca-central-1 region: ami-08e4134e846f71613
  ap-east-1 region: ami-0c25f3c1e58a9feab
  ap-southeast-1 region: ami-0831e5a4c51639fed
  ap-southeast-2 region: ami-023a99fa54f7c0157
  eu-central-1 region: ami-07e7923a95c1dd1a5
  us-east-1 region: ami-064aa90f5b18374d4
  us-east-2 region: ami-0f34ced1ad10dc4b1
  us-west-1 region: ami-04aaae41e774ec8c9
  us-west-2 region: ami-01d4c6f4d6d119d39

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0d5fbef4111f8f91e
  eu-north-1 region: ami-0ee561474f61fdbb7
  ap-south-1 region: ami-00cab50f4d85a4d34
  eu-west-3 region: ami-069f5537063a990d2
  eu-west-2 region: ami-0d0a39a9ca57ca0f5
  eu-south-1 region: ami-0d961a55e0960ad76
  eu-west-1 region: ami-0492ee1dc3aafcdc1
  ap-northeast-2 region: ami-030714ec47663d2dd
  me-south-1 region: ami-0c4bcb0299e117dcc
  ap-northeast-1 region: ami-09e1764a2692d33d9
  sa-east-1 region: ami-0e3f8570f44d781c1
  ca-central-1 region: 

Re: any images for freebsd-current?

[Glen Barber]

On Sat, Feb 06, 2021 at 11:59:27AM -0800, Steve Kargl wrote:
> Any one aware of where images from freebsd-current?
> freebsd.org appears to offer no images.
> 

Some juggling needs to be done to the release build machines, which
I hope to have done this week before the weekly snapshots.

Glen



signature.asc
Description: PGP signature

FreeBSD 13.0-BETA1 Now Available

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The first BETA build of the 13.0-RELEASE release cycle is now available.

Installation images are available for:

o 13.0-BETA1 amd64 GENERIC
o 13.0-BETA1 powerpc64 GENERIC64
o 13.0-BETA1 powerpc64le GENERIC64LE
o 13.0-BETA1 powerpcspe MPC85XXSPE
o 13.0-BETA1 aarch64 GENERIC
o 13.0-BETA1 aarch64 RPI
o 13.0-BETA1 aarch64 PINE64
o 13.0-BETA1 aarch64 PINE64-LTS
o 13.0-BETA1 aarch64 PINEBOOK
o 13.0-BETA1 aarch64 ROCK64
o 13.0-BETA1 aarch64 ROCKPRO64
o 13.0-BETA1 riscv64 GENERIC
o 13.0-BETA1 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 available by default for ssh(1) access.  Additionally,
the root user password is set to root.  It is strongly recommended
to change the password for both users after gaining access to the
system.

Installer images and memory stick images are available here:

https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/

The image checksums follow at the end of this e-mail.

If you notice problems you can report them through the Bugzilla PR
system or on the -stable mailing list.

If you would like to use Git to do a source based update of an existing
system, use the "releng/13.0" branch.

Please note, the release notes page is not yet complete, and will be
updated on an ongoing basis as the 13.0-RELEASE cycle progresses.

=== Virtual Machine Disk Images ===

VM disk images are available for the amd64, and aarch64
architectures.  Disk images may be downloaded from the following URL
(or any of the FreeBSD download mirrors):

https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-BETA1/

The partition layout is:

~ 16 kB - freebsd-boot GPT partition type (bootfs GPT label)
~ 1 GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 20 GB - freebsd-ufs GPT partition type (rootfs GPT label)

The disk images are available in QCOW2, VHD, VMDK, and raw disk image
formats.  The image download size is approximately 135 MB and 165 MB
respectively (amd64/i386), decompressing to a 21 GB sparse image.

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

BASIC-CI images can be found at:

https://download.freebsd.org/ftp/releases/CI-IMAGES/13.0-BETA1/

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-0b73d1612908a4a44
  eu-north-1 region: ami-01598fe2c2801d2ad
  ap-south-1 region: ami-06d1b0fd9c5080340
  eu-west-3 region: ami-0b5b08516fa6b9516
  eu-west-2 region: ami-0a36d92c5c4a2d895
  eu-south-1 region: ami-0b1f18f26cde8703e
  eu-west-1 region: ami-0fb3f046729fe283a
  ap-northeast-2 region: ami-0fb015c5f16d895cd
  me-south-1 region: ami-0f3fcb76b522aa8ec
  ap-northeast-1 region: ami-04131e8d488a81715
  sa-east-1 region: ami-0b71fe0c26e1b66ec
  ca-central-1 region: ami-035634001169005ca
  ap-east-1 region: ami-0f5f427b679c87e7e
  ap-southeast-1 region: ami-03a34e19c1f849294
  ap-southeast-2 region: ami-087b81741007cb3a0
  eu-central-1 region: ami-037955ce4fff3288e
  us-east-1 region: ami-0c516702a0317d73e
  us-east-2 region: ami-0ed1e964233416530
  us-west-1 region: ami-01e7215b6c673cce5
  us-west-2 region: ami-009d2f232eae501b7

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-08c04627b063f6ab5
  eu-north-1 region: ami-07033e3966f43030c
  ap-south-1 region: ami-03c045241cce2e199
  eu-west-3 region: ami-059387349d87254f5
  eu-west-2 region: ami-0ae0e486833625264
  eu-south-1 region: ami-0bbba0906ca01eeb3
  eu-west-1 region: ami-026d7bcdc6acde794
  ap-northeast-2 region: ami-0b7544eff7e1c8a26
  me-south-1 region: ami-053cb544670f5129e
  ap-northeast-1 region: ami-04e066702451c597c
  sa-east-1 region: ami-0ef8e02f34b1d6976
  ca-central-1 region: ami-05436cfaa24b3a00c
  ap-east-1 region: ami-0362c8f1e2a700094
  ap-southeast-1 region: ami-05b1cf5c8e05418e8
  ap-southeast-2 region: ami-0834a0f346c931136
  eu-central-1 region: ami-05e82803b24b6097a
  us-east-1 region: ami-06af003d9d818164f
  us-east-2 region: ami-08ef1a3f0f078b4a8
  us-west-1 region: ami-069a26eb191eb3271
  us-west-2 region: ami-05e25d5025e93b193

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site, and can
be installed by running:

% vagrant init freebsd/FreeBSD-13.0-BETA1
% vagrant up

=== Upgrading ===

Due to 

Re: Failure of release build with release.sh on 14-CURRENT amd64

[Glen Barber]

On Mon, Feb 01, 2021 at 09:38:33PM +, tech-lists wrote:
> On Mon, Feb 01, 2021 at 09:27:44PM +0000, Glen Barber wrote:
> > On Sun, Jan 31, 2021 at 03:30:14PM +, tech-lists wrote:
> > > Found
> > > A pre-built version of pkg could not be found for your system.
> > > Consider changing PACKAGESITE or installing it from ports:
> > > 'ports-mgmt/pkg'.
> > > 
> > > root@generic:/usr/src/release # which pkg
> > > /usr/sbin/pkg
> > > 
> > 
> > This is because the 14.0-CURRENT packages for arm64 take a significant
> > amount of more time to build than x86.
> 
> Hi,
> 
> Is there a way of making it use the pkg which is already installed on the 
> system
> running make release?
> 

No.  /usr/sbin/pkg is the bootstrap tool to install /usr/local/sbin/pkg.
It does not have the same functionality.

Glen



signature.asc
Description: PGP signature

Re: Failure of release build with release.sh on 14-CURRENT amd64

[Glen Barber]

On Sun, Jan 31, 2021 at 03:30:14PM +, tech-lists wrote:
> Hello,
> 
> I also tried to build a release and failed. My context is different to
> yours, though. The failure error is different. Just thought I'd mention
> it as "make release on -current is broken for me as well". In my
> context, it ignores the installed pkg and tries, and fails to get a
> -current pkg binary from the repos.
> 
> Context is raspberry pi4/8GB
> git version is src.git as of 30/01/21 evening UTC
> 
> command used was: root@generic:/usr/src/release # sh release.sh -c
> arm64/RPI.conf
> 
> error:
> --- installdirs-CONFSDIR ---
> installing DIRS CONFSDIR
> install -N /scratch/usr/src/etc  -d -m 0755 -o root  -g wheel
> /scratch/etc/pkg
> ELF ldconfig path: /lib /usr/lib /usr/lib/compat
> Bootstrapping pkg from
> pkg+http://pkg.FreeBSD.org/FreeBSD:14:aarch64/latest, please wait...
> pkg: Error fetching
> http://pkg.FreeBSD.org/FreeBSD:14:aarch64/latest/Latest/pkg.txz: Not
> Found
> A pre-built version of pkg could not be found for your system.
> Consider changing PACKAGESITE or installing it from ports:
> 'ports-mgmt/pkg'.
> 
> root@generic:/usr/src/release # which pkg
> /usr/sbin/pkg
> 

This is because the 14.0-CURRENT packages for arm64 take a significant
amount of more time to build than x86.

Glen



signature.asc
Description: PGP signature

Re: Failure of release build with release.sh on 14-CURRENT amd64

[Glen Barber]

On Sun, Jan 31, 2021 at 04:29:09PM +0900, Yasuhiro Kimura wrote:
> Hello,
> 
> I tried release build with /usr/src/release/release.sh on 14-CURRENT
> amd64 under followin conditions.
> 
> * 14-CURRENT amd64
> * f17fc5439f5 + revert of 84eaf2ccc6a (Workaroud of the problem
>   reported as bug 253087 on Bugzilla)
> * No release.conf, everithing is default
> * /scratch is empty when build starts
> * /scratch/usr/doc is ba0831043d of main
> * /scratch/usr/ports is r563439 of head
> * /scratch/usr/src is 151ec796a23 of main
> * devel/git is installed but devel/subversion isn't
> 
> And the result is failure with following error messages.
> 
> --
> cd /usr/doc/en_US.ISO8859-1/htdocs/releases/14.0R &&  env 
> MAN4DIR=/usr/src/release/../share/man/man4  _BRANCH=CURRENT  make all install 
> clean "FORMATS=html txt"  INSTALL_COMPRESSED='' URLS_ABSOLUTE=YES 
> DOCDIR=/usr/obj/usr/src/amd64.amd64/
> release/rdoc  WEBDIR=/usr/doc 
> DESTDIR=/usr/obj/usr/src/amd64.amd64/release/rdoc
> cd: /usr/doc/en_US.ISO8859-1/htdocs/releases/14.0R: No such file or directory
> *** Error code 2
> 
> Stop.
> make[1]: stopped in /usr/src/release
> *** Error code 1
> 
> Stop.
> make: stopped in /usr/src/release
> --
> 
> Full buld log is
> 
> https://www.utahime.org/FreeBSD/release.sh.2021-01-31-09-10-35.log
> 
> (Caution: Size of the file is about 75MB)
> 
> Does this mean that release.sh is simply broken right now or I did
> something wrong?
> 

Setting NODOC=1 should workaround the problem for now, until the
conversion from XML to ASCIIDoc/Hugo is 100% complete.  (It is
effectively complete, but there are a few nits here and there that need
to be resolved.)

Glen



signature.asc
Description: PGP signature

Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)

[Glen Barber]

On Thu, Sep 10, 2020 at 04:53:30PM +, Glen Barber wrote:
> On Thu, Sep 10, 2020 at 06:43:08PM +0200, Emmanuel Vadot wrote:
> >  Which port commit and which board ? There haven't been a commit in the
> > u-boot ports or rpi-firmware this a month now so I fails to understand
> > without more info.
> > 
> 
[...]
> 
> But I think the build would have failed in this case if the fetch
> succeeded, based on logs from other boards.
> 

I have committed a fix to release/release.sh (r365725) that allows
overriding the RELENGDIR variable if called from an external script, as
well as committed fixes to ^/user/gjb/thermite-git/ (365752) which moves
where RELENGDIR gets set for these boards.

This week's builds should be fine.

Glen



signature.asc
Description: PGP signature

Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)

[Glen Barber]

On Thu, Sep 10, 2020 at 06:43:08PM +0200, Emmanuel Vadot wrote:
> On Thu, 10 Sep 2020 16:36:44 +
> Glen Barber  wrote:
> 
> > On Thu, Sep 10, 2020 at 06:25:51PM +0200, Emmanuel Vadot wrote:
> > > On Thu, 3 Sep 2020 16:00:51 +
> > > Glen Barber  wrote:
> > > 
> > > > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote:
> > > > > 
> > > > >  Hello,
> > > > > 
> > > > > On Thu, 3 Sep 2020 15:02:45 +
> > > > > Glen Barber  wrote:
> > > > > 
> > > > > > -BEGIN PGP SIGNED MESSAGE-
> > > > > > Hash: SHA256
> > > > > > 
> > > > > > New FreeBSD development branch installation ISOs and virtual machine
> > > > > > disk images have been uploaded to the FreeBSD Project mirrors.
> > > > > > 
> > > > > > NOTE: These are the first snapshots built from the FreeBSD Git 
> > > > > > sources.
> > > > > > Also note: The armv6 and armv7 builds failed, and the cause is being
> > > > > > investigated.
> > > > > 
> > > > >  There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do 
> > > > > you
> > > > > have more info ?
> > > > > 
> > > > 
> > > > The ports tree failed to mount within the chroot directory.  I think
> > > > I see why, and am testing a fix now.
> > > > 
> > > 
> > >  Looks like there was a problem this week too.
> > >  How can I help ?
> > > 
> > 
> > Nothing really.  I know what the problem is.  The ports tree mounting
> > issue had been fixed, but two things: 1) the u-boot port failed to
> > fetch for at least one of the boards; 2) something got screwed up in the
> > environment, due to path changes and how the git checkout structure is
> > set up.
> > 
> > The first is basically a timing issue with a ports commit and
> > distribution of the distfiles.  The second I am working on fixing now,
> > which should be Relatively Easy(tm).
> > 
> 
>  Which port commit and which board ? There haven't been a commit in the
> u-boot ports or rpi-firmware this a month now so I fails to understand
> without more info.
> 

The PINEBOOK fetch failed, but after closer inspection, it looks like
a transient "Service not available" error.

But I think the build would have failed in this case if the fetch
succeeded, based on logs from other boards.

Glen



signature.asc
Description: PGP signature

Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)

[Glen Barber]

On Thu, Sep 10, 2020 at 06:25:51PM +0200, Emmanuel Vadot wrote:
> On Thu, 3 Sep 2020 16:00:51 +
> Glen Barber  wrote:
> 
> > On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote:
> > > 
> > >  Hello,
> > > 
> > > On Thu, 3 Sep 2020 15:02:45 +
> > > Glen Barber  wrote:
> > > 
> > > > -BEGIN PGP SIGNED MESSAGE-
> > > > Hash: SHA256
> > > > 
> > > > New FreeBSD development branch installation ISOs and virtual machine
> > > > disk images have been uploaded to the FreeBSD Project mirrors.
> > > > 
> > > > NOTE: These are the first snapshots built from the FreeBSD Git sources.
> > > > Also note: The armv6 and armv7 builds failed, and the cause is being
> > > > investigated.
> > > 
> > >  There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you
> > > have more info ?
> > > 
> > 
> > The ports tree failed to mount within the chroot directory.  I think
> > I see why, and am testing a fix now.
> > 
> 
>  Looks like there was a problem this week too.
>  How can I help ?
> 

Nothing really.  I know what the problem is.  The ports tree mounting
issue had been fixed, but two things: 1) the u-boot port failed to
fetch for at least one of the boards; 2) something got screwed up in the
environment, due to path changes and how the git checkout structure is
set up.

The first is basically a timing issue with a ports commit and
distribution of the distfiles.  The second I am working on fixing now,
which should be Relatively Easy(tm).

Glen



signature.asc
Description: PGP signature

Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)

[Glen Barber]

On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote:
> 
>  Hello,
> 
> On Thu, 3 Sep 2020 15:02:45 +
> Glen Barber  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > New FreeBSD development branch installation ISOs and virtual machine
> > disk images have been uploaded to the FreeBSD Project mirrors.
> > 
> > NOTE: These are the first snapshots built from the FreeBSD Git sources.
> > Also note: The armv6 and armv7 builds failed, and the cause is being
> > investigated.
> 
>  There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you
> have more info ?
> 

The ports tree failed to mount within the chroot directory.  I think
I see why, and am testing a fix now.

Glen



signature.asc
Description: PGP signature

New FreeBSD snapshots available: main (20200903 c122cf32f2a)

[Glen Barber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

New FreeBSD development branch installation ISOs and virtual machine
disk images have been uploaded to the FreeBSD Project mirrors.

NOTE: These are the first snapshots built from the FreeBSD Git sources.
Also note: The armv6 and armv7 builds failed, and the cause is being
investigated.

As with any development branch, the installation snapshots are not
intended for use on production systems.  We do, however, encourage
testing on non-production systems as much as possible.

Please also consider installing the sysutils/panicmail port, which can
help in providing FreeBSD developers the necessary information regarding
system crashes.

Checksums for the installation ISOs and the VM disk images follow at
the end of this email.

=== Installation ISOs ===

Installation images are available for:

o 13.0-CURRENT amd64 GENERIC
o 13.0-CURRENT i386 GENERIC
o 13.0-CURRENT powerpc GENERIC
o 13.0-CURRENT powerpc64 GENERIC64
o 13.0-CURRENT powerpcspe MPC85XXSPE
o 13.0-CURRENT aarch64 GENERIC

Snapshots may be downloaded from the corresponding architecture
directory from:

https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/

Please be patient if your local mirror has not yet caught up with the
changes.

Problems, bug reports, or regression reports should be reported through
the Bugzilla PR system or the appropriate mailing list such as -current@
or -stable@ .

=== Virtual Machine Disk Images ===

VM disk images are available for the following architectures:

o 13.0-CURRENT amd64
o 13.0-CURRENT i386
o 13.0-CURRENT aarch64

Disk images may be downloaded from the following URL (or any of the
FreeBSD Project mirrors):

https://download.freebsd.org/ftp/snapshots/VM-IMAGES/

Images are available in the following disk image formats:

~ RAW
~ QCOW2 (qemu)
~ VMDK (qemu, VirtualBox, VMWare)
~ VHD (qemu, xen)

The partition layout is:

~ 512k - freebsd-boot GPT partition type (bootfs GPT label)
~ 1GB  - freebsd-swap GPT partition type (swapfs GPT label)
~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label)

Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI
loader file is needed for qemu-system-aarch64 to be able to boot the
virtual machine images.  See this page for more information:

https://wiki.freebsd.org/arm64/QEMU

To boot the VM image, run:

% qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt  \
-bios QEMU_EFI.fd -serial telnet::,server -nographic \
-drive if=none,file=VMDISK,id=hd0 \
-device virtio-blk-device,drive=hd0 \
-device virtio-net-device,netdev=net0 \
-netdev user,id=net0

Be sure to replace "VMDISK" with the path to the virtual machine image.

=== Amazon EC2 AMI Images ===

FreeBSD/amd64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-08c85df99f131c41e
  eu-north-1 region: ami-092fee473b57ce293
  ap-south-1 region: ami-0f164c2f77d17c733
  eu-west-3 region: ami-0c76f6b53f6785c66
  eu-west-2 region: ami-029e99eecce2dccd7
  eu-south-1 region: ami-0631457525932e458
  eu-west-1 region: ami-052c5e4b4db76c3fb
  ap-northeast-2 region: ami-03ca41a3cd4d23104
  me-south-1 region: ami-05cb623a383daf32f
  ap-northeast-1 region: ami-06542baa9c54e8f57
  sa-east-1 region: ami-0b23146320070808d
  ca-central-1 region: ami-0775c8ea1d4c51202
  ap-east-1 region: ami-0936d677fddabc97a
  ap-southeast-1 region: ami-05e8f51cac90600cb
  ap-southeast-2 region: ami-0f7682c07043d35b2
  eu-central-1 region: ami-0c18f8b05b7cf56ff
  us-east-1 region: ami-0a95c17e40e205461
  us-east-2 region: ami-0df13af87e013a831
  us-west-1 region: ami-05a2ad30864e0a1f7
  us-west-2 region: ami-086dac6ecc576e960

FreeBSD/aarch64 EC2 AMIs are available in the following regions:

  af-south-1 region: ami-073a95521080cd18a
  eu-north-1 region: ami-0c3fd8908dbb8d2d5
  ap-south-1 region: ami-05594776938632a06
  eu-west-3 region: ami-09f042df7c4285573
  eu-west-2 region: ami-05940e5f4a220a528
  eu-south-1 region: ami-02963fa721e775744
  eu-west-1 region: ami-0f70514fd820b09cd
  ap-northeast-2 region: ami-03211c36231fe7bae
  me-south-1 region: ami-0d9711b19def01556
  ap-northeast-1 region: ami-08c8af0923a2ec4f4
  sa-east-1 region: ami-0405529811b49b9c2
  ca-central-1 region: ami-0d2cdbbb55b331683
  ap-east-1 region: ami-062a657fbd373cc97
  ap-southeast-1 region: ami-0c4f30d508c70f510
  ap-southeast-2 region: ami-00abe4775d151fb72
  eu-central-1 region: ami-030dc94d2caf60616
  us-east-1 region: ami-0035735483d37330c
  us-east-2 region: ami-01fc78890c9d8cf9d
  us-west-1 region: ami-014662c19db8b8287
  us-west-2 region: ami-07f9261cecfeaf8f1

=== Vagrant Images ===

FreeBSD/amd64 images are available on the Hashicorp Atlas site for the
VMWare Desktop and VirtualBox providers, and can be installed by
running:

% vagrant init freebsd/FreeBSD-13.0-CURRENT
% vagrant up

== ISO CHECKSUMS ==

o 13.0-CURRENT amd64 GENERIC:
  SHA512 

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Sat, Aug 29, 2020 at 05:54:31PM -0400, Michael Butler wrote:
> On 8/29/20 5:48 PM, Glen Barber wrote:
> > On Sat, Aug 29, 2020 at 09:43:25PM +0000, Glen Barber wrote:
> >> On Sat, Aug 29, 2020 at 09:40:17PM +, Glen Barber wrote:
> 
>  [ .. ]
> 
> >>> Nevermind, I see the problem.  Standby.
> >>>
> >>
> >> r364966 should fix it.  Thank you again for your help here.
> >>
> > 
> > Sigh.  r364968 should *really* fix it..
> 
> It does and without pulling ~1.2GB of GIT pack down :-)
> 

Awesome!  Thank you very much for testing!

> > Is it Friday yet?
> 
> LOL :-)
> 

:-)

Glen



signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Sat, Aug 29, 2020 at 09:43:25PM +, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 09:40:17PM +0000, Glen Barber wrote:
> > On Sat, Aug 29, 2020 at 09:30:02PM +0000, Glen Barber wrote:
> > > On Sat, Aug 29, 2020 at 05:21:16PM -0400, Michael Butler wrote:
> > > > On 8/29/20 5:17 PM, Glen Barber wrote:
> > > > > On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote:
> > > > >> The build-from-existing mode fails with ..
> > > > >>
> > > > >> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
> > > > >> fatal: not a git repository (or any parent up to mount point /usr)
> > > > >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not 
> > > > >> set).
> > > > >> umount: /usr/local/release-builds/i386/dev: not a file system root 
> > > > >> directory
> > > > >>
> > > > > 
> > > > > Here's the fun part - Which revision was this?
> > > > 
> > > > The host system is check-out from SVN r364964,
> > > > 
> > > 
> > > Can you please try the attached patch against your release.sh?
> > > 
> > 
> > Nevermind, I see the problem.  Standby.
> > 
> 
> r364966 should fix it.  Thank you again for your help here.
> 

Sigh.  r364968 should *really* fix it..

Is it Friday yet?

Glen



signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Sat, Aug 29, 2020 at 09:40:17PM +, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 09:30:02PM +0000, Glen Barber wrote:
> > On Sat, Aug 29, 2020 at 05:21:16PM -0400, Michael Butler wrote:
> > > On 8/29/20 5:17 PM, Glen Barber wrote:
> > > > On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote:
> > > >> The build-from-existing mode fails with ..
> > > >>
> > > >> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
> > > >> fatal: not a git repository (or any parent up to mount point /usr)
> > > >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not 
> > > >> set).
> > > >> umount: /usr/local/release-builds/i386/dev: not a file system root 
> > > >> directory
> > > >>
> > > > 
> > > > Here's the fun part - Which revision was this?
> > > 
> > > The host system is check-out from SVN r364964,
> > > 
> > 
> > Can you please try the attached patch against your release.sh?
> > 
> 
> Nevermind, I see the problem.  Standby.
> 

r364966 should fix it.  Thank you again for your help here.

Glen



signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Sat, Aug 29, 2020 at 09:30:02PM +, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 05:21:16PM -0400, Michael Butler wrote:
> > On 8/29/20 5:17 PM, Glen Barber wrote:
> > > On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote:
> > >> The build-from-existing mode fails with ..
> > >>
> > >> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
> > >> fatal: not a git repository (or any parent up to mount point /usr)
> > >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not 
> > >> set).
> > >> umount: /usr/local/release-builds/i386/dev: not a file system root 
> > >> directory
> > >>
> > > 
> > > Here's the fun part - Which revision was this?
> > 
> > The host system is check-out from SVN r364964,
> > 
> 
> Can you please try the attached patch against your release.sh?
> 

Nevermind, I see the problem.  Standby.

Glen



signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Sat, Aug 29, 2020 at 05:21:16PM -0400, Michael Butler wrote:
> On 8/29/20 5:17 PM, Glen Barber wrote:
> > On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote:
> >> The build-from-existing mode fails with ..
> >>
> >> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
> >> fatal: not a git repository (or any parent up to mount point /usr)
> >> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> >> umount: /usr/local/release-builds/i386/dev: not a file system root 
> >> directory
> >>
> > 
> > Here's the fun part - Which revision was this?
> 
> The host system is check-out from SVN r364964,
> 

Can you please try the attached patch against your release.sh?

Glen

Index: release/release.sh
===
--- release/release.sh  (revision 364960)
+++ release/release.sh  (working copy)
@@ -223,6 +223,8 @@ chroot_setup() {
if [ -z "${SRC_UPDATE_SKIP}" ]; then
if [ -d "${CHROOTDIR}/usr/src/.git" ]; then
${VCSUPDATE} -C ${CHROOTDIR}/usr/src
+   elif [ -d "${CHROOTDIR}/usr/src/.svn" ]; then
+   svn up ${CHROOTDIR}/usr/src
else
${VCSCMD} ${SRC} -b ${SRCBRANCH} ${CHROOTDIR}/usr/src
fi
@@ -230,6 +232,8 @@ chroot_setup() {
if [ -z "${NODOC}" ] && [ -z "${DOC_UPDATE_SKIP}" ]; then
if [ -d "${CHROOTDIR}/usr/doc/.git" ]; then
${VCSUPDATE} -C ${CHROOTDIR}/usr/doc
+   elif [ -d "${CHROOTDIR}/usr/doc/.svn" ]; then
+   svn up ${CHROOTDIR}/usr/doc
else
${VCSCMD} ${DOC} -b ${DOCBRANCH} ${CHROOTDIR}/usr/doc
fi
@@ -237,6 +241,8 @@ chroot_setup() {
if [ -z "${NOPORTS}" ] && [ -z "${PORTS_UPDATE_SKIP}" ]; then
if [ -d "${CHROOTDIR}/usr/ports/.git" ]; then
${VCSUPDATE} -C ${CHROOTDIR}/usr/ports
+   elif [ -d "${CHROOTDIR}/usr/ports/.svn" ]; then
+   svn up ${CHROOTDIR}/usr/ports
else
${VCSCMD} ${PORT} -b ${PORTBRANCH} 
${CHROOTDIR}/usr/ports
fi


signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Sat, Aug 29, 2020 at 04:38:05PM -0400, Michael Butler wrote:
> On 8/29/20 12:04 PM, Glen Barber wrote:
> > On Sat, Aug 29, 2020 at 03:51:23PM +0000, Glen Barber wrote:
> >> I added a way to update an existing tree in r364959.  I have only done
> >> very trivial testing on this change, however, so please let me know if
> >> it does not work as expected.
> >>
> > r364960 further refines how this works; that would be a better revision
> > to use to test.
> 
> The build-from-scratch mode now works to produce tar-balls and ISOs :-)
> However, I noticed that after building a clean amd64 tool-chain, it does
> fetch the amd64 GIT packages and dependencies (~76MB in all) before
> building 'all' for the target. No big deal but I usually prefer to build
> everything locally.
> 
> The build-from-existing mode fails with ..
> 
> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
> fatal: not a git repository (or any parent up to mount point /usr)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
> umount: /usr/local/release-builds/i386/dev: not a file system root directory
> 

Here's the fun part - Which revision was this?

> Many thanks for your efforts!
> 

Many thanks for your bug reports!

Glen



signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Sat, Aug 29, 2020 at 03:51:23PM +, Glen Barber wrote:
> On Sat, Aug 29, 2020 at 11:34:15AM -0400, Michael Butler wrote:
> > On 8/29/20 11:14 AM, Glen Barber wrote:
> > > NOPORTS=yes is the problem, and I forgot to address it before merging
> > > the project branch back.  Please try with r364956.
> > 
> > Trying now but, in the interim, I noted ..
> > 
> > With SVN, I could re-use a previously existing build directory and it
> > would simply apply the relevant diffs to bring the tree up to date.
> > 
> > In the move to GIT, now it seems I have to pull the whole tree down or
> > it complains ..
> > 
> > imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
> > fatal: destination path '/usr/local/release-builds/i386/usr/src' already
> > exists and is not an empty directory.
> > 
> > I'm not that familiar with GIT but .. Is there an incremental update
> > option I can use? If so, should this be the default? As is, it seems
> > like a colossal waste of bandwidth and unwanted load on the parent GIT repo,
> > 
> 
> I added a way to update an existing tree in r364959.  I have only done
> very trivial testing on this change, however, so please let me know if
> it does not work as expected.
> 

r364960 further refines how this works; that would be a better revision
to use to test.

Glen



signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Sat, Aug 29, 2020 at 11:34:15AM -0400, Michael Butler wrote:
> On 8/29/20 11:14 AM, Glen Barber wrote:
> > NOPORTS=yes is the problem, and I forgot to address it before merging
> > the project branch back.  Please try with r364956.
> 
> Trying now but, in the interim, I noted ..
> 
> With SVN, I could re-use a previously existing build directory and it
> would simply apply the relevant diffs to bring the tree up to date.
> 
> In the move to GIT, now it seems I have to pull the whole tree down or
> it complains ..
> 
> imb@vm01:/usr/src/release> sudo ./release.sh -c release-i386.conf
> fatal: destination path '/usr/local/release-builds/i386/usr/src' already
> exists and is not an empty directory.
> 
> I'm not that familiar with GIT but .. Is there an incremental update
> option I can use? If so, should this be the default? As is, it seems
> like a colossal waste of bandwidth and unwanted load on the parent GIT repo,
> 

I added a way to update an existing tree in r364959.  I have only done
very trivial testing on this change, however, so please let me know if
it does not work as expected.

Glen



signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Sat, Aug 29, 2020 at 10:30:24AM -0400, Michael Butler wrote:
> On 8/28/20 1:44 PM, Glen Barber wrote:
> 
> > Note, not entirely tested, however, since future snapshots and 13.0 will
> > be exclusively built from the git sources.
> 
> When building with ..
> 
> ## Set miscellaneous 'make release' settings.
> NODOC=yes
> NOPORTS=yes
> WITH_DVD=yes
> 
> The build fails after building the target kernel but before building
> either the tar-balls or ISOs with ..
> 
> >>> Kernel(s)  GENERIC-NODEBUG built in 765 seconds, ncpu: 8, make -j4
> --
> make: "/usr/src/release/Makefile.inc1" line 14: "Git binary not found.
> Set GIT_CMD appropriately."
> 
> It seems to want GIT in the chroot environment, because it's there on
> the host,
> 

NOPORTS=yes is the problem, and I forgot to address it before merging
the project branch back.  Please try with r364956.

Thank you for reporting this.

Glen



signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Fri, Aug 28, 2020 at 05:43:07PM +, Glen Barber wrote:
> On Fri, Aug 28, 2020 at 01:32:06PM -0400, Michael Butler wrote:
> > Is there any documentation around the changes to the release build
> > system from SVN to GIT?
> > 
> > I currently keep a mirrored SVN repo and the revised release scripts
> > seem not to have that as a build option. Can I still use this or do I
> > need to throw it all out and start over?
> > 
> > With one target machine being a 700MHz Pentium-3, building locally is
> > not a practical option,
> > 
> 
> You should be able to override VCSCMD, GIT{ROOT,SRC,PORTS,DOC}, and
> {SRC,DOC,PORTS}BRANCH in a local release.conf (see release.conf.sample).
> 

Note, not entirely tested, however, since future snapshots and 13.0 will
be exclusively built from the git sources.

Glen



signature.asc
Description: PGP signature

Re: documentation on release build process change (svn -> git)?

[Glen Barber]

On Fri, Aug 28, 2020 at 01:32:06PM -0400, Michael Butler wrote:
> Is there any documentation around the changes to the release build
> system from SVN to GIT?
> 
> I currently keep a mirrored SVN repo and the revised release scripts
> seem not to have that as a build option. Can I still use this or do I
> need to throw it all out and start over?
> 
> With one target machine being a 700MHz Pentium-3, building locally is
> not a practical option,
> 

You should be able to override VCSCMD, GIT{ROOT,SRC,PORTS,DOC}, and
{SRC,DOC,PORTS}BRANCH in a local release.conf (see release.conf.sample).

Glen



signature.asc
Description: PGP signature

Re: FreeBSD-head-i386-build - Build #17845 (r364891) - Failure

[Glen Barber]

Well, this was unexpected.  I have pinged jenkins-admin@.

Glen

On Thu, Aug 27, 2020 at 09:59:47PM +, jenkins-ad...@freebsd.org wrote:
> FreeBSD-head-i386-build - Build #17845 (r364891) - Failure
> 
> Build information: https://ci.FreeBSD.org/job/FreeBSD-head-i386-build/17845/
> Full change log: 
> https://ci.FreeBSD.org/job/FreeBSD-head-i386-build/17845/changes
> Full build log: 
> https://ci.FreeBSD.org/job/FreeBSD-head-i386-build/17845/console
> 
> Status explanation:
> "Failure" - the build is suspected being broken by the following changes
> "Still Failing" - the build has not been fixed by the following changes and
>   this is a notification to note that these changes have
>   not been fully tested by the CI system
> 
> Change summaries:
> (Those commits are likely but not certainly responsible)
> 
> 364891 by gjb:
> Merge the projects/release-git branch to head.
> This allows building 13.x from Git instead of Subversion.
> 
> No MFC to stable branches is planned at this time. [1]
> 
> Discussed with:   git working group [1]
> Sponsored by: Rubicon Communications, LLC (netgate.com)
> 
> 
> 

 [...]

> --
> >>> Kernel build for GENERIC completed on Thu Aug 27 21:59:39 UTC 2020
> --
> >>> Kernel(s)  GENERIC built in 169 seconds, ncpu: 48, make -j24
> --
> + cd /usr/src/release
> + sudo make clean
> make: "/usr/src/release/Makefile.inc1" line 14: "Git binary not found.  Set 
> GIT_CMD appropriately."
> Build step 'Execute shell' marked build as failure
> [WARNINGS]Skipping publisher since build result is FAILURE
> FTP: Current build result is [FAILURE], not going to run.
> [PostBuildScript] - [INFO] Executing post build scripts.
> [PostBuildScript] - [INFO] Build does not have any of the results [SUCCESS]. 
> Did not execute build step #0.
> [PostBuildScript] - [INFO] Executing post build scripts.
> [FreeBSD-head-i386-build] $ /bin/sh -xe /tmp/jenkins5000682500845227971.sh
> + sh freebsd-ci/scripts/jail/clean.sh
> clean jail FreeBSD-head-i386-build
> Checking for post-build
> Performing post-build step
> Checking if email needs to be generated
> Email was triggered for: Failure - Any
> Sending email for trigger: Failure - Any



signature.asc
Description: PGP signature

Re: Weekly Current 13.0 Snapshot?

[Glen Barber]

Not bugging at all.

I’m hoping that the state that machine is in now, with some sanding off some 
newly-discovered rough edges of some code changes, to have snapshots from git 
before Wednesday.

Fingers crossed

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Aug 20, 2020, at 7:43 PM, Clay Daniels  wrote:
> 
> 
> Sorry to bug you. I didn't even know about the snapshot email list, but I 
> have just subscribed and will know next time. Do what you need to and don't 
> worry about the snapshot this week. I too am busy this week and have plenty 
> to do.
> 
> Clay
> 
>> On Thu, Aug 20, 2020 at 5:39 PM Glen Barber  wrote:
>> Not without putting a wedge in place with updating scripts for the git 
>> conversion, which as you know, I am already past the deadline.
>> 
>> Glen
>> Sent from my phone.
>> Please excuse my brevity and/or typos.
>> 
>>>> On Aug 20, 2020, at 5:54 PM, Warner Losh  wrote:
>>>> 
>>> 
>>> 
>>> 
>>>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber  wrote:
>>>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
>>>> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0
>>>> > Current with new goodies. I don't see it at it's usual location:
>>>> > 
>>>> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
>>>> > 
>>>> 
>>>> Not ill, but indeed sick of the build being broken so much.
>>>> 
>>>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.html
>>> 
>>> Build isn't broken now, can't you just run it again?
>>> 
>>> Warner 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Weekly Current 13.0 Snapshot?

[Glen Barber]

Not without putting a wedge in place with updating scripts for the git 
conversion, which as you know, I am already past the deadline.

Glen
Sent from my phone.
Please excuse my brevity and/or typos.

> On Aug 20, 2020, at 5:54 PM, Warner Losh  wrote:
> 
> 
> 
> 
>> On Thu, Aug 20, 2020 at 3:47 PM Glen Barber  wrote:
>> On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
>> > I hope nobody is ill & just busy filling the weekly snapshot of 13.0
>> > Current with new goodies. I don't see it at it's usual location:
>> > 
>> > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
>> > 
>> 
>> Not ill, but indeed sick of the build being broken so much.
>> 
>> https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.html
> 
> Build isn't broken now, can't you just run it again?
> 
> Warner 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Weekly Current 13.0 Snapshot?

[Glen Barber]

On Thu, Aug 20, 2020 at 04:41:59PM -0500, Clay Daniels wrote:
> I hope nobody is ill & just busy filling the weekly snapshot of 13.0
> Current with new goodies. I don't see it at it's usual location:
> 
> https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/13.0/
> 

Not ill, but indeed sick of the build being broken so much.

https://lists.freebsd.org/pipermail/freebsd-snapshots/2020-August/000739.html

Glen



signature.asc
Description: PGP signature

Re: nightly snapshot for CURRENT ?

[Glen Barber]

On Mon, Jul 27, 2020 at 04:23:22PM +0200, Emmanuel Vadot wrote:
> On Mon, 27 Jul 2020 14:14:13 +
> Glen Barber  wrote:
> 
> > On Sat, Jul 25, 2020 at 12:29:42PM +0200, Emmanuel Vadot wrote:
> > > On Fri, 24 Jul 2020 22:28:39 +
> > > Glen Barber  wrote:
> > > 
> > > > On Sat, Jul 25, 2020 at 12:14:52AM +0200, Emmanuel Vadot wrote:
> > > > > On Fri, 24 Jul 2020 22:06:07 +
> > > > > Glen Barber  wrote:
> > > > > 
> > > > > > On Fri, Jul 24, 2020 at 10:31:35PM +0200, Emmanuel Vadot wrote:
> > > > > > > On Tue, 9 Jun 2020 22:04:07 +0200
> > > > > > > Emmanuel Vadot  wrote:
> > > > > > > 
> > > > > > > > On Tue, 9 Jun 2020 19:56:30 +
> > > > > > > > Glen Barber  wrote:
> > > > > > > > 
> > > > > > > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot 
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > >  Hello all,
> > > > > > > > > > 
> > > > > > > > > >  I've just hit again something that I've hit (and probably 
> > > > > > > > > > others too)
> > > > > > > > > > often.
> > > > > > > > > >  If a change in base break some ports and it's snapshoted 
> > > > > > > > > > in the txz
> > > > > > > > > > available at download.freebsd.org, you need to wait a week 
> > > > > > > > > > for the next
> > > > > > > > > > tarball to be available.
> > > > > > > > > >  Since poudriere uses the tarball when you setup a jail it 
> > > > > > > > > > means that
> > > > > > > > > > the only solution you have is to recreate your jail by 
> > > > > > > > > > building it, and
> > > > > > > > > > since building world nowdays is very expensive that delay 
> > > > > > > > > > your work too
> > > > > > > > > > much.
> > > > > > > > > >  Would it be possible to generate the tarballs every day 
> > > > > > > > > > instead of
> > > > > > > > > > every week ? At least for tier-1 arches.
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Let's revisit this sometime next week after 11.4 is out.
> > > > > > > > > 
> > > > > > > > > Glen
> > > > > > > > > 
> > > > > > > > 
> > > > > > > >  Sure, works for me.
> > > > > > > > 
> > > > > > > >  Thanks,
> > > > > > > > 
> > > > > > > 
> > > > > > >  Ping ?
> > > > > > > 
> > > > > > 
> > > > > > I thought the artifacts from the jenkins builder for CI were 
> > > > > > sufficient.
> > > > > > 
> > > > > > Glen
> > > > > > 
> > > > > 
> > > > >  Yes and no,
> > > > > 
> > > > >  I can add something to poudriere for getting the tarballs from the CI
> > > > > artifacts but that won't be by default.
> > > > > 
> > > > 
> > > > To be honest, that would be the preferred route, since updating the
> > > > various *.txz distribution sets would break things like bootonly.iso,
> > > > mini-memstick.img, and so on.
> > > 
> > >  Why would it break things ?
> > > 
> > 
> > The bootonly.iso and mini-memstick.img do not contain the distribution
> > sets, only the MANIFEST file.  So, people using these to install
> > a system would not be able to do so, because the checksums for the sets
> > would not match that in the MANIFEST.
> 
>  What about putting the daily sets in another directory ? With maybe
> the latest 7 days or something like that.
> 

But the CI system already does this...

Glen



signature.asc
Description: PGP signature

Re: nightly snapshot for CURRENT ?

[Glen Barber]

On Sat, Jul 25, 2020 at 12:29:42PM +0200, Emmanuel Vadot wrote:
> On Fri, 24 Jul 2020 22:28:39 +
> Glen Barber  wrote:
> 
> > On Sat, Jul 25, 2020 at 12:14:52AM +0200, Emmanuel Vadot wrote:
> > > On Fri, 24 Jul 2020 22:06:07 +
> > > Glen Barber  wrote:
> > > 
> > > > On Fri, Jul 24, 2020 at 10:31:35PM +0200, Emmanuel Vadot wrote:
> > > > > On Tue, 9 Jun 2020 22:04:07 +0200
> > > > > Emmanuel Vadot  wrote:
> > > > > 
> > > > > > On Tue, 9 Jun 2020 19:56:30 +
> > > > > > Glen Barber  wrote:
> > > > > > 
> > > > > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote:
> > > > > > > > 
> > > > > > > >  Hello all,
> > > > > > > > 
> > > > > > > >  I've just hit again something that I've hit (and probably 
> > > > > > > > others too)
> > > > > > > > often.
> > > > > > > >  If a change in base break some ports and it's snapshoted in 
> > > > > > > > the txz
> > > > > > > > available at download.freebsd.org, you need to wait a week for 
> > > > > > > > the next
> > > > > > > > tarball to be available.
> > > > > > > >  Since poudriere uses the tarball when you setup a jail it 
> > > > > > > > means that
> > > > > > > > the only solution you have is to recreate your jail by building 
> > > > > > > > it, and
> > > > > > > > since building world nowdays is very expensive that delay your 
> > > > > > > > work too
> > > > > > > > much.
> > > > > > > >  Would it be possible to generate the tarballs every day 
> > > > > > > > instead of
> > > > > > > > every week ? At least for tier-1 arches.
> > > > > > > > 
> > > > > > > 
> > > > > > > Let's revisit this sometime next week after 11.4 is out.
> > > > > > > 
> > > > > > > Glen
> > > > > > > 
> > > > > > 
> > > > > >  Sure, works for me.
> > > > > > 
> > > > > >  Thanks,
> > > > > > 
> > > > > 
> > > > >  Ping ?
> > > > > 
> > > > 
> > > > I thought the artifacts from the jenkins builder for CI were sufficient.
> > > > 
> > > > Glen
> > > > 
> > > 
> > >  Yes and no,
> > > 
> > >  I can add something to poudriere for getting the tarballs from the CI
> > > artifacts but that won't be by default.
> > > 
> > 
> > To be honest, that would be the preferred route, since updating the
> > various *.txz distribution sets would break things like bootonly.iso,
> > mini-memstick.img, and so on.
> 
>  Why would it break things ?
> 

The bootonly.iso and mini-memstick.img do not contain the distribution
sets, only the MANIFEST file.  So, people using these to install
a system would not be able to do so, because the checksums for the sets
would not match that in the MANIFEST.

> > In other words, we already have a system in place that generates these
> > archive files, so I personally see no need to disrupt the "official"
> > snapshot build process to appease a subset of the user base while
> > unnecessarily adding a pain point for the rest.
> > 
> 
>  If only the sets are generated each day I don't see how it can cause a
> pain to anyone.
> 

See above.

Glen



signature.asc
Description: PGP signature

Re: nightly snapshot for CURRENT ?

[Glen Barber]

On Sat, Jul 25, 2020 at 12:14:52AM +0200, Emmanuel Vadot wrote:
> On Fri, 24 Jul 2020 22:06:07 +
> Glen Barber  wrote:
> 
> > On Fri, Jul 24, 2020 at 10:31:35PM +0200, Emmanuel Vadot wrote:
> > > On Tue, 9 Jun 2020 22:04:07 +0200
> > > Emmanuel Vadot  wrote:
> > > 
> > > > On Tue, 9 Jun 2020 19:56:30 +
> > > > Glen Barber  wrote:
> > > > 
> > > > > On Tue, Jun 09, 2020 at 09:47:56PM +0200, Emmanuel Vadot wrote:
> > > > > > 
> > > > > >  Hello all,
> > > > > > 
> > > > > >  I've just hit again something that I've hit (and probably others 
> > > > > > too)
> > > > > > often.
> > > > > >  If a change in base break some ports and it's snapshoted in the txz
> > > > > > available at download.freebsd.org, you need to wait a week for the 
> > > > > > next
> > > > > > tarball to be available.
> > > > > >  Since poudriere uses the tarball when you setup a jail it means 
> > > > > > that
> > > > > > the only solution you have is to recreate your jail by building it, 
> > > > > > and
> > > > > > since building world nowdays is very expensive that delay your work 
> > > > > > too
> > > > > > much.
> > > > > >  Would it be possible to generate the tarballs every day instead of
> > > > > > every week ? At least for tier-1 arches.
> > > > > > 
> > > > > 
> > > > > Let's revisit this sometime next week after 11.4 is out.
> > > > > 
> > > > > Glen
> > > > > 
> > > > 
> > > >  Sure, works for me.
> > > > 
> > > >  Thanks,
> > > > 
> > > 
> > >  Ping ?
> > > 
> > 
> > I thought the artifacts from the jenkins builder for CI were sufficient.
> > 
> > Glen
> > 
> 
>  Yes and no,
> 
>  I can add something to poudriere for getting the tarballs from the CI
> artifacts but that won't be by default.
> 

To be honest, that would be the preferred route, since updating the
various *.txz distribution sets would break things like bootonly.iso,
mini-memstick.img, and so on.

In other words, we already have a system in place that generates these
archive files, so I personally see no need to disrupt the "official"
snapshot build process to appease a subset of the user base while
unnecessarily adding a pain point for the rest.

Glen



signature.asc
Description: PGP signature