[Users] Issues with kernel upgrade on Debian Wheezy
Narcis Garcia
informatica at actiu.net
Wed Mar 26 10:21:41 PDT 2014
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 at openvz.org
>>> https://lists.openvz.org/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Users mailing list
> Users at openvz.org
> https://lists.openvz.org/mailman/listinfo/users
>
More information about the Users
mailing list