While upgrading 13.2-p3 to 14.0-BETA1 on amd64, after rebooting and during the second freebsd-update install I get: # freebsd-update install src component not installed, skipped Creating snapshot of existing boot environment... done. Installing updates...install: ///usr/include/c++/v1/__string exists but is not a directory install: ///usr/include/c++/v1/__string/char_traits.h: Not a directory install: ///usr/include/c++/v1/__string/extern_template_lists.h: Not a directory
@dim, do you know off hand of Clang changes that might have triggered this?
I'm unsure if freebsd-update can cope with it, but at some point during the llvm-15 import (which happened after 13.2 was released), the _file_ /usr/include/c++/v1/__string changed into a _directory_. In https://cgit.freebsd.org/src/diff/etc/Makefile?id=fcaf7f8644a99 this is handled by the distrib-cleanup target: the old file is deleted before creating the new directory (which I assume is done by mtree).
Confirmed, I see this also.
I had similiar on 13-STABLE after a potionally upgrade from src. I have too boot from the ISO and copy the files over manually. I never investigated the cause.
(In reply to Michael Osipov from comment #4) Sensible approach, I assume that's the way to fix it properly. For those who are hit by this bug and don't want to search for install media, extract tarballs etc., here's a another, simpler approach that seems to work just as well. I can confirm that Clang is usable as I compiled GROMACS (C++) with several different CMake configurations just to verify that. Assuming machine can access the internet, as root do the following: # cd /usr/include/c++/v1 # mkdir __string # cd __string # fetch https://raw.githubusercontent.com/freebsd/freebsd-src/releng/14.0/contrib/llvm-project/libcxx/include/__string/char_traits.h # fetch https://raw.githubusercontent.com/freebsd/freebsd-src/releng/14.0/contrib/llvm-project/libcxx/include/__string/extern_template_lists.h
Upgrading a poudriere jail from src also gets bitten by this, but slightly different: cd /zroot/poudriere/jails/14-amd64/usr/src; time env INSTALL="sh /zroot/poudriere/jails/14-amd64/usr/src/tools/install.sh" TOOLS_PREFIX=/usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64 .amd64/tmp PATH=/usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/zroot /poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/o bj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp MAKEFLAGS="-m /zroot/poudriere/jails/14-amd64/usr/src/tools/build/mk -j 4 -J 15,16 -m /zroot/poudriere/jails/14-amd64/usr/src/shar e/mk" make -f Makefile.inc1 DESTDIR= OBJTOP='/usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools' OBJROOT='${OBJTOP}/' UNIVERSE_TOOLCHAIN_PATH= MAKEOBJDIRPREFIX= BOOTSTRAPPING=1400097 BWPHASE=bootstrap-tools -DNO_CPU_CFLAGS -DNO_LINT -DNO_PIC -DNO_SHARED MK_ASAN=no MK_CTF=no MK_CLANG_EXTRAS=no MK_CLANG_FORMAT=no MK_CLANG_FULL=no MK_HTML=n o MK_MAN=no MK_PROFILE=no MK_RETPOLINE=no MK_SSP=no MK_TESTS=no MK_UBSAN=no MK_WERROR=no MK_INCLUDES=yes MK_MAN_UTILS=yes MK_LLVM_TARGET_ALL=no bootstrap-tools Building /usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/fortune/strfile/strfile.o Building /usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libclangminimal/Support/RISCVVIntrinsicUtils.o Building /usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/dtc/dtc.o Building /usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/Demangle/ItaniumDemangle.o Building /usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/fortune/strfile/strfile.full Building /usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/fortune/strfile/strfile.debug Building /usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/fortune/strfile/strfile Building /usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/fortune/strfile/_proginstall Building /usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/dtc/input_buffer.o In file included from /zroot/poudriere/jails/14-amd64/usr/src/contrib/llvm-project/llvm/lib/Demangle/ItaniumDemangle.cpp:13: In file included from /zroot/poudriere/jails/14-amd64/usr/src/contrib/llvm-project/llvm/include/llvm/Demangle/Demangle.h:13: /usr/include/c++/v1/string:561:10: fatal error: '__string/char_traits.h' file not found #include <__string/char_traits.h> ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from /zroot/poudriere/jails/14-amd64/usr/src/usr.bin/dtc/dtc.cc:44: In file included from /zroot/poudriere/jails/14-amd64/usr/src/usr.bin/dtc/fdt.hh:35: In file included from /usr/include/c++/v1/algorithm:1913: In file included from /usr/include/c++/v1/chrono:746: In file included from /usr/include/c++/v1/__chrono/convert_to_tm.h:19: In file included from /usr/include/c++/v1/__chrono/statically_widen.h:17: In file included from /usr/include/c++/v1/__format/concepts.h:17: In file included from /usr/include/c++/v1/__format/format_parse_context.h:15: /usr/include/c++/v1/string_view:220:10: fatal error: '__string/char_traits.h' file not found #include <__string/char_traits.h> ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from /zroot/poudriere/jails/14-amd64/usr/src/contrib/llvm-project/clang/lib/Support/RISCVVIntrinsicUtils.cpp:9: In file included from /zroot/poudriere/jails/14-amd64/usr/src/contrib/llvm-project/clang/include/clang/Support/RISCVVIntrinsicUtils.h:12: In file included from /zroot/poudriere/jails/14-amd64/usr/src/contrib/llvm-project/llvm/include/llvm/ADT/ArrayRef.h:12: In file included from /zroot/poudriere/jails/14-amd64/usr/src/contrib/llvm-project/llvm/include/llvm/ADT/Hashing.h:51: In file included from /usr/include/c++/v1/algorithm:1913: In file included from /usr/include/c++/v1/chrono:746: In file included from /usr/include/c++/v1/__chrono/convert_to_tm.h:19: In file included from /usr/include/c++/v1/__chrono/statically_widen.h:17: In file included from /usr/include/c++/v1/__format/concepts.h:17: In file included from /usr/include/c++/v1/__format/format_parse_context.h:15: /usr/include/c++/v1/string_view:220:10: fatal error: '__string/char_traits.h' file not found #include <__string/char_traits.h> ^~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. *** [dtc.o] Error code 1 make[3]: stopped in /zroot/poudriere/jails/14-amd64/usr/src/usr.bin/dtc .ERROR_TARGET='dtc.o' .ERROR_META_FILE='/usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/dtc/dtc.o.meta' .MAKE.LEVEL='3' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='/usr/local/bin/ccache c++ -O2 -pipe -fno-common -g -gz=zlib -Wno-format-zero-length -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wpointer-arith -Wno-uninitia lized -Wdate-time -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-parameter -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -W no-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments -I/usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/legacy/us r/include -fno-rtti -fno-exceptions -std=c++11 -Wno-c++11-extensions -c /zroot/poudriere/jails/14-amd64/usr/src/usr.bin/dtc/dtc.cc -o dtc.o;' .CURDIR='/zroot/poudriere/jails/14-amd64/usr/src/usr.bin/dtc' .MAKE='make' .OBJDIR='/usr/obj/zroot/poudriere/jails/14-amd64/usr/src/amd64.amd64/tmp/obj-tools/usr.bin/dtc' .TARGETS='all' CPUTYPE='' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MACHINE_CPUARCH='amd64' 0.92 real 0.47 user 0.14 sys make[1]: stopped in /zroot/poudriere/jails/14-amd64/usr/src
(In reply to Rene Ladan from comment #6) This is from 14.0-ALPHA3 to todays stable/14
(In reply to Rene Ladan from comment #6) That means that for some reason the headers didn't get installed, but the directory does seem to have been made? You should probably look at the installworld log for the jail.
Semi-related, the third invocation of freebsd-update fails to complete at least two file moves in the OpenZFS contrib code: > # freebsd-update install > Installing updates...rmdir: ///usr/src/sys/contrib/openzfs/cmd/zvol_wait: Directory not empty > rmdir: ///usr/src/sys/contrib/openzfs/cmd/arc_summary: Directory not empty > done. > > # ls ///usr/src/sys/contrib/openzfs/cmd/zvol_wait > b3433d339ca5398071ebb49e801b32f541c1f3f95b5c76ca8dbdf1888faec897* > > # ls ///usr/src/sys/contrib/openzfs/cmd/arc_summary > 81fc104da57777f45c931c9c2f425f1fe219d12dc61a9d2928a1b03561f9aecb* Both are executable scripts, one shell, the other python. Quick fix is to mv the file out of the directory, rmdir the directory, then change that file's name to be that of the directory. Neither script is actually installed into the base system, but arc_summary is available as a port under sysutils. Not sure if a new bug should be opened for this, or if any/all issues w/ freebsd-update itself failing to complete file updates should go into this bug. A quick way to find these missed files may be to look for a file with a name 64 characters long in hex via 'find . -type f | grep -E "[a-f0-9]{64}"'
Perhaps related, after doing a freebsd-update from 13.2-R to 14.0-BETA1 (I believe this is a continued upgrade from earlier from when upgrading userland took to long and I had to catch a train to Coimbra), I see this in the third `freebsd-update install` after upgrading all ports packages: `` Creating snapshot of existing boot environment... done. Installing updates...rmdir: ///usr/tests/usr.bin/uuencode: Directory not empty rmdir: ///usr/tests/usr.bin/uudecode: Directory not empty rmdir: ///usr/src/sys/contrib/openzfs/cmd/zvol_wait: Directory not empty rmdir: ///usr/src/sys/contirb/openzfs/cmd/arc_summary: Directory not empty ``` But perhaps this is because I might have downloaded patches for BETA3 too, not sure where they went though.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f6d37c9ca13f8ab0ef32cf5344daecb8122d1e85 commit f6d37c9ca13f8ab0ef32cf5344daecb8122d1e85 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-09-27 13:36:33 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-09-27 19:23:08 +0000 freebsd-update: handle file -> directory on upgrade Upgrading from FreeBSD 13.2 to 14.0 failed with install: ///usr/include/c++/v1/__string exists but is not a directory because __string changed from a file to a directory with an LLVM upgrade. Now, remove the existing file when the type conflicts. Note that this is only an interim fix to facilitate upgrades from 13.2 for 14.0 BETA testing. This change does not handle the directory -> file case and further work is needed. PR: 273661 Reviewed by: dim, gordon Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41893 usr.sbin/freebsd-update/freebsd-update.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
A change to handle the file->directory case is now committed to main. Note that rollback will not yet work because we don't handle the directory->file case, in addition to preexisting issues with rollback (PR256252, PR273950). You can try fetching freebsd-update from main and using it to upgrade to 14.0-BETA3 with something like: $ fetch -o freebsd-update https://cgit.freebsd.org/src/plain/usr.sbin/freebsd-update/freebsd-update.sh $ sha256 freebsd-update SHA256 (freebsd-update) = cf4f38fb2ccc32236be9ec2300a21dcb02a1520d26f82479355b55508dd8598f $ chmod a+x freebsd-update then carry on with usual freebsd-update steps: # ./freebsd-update -r 14.0-BETA3 upgrade ...
At present a warning will still be emitted during the upgrade: rm: ///usr/include/c++/v1/__string: is a directory Despite this the on-disk install will be correct. The warning can be ignored.
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=bc412215646cbb21529156d08fbbb7bbf5028c26 commit bc412215646cbb21529156d08fbbb7bbf5028c26 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-09-27 13:36:33 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-10-01 13:06:44 +0000 freebsd-update: handle file -> directory on upgrade Upgrading from FreeBSD 13.2 to 14.0 failed with install: ///usr/include/c++/v1/__string exists but is not a directory because __string changed from a file to a directory with an LLVM upgrade. Now, remove the existing file when the type conflicts. Note that this is only an interim fix to facilitate upgrades from 13.2 for 14.0 BETA testing. This change does not handle the directory -> file case and further work is needed. PR: 273661 Reviewed by: dim, gordon Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41893 (cherry picked from commit f6d37c9ca13f8ab0ef32cf5344daecb8122d1e85) usr.sbin/freebsd-update/freebsd-update.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
A commit in branch releng/14.0 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4719202d8cffdcae1645b2bf508ba6097e912b77 commit 4719202d8cffdcae1645b2bf508ba6097e912b77 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-09-27 13:36:33 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-10-01 16:28:04 +0000 freebsd-update: handle file -> directory on upgrade Upgrading from FreeBSD 13.2 to 14.0 failed with install: ///usr/include/c++/v1/__string exists but is not a directory because __string changed from a file to a directory with an LLVM upgrade. Now, remove the existing file when the type conflicts. Note that this is only an interim fix to facilitate upgrades from 13.2 for 14.0 BETA testing. This change does not handle the directory -> file case and further work is needed. PR: 273661 Reviewed by: dim, gordon Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41893 (cherry picked from commit f6d37c9ca13f8ab0ef32cf5344daecb8122d1e85) (cherry picked from commit bc412215646cbb21529156d08fbbb7bbf5028c26) Approved by: re (gjb) usr.sbin/freebsd-update/freebsd-update.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=774cc6348a50c13b952e9f36ef8395f9b48733db commit 774cc6348a50c13b952e9f36ef8395f9b48733db Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-09-27 13:36:33 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-10-01 16:33:03 +0000 freebsd-update: handle file -> directory on upgrade Upgrading from FreeBSD 13.2 to 14.0 failed with install: ///usr/include/c++/v1/__string exists but is not a directory because __string changed from a file to a directory with an LLVM upgrade. Now, remove the existing file when the type conflicts. Note that this is only an interim fix to facilitate upgrades from 13.2 for 14.0 BETA testing. This change does not handle the directory -> file case and further work is needed. PR: 273661 Reviewed by: dim, gordon Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41893 (cherry picked from commit f6d37c9ca13f8ab0ef32cf5344daecb8122d1e85) usr.sbin/freebsd-update/freebsd-update.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
A commit in branch stable/12 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=274281864fc03c62443677751bf3036fbbf9d778 commit 274281864fc03c62443677751bf3036fbbf9d778 Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-09-27 13:36:33 +0000 Commit: Ed Maste <emaste@FreeBSD.org> CommitDate: 2023-10-01 16:33:56 +0000 freebsd-update: handle file -> directory on upgrade Upgrading from FreeBSD 13.2 to 14.0 failed with install: ///usr/include/c++/v1/__string exists but is not a directory because __string changed from a file to a directory with an LLVM upgrade. Now, remove the existing file when the type conflicts. Note that this is only an interim fix to facilitate upgrades from 13.2 for 14.0 BETA testing. This change does not handle the directory -> file case and further work is needed. PR: 273661 Reviewed by: dim, gordon Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41893 (cherry picked from commit f6d37c9ca13f8ab0ef32cf5344daecb8122d1e85) usr.sbin/freebsd-update/freebsd-update.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
Screen recordings of upgrades from 12.3 and from 13.2, fetching freebsd-update per comment #12 12.3 https://asciinema.org/a/611456 13.2 https://asciinema.org/a/611461
Fix is merged into all stable branches and 14.0 releng branch, and being prepared for an EN for 12.4 and 13.2. (In reply to Rene Ladan from comment #10) > Installing updates...rmdir: ///usr/tests/usr.bin/uuencode: Directory not empty > rmdir: ///usr/tests/usr.bin/uudecode: Directory not empty > rmdir: ///usr/src/sys/contrib/openzfs/cmd/zvol_wait: Directory not empty > rmdir: ///usr/src/sys/contirb/openzfs/cmd/arc_summary: Directory not empty I did not observe any similar errors while testing this change; if you happy to see this again please open a new bug with the details.
A commit in branch releng/13.2 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=cfb624d7e2507c81441bb01e0078abad25ef235d commit cfb624d7e2507c81441bb01e0078abad25ef235d Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-09-27 13:36:33 +0000 Commit: Gordon Tetlow <gordon@FreeBSD.org> CommitDate: 2023-10-03 21:22:19 +0000 freebsd-update: handle file -> directory on upgrade Upgrading from FreeBSD 13.2 to 14.0 failed with install: ///usr/include/c++/v1/__string exists but is not a directory because __string changed from a file to a directory with an LLVM upgrade. Now, remove the existing file when the type conflicts. Note that this is only an interim fix to facilitate upgrades from 13.2 for 14.0 BETA testing. This change does not handle the directory -> file case and further work is needed. PR: 273661 Reviewed by: dim, gordon Approved by: so Security: FreeBSD-EN-23:12.freebsd-update Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41893 (cherry picked from commit f6d37c9ca13f8ab0ef32cf5344daecb8122d1e85) (cherry picked from commit 774cc6348a50c13b952e9f36ef8395f9b48733db) usr.sbin/freebsd-update/freebsd-update.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
A commit in branch releng/12.4 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=0eb6c273622d77a89115e7d4f01609eefc50b33c commit 0eb6c273622d77a89115e7d4f01609eefc50b33c Author: Ed Maste <emaste@FreeBSD.org> AuthorDate: 2023-09-27 13:36:33 +0000 Commit: Gordon Tetlow <gordon@FreeBSD.org> CommitDate: 2023-10-03 21:10:42 +0000 freebsd-update: handle file -> directory on upgrade Upgrading from FreeBSD 13.2 to 14.0 failed with install: ///usr/include/c++/v1/__string exists but is not a directory because __string changed from a file to a directory with an LLVM upgrade. Now, remove the existing file when the type conflicts. Note that this is only an interim fix to facilitate upgrades from 13.2 for 14.0 BETA testing. This change does not handle the directory -> file case and further work is needed. PR: 273661 Reviewed by: dim, gordon Approved by: so Security: FreeBSD-EN-23:12.freebsd-update Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.freebsd.org/D41893 (cherry picked from commit f6d37c9ca13f8ab0ef32cf5344daecb8122d1e85) (cherry picked from commit 274281864fc03c62443677751bf3036fbbf9d778) usr.sbin/freebsd-update/freebsd-update.sh | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
The same in 14.0-RELEASE. By the end of the upgrade via freebsd-update /usr/include/c++/v1/__strings is just missing. I had to fix it by extracting it directly from base.txz: #tar -C / -xzvf share/TEMP/base.txz './usr/include/c++/v1/__string'
And mine is a system CONTINUALLY upgraded via freebsd-update. So if freebsd-update is supposed to work, this needs to be fixed.
(In reply to bergerkos from comment #22) Did you upgrade from 13.2-RELEASE-p5 or newer? Working freebsd-update was shipped in the errata for 13.2-RELEASE: https://www.freebsd.org/releases/13.2R/errata/
I've just updated system from 13.2 to 14.0 and got the following error messages which led me to this bug: # freebsd-update install src component not installed, skipped Installing updates...rmdir: ///usr/tests/usr.bin/uuencode: Directory not empty rmdir: ///usr/tests/usr.bin/uudecode: Directory not empty This particular error message was mentioned in comment #10, though comment #19 suggested it was not reproducible. It is also the entire error (no c++ or zfs errors that seem to be the more relevant errors tackled in this bug report). System was upgraded per instructions on https://www.freebsd.org/releases/14.0R/installation/ including the initial: # freebsd-update fetch # freebsd-update install The system seems to work fine after the final restart, so I'm posting it just in case someone gets a chance to look at it. tl;dr as of 2023-11-26 a clean upgrade from 13.2 to 14.0 still emits an error.
Upgrading from 13.2-p9 to 14.0-RELEASE, I'm still getting the error Installing updates...rm: ///usr/src/contrib/llvm-project/libcxx/include/__string: is a directory rm: ///usr/include/c++/v1/__string: is a directory Though everything looks fine afterward
On 14.0 system upgraded with freebsd-update from 13.2, I've also the end /usr/include/c++/v1/string still as a file. When trying to build a software with include <string>, I've the error noted above: In file included from ./Column.h:33: /usr/include/c++/v1/string:561:10: fatal error: '__string/char_traits.h' file not found #include <__string/char_traits.h> ^~~~~~~~~~~~~~~~~~~~~~~~ So a verification for 14.0 in the next patch to supersede the file by the directory would be welcome in 14.0-RELEASE-p5 for example.
(In reply to dereckson from comment #27) > On 14.0 system upgraded with freebsd-update from 13.2 What exact version (patch level) of 13.2 did you upgrade from?
Going from 13.2-p11 to 13.3-RELEASE, this file vs. directory issue still seems to be here: # /usr/sbin/freebsd-update install src component not installed, skipped Creating snapshot of existing boot environment... done. Installing updates...install: ///usr/include/c++/v1/__string exists but is not a directory install: ///usr/include/c++/v1/__tuple exists but is not a directory install: ///usr/include/c++/v1/__string/char_traits.h: Not a directory install: ///usr/include/c++/v1/__string/constexpr_c_functions.h: Not a directory install: ///usr/include/c++/v1/__string/extern_template_lists.h: Not a directory install: ///usr/include/c++/v1/__tuple/make_tuple_types.h: Not a directory install: ///usr/include/c++/v1/__tuple/pair_like.h: Not a directory install: ///usr/include/c++/v1/__tuple/sfinae_helpers.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_element.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_indices.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_like.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_like_ext.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_size.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_types.h: Not a directory Restarting sshd after upgrade
I've been hit by the same issue after upgrading from 13.2 to 13.3 (unfortunately I don't remember if I was on the latest patch version on 13.2, though). When I try to build 'node-sass' now I get an error because an included file (__string/constexpr_c_functions.h) is missing. But "freebsd-update IDS" doesn't report any inconsistency, is it correct? I'd expect to report at least the 3 missing files in the '__string' directory, but perhaps it reports mismatches only on existing files? What's the best/easiest way to fix it now?
(In reply to Alex Dupre from comment #30) Download https://download.freebsd.org/ftp/releases/amd64/13.3-RELEASE/base.txz (or the file for another architecture, if you aren't using amd64), extract it somewhere, and replace the whole /usr/include/c++/v1 directory with the copy from the tarball.
I looked through the version history of the releng/13.2 and releng/12.4 branches, and the fix landed in 13.2-RELEASE-p4, and 12.4-RELEASE-p6, respectively. So anybody reporting on this bug again, please make sure that you have upgraded first to the above patch levels!
It's a little bit confusing, I got the following output when upgrading from 13.2 to 13.3, but this seems related to the fix itself (which tries to delete the former files). root@olinguito:~ # /usr/sbin/freebsd-update install src component not installed, skipped Installing updates...rm: ///usr/include/c++/v1/__tuple: is a directory rm: ///usr/include/c++/v1/__string: is a directory
(In reply to Andreas Schwarz from comment #33) > 13.2 Which version, exactly? Need to know the patch level.
(In reply to Graham Perrin from comment #34) Should be 13.2-RELEASE-p8 -> 13.3-RELEASE-p1 -asc
I also get Installing updates...rm: ///usr/include/c++/v1/__tuple: is a directory rm: ///usr/include/c++/v1/__string: is a directory during freebsd-upgrade from 13.2-RELEASE-p11 to 13.3-RELEASE-p4. It looks like this is benign in this case, because it has installed the new directories with the correct files.
It just happened to me today. Small media center running FreeBSD 13.2 p2. Update to 13.2 p4. Got message warning about 13.2 p4 being EOL since July the 2nd. Reboot and everything looks good. Run freebsd-update upgrade -r 13.3-RELEASE. Solve a couple of minor merge conflicts (nptd.conf and passwd). Reboot. As instructed by freebsd-update(8), execute /usr/sbin/freebsd-update install. Got: sudo /usr/sbin/freebsd-update install Password: src component not installed, skipped Installing updates...install: ///usr/include/c++/v1/__string exists but is not a directory install: ///usr/include/c++/v1/__tuple exists but is not a directory install: ///usr/include/c++/v1/__string/char_traits.h: Not a directory install: ///usr/include/c++/v1/__string/constexpr_c_functions.h: Not a directory install: ///usr/include/c++/v1/__string/extern_template_lists.h: Not a directory install: ///usr/include/c++/v1/__tuple/make_tuple_types.h: Not a directory install: ///usr/include/c++/v1/__tuple/pair_like.h: Not a directory install: ///usr/include/c++/v1/__tuple/sfinae_helpers.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_element.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_indices.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_like.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_like_ext.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_size.h: Not a directory install: ///usr/include/c++/v1/__tuple/tuple_types.h: Not a directory Restarting sshd after upgrade Performing sanity check on sshd configuration. Stopping sshd. Waiting for PIDS: 902. Performing sanity check on sshd configuration. Starting sshd. Scanning //usr/share/certs/blacklisted for certificates... Scanning //usr/share/certs/trusted for certificates... Scanning //usr/local/share/certs for certificates... done. This small computer is only upgraded with freebsd-update, only installs packages and has minimal configuration changes beyond the default. Even I don't really need the c++ headers in this machine, I replaced the whole /usr/include/c++/v1 directory with a fresh copy from the 13.3-RELEASE base.txz.
This also affects pkgbase if upgrading using this. I think the solution involves checking the error because of overwriting files with directories/vice versa, but unfortunately I don't have time to fix this myself, I'm sorry. I can't imagine this will be the last time this issue rears its head!
Reassign to pkgbase list to fix there too-- I should have time to look over the next couple of weeks but not right now, I'm sorry.
Apologies for the noise- I think it's more appropriate for me to file a pkg bug instead, so I've done this. Thanks for the work done on freebsd-update! https://github.com/freebsd/pkg/issues/2324