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

[spameden]

Hi


2014-03-07 5:28 GMT+04:00 Kir Kolyshkin <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>:
>
>> 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).


> 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..




>
> Kir.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/users/attachments/20140307/5db06851/attachment-0001.html>