# Why does "freebsd-update fetch" in a 10.1-RELEASE-p24 Jail yield 10.2-RELEASE-p10?



## robroy (Jan 16, 2016)

FreeBSD Friends,

My computer runs FreeBSD 10.2-RELEASE-p10 amd64.

On my computer are eleven full system image Jails running a variety of 10.x userland versions.  These are from-source Jails which I created manually, using steps modeled after the examples in jail(8).

Today, I tried to patch a 10.1-RELEASE-p24 Jail by logging in to it using `ssh`, and running `freebsd-update fetch`.

My expectation was:  10.1-RELEASE-p24 -> 10.1-RELEASE-p27.

What happened was:  10.1-RELEASE-p24 -> 10.2-RELEASE-p10.

Does anybody happen to know what may have caused this?  I suspect that I've misunderstood how `freebsd-update` is supposed to work.

I've included a partial transcript below.

Thanks so very much!
Robroy


```
funmax:~# freebsd-version
10.1-RELEASE-p24
funmax:~# freebsd-update fetch
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching metadata signature for 10.2-RELEASE from update5.freebsd.org... done.
Fetching metadata index... done.
Fetching 2 metadata patches.. done.
Applying metadata patches... done.
Fetching 2 metadata files... done.
Inspecting system...
The following files will be updated as part of updating to 10.2-RELEASE-p10:
/bin/freebsd-version
/lib/libbsdxml.so.4
/lib/libc.so.7
/lib/libcrypto.so.7
/libexec/ld-elf.so.1
/libexec/ld-elf32.so.1
/rescue/[
/rescue/atmconfig
/rescue/badsect
/rescue/bsdlabel
...
```


----------



## SirDice (Jan 18, 2016)

Jails don't have a kernel and use the host's kernel. A `uname -a` shows the kernel version.

An upgrade from 10.1 to 10.2 will only happen if you did a `freebsd-update -r 10.2-RELEASE upgrade`, the next `freebsd-update fetch` will fetch the updates for 10.2-RELEASE. So my guess is this jail was upgraded (accidentally perhaps) but never restarted.


----------



## kpa (Jan 18, 2016)

You can use freebsd-version(1) inside the jail to see which version of world is installed there.


----------



## robroy (Mar 27, 2016)

SirDice and kpa, thank you both for replying!  I'm sorry for not following up for two months.



SirDice said:


> Jails don't have a kernel and use the host's kernel. A `uname -a` shows the kernel version.



Thank you.  Here's how this looks, from within one of my Jails.
	
	



```
funmax:~# freebsd-version
10.1-RELEASE-p24
funmax:~# uname -a
FreeBSD funmax 10.2-RELEASE-p14 FreeBSD 10.2-RELEASE-p14 #0: Wed Mar 16 20:46:12 UTC 2016     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
```



SirDice said:


> An upgrade from 10.1 to 10.2 will only happen if you did a `freebsd-update -r 10.2-RELEASE upgrade`, the next `freebsd-update fetch` will fetch the updates for 10.2-RELEASE.



Yeah, I also thought that 10.2-RELEASE patches wouldn't be applied unless an upgrade was performed.



SirDice said:


> So my guess is this jail was upgraded (accidentally perhaps) but never restarted.



This guess seems reasonable; thanks.  Yet I've tried the same thing with several other jails, and this doesn't seem to be what's causing this behavior.



kpa said:


> You can use freebsd-version(1) inside the jail to see which version of world is installed there.



Thank you kpa.

I looked at this again today, and it looks like freebsd-update(8) runs `uname -r` to find out what patches to download.  Here's what I see in /usr/sbin/freebsd-update:


```
RELNUM=`uname -r |
            sed -E 's,-p[0-9]+,,' |
            sed -E 's,-SECURITY,-RELEASE,'`
        ARCH=`uname -m`
        FETCHDIR=${RELNUM}/${ARCH}
```
Here's how this looks from within one of my Jails:


```
funmax:~# freebsd-version
10.1-RELEASE-p24
funmax:~# uname -r
10.2-RELEASE-p14
```
So, it looks like freebsd-update(8) can't patch a Jail's userland, if the userland release is older than the kernel release (like a jailed 10.1' userland on a 10.2' kernel).

I also followed Handbook section 14.4.3 (which I appreciate immensely) to attempt `freebsd-update -b /j/d.net/funmax fetch` from the host operating system, yet the result was the same--freebsd-update(8) insisted on applying 10.2-RELEASE patches to my 10.1-RELEASE Jail.

I may still be misunderstanding this, yet it seems that if one wishes to use freebsd-update(8) to keep jailed userlands patched, the jailed userlands must be the same release as the kernel.

SirDice and kpa, thanks again for your replies.

PS.  'looks like I can't upgrade my 10.1-RELEASE Jails to 10.2-RELEASE using freebsd-update(8) either, presumably for the same reason.  Here's how that looks from within a Jail:


```
funmax:~# freebsd-version
10.1-RELEASE-p24
funmax:~# uname -r
10.2-RELEASE-p14
funmax:~# freebsd-update upgrade -r 10.2-RELEASE
freebsd-update: Cannot upgrade from 10.2-RELEASE to itself
```
The only simple solution I can think of is to make new 10.2' Jails and copy stuff over from the old 10.1' Jails.


----------



## robroy (Mar 27, 2016)

A fresh search revealed that my scenario's embarrassingly widely documented; I'm sorry for not searching more before posting, and thank you again for the replies.

On my 10.2-RELEASE-p14 host, I managed to patch a jailed userland from 10.1-RELEASE-p24 to 10.1-RELEASE-p31, like this:


 On the host, stop the Jail and make a pre-patch snapshot with `jail -r funmax; zfs snapshot z/j/d.net/funmax@2016Mar27-p24`
 On the host, start the Jail with `jail -c funmax`
 On the host, allow processes in the Jail to use chflags(2) with `jail -m name=funmax allow.chflags=1`
 Inside of the Jail, over-ride `uname -r` with `export UNAME_r=`freebsd-version``
 Inside of the Jail, run `freebsd-update fetch` and `freebsd-update install`
 On the host, stop the Jail and make a post-patch snapshot with `jail -r funmax; zfs snapshot z/j/d.net/funmax@2016Mar27-p31`
 On the host, start the Jail with `jail -c funmax`

I saw references to tricking freebsd-update(8) with something similar to `export UNAME_r=`freebsd-version`` here:


 iddqd's post in Thread 49079
 https://clinta.github.io/freebsd-jails-the-hard-way/

This method seems to work, yet I'd be curious to hear about any undesirable side-effects it may bring about, if anybody feels like chatting about it.  Thank you again.


----------

