Late-breaking FreeBSD 14 breakage

You 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.
Use 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...


These are parts of it. It also points to https://www.freebsd.org/security/advisories/FreeBSD-EN-23:12.freebsd-update.asc. The notice didn't reach another location of https://www.freebsd.org/releases/14.0R/errata/ yet.
 
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.

The listed errata is from October, and, prior to this announcement, I upgraded all my servers and jails from 13.2-RELEASE to 14.0-RELEASE. They were all on either p4 or p5 prior to the update, and all upgrades appear to have been successful, but seeing this error made me concerned about this, which is an error I received during all my upgrades:

Installing updates...rm: /jails/plex//usr/include/c++/v1/__string: is a directory

I assumed this was benign, but seeing this announcement now I'm not so sure. Is this a problem I need to be concerned about?
 
Is this a problem I need to be concerned about?
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 that 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.

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
Intended to illicit the error. Just to see what would happen. It just gets stuck.
 
cracauer@ I did snort when I read "Make it blink". Fortunately, I wasn't drinking anything. A friend used to preface funny lines with what he called C&C warnings. Coffee, because you might spit it out and cats, because as most cat owners learn sooner or later, if a cat is on your lap, and you suddenly laugh, the cat, startled, will take off, digging its claws into your legs for purchase.
 
Force it as a modal pop-up on every page load? 🤡

Make it blink!

I applaud the collective creativeness, but still, it's not enough.

Combine those two things with an asynchronous progress indicator in the modal, for maybe five seconds, whilst this page undergoes a background redirect to Colin's post, which is pinned in Reddit. I already submitted a patch to XenForo.
 
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 that 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.

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
Intended to illicit the error. Just to see what would happen. It just gets stuck.

Woops, wrote my post too quickly and didn't stop to sanitize my error. But yeah, aside from Plex, between two physical servers and perhaps a dozen jails between them, I 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. None of my current jails or physical hosts compile anything, so it sounds like the problem is not negatively affecting me.
 
I 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.
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 a freebsd-update fetch install first to get it up to p5. Then redid the upgrade to 14.0.

Any way, it's always a good idea to 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.

 
Blinking is so Web 0.8. Should have never given up on it.
ah, the good old times when a simple '<marquee>' tag could bring the whole browser to its knees...

So I vote for <marquee><blink>late breaking breakage</blink></marquee>... and make that a full-screen overlay while at it...

(scnr)


regarding that "late-breaking breakage":
Seems I was spot-on with my wild guess about freebsd-update and the "file became a directory" change - I should have played the lottery that day 😩
 

CAUTION

To update old EFI system partitions, users should stop using the gpart(8) utility.



Could you please explain about this further, on what to do, in case of EFI?

With SirDice 's help, I have successfully updated my non-UEFI computers' bootcode (they had freebsd-boot), however I have one computer left, running 13.2 with UEFI and EFI partitions. And I'd love to know how to proceed with that.
 
Could you please explain about this further, on what to do, in case of EFI?
Mount the partition (if it's not mounted already)
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.

Some older installations may have a created a buggy FAT partition. You could get an error saying loader.efi doesn't fit even though the filesystem appears to be large enough. Then you may need to newfs_msdos(8) it first.
 
Back
Top