I can confirm there is an issue in upgrading on wheezy (stable). It uses linux-image-openvz-amd64 042+1 instead of the regular version and generates /boot/vmlinuz-2.6.32-openvz-amd64 instead of the prefixed version, i.e.: /boot/vmlinuz-2.6.32-openvz-042stab084.17-amd64
Could you guy look into it and fix it completely, so upgrades will go fine and not break anything? 2014-03-26 21:21 GMT+04:00 Narcis Garcia <informat...@actiu.net>: > These may be alternatives for version numbering (I've tested them with > dpkg --compare-versions): > > As a complete upstream version: > 42.85.20 > Combining old and new schema: > 042+stab085.20 > > > El 26/03/14 17:07, Roman Haefeli ha escrit: > > On Mon, 2014-03-24 at 09:40 -0700, Kir Kolyshkin wrote: > >> Thank you for detailed position. I have already rolled back to the old > >> versioning scheme, > >> please check packages in wheezy-test and let me know if anything is > >> wrong there. > > > > Things look pretty good in wheezy-test. Thanks for the work. > > > > Two minor issues: > > > > * There is still no changelog of the kernel in the package (or > > I cannot find it, usually it goes to something like: > > > /usr/share/doc/linux-image-2.6.32-openvz-042stab085.20-amd64/changelog.Debian.gz > > > > * The version of the meta package linux-image-openvz-amd64 is higher > > (042+1) in wheezy than in wheezy-test (042stab085.20). When switching > > from wheezy to wheezy-test, one has to remove and re-install the > > package linux-image-openvz-amd64 in order to automatically install the > > newest kernel packagelinux-image-2.6.32-openvz-042stab085.20-amd64 > > > > I'm not sure how to resolve the latter problem or whether it should be > > addressed at all (switching from wheezy to wheezy-test can considered to > > be one time thing). However, once the the current wheezy-test > > linux-image-openvz-amd64 goes to wheezy, there is a problem because you > > cannot downgrade packages. Either the version needs to be bumped with an > > epoch version [1] like 1:042stab085.20 (ugly) or the versioning scheme > > needs to be adapted (perhaps also ugly), but how? I can't think of a > > truly satisfying solution right now. > > > > [1] > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version > > > > > > Roman > > > > > >> On 03/24/2014 09:04 AM, Roman Haefeli wrote: > >>> Hi all, Ola > >>> > >>> I followed the recent discussion about OpenVZ kernel package management > >>> for Debian. While I don't really have a qualified opinion on the > subject > >>> matter (personally, I slightly tend towards a new package for each > >>> release), let me mention problems with the current situation: > >>> > >>> * 'uname -r' does not print the actual version (This already has > >>> been mentioned in the other thread) > >>> > >>> * If there is a problem with a kernel update, I cannot easily revert > >>> to the previous version. At our institution, we experienced cases > >>> where a switch to the previous kernel because of a bug was > necessary. > >>> > >>> * I'm trying to upgrade a machine right now from version 042stab084.26 > >>> to newest 042stab085.17. I do: > >>> > >>> $ apt-get update && apt-get dist-upgrade > >>> > >>> and I'm prompted with the following dialog: > >>> > >>> $ Configuring linux-image-2.6.32-openvz-amd64 > >>> $ ------------------------------------------- > >>> $ > >>> $ You are attempting to install a kernel image (version > 2.6.32-openvz-amd64) However, the directory > /lib/modules/2.6.32-openvz-amd64/kernel still exists. If this directory > belongs to a previous linux-image-2.6.32-openvz-amd64 > >>> $ package, and if you have deselected some modules, or installed > standalone modules packages, this could be bad. > >>> $ > >>> $ If /lib/modules/2.6.32-openvz-amd64/kernel belongs to an old > install of linux-image-2.6.32-openvz-amd64, then this is your last chance > to abort the installation of this kernel image (nothing has been changed > yet). > >>> $ > >>> $ If you know what you are doing, and if you feel that this image > should be installed despite this anomaly, Please answer n to the question. > >>> $ > >>> $ Otherwise, I suggest you move > /lib/modules/2.6.32-openvz-amd64/kernel out of the way, perhaps to > /lib/modules/2.6.32-openvz-amd64.kernel.old or something, and then try > re-installing this image. > >>> $ > >>> $ Stop install since the kernel-image is already installed? > >>> > >>> If Debian does in-place kernel upgrades (a.k.a keeping the package > >>> name while upgrading the kernel), they managed to never bother the > >>> user with a question like this. I certainly know too little about > >>> kernel package management to be of any help, but to me that dialog > >>> indicates that something is still odd. > >>> > >>> > >>> Those issues might be solved while sticking to the in-place upgrade > >>> scheme and are not necessarily an argument against it. I just wanted to > >>> mention them. > >>> > >>> Ranting aside, I am more than happy to see someone puts the effort into > >>> making all the great OpenVZ software easily accessible for Debian > >>> systems. For Debian, the situation has never been better before. Thanks > >>> a lot for that work. > >>> > >>> Roman > >>> > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> Users@openvz.org > >>> https://lists.openvz.org/mailman/listinfo/users > >> > > > > > > _______________________________________________ > > Users mailing list > > Users@openvz.org > > https://lists.openvz.org/mailman/listinfo/users > > > _______________________________________________ > Users mailing list > Users@openvz.org > https://lists.openvz.org/mailman/listinfo/users >
_______________________________________________ Users mailing list Users@openvz.org https://lists.openvz.org/mailman/listinfo/users
