[Debian] [Users] Installation of latest Kernel fails again (deb size mismatch)
Kir Kolyshkin
kir at parallels.com
Thu Mar 13 11:58:41 PDT 2014
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.
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/debian/attachments/20140313/58b1717a/attachment-0001.html>
More information about the Debian
mailing list