Can't upgrade jails to 8.0 using freebsd-update

[Martin Turgeon]

Eirik Øverby a écrit :
>
> On 15. okt. 2009, at 20.56, Martin Turgeon wrote:
>
>> Eirik Øverby a écrit :
>>>
>>> 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
>>>
>> Sounds reasonable to me. Thanks for your quick reply.
>
> Reasonable != true. And for that matter, reasonable != reasonable. 
> YMMV etc. etc. I haven't peeked (much) into the code, so I'm just 
> guessing from my experiences. ;)
>
> People in the know should correct me if I'm wrong..
>
> /Eirik
I must admit that I was looking for a confirmation... ;)

I thought it was a problem a lot of people would have faced...

Martin