From the FreeBSD Primary Release Engineering Team Lead at <https://redd.it/180nzh8>
UseYou need to freebsd-update fetch install before you upgrade
Moving from FreeBSD 13 to FreeBSD 14 we have the unusual case of a file in FreeBSD 13 having the same name as a directory in FreeBSD 14. This is not something I ever imagined happening when I wrote freebsd-update, and my original code didn't handle it (I assumed that I could create everything new before deleting old bits). This was fixed via an Errata Notice but if you haven't installed the fix yet then using freebsd-update to upgrade to 14.0 will break.
freebsd-update fetch install
for your last copy of the version you use, before using freebsd-update
to upgradde to 14.0.FreeBSD Update reports 14.0-RELEASE approaching its EoL
The FreeBSD Update metadata includes the release End-of-Life date; but the wrong value got inserted when the FreeBSD Update bits were put together for FreeBSD 14.0-RELEASE. Just ignore the warning; it will go away with the value being corrected along with the first Security Advisory or Errata Notice.
Be careful when merging master.passwd
The default shell for root changed from csh to sh in FreeBSD 14. When you upgrade to FreeBSD 14, freebsd-update will prompt you to merge changes to /etc/master.passwd...
Moving from FreeBSD 13 to FreeBSD 14 we have the unusual case of a file in FreeBSD 13 having the same name as a directory in FreeBSD 14. This is not something I ever imagined happening when I wrote freebsd-update, and my original code didn't handle it (I assumed that I could create everything new before deleting old bits). This was fixed via an Errata Notice but if you haven't installed the fix yet then using freebsd-update to upgrade to 14.0 will break.
Installing updates...rm: /jails/plex//usr/include/c++/v1/__string: is a directory
Stickied. Can't make it any more prominent.That "breakage" blog message from Colin Percival needs to be pinned somewhere prominent.
As far as I can tell, nothing major. Issue appears to be in an include file/directory. As long as you don't actually compile anything it would not be a problem. And looking at the directory, yours appears to be in a jail too. Probably not very likely you're going to be doing a lot of compiling C/C++ in jail for PlexIs this a problem I need to be concerned about?
freebsd-update install
just stops working when this happens. It stalls, waiting for something that's never going to happen. So the upgrade is never properly completed.root@jenkins:~ # 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
load: 0.61 cmd: sh 68533 [wait] 950.32r 1.90u 7.60s 0% 3408k
mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1e1 kern_wait6+0x560 sys_wait4+0x7d amd64_syscall+0x10c fast_syscall_common+0xf8
^C
Force it as a modal pop-up on every page load?Can't make it any more prominent.
Force it as a modal pop-up on every page load?
… update the bootcode when you have root on ZFS and want to upgrade the pool.
Force it as a modal pop-up on every page load?
Make it blink!
… Is this a problem I need to be concerned about?
III. Impact
Using freebsd-update to upgrade to FreeBSD 14.0 emits errors during install and results in a system with broken C++ headers.
As far as I can tell, nothing major. Issue appears to be in an include file/directory. As long as you don't actually compile anything it would not be a problem. And looking at the directory, yours appears to be in a jail too. Probably not very likely you're going to be doing a lot of compiling C/C++ in jail for Plex
What is a problem is thatfreebsd-update install
just stops working when this happens. It stalls, waiting for something that's never going to happen. So the upgrade is never properly completed.
Intended to illicit the error. Just to see what would happen. It just gets stuck.Code:root@jenkins:~ # 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 load: 0.61 cmd: sh 68533 [wait] 950.32r 1.90u 7.60s 0% 3408k mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1e1 kern_wait6+0x560 sys_wait4+0x7d amd64_syscall+0x10c fast_syscall_common+0xf8 ^C
14.0-RELEASE
uname -mp
… The notice didn't reach another location of https://www.freebsd.org/releases/14.0R/errata/ yet.
I applaud the collective creativeness, but still, it's not enough.
Not sure why it got stuck though, I left it for about an hour and it never progressed beyond those errors. <ctrl>-T showed the process was sleeping, probably waiting on a signal(3) that never gets triggered. This was on a 13.2-RELEASE-p3. Luckily this system has ZFS and freebsd-update(8) created new boot environments with every step. So I just reverted to the "pre-upgrade" BE and did aI saw the same error on all upgrades but did not run into the more extensive errors you saw in your test, and with no failed or stuck upgrades.
freebsd-update fetch install
first to get it up to p5. Then redid the upgrade to 14.0. freebsd-update fetch install
first to get to the latest patch release before undertaking a major (or minor) version upgrade. A few years ago we had a different kind of bug, that bug made it impossible to upgrade to 11.0 from any previous version.ah, the good old times when a simple '<marquee>' tag could bring the whole browser to its knees...Blinking is so Web 0.8. Should have never given up on it.
<marquee><blink>late breaking breakage</blink></marquee>
... and make that a full-screen overlay while at it...I had file and directory inconsistencies when I ranI assumed this was benign, but seeing this announcement now I'm not so sure. Is this a problem I need to be concerned about?
freebsd-update IDS
.… Serious questions remain, …
… up to p5. Then …
CAUTION
To update old EFI system partitions, users should stop using the gpart(8) utility.
Mount the partition (if it's not mounted already)Could you please explain about this further, on what to do, in case of EFI?
mount -t msdosfs /dev/ada0p1 /boot/efi
(Use the correct disk and partition for your system; look at gpart show
) cp /boot/loader.efi /boot/efi/EFI/BOOT/Bootx64.efi
The 'target' directory and filename (EFI/BOOT/BOOTx64.efi) is on a FAT filesystem, FAT isn't case sensitive, so the exact case may be different on your system, case doesn't matter. Certain installations may also have created a EFI/FreeBSD/loader.efi, copy /boot/loader.efi to that too, just for good measure.