On 03/06/2014 06:13 PM, spameden wrote:
Hi
2014-03-07 5:28 GMT+04:00 Kir Kolyshkin <k...@openvz.org
<mailto:k...@openvz.org>>:
On 03/02/2014 02:01 PM, spameden wrote:
2014-03-03 0:38 GMT+04:00 Ola Lundqvist <o...@inguza.com
<mailto:o...@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.
_______________________________________________
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users
