Late-breaking FreeBSD 14 breakage

Upgrade went well here but was very, very slow - like 10 to 11 hours for freebsd-update upgrade / install / reboot / install. I'm hoping future upgrades won't be so slow. My expectation is an upgrade should not take longer than a fresh install.
 
… 10 to 11 hours for freebsd-update upgrade / install / reboot / install. …

UFS or ZFS?

From which version of FreeBSD, exactly, did you begin updating before the major upgrade?

freebsd-update upgrade / install

Was that condensed writing, or did you omit the minor update before the major upgrade?



Reported slowness elsewhere, I do not attribute this case to download speeds:

 
I also upgraded my laptop (Thinkpad T16 with i7-1255U) yesterday from the "known clean" 13.2-RELEASE BE (I did a lot of testing with newer drm-515 and custom kernels with the BETA and RC versions and didn't want to use that as a starting point). I let it run alongside during work, but IIRC the fetching and installing of patches took somewhere between 1-2 hours.
Due to the fact that the NIC (still) won't work with mtus <5360 [1] and I often recognized processes occasionally taking much longer than expected on that CPU (stuck on one of the crippled cores?), I really didn't bother. Slow-ish download speeds could have been the NIC or overloaded mirrors; the rest could have been the CPU...

The latter "problem" showed again (as with 13.2) during rebuild of the packages with poudriere: build times of one and the same port can vary wildly on that system, most likely depending on which CPU core the build is running on. TBH, if I had looked into this (mis)feature beforehand, I'd have probably bought an 11th gen model.

I'm planning on updating my systems at home from 12.4 to 13.2 this weekend, then I'll have a direct comparison of update times. But TBH - as long as it is as smoothly as the 13.2->14.0 upgrade went (or almost any FreeBSD major upgrades I can remember) I absolutely don't care if it takes 1 or 3 hours...
You know - there's that other (so-called) OS that usually takes a whole day and completely breaks and/or is uselessly slow after a major release upgrade, and many people still consider this as "the standard" :rolleyes:


[1] https://forums.freebsd.org/threads/intel-i219-v-adl-16-unusable-with-mtu-5360.88258/
 
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.
Updating the bootcode is needed for ZFS systems only? or all upgrades from v13 to v14? And/or, only if using freebsd-update vs from source?
 
Updating the bootcode is needed for ZFS systems only?
Yes. Due to a newer version of OpenZFS. If you have a system booting from UFS, then you don't need to update the bootcode.

or all upgrades from v13 to v14?
From 12 to 13 and 13 to 14. So also from 12 to 14.
And/or, only if using freebsd-update vs from source?
Both ways will get you a new ZFS version, so how you upgrade is irrelevant. Note that you only need to upgrade the bootcode IF you upgrade your boot zpool. If you don't upgrade the pool then the old bootcode will continue to work. So I recommend just finishing the FreeBSD version upgrade first and only if everything works should you upgrade the zpool (and the bootcode).
 
I'll note, relevant for those who haven't upgraded yet: when upgrading to 14.0, and it asks you to rebuild packages before running freebsd-update install one more time, because it needs shared object libraries. If ports-mgmt/pkg is not installed, you'll get an error trying to run pkg, saying, "libsssl.so.111" not found, required by pkg.

I'm without pkg and I've heard portsnap is no longer in base. So, I'll have to resort to git in base, then build pkg.

[I'll update the command line message output for this post later. Update: alternative way to reinstall pkg afterwards, shown below, is much better]
 
I'm without pkg and I've heard portsnap is no longer in base. So, I'll have to resort to git in base, then build pkg.
Portsnap is still available, as a port/package, but yes, not included in the base anymore. No git in base either. Probably a good idea to keep a copy of the pkg package, and git-tiny perhaps?
 
I've been aware that portsnap was in ports. But I still need pkg or to update my ports tree first to get those programs.
No git in base either
I thought git or some git using program replaced portsnap in base for installing/upgrading ports-tree.

If not, what's the method that's in base, that's required to update my ports tree? For others, a clean install has to have something.
 
pkg-static should still work even if you ran the third freebsd-update install too soon and removed the old libraries.
 
Updating the bootcode is needed for ZFS systems only?

No. Not ZFS alone.

If (for example) someone has an installation of 12.4 or 13.0 for AMD64 that will be used with multiple computers:
  • UEFI loader improvements that were sponsored by The FreeBSD Foundation will significantly reduce the likelihood of FreeBSD failing to boot.
Attached: a photograph from one of the numerous reports that were closed, thanks to the set of fixes.

 

Attachments

  • 1700808335829.png
    1700808335829.png
    1 MB · Views: 84
I thought git or some git using program replaced portsnap in base. …

Whilst I was a committer, I (privately) suggested inclusion of gitup and Game of Trees:
Retrospective:

 
Hi folks,
Sorry, I'm not 100% if this is related but I think that I ran into similar issue when upgrading from 13.2-RELEASE to 14-RELEASE yesterday
I've fetched all updates first. Then rebooted and ran freebsd-update install again.. It was running without issues for a while but after some time it started throwing lots of 'File doesn't exist' errors mostly related to some man pages files. Then I rebooted the server again - it came back.. And.. Now I'm getting:


> sudo su -
ld-elf.so.1: Shared object "libintl.so.8" not found, required by "sudo"


Now - this is the best part.. (and I know - it's stupid..) - I forgot root password.. And I cannot switch to root with su command.. ;-) I know it's embarrassing.. :p
Can I ask if someone would have any suggestions on how I could fix this..?
 
Hi folks,
Sorry, I'm not 100% if this is related but I think that I ran into similar issue when upgrading from 13.2-RELEASE to 14-RELEASE yesterday
I've fetched all updates first. Then rebooted and ran freebsd-update install again.. It was running without issues for a while but after some time it started throwing lots of 'File doesn't exist' errors mostly related to some man pages files. Then I rebooted the server again - it came back.. And.. Now I'm getting:


> sudo su -
ld-elf.so.1: Shared object "libintl.so.8" not found, required by "sudo"


Now - this is the best part.. (and I know - it's stupid..) - I forgot root password.. And I cannot switch to root with su command.. ;-) I know it's embarrassing.. :p
Can I ask if someone would have any suggestions on how I could fix this..?
Prepare a 14-RELEASE installation tool to reset the root password
 
ld-elf.so.1: Shared object "libintl.so.8" not found, required by "sudo"

Maybe you forgot the forced upgrade of packages.

Code:
% pkg provides libintl.so.8
Name    : gettext-runtime-0.22.3
Comment : GNU gettext runtime libraries and programs
Repo    : FreeBSD
Filename: usr/local/lib/libintl.so.8.4.0
          usr/local/lib/libintl.so.8
Name    : gettext-runtime-0.22.3
Comment : GNU gettext runtime libraries and programs
Repo    : poudriere
Filename: usr/local/lib/libintl.so.8.4.0
          usr/local/lib/libintl.so.8
% pkg query %o gettext-runtime
devel/gettext-runtime
%

devel/gettext-runtime
 
13.2-RELEASE (which was already at latest) to 14.0-RELEASE on ZFS. …

Thanks, that's good.

In contrast: a leap from 13.0⋯ with UFS with soft updates without journaling might have had an undiscovered file system inconsistency prior to booting 14.0-RELEASE.
 
This might be a dumb question.

After doing the
freebsd-update fetch
freebsd-update install

on a 13.2-RELEASE-p4 FreeBSD 13.2-RELEASE-p4 GENERIC amd64 and after rebooting shouldn't it say FreeBSD 13.2-RELEASE-p5 GENERIC amd64?

Note, the freebsd-update install said there wasn't anything to install for P5.
 
Back
Top