On 03/13/2014 11:58 AM, Kir Kolyshkin wrote:
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.
In fact I've just released 042stab085.18 to wheezy-testing, which is
back to the old versioning.
Please test it and let me know if it works for you.
Kir
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 <[email protected]
<mailto:[email protected]>> wrote:
On 03/06/2014 06:13 PM, spameden wrote:
Hi
2014-03-07 5:28 GMT+04:00 Kir Kolyshkin <[email protected]
<mailto:[email protected]>>:
On 03/02/2014 02:01 PM, spameden wrote:
2014-03-03 0:38 GMT+04:00 Ola Lundqvist <[email protected]
<mailto:[email protected]>>:
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 ----
/ [email protected] <mailto:[email protected]> Annebergsslingan 37 \
| [email protected] <mailto:[email protected]> 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 /
---------------------------------------------------------------
_______________________________________________
Users mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/users
