Solved freebsd-update leaves kernel and tools out of sync

I ended up falling into a bit of a rabbit hole...I did a freebsd-update fetch install on my laptop and my desktop three days ago. After the update, I found that I was unable to successfully to ssh-add my keys to ssh-agent, but only on my laptop. Whenever I try to add a key, it fails:

Code:
$ ssh-add /home/user/.ssh/id_rsa ; echo $?
Enter passphrase for /home/user/.ssh/id_rsa:  
Bus error
138
$ ssh-add /home/user/.ssh/id_ed25519 ; echo $?
Enter passphrase for /home/user/.ssh/id_ed25519:  
Bus error
138

If I boot back into my 13.0p1 BE, I can successfully ssh-add the keys. So I started looking into what exactly the freebsd-update did. On the laptop:
Code:
$ uname -K ; uname -U; uname -ro
1302001
1301000
FreeBSD 13.2-RELEASE-p2

And on the desktop:
Code:
$ uname -K; uname -U ; uname -ro
1302001
1302001
FreeBSD 13.2-RELEASE-p2

Both hosts are on the latest repo. I know that the tools portion of FreeBSD is in limbo until the next patch release, since 13.1 was just EOL'ed last week. However, it appears that the tools on the desktop is 13.2p1, while the tools on the laptop is 13.1.

How does one update the tools to the latest, why did it get that far behind, and is it the cause of my problem putting keys in ssh-agent?

Thanks.
 
You were trying to go from 13.0 to the latest 13, which is 13.2-p2? I think that is technically across releases, so at least the fetch needs the "-r" option and as sko points out, definitely would require a reboot to get the kernel updated and then another freebsd-update install.
 
You were trying to go from 13.0 to the latest 13, which is 13.2-p2? I think that is technically across releases, so at least the fetch needs the "-r" option and as sko points out, definitely would require a reboot to get the kernel updated and then another freebsd-update install.
Actually, no. I went from 13.1p7 -> 13.2 -> 13.2p1 -> 13.2p2. However, I have apparently been screwing up the freebsd-update and not doing the second install step for a while.
 
  • Like
Reactions: mer
I was confused by your statement "If I boot back into my 13.0p1 BE".
If freebsd-update install has nothing to do, it tells you that, so running it again never hurts.
 
I was confused by your statement "If I boot back into my 13.0p1 BE".
If freebsd-update install has nothing to do, it tells you that, so running it again never hurts.
Sorry. I misspoke (typed) I meant to say "if I boot back into my 13.2p1 BE" Apologies for my inaccuracies.
 
  • Like
Reactions: mer
Okay. So I done screwed up in the transition from 13.1 to 13.2. I should have done the second freebsd-update install after the reboot. So at this point, should I go back to the 13.1p7 BE and upgrade forward from there or just take the 13.2p1 and upgrade from there?

Thanks!
 
All right, I tried upgrading from 13.2p1 to 13.2p2. It completed, I rebooted, and tried another freebsd-update install. came back and said
Code:
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.

However the versions were still different:
Code:
uname -K ; uname -U
1302001
1301000

So I guess I am going to go all the way back to 13.1p7 and do a minor upgrade and try to catch up that way.
 
what is the output of freebsd-version -kru?
uname is looking at different stuff than freebsd-version
Your system looks like you have missed either a reboot or a fetch/install.
Did you run out of space somewhere?

Output from my system that I recently (earlier today) did freebsd-update on.

uname -K && uname -U && freebsd-version -kru 1302001 1302001 13.2-RELEASE-p2 13.2-RELEASE-p2 13.2-RELEASE-p2
 
Mine looks similar on the BE that I did the upgrade:
Code:
uname -K && uname -U && freebsd-version -kru
1302001
1302001
13.2-RELEASE-p2
13.2-RELEASE-p2
13.2-RELEASE-p2

Also my pool is less than 50% capacity:

Code:
zpool list
NAME      SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
NX72003   664G   318G   346G        -         -    45%    47%  1.00x    ONLINE  -

So it looks like everything is caught up, but I am still having problems with ssh-add, and I feel like things are still out of sync. If I do an ssh -V on my desktop it says
Code:
OpenSSH_9.3p2, OpenSSL 1.1.1t-freebsd  7 Feb 2023
But the laptop says
Code:
OpenSSH_9.3p2, OpenSSL 1.1.1o-freebsd  3 May 2022
Shouldn't the upgrade have bumped the version of openssl?
 
So the desktop has been updated the same as the laptop and desktop is correct but laptop not, and your problems with ssh-add are happening on the laptop but not on the desktop, is that correct?
The laptop is now showing the correct versions freebsd-version -kru?


My systems are showing the same as your desktop.
On the laptop:
Does pkg info | grep -i ssl show anything weird relating to openssl?

Both hosts are on the latest repo.
Do you mean for binary packages?
 
So the desktop has been updated the same as the laptop and desktop is correct but laptop not, and your problems with ssh-add are happening on the laptop but not on the desktop, is that correct?
The laptop is now showing the correct versions freebsd-version -kru?

That is correct. On the desktop (defiant):
Code:
[defiant ~]# freebsd-version -kru
13.2-RELEASE-p2
13.2-RELEASE-p2
13.2-RELEASE-p2

On the laptop:
Code:
[danube ~]# freebsd-version -kru
13.2-RELEASE-p2
13.2-RELEASE-p2
13.2-RELEASE-p2
My systems are showing the same as your desktop.
On the laptop:
Does pkg info | grep -i ssl show anything weird relating to openssl?

Nope. Both machines have
Code:
brotli-1.0.9,1                 Generic-purpose lossless compression algorithm
easy-rsa-3.1.5                 Small RSA key management package based on openssl
flac-1.4.3,1                   Free lossless audio codec
jbigkit-2.1_1                  Lossless compression for bi-level images such as scanned pages, faxes
liblz4-1.9.4,1                 LZ4 compression library, lossless and very fast
lzo2-2.10_1                    Portable speedy, lossless data compression library
py39-brotli-1.0.9              Generic-purpose lossless compression algorithm
py39-certifi-2023.5.7          Mozilla SSL certificates
py39-openssl-21.0.0,1          Python interface to the OpenSSL library
py39-service_identity-18.1.0   Service identity verification for pyOpenSSL
wavpack-5.6.0                  Audio codec for lossless, lossy, and hybrid compression

In addition, defiant has
Code:
p5-IO-Socket-SSL-2.083_1       Perl5 interface to SSL sockets
p5-Net-SSLeay-1.92             Perl5 interface to SSL

And the versions of openssl that I listed above, according to which, is in /usr/bin, so would be in the base system, right?

Do you mean for binary packages?
Correct. "Latest" as opposed to "quarterly"
 
  • Like
Reactions: mer
What is the output of freebsd-update IDS?
It gives me nearly 9900 lines of files saying <file> has sha256 hash <hash1> but should have sha256 has <hash2>. and other permissions-related issues. I can try to post the list to someplace like controlc.com if you need the list.

I'm actually thinking about booting the laptop back into 13.1p7 and running freebsd-update IDS to see what that shows.
 
Okay, so just for giggles, I booted into my 13.1p7 (p6?) BE, and while things are a bit wonky, it looks like it may be a good starting point from which to upgrade:

Code:
[danube ~]# uname -K && uname -U && freebsd-version -kru
1301000
1301000
13.1-RELEASE-p6
13.1-RELEASE-p6
13.1-RELEASE-p7

Unsure what I messed up to get two p6s and one p7...

The freebsd-update IDS has ~11000 lines of content. That said, I am going to clone my 13.1p7 BE, and try the upgrade.
 
If an update has only updates to userland, the installed kernel will not get updated so will show a different patch level. I believe that is what you are seeing
Fair. That said, I am going to run some stuff to the dump, then come back and upgrade the laptop from 13.1p7. I tend to be overcautious, but I am very much warming to being able to roll back through BEs. About 10 years ago, when I started dabbling with FreeBSD, I said that it was systemd that drove me to FreeBSD, but ZFS is what kept me here. :D
 
  • Like
Reactions: mer
Okay. It appears that going back to 13.1p7 and doing a proper upgrade to 13.2 did the trick. I believe the specific problems was the older version of OpenSSL:
my desktop it says
Code:
OpenSSH_9.3p2, OpenSSL 1.1.1t-freebsd 7 Feb 2023

But the laptop says
Code:
OpenSSH_9.3p2, OpenSSL 1.1.1o-freebsd 3 May 2022
So thanks to all the helpful folks, mer, Charlie_, and sko for pointing me in the right direction.
 
Thanks for the update and glad I could help.
So just to be clear, and what I believe I read in the handbook is that the freebsd-update install -> reboot -> freebsd-update install is only required for major and minor version bumps, not for patchlevel security updates. Correct?
 
So just to be clear, and what I believe I read in the handbook is that the freebsd-update install -> reboot -> freebsd-update install is only required for major and minor version bumps, not for patchlevel security updates. Correct?
My opinion, hard to tell. Patch level all the kernel ABI stuff should be consistent and may not need a "reboot now", that's where freebsd-version -kr comes in. "r" is "this is the currently running kernel", "k" is the "installed kernel that would be run after a reboot". if they are the same, one can probably put off a reboot, but I think safety says "do a reboot".

Now going from say 13.0 to 13.2 absolutely do a freebsd-update fetch -r 13.2 && freebsd-update install && reboot.

But if you do a search there are a couple different threads that show you how to do a binary update into a new BE (chroot and such) which lets you update into a BE and then you just bectl activate the new thing and reboot once.
 
The reason you need to install after reboot is that the new userland depends on the new kernel.
There should be no need to install after reboot for patchlevel.
Whether or not a reboot after install is required is described in the SA or EN.
 
The reason you need to install after reboot is that the new userland depends on the new kernel.
There should be no need to install after reboot for patchlevel.
Whether or not a reboot after install is required is described in the SA or EN.
I always reboot after a freebsd-upgrade install (hell, I usually reboot after a pkg upgrade), but my question was specifically whether I needed to do the freebsd-upgrade install step again after the reboot. Of course, it is perfectly safe, because it will either work, or it will tell you

Code:
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.

Non-destructive either way. :)
 
Back
Top