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

robroy

robroy

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

Code: 
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
...
 
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.
 
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.
Click to expand...

Thank you. Here's how this looks, from within one of my Jails.
Code: 
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.
Click to expand...

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.
Click to expand...

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.
Click to expand...

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:

Code: 
        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:

Code: 
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:

Code: 
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.
 
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:

  1. 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
  2. On the host, start the Jail with jail -c funmax
  3. On the host, allow processes in the Jail to use chflags(2) with jail -m name=funmax allow.chflags=1
  4. Inside of the Jail, over-ride uname -r with export UNAME_r=`freebsd-version`
  5. Inside of the Jail, run freebsd-update fetch and freebsd-update install
  6. 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
  7. 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:


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.
 
You must log in or register to reply here.
Back
Top