Solved FreeBSD 15.1 Upgrade Question

M

Mayhem30

I'm upgrading from 14.4 to 15.1 and currently on this step:
Code: 
Completing this upgrade requires removing old shared object files.
Please upgrade or rebuild all installed 3rd party software (e.g.,
programs installed with pkg or from the ports tree) and then run
'freebsd-update [options] install' again to finish installing updates.

I have 2 different AI's saying two completely different things. I'm using synth to rebuild all my ports.

I'm assuming I need to do all of this before running freebsd-update install again?

Code: 
su (change to root)
screen
rm -rf /var/synth/live_packages/All/*.pkg
sudo rm -f /var/db/gitup/ports /var/db/gitup/ports.history
gitup ports
synth just-build `cat /home/mayhem/build.list`
synth rebuild-repository
pkg delete -af
/usr/sbin/pkg bootstrap -f
pkg install `cat /home/mayhem/install.list`
 
Mayhem30 said:
I have 2 different AI's saying two completely different things.
Click to expand...
Thus the cause of all your problems. I have as yet to get a correct answer from AI about anything.
Use the source, my friend. AI will screw you up every way imaginable.
Yes, when moving from one major version to another, all software needs to be reinstalled because the ABI changes.
Mayhem30 said:
I'm using synth to rebuild all my ports.
Click to expand...
Why would you use a third party thing instead of FreeBSD's native for that?
EDIT: Re-reading I see you are using ports. I don't recall what is done for ports since I haven't used them in many years.
 
Last edited:
My issue here is with the wording:
Please upgrade or rebuild all installed 3rd party software
Click to expand...

It doesn't say whether to install them or not. So I don't know what to do .. I'm just sitting at this prompt.
 
Thanks, I'm using non-standard configuration for ports. I'll let them build tonight and worry about the rest of the steps tomorrow.
 
The biggest concern about ports and upgrading is "do you have any third party kmods lie drm stuff that gets loaded during reboot".
What I have done in the past is comment out the kld_list variable in /etc/rc.conf, do the freebsd-update steps, rebuild/install all the ports then reenable kld_list. First time I usually manually load any of the modules just to play it safe.

Applications are typically safe because of compatibility with the previous version in the kernel, but one needs to update as soon a possible.

If you are using ZFS you can manually create new BEs and do the upgrade into them.
 
Same for building packages with Poudriere, same process.

Upgrade the base OS first, this is a major version upgrade so run freebsd-update install twice (to update the kernel and userland). Then start your poudriere/synth bulk builds (make sure both are using the correct version jail, your new FreeBSD version). Let it build everything, then upgrade/reinstall your packages on the host. Once that's done you can run the third and final freebsd-update install. This will remove all the old libraries and other files from the previous version.
 
Mayhem30 said:
Completing this upgrade requires removing old shared object files.
Click to expand...
I wonder if there's a way to list old shared object files? So one could search the system for any binaries referencing. I assume since freebsd-update knows.. in ` /var/db/freebsd-update/<hash>-install/` I see `kernelfirst, kerneldone, worlddone` files with timestamp of worlddone resembling the first `freebsd-update install`. There's also INDEX-OLD and INDEX-NEW.. so I guess the freebsd-update script would know based on that what to remove later. Well, could figure out based on the script if I really wanted...

SirDice said:
Once that's done you can run the third and final freebsd-update install.
Click to expand...
Just to clarify, the message sounded like one would rebuild the third-party packages, then issue a second `freebsd-update install`. While you mentioning sounds like doing two install commands in a row, then the third-party, and a final third install command? What is the source of divergence I wonder?
 
mer said:
What I have done in the past is comment out the kld_list variable in /etc/rc.conf, do the freebsd-update steps, rebuild/install all the ports then reenable kld_list. First time I usually manually load any of the modules just to play it safe.
Click to expand...
Another way would be (if you have up-to-date distfiles in hand) entering single user mode on reboot for freebsd-update and build kmods there.
On single user mode, rc scripts are NOT run at all, so anything in kld_list are NOT loaded.

I'm on src upgrades, and rebuild all kmod ports (plus known kernel source abusers like lsof) AFTER etcupdate -p, make installworld, make check-old, (if needed, make delete-old,)
etcupdate -B -n and etcupdate -B if needed while in single user mode.
 
  • Like
Reactions: mer
Note that network accesses are impossible while in single user mode.
So if you're upgrading remote hosts that you don't have physical access to the host and neither remote KVM (not Kernel Virtual Machine, but Keyboard Video Mouse) switch nor IPMI remote console is available, this method cannot be used.
 
rdog said:
Ah you are right, there was one install before the reboot, and one after the reboot at that point. Memory erased the before-reboot one.
Click to expand...
Likewise, it's not uncommon for new users to only do the first install, reboot and completely forgetting the instructions to do that second install phase.
 
freebsd-version will show an out of sync userland if you don't do the install after reboot.
for the third install (after packages) you will know when you do freebsd-update again (if you don't do it)
 
SirDice said:
Not impossible. It's not enabled because none of the rc(8) scripts have been run. You can configure network in single user mode.
Click to expand...
Precisely, yes.
But it's only AFTER choosing any shell (default is /bin/sh).
So if rebooting to single user mode with configuring so via nextboot(8) and no physical console access (nor network KVM nor IPMI console), nothing can be done. So I consider "actually impossible".
 
T-Aoki said:
So if rebooting to single user mode with configuring so via nextboot(8) and no physical console access (nor network KVM nor IPMI console), nothing can be done.
Click to expand...
Yes, you are royally screwed that way, you have locked yourself out. Similarly if you make a mistake in /etc/fstab and reboot. But assuming you do have console access you can enable networking when in single user mode, it can be useful in certain situations.
 
Just to serve as a datapoint to others: I was too quick to issue the *third* freebsd-install, without doing a pkg update/upgrade. Then commands like sudo, pkg, reboot were missing libraries, all was left is a hard reboot, finding a VGA cable and entering single-user mode.

After remounting root as rw, configuring IP address for em0, and adding a default gateway, could do pkg bootstrap -f (maybe that was not needed at that point, and was a no-op) and pkg upgrade.

The upside, while the userland was botched until this got fixed, jails happily kept running (even after some reboot attempts), so most services were not disrupted.
 
You must log in or register to reply here.
Back
Top