Date: Thu, 15 Oct 2009 20:20:04 +0200 From: =?iso-8859-1?Q?Eirik_=D8verby?= <ltning@anduin.net> To: Martin Turgeon <freebsd@optiksecurite.com> Cc: freebsd-jail@freebsd.org Subject: Re: Can't upgrade jails to 8.0 using freebsd-update Message-ID: <DDF109BF-9330-4EF3-9E33-6D5D82DE3881@anduin.net> In-Reply-To: <4AD75F8B.10906@optiksecurite.com> References: <4ACE2829.6030804@optiksecurite.com> <295A1256-A620-4DD1-8B7F-22BDB216D164@anduin.net> <4ACE37D6.9040908@optiksecurite.com> <F389E50E-1C7B-49D1-BB0F-402C1D49FBFC@anduin.net> <4AD75F8B.10906@optiksecurite.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 15. okt. 2009, at 19.44, Martin Turgeon wrote: > Eirik =D8verby a =E9crit : >> >> On 8. okt. 2009, at 21.04, Martin Turgeon wrote: >> >>> Eirik =D8verby a =E9crit : >>>> On 8. okt. 2009, at 19.58, Martin Turgeon wrote: >>>> >>>>> Hi everyone! >>>>> >>>>> I just upgraded a 7.2-REL to 8.0RC1 using freebsd-update. The =20 >>>>> upgrade >>>>> went fine on the base system following the procedure written in =20= >>>>> the >>>>> announcement email by Ken Smith. My problem is when I try to =20 >>>>> upgrade my >>>>> jails, I get this message: >>>>> >>>>> # freebsd-update -b /usr/jail/mysql/ fetch install >>>>> Looking up update.FreeBSD.org mirrors... 3 mirrors found. >>>>> Fetching metadata signature for 8.0-RC1 from =20 >>>>> update5.FreeBSD.org... done. >>>>> Fetching metadata index... done. >>>>> Inspecting system... done. >>>>> Preparing to download files... done. >>>>> >>>>> No updates needed to update system to 8.0-RC1-p0. >>>>> No updates are available to install. >>>>> Run '/usr/sbin/freebsd-update fetch' first. >>>>> >>>>> But, if I compare the dates of the files in the base system to =20 >>>>> the files >>>>> in the jails, it's obvious that the jails are not up to date. >>>>> >>>>> It seems like freebsd-update doesn't care about the basedir I =20 >>>>> specified. >>>> >>>> It does, but if you do a 'uname -a' - inside or outside the jail =20= >>>> - you'll see that it reports the OS revision of the host. So you =20= >>>> should have updated your jails first, then the host ... >>>> >>> Ok but if I update in the process of upgrading the first jail, the =20= >>> new kernel will be installed and asked to reboot. After that, I =20 >>> will have the same problem when upgrading the other jails and the =20= >>> base system, right? There must be something I don't understand =20 >>> well. Thanks a lot for your answer. >> >> The kernel will be installed inside the jail, and the message about =20= >> rebooting can be safely ignored. Just run the install command once =20= >> more, and you're done and can move on to the next jail. :) >> >> /Eirik >> >> >>> Martin >>>> One way to get around it is to replace /usr/bin/uname with a =20 >>>> shell script, which calls the original uname (which you have =20 >>>> renamed) and pipes through something like sed to replace the =20 >>>> revision with what you used to have: >>>> >>>> #!/bin/sh >>>> /usr/bin/uname.org $* | sed s/"8.0-RC1-p0"/"7.2-RELEASE_p3"/g >>>> >>>> And this is a seriously butt ugly hack. >>>> >>>> /Eirik >>>> >>>>> Thanks a lot for your help, >>>>> >>>>> Martin >>>>> >>>>> > Thanks a lot! It worked great, but I'm still concerned by the fact =20 > that the world in the jails are from 8.0 while the kernel is still =20 > at 7.2 during the updates of the jails. In the normal update =20 > procedure, the kernel is upgraded first, rebooted and then the world =20= > is updated. It must have a good reason for this. Why can I jail be =20 > an exception to this rule? Because when you upgrade the host, the very binaries you are =20 installing are being installed by ... the binaries you are installing. =20= Which is why you'll want them to be reasonably in-sync with the kernel. When upgrading jails using freebsd-update, my understanding is that it =20= uses the host binaries to push files to the target directory =20 (basedir). The risk of trouble is therefore very low (I've upgraded =20 dozens of jails from 7.x to 8.0-RC1 without any issues), though I can =20= probably imagine situations where this is not the case - i.e. if the =20 upgrade depends on functionality in an upgraded binary in order to be =20= able to complete the upgrade, however that sounds like a very unlikely =20= scenario to me. And *any* use of the basedir option to freebsd-update =20= would break in such a case. /Eirik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DDF109BF-9330-4EF3-9E33-6D5D82DE3881>