# freebsd-update 12.1-RELEASE-p4 version mismatch



## victortsang (May 1, 2020)

Hi,

It is my first time to try freebsd-update. I patch the system from p2 to p4. After update and reboot, freebsd-version tells me it is p4 but unman tells me it is p3. 

Is it normal? 

```
victor@freebsddev: ~$ freebsd-version
12.1-RELEASE-p4
victor@freebsddev: ~$ uname -a
FreeBSD freebsddev.local 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC  amd64
victor@freebsddev: ~$
```


----------



## richardtoohey2 (May 1, 2020)

freebsd-version is a standalone binary - if you watch what freebsd-update installs you'll see a new freebsd-version.

uname uses the kernel, so if a new kernel wasn't installed then the version number won't change.

As long as you did

```
freebsd-update fetch
freebsd-update install
reboot
```

You should be OK.


----------



## richardtoohey2 (May 1, 2020)

So this is a machine that I did a clean FreeBSD 12.1 install on today, followed by the upgrade steps:

```
blah@blah:~ % freebsd-version
12.1-RELEASE-p4
blah@blah:~ % uname -a
FreeBSD blah.blah.co.nz 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC  amd64
```
So the same as you - I think you're all good.


----------



## hsw (May 1, 2020)

The freebsd-version can show up to 3 differebt values.  e.g.:

```
# freebsd-version -kru
12.1-RELEASE-p3    # -k: the currently installed kernel file
12.1-RELEASE-p3    # -r: the running kernel  (same as uname -r)
12.1-RELEASE-p4    # -u: the user-land revision
```
I added comments to show the meanings, and note that the output order is after sorting options
In this case the last update only affected the userland so it should be ok to continues without a reboot.
However if some shared library was changed then there could be daemons still using the old one.


----------



## SirDice (May 1, 2020)

victortsang said:


> Is it normal?


Yes. The last patch update didn't involve an issue with the kernel, so it wasn't updated. 



richardtoohey2 said:


> freebsd-version is a standalone binary


It's a large script actually.

```
# head /usr/sbin/freebsd-update

#!/bin/sh

#-
# SPDX-License-Identifier: BSD-2-Clause-FreeBSD
#
# Copyright 2004-2007 Colin Percival
# All rights reserved
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted providing that the following conditions
```


----------



## Minbari (May 1, 2020)

SirDice said:


> Yes. The last patch update didn't involve an issue with the kernel, so it wasn't updated.


Well it wasn't updated by the freebsd-update but in sources the Kernel was also updated.

```
freebsd-version -kru
12.1-RELEASE-p4
12.1-RELEASE-p4
12.1-RELEASE-p4
```

I did not find any references to see how things works exactly, but I've seen that FreeBSD Release Engineering Team does not always follow the sources updates. What I am trying to say is that sometimes if freebsd-update is used a user could have different version of Kernel or userland while if the system is updated from sources the versions always match.


----------



## richardtoohey2 (May 1, 2020)

SirDice said:


> It's a large script actually.


Maybe a _binary_ script? 

But it's certainly useful for situations like this (well I've found it useful) when you can't recall if you've run freebsd-update and uname doesn't show you.


----------



## SirDice (May 1, 2020)

Minbari said:


> Well it wasn't updated by the freebsd-update but in sources the Kernel was also updated.


Not exactly. If you rebuild your kernel the new version (set in sys/conf/newvers.sh) will be compiled into the kernel, the kernel itself  doesn't change, only the version number. If you do binary updates that kernel hasn't been rebuild (because there's no need for it) and thus would still show the "old" version information.





__





						[base] Contents of /releng/12.1/sys/conf/newvers.sh
					






					svnweb.freebsd.org
				



(lines 47-49)



Minbari said:


> but I've seen that FreeBSD Release Engineering Team does not always follow the sources updates.


They do follow the source updates. But the kernel didn't have an issue so it wasn't rebuilt, and therefor wasn't included in the binary updates.


----------



## victortsang (May 1, 2020)

SirDice said:


> Not exactly. If you rebuild your kernel the new version (set in sys/conf/newvers.sh) will be compiled into the kernel, the kernel itself  doesn't change, only the version number. If you do binary updates that kernel hasn't been rebuild (because there's no need for it) and thus would still show the "old" version information.
> 
> 
> 
> ...



Thank you all guys...

I just wonder if this should be considered as an issue and file a report...


----------



## zirias@ (May 1, 2020)

victortsang said:


> I just wonder if this should be considered as an issue and file a report...


Why should it be? The current behavior is even documented in 23.2.2. Applying Security Patches:


> The updates distributed by `freebsd-update` do not always involve the kernel. It is not necessary to rebuild a custom kernel if the kernel sources have not been modified by `freebsd-update install`. [...]


Delivering a new unchanged kernel for binary updates, just for the heck of updating its version string, would be a great waste of bandwidth.


----------



## SirDice (May 1, 2020)

victortsang said:


> I just wonder if this should be considered as an issue and file a report...


It's _expected_ behavior by design, not a bug or an issue.



Zirias said:


> Delivering a new unchanged kernel for binary updates, just for the heck of updating its version string, would be a great waste of bandwidth.


Exactly!


----------

