[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