Can't upgrade jails to 8.0 using freebsd-update

Eirik Øverby ltning at anduin.net
Thu Oct 15 18:20:06 UTC 2009


On 15. okt. 2009, at 19.44, Martin Turgeon wrote:

> Eirik Øverby a écrit :
>>
>> On 8. okt. 2009, at 21.04, Martin Turgeon wrote:
>>
>>> Eirik Øverby a écrit :
>>>> 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  
>>>>> upgrade
>>>>> went fine on the base system following the procedure written in  
>>>>> the
>>>>> announcement email by Ken Smith. My problem is when I try to  
>>>>> 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  
>>>>> 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  
>>>>> 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  
>>>>> specified.
>>>>
>>>> It does, but if you do a 'uname -a' - inside or outside the jail  
>>>> - you'll see that it reports the OS revision of the host. So you  
>>>> should have updated your jails first, then the host ...
>>>>
>>> Ok but if I update in the process of upgrading the first jail, the  
>>> new kernel will be installed and asked to reboot. After that, I  
>>> will have the same problem when upgrading the other jails and the  
>>> base system, right? There must be something I don't  understand  
>>> well. Thanks a lot for your answer.
>>
>> The kernel will be installed inside the jail, and the message about  
>> rebooting can be safely ignored. Just run the install command once  
>> 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  
>>>> shell script, which calls the original uname (which you have  
>>>> renamed) and pipes through something like sed to replace the  
>>>> 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  
> that the world in the jails are from 8.0 while the kernel is still  
> at 7.2 during the updates of the jails. In the normal update  
> procedure, the kernel is upgraded first, rebooted and then the world  
> is updated. It must have a good reason for this. Why can I jail be  
> an exception to this rule?

Because when you upgrade the host, the very binaries you are  
installing are being installed by ... the binaries you are installing.  
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  
uses the host binaries to  push files to the target directory  
(basedir). The risk of trouble is therefore very low (I've upgraded  
dozens of jails from 7.x to 8.0-RC1 without any issues), though I can  
probably imagine situations where this is not the case - i.e. if the  
upgrade depends on functionality in an upgraded binary in order to be  
able to complete the upgrade, however that sounds like a very unlikely  
scenario to me. And *any* use of the basedir option to freebsd-update  
would break in such a case.

/Eirik



More information about the freebsd-jail mailing list