[Users] Installation of latest Kernel fails again (deb size mismatch)

[Kir Kolyshkin]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20140307/1b2b17f7/attachment.html>