All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Debian 8.6 Upgrade not possible in OpenVZ?
nqservices
Member
Hi all,
I have several OpenVZ VPS servers hosted on different companies and they are all running Debian 8.6 Minimal. All the providers use SolusVM.
And because yesterday was released the new 8.7 Debian version, as I normally do, I went to upgrade all my VPS’s… but I saw on one of the hosting providers the following warning message on their SolusVM control panel:
/////
Debian 8 64bit minimal NOTICE: DO NOT run apt-get upgrade/dist-upgrade as it will break sysvinit.
/////
I ask their support team more info about this and their response was:
/////
This is an issue related to OpenVZ, there are additional steps that would need to be taken on the server side to prevent any issues. Unfortunately, this would cause downtime for the entire node, as changes would need to be made to the host's kernel.
Please use #update and do NOT use #upgrade as it will break many core components within the system.
/////
I have then contacted the others hosting providers and I’m getting mixed responses. I have one provider that is running OpenVZ latest version (2.6.32-042stab120.16) and there I could do the upgrade without any problems.
But the providers that are saying I can’t do the upgrade are running “old” versions of OpenVZ (2.6.32-042stab113.21 and Linux 2.6.32-042stab120.6)
Does anyone know anything more or has experience this issue? Is this normal?
Thanks
Comments
Yeah there's a hack where you have to install systemd-shim to go back to sysv init. You can also use that trick to upgrade 32-bit debian 7 to debian 8, since there is no 32-bit debian 8 openvz template afaik. If a web search doesn't work then I can look for the info for you. I have some notes around here somewhere.
Note, the symptom of the upgrade failing is you can't ssh into the server. Serial console simulator might work. Non-interactive ssh (i.e. scp, ssh hostname command...) do work. So you can probably un-hose yourself if you get stuck in this state. But, I'd suggest backing everything up thoroughly before doing this operation. I'm planning to upgrade my dedi (not even openvz) from 7 to 8 pretty soon, which gives me a logistic problem of copying around 3TB of data off it before upgrading...
Ran into a similar issue (linked) wanting to upgrade to the latest Ubuntu but unfortunately not listed in SolusVM template selection.
Willie is correct that ssh upgrade will fail. I never found a work-around (and I tried a couple) other than a tech who upgraded it manually from their end.
https://www.lowendtalk.com/discussion/101982/q-how-to-install-an-os-in-kvm-not-offered-by-isp
Yes, it is normal to experience issues while still trying to use OVZ in 2017.
did that for some machines by now, only run into problems once and that's been months ago.
can't tell about openvz as I am not using it, but for dedis/KVM this shouldn't be a big issue anymore. mostly I had wheezy running a 3.x kernel via backports before changing to jessie which might have helped...
yet it might heavily depend on what packages and maybe self compiled software you are running, so no guarantees at all, backing up everything for sure is the right way to do it.
As a general rule as of right now, unless you require the update for critical security (highly unlikely with an OpenVZ container) just assume you will always be 6 months behind on OS releases, if you don't like that, pay more and get KVM/Xen.
There's been 64-bit debian 8 for openvz for quite a while--there's just never been 32-bit debian 8, and the 7-to-8 dist-upgrade procedure under openvz needs a hacky workaround to keep systemd from interfering with ssh. I'll figure it out again and write it up for here and/or LES if anyone else cares about it. I got the impression that the openvz team was not planning to do a 32-bit debian 8 template but maybe I'm wrong.
Debian 9 is a few months away unless something snags, so we may go through this whole thing again then.
you would not want to run an OS made around kernel 4.x on kernel 2.6, would you?
I already upgraded few (freshly installed kvm/xen) jessie systems to stretch, which works very well - yet there is no change like from sysinit to systemd involved at all ;-)
if one really wants to go this way with OVZ, it most probably might be worth trying to mirror the actual wheezy system (of course without 3 TB whatever non-os-related data ^^) to a staging system and try to do the whole upgrade path to jessie and stretch directly after, to see if this might work out or where there might be culprits...
Exactly, I stick with Debian 7 personally for OpenVZ
ugh.
At least lxc hosters aren't facing this issue, i hope.
I am running Debian 8 (64 bit) on all my OpenVZ containers. I don't run systemd on any of them (and still use sysvinit). I've not had any troubles at all so far on any of the various 8.x updates so far. Yes the initial removal of systemd and migrating to sysvinit was a bit of a pain but once you get systemd out of the way, its mostly smooth sailing.
I personally prefer sysvinit and run it everywhere I can (except for proxmox which doesn't run without systemd - not because proxmox needs it but because one of their dependencies needs it - and also now they're not providing a sysvinit script - which is not hard to overcome if required).
I think the key issues with OpenVZ are that the (default) kernels are all 2.6 and they possibly/probably/maybe don't work nicely with cgroups et all which systemd depends on.
Also, not having udev sometimes makes life a bit hard (not impossible) because sshd depends on /dev/random (etc.) which may not be created by default without udev.
P.S: I also avoid systemd on KVM/Xen hosts wherever possible just because (so far) I can.
I can confirm that none of our nodes face any problems with this
Debian 8.7 works fine on OpenVZ, both 32 bit and 64 bit. Though debian 8 by default uses systemd, not sysvinit. Probably your provider has modified their debian 8 templates to use sysvinit instead of systemd.
Thanks all for information and advises. As said before I founded strange because on 1 of my OpenVZ VPS server I could do the update without problems. But all my other VPS's I can't.
I'm getting tired of OpenVZ "little" issues... Probably will move all my OpenVZ to KVM during 2017.
Will a KVM solve your issue? I am on a KVM with my ISP using SolusVM as their virtualization platform.
This is the template list currently offered by SolusVM
https://tdn.solusvm.com/
The next step is "slices" or dedicated.
Oh how I love SystemD!
Anyway, yes, KVM would address all of this since you can update the guest kernel w/o issue.
Francisco
I'd suggest ignoring solus's tdn and just roll your own. For some reason solus aren't automating updates&repackaging, so most things on the tdn are risky. From a quick look there's only one template added by OnApp in the last year -- that's asking for trouble if you use those templates.
I haven't had any issues upgrading Debian 8 on OpenVZ. Although I only really buy OpenVZ if there's a good storage deal or something. The majority of my servers are all KVM...with KVM you can install whatever you want, use your distro with it's regular kernel or do your own, and shit just works.
I buy OpenVZ if it's less than $1/mo and comes with both an IPv4, and a /64. I can't explain it, beyond "This may be useful!"
I can explain it. We are all VPSoholics
.
@Awmusic12635 ... are we covered on this ?
You are the only provider I have an OpenVZ with... all KVMs and Dedis otherwise
@mehargags I have a VPS with Subnetlabs - @Awmusic12635 - running Debian 8.x without issues. I'm not sure if this is "covered" in the sense that it'll work for you or your specific setup but at least there should be nothing that prevents it from working.
(see my previous post above referencing that I run sysvinit instead of systemd).
I do run systemd so that's why concerned.
You shouldn't have any issues with upgrading Debian on OpenVZ then (at least when it comes to Debian 8, not sure about the upcoming Debian 9). The only things I had to do (and it's far from required, I'm just OCD about it) with major release upgrades is systemctl disable certain services that would try to load kernel stuff that obviously OpenVZ can't do and they would show as failed when using systemctl status.