[Users] Installation of latest Kernel fails again (deb size mismatch)
Kir Kolyshkin
kir at openvz.org
Thu Mar 20 17:50:47 PDT 2014
On 03/13/2014 11:58 AM, Kir Kolyshkin wrote:
> Ola, thanks for info!
>
> To make a long story short, I have reverted the build script to the
> old versioning
> scheme. The next -testing kernel (042stab086.x) will use it, and the
> stable kernel
> with this old versioning will be released in about a month.
In fact I've just released 042stab085.18 to wheezy-testing, which is
back to the old versioning.
Please test it and let me know if it works for you.
Kir
>
> Kir.
>
> On 03/12/2014 01:47 PM, Ola Lundqvist wrote:
>> Hi
>>
>> I can give you some additional feedback on what I think is the
>> motivation for why the Debian packages was done this way.
>>
>> 1) Debian kernels are tested a lot before each release. The release
>> is done every second year or so and there is a freeze period of at
>> least a half a year with a lot of testing involved.
>> 2) The main motivation for this change is probably that the kernel
>> maintainers do not want to wait for FTP maintainers for every new
>> version uploaded. If you create a new package in Debian you have to
>> wait for FTP maintainers approval before it can reach the archives.
>> 3) There is probably one more motivation and that is the Debian
>> archive size. It has grown over the years and the kernel is a quite
>> significant size of it. If every new kernel is kept for a while that
>> cause a large archive. Keeping the package name solves this issue.
>> 4) There is one more thing as well. That is that there are quite a
>> few module packages in debian and they have to be re-built when the
>> package name is changed. If the name can be kept (see ABI too below)
>> they do not have to be and that release some load on the build
>> infrastructure.
>> 5) Still kernel maintainers are aware of ABI compatibility. This is
>> the reason for the -n part of the version number. It tells (I guess)
>> the ABI version number for that kernel. As long as the ABI is still
>> kept the package name can remain.
>> 6) The same thing as in 4) above applies for custom build kernel
>> modules done by the system administrator. This time it reduce the
>> work for the system admin to build their custom modules as ABI
>> compatibility is known by package name.
>>
>> I do not think the error message:
>> "Some packages can not be updated, because they require other
>> packages that are not installed on your system. You might use
>> apt-get dist-upgrade to work around that"
>> is something that we should have as an argument. It is not really an
>> error message, and in some cases it is a good thing to get an extra
>> reminder that something large is on the way.
>>
>> I agree that the "old scheme" is better in case the kernel is not
>> that well tested. If it is well tested then it is not really a problem.
>>
>> On the other hand point 6) above is an argument for the "new scheme".
>>
>> I do not think point 2), 3) and 4) is something that applies to the
>> openvz kernels. They should not be a problem.
>>
>> Kir: But you need to consider point 5 and make sure that you make a
>> new package name each time the ABI compatibility is broken.
>>
>> I do not want to vote for either scheme, both are good, but in
>> different ways.
>>
>> Cheers,
>>
>> // Ola
>>
>>
>>
>> On Fri, Mar 7, 2014 at 9:23 AM, Kir Kolyshkin <kir at openvz.org
>> <mailto:kir at openvz.org>> wrote:
>>
>> On 03/06/2014 06:13 PM, spameden wrote:
>>> Hi
>>>
>>>
>>> 2014-03-07 5:28 GMT+04:00 Kir Kolyshkin <kir at openvz.org
>>> <mailto:kir at openvz.org>>:
>>>
>>> On 03/02/2014 02:01 PM, spameden wrote:
>>>>
>>>>
>>>>
>>>> 2014-03-03 0:38 GMT+04:00 Ola Lundqvist <ola at inguza.com
>>>> <mailto:ola at inguza.com>>:
>>>>
>>>> Hi
>>>>
>>>> Problem fixed now.
>>>> I had fixed the problem temporarily, but I had
>>>> forgotten to upgrade to the debarchiver version with
>>>> the fix so it will not happen again. Now I have done
>>>> the upgrade and fixed the problem properly.
>>>>
>>>>
>>>> I think it's not fixed properly:
>>>>
>>>> 1) wrong version of linux-image:
>>>> # dpkg -l|grep linux-image-openvz
>>>> ii linux-image-openvz-amd64 042+1 amd64 OpenVZ Linux
>>>> kernel (meta-package)
>>>>
>>>> 2) # ls /boot |grep openvz
>>>> config-2.6.32-openvz-042stab084.17-amd64
>>>> *config-2.6.32-openvz-amd64*
>>>> initrd.img-2.6.32-openvz-042stab084.17-amd64
>>>> *initrd.img-2.6.32-openvz-amd64*
>>>> System.map-2.6.32-openvz-042stab084.17-amd64
>>>> *System.map-2.6.32-openvz-amd64*
>>>> vmlinuz-2.6.32-openvz-042stab084.17-amd64
>>>> *vmlinuz-2.6.32-openvz-amd64*
>>>>
>>>> so now we are missing usual version here in the package..
>>>> that's actually very bad ... can you look into it?
>>>>
>>>> many thanks.
>>>
>>> This is intentional, and I changed it after looking into how
>>> default Debian kernel is packaged/versioned.
>>>
>>> If you take a look, they have [meta]package
>>> linux-image-amd64 which requires
>>> package linux-image-3.2.0-4-amd64. The latter (currently)
>>> has a version of
>>> 3.2.54-2 and this version is changed (incremented) with
>>> every release, while
>>> package name stays the same (linux-image-3.2.0-4-amd64).
>>> Also, vzkernel
>>> name stays the same -- it is /boot/vmlinuz-3.2.0-4-amd64 in
>>> different versions.
>>> I am using the very same approach now for OpenVZ kernels.
>>>
>>>
>>> I understand your position. I checked how it's done in Debian
>>> and yes you're right, they're using this scheme for their
>>> mainline 3.2.0-4 kernel.
>>>
>>> Tbh, I don't like their "NEW" way at all.
>>>
>>> Here is why:
>>>
>>> When new version of OpenVZ kernel comes its hard to have 2
>>> different kernels on the system (with different versions).
>>>
>>> Here is a simple scenario:
>>>
>>> 1) new kernel comes and it's not working at all on certain
>>> configurations.
>>>
>>> 2) if you configured grub correctly it would boot previously
>>> working kernel after reboot.
>>>
>>> --> But it wont boot previous OpenVZ kernel version, because
>>> when you upgrade you overwrite existing kernel and you need to
>>> rollback to the previous version manually.
>>>
>>>
>>> Previously I was adding the VZ version (i.e. 042stab0xy.z)
>>> into kernel package name,
>>> and it was added to vmlinuz and the /lib/modules directory
>>> name as well.
>>>
>>>
>>> I really liked how it was done before. There was an option to
>>> leave certain kernel versions for testing as well and delete
>>> what is not needed.
>>>
>>> The problem
>>> is, you need to specify a different dependency in
>>> linux-image-openvz-amd64 metapackage,
>>> and apt-get upgrade complains that it can't upgrade the
>>> system since a new version
>>> of an installed package (linux-image-amd64) requires a
>>> package that is not installed yet.
>>> The problem could be fixed by running dist-upgrade, but
>>> eventually I decided that
>>> this message is a hint that I package openvz kernels
>>> improperly, that lead me to
>>> looking into a way standard Debian kernels are packaged and
>>> implementing it
>>> the same way for OpenVZ kernels.
>>>
>>>
>>> Interesting.. I never seen myself such problem before. It worked
>>> just fine for me for a long time (before there was a problem
>>> with chksums).
>>
>> The error from apt-get update was something like this
>> (sorry I don't have exact message):
>>
>> "Some packages can not be updated, because they require other
>> packages that are not installed on your system. You might use
>> apt-get dist-upgrade to work around that"
>>
>> So I started to look why this is not happening with stock Debian
>> kernels
>> and found out that I was doing it all wrong (or so I thought at
>> that time).
>>
>> We can surely revert back to the old packaging scheme...
>>
>>
>>>
>>>
>>> I am not a Debian guru and am very open to suggestions on
>>> how to improve this.
>>> Perhaps we can return to the older versioning scheme and ask
>>> people to use dist-upgrade.
>>> Or maybe I am totally missing something. Please help.
>>>
>>>
>>> Yes, old way was really cool and convinient personally for me on
>>> production environment. And for testing new stable kernel
>>> versions too.
>>>
>>> Of course there is a drawback that you need to cleanup old
>>> kernel versions manually, cuz your /boot partition must have
>>> some free space for future upgrades.
>>>
>>> If OpenVZ kernels are very well tested before going to stable
>>> versions I wouldnt mind NEW way. It's probably more proper to
>>> have just 1 OpenVZ kernel version and update it from time to time..
>>
>> This is what we do with stable kernels -- they are released about
>> once a month,
>> and we test a lot before releasing those. But yeah, maybe we
>> should just revert
>> back to the old scheme.
>>
>>
>>
>>
>> --
>> --- Inguza Technology AB --- MSc in Information Technology ----
>> / ola at inguza.com <mailto:ola at inguza.com> Annebergsslingan 37 \
>> | opal at debian.org <mailto:opal at debian.org> 654 65 KARLSTAD |
>> | http://inguza.com/ Mobile: +46 (0)70-332 1551 |
>> \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
>> ---------------------------------------------------------------
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20140320/220c8211/attachment-0001.html>
More information about the Users
mailing list