Update to the Release Engineering Team Roster
-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
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
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", notab
Re: [HEADS-UP] Quick update to 14.0-RELEASE schedule
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
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
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
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
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
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
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
-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 new
FreeBSD 14.0-RC3 Now Available
-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 recommen
FreeBSD 14.0-RC2 Now Available
-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 again
FreeBSD 14.0-RC1 Now Available
-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 lib
FreeBSD 14.0-BETA5 Now Available
-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
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
-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. # freebsd-upda
[UPDATE] FreeBSD 14.0-BETA3 Now Available
-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
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
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
-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) = e34913b56eb402cbcac1945d66b715757439ec125794cd6fc36c9e686b1a406bd9ec82a4902a561e5f5b33e90b1db496c278dbe489ace921baab56411d04b
FreeBSD 14.0-BETA2 Now Available
-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 1
FreeBSD 14.0-BETA1 Now Available
-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) = 2f49b058bd39f6491ae720af773dad7861509a5d
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
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)
-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) = 0d026c7e14eb64ea65ffc5
Re: Possible regression in main causing poor performance
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)
-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) = bb7b872330f89d441ff3f1263f9f882c423b46bdf2f9a
HEADS-UP: stable/14 branched
-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
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
New FreeBSD snapshots available: main (ALPHA2) (20230819 77013f29d048)
-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 (FreeBSD-14.0-ALPHA2-am
Possible regression in main causing poor performance
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)
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)
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)
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 us-west-
FreeBSD main snapshot status for 20230629
-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
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
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
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
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
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
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
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
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
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
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
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
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?
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"
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"
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"
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"
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"
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"
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"
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"
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
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
-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: ami-0201a
Re: update to RC4 from RC3 shutdown regression
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
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
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
-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: ami-022e5a7f31875d08
Re: 13.0-RELEASE schedule update: PR 251866 (unable to boot some modern hardware)
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
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
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
-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: ami
FreeBSD 13.0-RC2 Now Available
-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: ami-0f3492211bdf2157
FreeBSD 13.0-RC1 Now Available
-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 ap-northeast-
FreeBSD 13.0-BETA4 Now Available
-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 r
FreeBSD 13.0-BETA3 Now Available
-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: af-s
[RESENT] FreeBSD 13.0-BETA2 Now Available
-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: ami-09e1764
FreeBSD 13.0-BETA2 Now Available
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: ami-00daec
Re: any images for freebsd-current?
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
-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
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
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
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)
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)
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)
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)
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)
-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 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2
Re: documentation on release build process change (svn -> git)?
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)?
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)?
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)?
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)?
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)?
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)?
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)?
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)?
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)?
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)?
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
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?
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?
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?
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 ?
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 ?
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 ?
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