# Determining the version of FreeBSD



## jdmurray (Apr 12, 2012)

I have a network appliance whose OS and shell is based on FreeBSD. I am unable to determine which version of FreeBSD it is. The *uname -a* command only returns the name and version of the appliance. The FreeBSD copyright strings I have found do not indicate the version. I do not have the source code for the appliance.

Is there a way to discover the major/minor release of FreeBSD by looking at the file system? Unique changes in the size and presence of files and directory structure as FreeBSD has evolved should give definite clues to the identity of each release. Has anyone compiled this type of information?


----------



## pelmen (Apr 12, 2012)

*T*ry to obtain from sysctl: 

`% sysctl -n kern.osrelease kern.ostype`


----------



## SirDice (Apr 13, 2012)

Tricky. I do believe if you change the name it also changes those sysctl's.

Looking at binaries probably isn't helpful either. Different compiler options will result in different binaries making a straight comparison rather difficult.

I thought looking at the version of libc would be a good way but 9.0 and 8.x have the same version. So that's not good either.


----------



## Terry_Kennedy (Apr 13, 2012)

jdmurray said:
			
		

> Is there a way to discover the major/minor release of FreeBSD by looking at the file system? Unique changes in the size and presence of files and directory structure as FreeBSD has evolved should give definite clues to the identity of each release. Has anyone compiled this type of information?


If you have access to the include files and they haven't had all useful information stripped out, you may find something like this, from /usr/include/sys/syscall.h:


```
/*
 * System call numbers.
 *
 * DO NOT EDIT-- this file is automatically generated.
 * $FreeBSD: src/sys/sys/syscall.h,v 1.233.2.6 2012/01/06 19:33:27 jhb Exp $
 * created from FreeBSD: stable/8/sys/kern/syscalls.master 229725 2012-01-06 19:32:39Z jhb 
 */
```

If that isn't useful, try doing a [cmd=""]ident /boot/kernel/kernel[/cmd] which will give you the version header info for everything compiled into the kernel, including datestamps. It should also show you the FreeBSD CVS version number and committer name - the first will help you compare version numbers to the FreeBSD CVS repository. As long as the appliance vendor hasn't wholesale-renumbered the versions, this info should be useful.

To give you an example, my kernel starts off like this:

```
(141:118) node:/tmp# ident /boot/kernel/kernel | more
/boot/kernel/kernel:
     $FreeBSD: src/sys/cam/cam.c,v 1.13.2.5 2010/08/05 10:45:27 bcr Exp $
     $FreeBSD: src/sys/cam/cam_periph.c,v 1.80.2.14 2012/01/31 23:09:27 ken Exp $
     $FreeBSD: src/sys/cam/cam_queue.c,v 1.9.22.3 2009/12/02 10:10:37 mav Exp $
     $FreeBSD: src/sys/cam/cam_sim.c,v 1.13.2.2 2010/02/14 19:38:27 mav Exp $
     $FreeBSD: src/sys/cam/cam_xpt.c,v 1.217.2.37 2012/01/31 23:09:27 ken Exp $
```


----------



## jdmurray (Apr 16, 2012)

SirDice said:
			
		

> Tricky. I do believe if you change the name it also changes those sysctl's.


This is true. The [cmd=]sysctl -n kern.osrelease kern.ostype[/cmd] command suggested by pelmen only displays the appliance's version and OS name.



			
				Terry_Kennedy said:
			
		

> If you have access to the include files and they haven't had all useful information stripped out, you may find something like this, from /usr/include/sys/syscall.h:


Nope, no /usr/include or /include on this device.



			
				Terry_Kennedy said:
			
		

> If that isn't useful, try doing a
> `ident /boot/kernel/kernel`


Nope, no 'ident' command on this box.


This is a tough one.


----------



## Zare (Apr 16, 2012)

`# objdump -sj .data /boot/kernel/kernel | tail -n 22`


----------



## Chris_H (Jan 17, 2018)

jdmurray , I think what you're looking for is either, or both of freebsd-version(1), and uname(1)-U.
freebsd-version(1) returns the equivalent of `uname -r` eg; 12.0-CURRENT (osrelease), whereas `uname -U` returns the equivalent of `uname -K` eg; 1200054 (osreldate). These values are returned from the jail(8), or "guest"; as opposed to from the host. If the (jail/guest) $base, and kernel were both cut from the same source revision. It's a safe bet the results returned are correct.

HTH!

EDIT
Just to appease the gods that be;
Yes. I _know_ this post is ancient. But hey; I was looking for an answer to this very same question, and DuckDuck brought me here. Turns out this question had no answer. But a little experimentation, and man(1) page reading _enlightened_ me. So I thought I'd be gracious enough to "share the knowledge". Please don't beat me with a stick, for trying to help. 

--Chris


----------



## SirDice (Jan 18, 2018)

Chris_H, this thread is almost 6 years old. The original poster hasn't been seen since then.


----------



## Chris_H (Jan 18, 2018)

Yes indeed. But I felt it was _still_ worth replying. Because should anyone else have the same question. A simple search of the Forums will provide an answer, rather than make yet _another_ (same) question. 

--Chris


----------



## poorandunlucky (Jan 19, 2018)

I wish I still had that reaction image...  : \


----------



## scottro (Jan 19, 2018)

For what it's worth, if I answer a very old thread, I give the reason, e.g, Google brought me here and even though it's 5 years old, the problem persists, and so on.  Of course, on Arch, they'll close it anyway, but they are an extremely busy forum and while I often disagree with them closing, I've sometimes email the mod who did it and said, Hey, google brought me here, the problem persists, it might be worth adding a note to the closing post, and they will sometimes add such a note.  
But it is always good to mention that a) you've noticed a post is very old, and b) why you are posting to it, best reason, IMHO, because searching your question brought you to the thread.  Of course, and I'm sure it's happened to many people, sometimes one finds a solution, gets excited about it, and doesn't realize they're posting to a several year old post too.


----------



## Chris_H (Jan 20, 2018)

OK I edited my reply, above. _Technically speaking_ I didn't have the _same_ question. But was interested in my jail(8) environment, and wanting to make it reflect the _actual_ osrelease, and osreldate;
`11.1-STABLE`, and `1101506`, respectively. The answer to my needs, _also_ answered the question here -- *bonus*. 
Oh, and speaking of; for bonus points, here's how I managed to adjust my jail(8) environment to reflect it's actual release:

```
# uname -r, freebsd-version
osrelease = 11.1-STABLE;
# /usr/obj/usr/src/include/osreldate -- uname -K, uname -U
osreldate = 1101506;
```
Commented for better understanding, for inquiring minds, that need to know. Entered in the jail.conf(5) that reflects the jail(8) I was working in.

Are we good now? 

--Chris


----------



## nrgmilk (Feb 6, 2021)

If you are using FreeBSD 13 or higher, you can get from os-release().

`# cat /etc/os-release
NAME=FreeBSD
VERSION=13.0-STABLE
VERSION_ID=13.0
ID=freebsd
ANSI_COLOR="0;31"
PRETTY_NAME="FreeBSD 13.0-STABLE"
CPE_NAME=cpe:/o:freebsd:freebsd:13.0
HOME_URL=https://FreeBSD.org/
BUG_REPORT_URL=https://bugs.FreeBSD.org/`


----------



## Alexander88207 (Feb 6, 2021)

Oh nice, good to know what this exists in the base system soon.

So sysutils/etc_os-release could get obsolete for 13?


----------



## SirDice (Feb 6, 2021)

Already is.

```
.if ${OSVERSION} >= 1300060
IGNORE=         /etc/os-release is present in base
.endif
```


----------

