I recently acquired a XEN based virtual private server but the only version of suse they provide is 10.0. I have full root access to my VPS through ssh but that’s it. I’d really like to upgrade it to a new version, say 11.0.
Is there a way to do a full upgrade in such a way that it is all done remotely through ssh? Or, at the very least, a way to neatly get it to use an 11.0 repository and at least update things like apache, php5, and other services that will necessarily be exposed to the Internet?
I have some ideas of my own but wanted to get sound off of others who may already have done such a thing.
Hmm… if the current version “they” (who ever they are) provide is 10.0, that is most likely SLES (SuSE Linux Enterprise Server). In which case there is no version 11 of SLES to upgrade to. The latest version of SLES is currently 10 SP2.
Upgrading to openSuSE 11.0, if that is what you meant, is most likely not possible, but that is just a hunch of mine.
Thanks for the reply. I have seen those remote install kernel options before but the machine in question is a XEN based virtual machine. I only SSH access to it, and that only after the vm has booted – no physical access, or even “virtual” physical access. Hence, I don’t see a way to pass those parameters to the boot kernel. I have talked to the hosting company and they claim they are planning to update their SUSE Virtual Private Server “soon”. I told’em I’d pester’em until they did.
I don’t see a way to pass those parameters to the boot kernel.
I would think the idea is to put those parameters into a new menu option in grub (or whatever boot loader is used), and in your case make it the default menu choice and then reboot. This could of course leave you without access to the system if things don’t go as expected. But in that case the hosting company will hopefully be kind enough to change it back for you.
Perhaps this is still not possible to do with a virtual server. I must confess I’ve never used one in this manner, though with an ordinary computer these things should work. So I would expect it to work with a vm as well given that all the virtual hardware is properly setup. Still, I’m guessing here
I forgot to mention this earlier… it’s definitely NOT SLES10. I was hoping that would be the case but, no, it’s regular 10.0 that went EOL about 9 months ago.
I’ve used Virtual Machines (though not XEN) a lot and I expected to be able to try exactly what you suggest. Alas, the /boot dir of my VPS is completely empty. i.e. there is no grub.conf/menu.lst to edit. I don’t know if that’s a normal XEN thing or if it’s a precaution taken by the provider to keep people from doing exactly what I want to do. Otherwise, I could use grubonce to select that special entry only the next time it boots. It might work, or it might blow up, but the only way I have to test it is with different VM software so the results, even if successful, wouldn’t apply anyway.
However, a potentially viable option that remains is this: Is there a way to get 10.0 to use an 11.0 RPM repository? It would seem that at least this way I could start using more up-to-date RPMs and that would alleviate the overwhelming majority of my concern. I’ve been able to successfully add an 11.0 repo to my 10.0’s list of install sources, and they are accepted into the list, but yast doesn’t seem to want to actually use them. Or perhaps I could install apt4rpm on it. Hmmm, now there’s a thought. I prefer to stick with “native” tools but in this case my hand may be forced.
One barrier to that idea is that the compression method in 11.0 RPMs is LZMA and the RPM utility has to be updated first to handle such RPMs.
And anyway I think this a risky approach as the versions are so far apart that you will end up with heaps of broken dependencies and oddities.
Such a migration really calls for swapping in a new, tested machine in a flash cutover. Isn’t the concept of virtualisation to allow such new machines to be slipped in easily?
Greets Ken, you truly are a wise penguin. Isn’t the whole idea behind a package manager that it resolves the dependencies automatically? If it doesn’t do that then, right, I’d be risking a bunch of broken dependencies. But assuming the concept is fundamentally valid, which it may prove not to be, I’d think the list of the dependencies provided by each RPM would feed the package manager (yum, yast, apt) the info it needed to keep things tidy. I HAVE done this kind of thing before, where i updated all the RPMs although the underlying version wasn’t the same. It worked pretty well as I recall but I think the version difference between the two was only .1. Not as radical, but I’d think the principle would still apply.
Worst case I could simply call for my VPS to be reimaged to it’s original state which is a free service and allegedly takes only “minutes”… so I have the freedom to take such risks. The first obstacle is whether or not I can get the 10.0 box to even use an 11.0 repo. The compression difference is a noteworthy observation so I’ll start there.
Yes, but the dependency resolution only applies within a particular release. When you mix releases it becomes less predictable. A distro upgrade using the boot media tries to patch up the differences, but there will be some packages that are no longer supported, replaced by something else, or the configuration has changed somewhat.
