I'm running a FreeBSD 13.1 amd64 build from stable/13 at changeset b63021e001d. uname:
I'd noticed some unusual errors when building ports - using ZFS in poudriere, no tmpfs. An example of the error, during a port build for llvm13:
In a local ports build, this bad FD error had occurred with a total of 190 ports, during one poudriere bulk run. This might be an example of a bug observed by y.freebsd@paritcher.com.
At the time - I was in fact running cinnamon in an X session while poudriere ran - I'd also noticed that gvfsd-trash had more than 10,000 open file descriptors, visible via 'fstat -p'. I've since sent a patch to the ports section of FreeBSD bugzilla, for devel/gvfs, to make gvfsd-trash an optional feature in the port. After closing the gvfsd-trash process (sighup) then rebulding iirc during the same boot session, I'd not noticed the error again.
I later rebooted, and tried to finish the port build. The Bad FD error resurfaced. So, I rebuilt the kernel, using options recommended by y.freebsd:
The port build completed, running the newer kernel built from that same changeset.
Out of curiousity, I thought I'd try building FreeBSD 13.1 from stable/13 (at a latest changeset, 84b4709f38f) using LLVM 14 from ports. This machine is using ZFS on root. bectl made it easy to install the upgrade. I rebooted to the new root filesystem, but it failed to boot during vfs mount.
This new build was built with LLVM 14 from ports as XCC
With this FreeBSD 13.1 build, built with LLVM 14 from ports, I was dropped to the loader to select a suitable root filesystem. I tried to select the filesystem from the earlier build, but the loader reported the same error, "Unknown file system". Both of these filesystems are on ZFS.
The 13.1-next-01 build was built with LLVM 14 from ports, at the newer changeset. It was mounted successfully while booted from the 13.1-next-00 root filesystem, with the uname illustrated above.
When trying to boot from the 13.1-next-01 filesystem, it failed - seemingly unable to recognize the root filesystem on ZFS. I've rebooted successfully from the root filesystem mroot/ROOT/13.1-next-00 on the same ZFS pool.
Using a USB thumb drive from a local memstick image for an earlier stable/13 build (built with LLVM 13 from the base system), I was able to reboot and set the
I'm assuming that the newer stable/13 source tree will probably build and run successfully if it's built with LLVM 13 from the base system, using the existing, bootable stable/13 build. I'll try to test this shortly.
I've rebooted to the earlier stable/13 build for now, with the newer kernel build (same changeset as the base system, added kernel options as above). I'll try to test out some more port builds, hopefully the bad FD error may not occur with this build.
I'm not certain why the build with LLVM 14 from ports would not boot. The same ZFS root filesystem is accessible with that earlier build, which was built with LLVM in the base system (CC and XCC)
Is it odd that newer stable/13 build that was built with LLVM 14 from ports would not load the root (ZFS) filesystem?
Code:
FreeBSD xmin.cloud.thinkum.space 13.1-STABLE FreeBSD 13.1-STABLE #1 build/stable/13-n252436-b63021e001d: Sat Oct 22 08:47:32 PDT 2022 gimbal@xmin.cloud.thinkum.space:/usr/obj/xmin_FreeBSD-13.1-STABLE_amd64/usr/src/amd64.amd64/sys/XMIN amd64I'd noticed some unusual errors when building ports - using ZFS in poudriere, no tmpfs. An example of the error, during a port build for llvm13:
Code:
===> Returning to build of llvm13-13.0.1_3
===> llvm13-13.0.1_3 depends on executable: ninja - not found
===> Installing existing package /packages/All/ninja-1.11.1,2.pkg
[xmin.bld.cloud.thinkum.space] Installing ninja-1.11.1,2...
[xmin.bld.cloud.thinkum.space] `-- Installing python38-3.8.15...
[xmin.bld.cloud.thinkum.space] | `-- Installing libffi-3.4.3...
[xmin.bld.cloud.thinkum.space] | `-- Extracting libffi-3.4.3: .......... done
[xmin.bld.cloud.thinkum.space] | `-- Installing mpdecimal-2.5.1...
[xmin.bld.cloud.thinkum.space] | `-- Extracting mpdecimal-2.5.1: .......... done
[xmin.bld.cloud.thinkum.space] | `-- Installing readline-8.1.2...
[xmin.bld.cloud.thinkum.space] | `-- Extracting readline-8.1.2: .......... done
[xmin.bld.cloud.thinkum.space] `-- Extracting python38-3.8.15: ...
pkg-static: Fail to chown /usr/local/lib/python3.8/idlelib/idle_test/.pkgtemp.test_squeezer.py.bFIrNzt0LFou:Bad file descriptorIn a local ports build, this bad FD error had occurred with a total of 190 ports, during one poudriere bulk run. This might be an example of a bug observed by y.freebsd@paritcher.com.
At the time - I was in fact running cinnamon in an X session while poudriere ran - I'd also noticed that gvfsd-trash had more than 10,000 open file descriptors, visible via 'fstat -p'. I've since sent a patch to the ports section of FreeBSD bugzilla, for devel/gvfs, to make gvfsd-trash an optional feature in the port. After closing the gvfsd-trash process (sighup) then rebulding iirc during the same boot session, I'd not noticed the error again.
I later rebooted, and tried to finish the port build. The Bad FD error resurfaced. So, I rebuilt the kernel, using options recommended by y.freebsd:
Code:
makeoptions BUILD_OPTIMIZED=NO
makeoptions COPTFLAGS=-O0The port build completed, running the newer kernel built from that same changeset.
Out of curiousity, I thought I'd try building FreeBSD 13.1 from stable/13 (at a latest changeset, 84b4709f38f) using LLVM 14 from ports. This machine is using ZFS on root. bectl made it easy to install the upgrade. I rebooted to the new root filesystem, but it failed to boot during vfs mount.
This new build was built with LLVM 14 from ports as XCC
With this FreeBSD 13.1 build, built with LLVM 14 from ports, I was dropped to the loader to select a suitable root filesystem. I tried to select the filesystem from the earlier build, but the loader reported the same error, "Unknown file system". Both of these filesystems are on ZFS.
Code:
$ bectl list -a
BE/Dataset/Snapshot Active Mountpoint Space Created
13.1-STABLE
mroot/ROOT/13.1-STABLE - - 724K 2022-10-10 00:14
mroot/ROOT/13.1-next-01@2022-10-22-08:52:52-0 - - 0 2022-10-22 08:52
13.1-next-00
mroot/ROOT/13.1-next-00 NR / 1.81M 2022-10-22 08:52
mroot/ROOT/13.1-next-01@2022-10-22-10:43:49-0 - - 0 2022-10-22 10:43
13.1-next-01
mroot/ROOT/13.1-next-01 - - 16.9G 2022-10-22 10:43The 13.1-next-01 build was built with LLVM 14 from ports, at the newer changeset. It was mounted successfully while booted from the 13.1-next-00 root filesystem, with the uname illustrated above.
When trying to boot from the 13.1-next-01 filesystem, it failed - seemingly unable to recognize the root filesystem on ZFS. I've rebooted successfully from the root filesystem mroot/ROOT/13.1-next-00 on the same ZFS pool.
Using a USB thumb drive from a local memstick image for an earlier stable/13 build (built with LLVM 13 from the base system), I was able to reboot and set the
bootfs property on the root ZFS pool to boot from the original root filesystem with stable/13 built at changeset b63021e001d.I'm assuming that the newer stable/13 source tree will probably build and run successfully if it's built with LLVM 13 from the base system, using the existing, bootable stable/13 build. I'll try to test this shortly.
I've rebooted to the earlier stable/13 build for now, with the newer kernel build (same changeset as the base system, added kernel options as above). I'll try to test out some more port builds, hopefully the bad FD error may not occur with this build.
I'm not certain why the build with LLVM 14 from ports would not boot. The same ZFS root filesystem is accessible with that earlier build, which was built with LLVM in the base system (CC and XCC)
Is it odd that newer stable/13 build that was built with LLVM 14 from ports would not load the root (ZFS) filesystem?