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-di
Re: Possible issue with linux xattr support?
* Felix Palmen [20230825 19:54]:
> So, hoping for someone with some knowledge how to debug this ;)
Information I forgot to add, sorry:
I did my tests on an aarch64 machine with a kernel built from
a98a0090b2ba64ff0bc3cf71a00fb5f9e31fc1d3.
Cheers, Felix
--
Felix Palmen {private} fe...@palmen-it.de
-- ports committer -- {web} http://palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt
{pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231
signature.asc
Description: PGP signature
Possible issue with linux xattr support?
Hi all and Dmitry,
(CC to Dmitry because he added this linux xattr support in
22dca7acf7756c07d3ccbfdc8dfd10fd9ad3f9cf)
I'm currently working on an idea to build a userland for Linuxulator
from source here:
https://github.com/Zirias/zfbsd-ports/commits/linux
Now I ran into an issue with the first port using the full "base"
userland for building (I tried expat2 for this): The "install" tool from
GNU coreutils was unable to set file permissions, and truss showed me
this:
| linux_fsetxattr(0x4,0x401860e8,0x134dd0,0x1c,0x0) ERR#-1 'Operation
| not permitted'
To verify, I removed xattr support completely from coreutils (and also
sed) in commit "linuxsrc: Disable usage of xattr" and indeed, with this
change, GNU's install works as it should.
So, hoping for someone with some knowledge how to debug this ;)
Thanks, Felix
--
Felix Palmen {private} fe...@palmen-it.de
-- ports committer -- {web} http://palmen-it.de
{pgp public key} http://palmen-it.de/pub.txt
{pgp fingerprint} 6936 13D5 5BBF 4837 B212 3ACC 54AD E006 9879 F231
signature.asc
Description: PGP signature
Re: www/chromium will not build on a host w/ 8 CPU and 16G mem [RPi4B 8 GiByte example]
On Fri, Aug 25, 2023 at 02:21:33AM -0700, Mark Millard wrote: > > That will not help avoid the R_AARCH64_ABS64 abuse, > unfortunately. > > Thank you for the analysis. I've posted a bug,id=273349. Sounds like I shouldn't hold my breath 8-( bob prohaska >
Re: Panic with 15.0-CURRENT
On 8/25/23, Mateusz Guzik wrote: > On 8/25/23, Yasuhiro Kimura wrote: >> Hello, >> >> I made regular update of my amd64 system from main-n264870-e5e6a865358 >> to main-n265022-1554ba03b65 and system crashed with panic while >> building packages with poudriere. >> >> Screenshot of console: >> https://people.freebsd.org/~yasu/FreeBSD-15-CURRENT-amd64-main-n265022-1554ba03b65.20230825.panic.png >> > > this is a fallout from the recent timerfd commit. I'll fix it in few. > fixed in https://cgit.freebsd.org/src/commit/?id=02f534b57f84d6f4f97c337b05b383c8b3aaf18c -- Mateusz Guzik
Re: Panic with 15.0-CURRENT
On 8/25/23, Yasuhiro Kimura wrote: > Hello, > > I made regular update of my amd64 system from main-n264870-e5e6a865358 > to main-n265022-1554ba03b65 and system crashed with panic while > building packages with poudriere. > > Screenshot of console: > https://people.freebsd.org/~yasu/FreeBSD-15-CURRENT-amd64-main-n265022-1554ba03b65.20230825.panic.png > this is a fallout from the recent timerfd commit. I'll fix it in few. -- Mateusz Guzik
Panic with 15.0-CURRENT
Hello, I made regular update of my amd64 system from main-n264870-e5e6a865358 to main-n265022-1554ba03b65 and system crashed with panic while building packages with poudriere. Screenshot of console: https://people.freebsd.org/~yasu/FreeBSD-15-CURRENT-amd64-main-n265022-1554ba03b65.20230825.panic.png --- Yasuhiro Kimura
Re: www/chromium will not build on a host w/ 8 CPU and 16G mem [RPi4B 8 GiByte example]
On Aug 24, 2023, at 21:57, bob prohaska wrote: > On Thu, Aug 24, 2023 at 03:20:50PM -0700, Mark Millard wrote: >> bob prohaska wrote on >> Date: Thu, 24 Aug 2023 19:44:17 UTC : >> >>> On Fri, Aug 18, 2023 at 08:05:41AM +0200, Matthias Apitz wrote: sysctl vfs.read_max=128 sysctl vfs.aio.max_buf_aio=8192 sysctl vfs.aio.max_aio_queue_per_proc=65536 sysctl vfs.aio.max_aio_per_proc=8192 sysctl vfs.aio.max_aio_queue=65536 sysctl vm.pageout_oom_seq=120 sysctl vm.pfault_oom_attempts=-1 >>> >>> Just tried these settings on a Pi4, 8GB. Seemingly no help, >>> build of www/chromium failed again, saying only: >>> >>> ===> Compilation failed unexpectedly. >>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to >>> the maintainer. >>> *** Error code 1 >>> >>> No messages on the console at all, no indication of any swap use at all. >>> If somebody can tell me how to invoke MAKE_JOBS_UNSAFE=yes, either >>> locally or globally, I'll give it a try. But, if it's a system problem >>> I'd expect at least a peep on the console >> >> Are you going to post the log file someplace? > > > http://nemesis.zefox.com/~bob/data/logs/bulk/main-default/2023-08-20_16h11m59s/logs/errors/chromium-115.0.5790.170_1.log > >> You may have missed an earlier message. > > Yes, I did. Some (very long) lines above there is: > > [ 96% 53691/55361] "python3" "../../build/toolchain/gcc_link_wrapper.py" > --output="./v8_context_snapshot_generator" -- c++ -fuse-ld=lld > -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now > -Wl,--icf=all -Wl,--color-diagnostics -Wl,--undefined-version > -Wl,-mllvm,-enable-machine-outliner=never -no-canonical-prefixes -Wl,-O2 > -Wl,--gc-sections -rdynamic -pie -Wl,--disable-new-dtags -Wl,--icf=none > -L/usr/local/lib -fstack-protector-strong -L/usr/local/lib -o > "./v8_context_snapshot_generator" -Wl,--start-group > @"./v8_context_snapshot_generator.rsp" -Wl,--end-group -lpthread > -lgmodule-2.0 -lglib-2.0 -lgobject-2.0 -lgthread-2.0 -lintl -licui18n -licuuc > -licudata -lnss3 -lsmime3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -ldl -lkvm > -lexecinfo -lutil -levent -lgio-2.0 -ljpeg -lpng16 -lxml2 -lxslt -lexpat > -lwebp -lwebpdemux -lwebpmux -lharfbuzz-subset -lharfbuzz -lfontconfig -lopus > -lopenh264 -lm -lz -ldav1d -lX11 -lXcomposite -lXdamage -lXext -lXfixes > -lXrender -lXrandr -lXtst -lepoll-shim -ldrm -lxcb -lxkbcommon -lgbm -lXi > -lGL -lpci -lffi -ldbus-1 -lpangocairo-1.0 -lpango-1.0 -lcairo -latk-1.0 > -latk-bridge-2.0 -lsndio -lFLAC -lsnappy -latspi > FAILED: v8_context_snapshot_generator That FAILED line is 64637. > Then, a bit further down in the file a series of > d.lld: error: relocation R_AARCH64_ABS64 cannot be used against local symbol; > recompile with -fPIC > complaints. The first R_AARCH64_ABS64 lines is 64339. After that are the next 2 lines, with: defined in obj/third_party/ffmpeg/libffmpeg_internal.a(ffmpeg_internal/autorename_libavcodec_aarch64_fft_neon.o) and: referenced by ffmpeg_internal/autorename_libavcodec_aarch64_fft_neon.o:(fft_tab_neon) in archive obj/third_party/ffmpeg/libffmpeg_internal.a > Unclear if the two kinds of complaints are related, nor whether they're the > first.. > >> How long had it run before stopping? > > 95 hours, give or take. Nothing about timeout was reported > >> How does that match up with the MAX_EXECUTION_TIME >> and NOHANG_TIME and the like that you have poudriere set >> up to use ( /usr/local/etc/poudriere.conf ). > > NOHANG_TIME=44400 > MAX_EXECUTION_TIME=1728000 > MAX_EXECUTION_TIME_EXTRACT=144000 > MAX_EXECUTION_TIME_INSTALL=144000 > MAX_EXECUTION_TIME_PACKAGE=11728000 > Admittedly some are plain silly, I just started > tacking on zeros after getting timeouts and being > unable to match the error message and variable name.. > > I checked for duplicates this time, however. Not stopped for time. >> Something relevant for the question is what you have for: >> >> # Grep build logs to determine a possible build failure reason. This is >> # only shown on the web interface. >> # Default: yes >> DETERMINE_BUILD_FAILURE_REASON=no >> >> Using DETERMINE_BUILD_FAILURE_REASON leads to large builds >> running for a long time after it starts the process of >> stopping from a timeout the grep activity takes a long >> time and the build activity is not stopped during the >> grep. >> >> >> vm.pageout_oom_seq=120 and vm.pfault_oom_attempts=-1 make >> sense to me for certain kinds of issues involved in large >> builds, presuming sufficient RAM+SWAP for how it is set >> up to operate. vm.pageout_oom_seq is associated with >> console/log messages. if one runs out of RAM+SWAP, >> vm.pfault_oom_attempts=-1 tends to lead to deadlock. But >> it allows slow I/O to have the time to complete and so >> can be useful. >> >> I'm not sure that any vfs.aio.* is actually involved: special >> system calls are involved, splitting requests vs.
