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

Wed Mar 12 13:47:16 PDT 2014

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> 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>:
>
>>  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).
>
>
> 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                    Annebergsslingan 37        \
|  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/20140312/fe3262f7/attachment.html>