On Monday 09 March 2009 12:56:25 hh.eu@gmx.de wrote:
> Hello Debian users,
>
> I have a virtual private server (VPS) that is running a minimal
> install of
> etch (image used for installation provided by the hosting
company). I
> believe they use Virtuozzo for virtualisation. Since the virtual
> servers are
> not run using Xen, this means I am bound by the kernel provided
by the
> hoster since all virtual machines are sharing the kernel.
My VPS provider is running Xen, but I still have no control over
my kernel. (I know Xen can be configured so that /boot [or
similar] is available to both the host and the guest, but they are
not doing so.)
Anyway, I upgraded to Lenny without issue on an image that was
originally Etch, so I'm using:
Linux rei 2.6.24-19-xen #1 SMP Sat Jul 12 00:15:59 UTC 2008 x86_64
GNU/Linux
with Lenny.
They now support Lenny, but AFAIK the only way to get a Lenny VPS
would requires starting from a fresh Lenny install by them. I may
look into that in the future, but right now I don't feel like
trying a data/settings migration and the kernel is working fine
right now.
> The kernel is:
>
> servername:~# uname -a
> Linux servername.provider.tld 2.6.18-028stab060.2 #1 SMP Tue Jan
13
> 10:24:09 MSK 2009 i686 GNU/Linux
>
> Now my question is: Is it possible (or wise) to try to upgrade
to
> lenny?
I *think* that kernel should work for Lenny, but I'm not sure if
2.6.18 will be supported for Squeeze.
> Is
> it good practice to combine a lenny system with an etch kernel?
No, but Lenny packages do have to support running on Etch and
Etch-n-half kernels, since the reboot into the Lenny kernel can't
happen until after a number of Lenny packages are running.
So, you'll probably be safe running Lenny on an Etch kernel, but
no guarantees.
> Are
> there
> security risks?
I wouldn't think so. Etch still has security support, and your
hosting provider should be responsible for that since they don't
allow you to install your own kernel.
> Maybe it's better to stick with etch and keep the system
> updated with security updates as long as they are available?
Probably, at least until your hosting provider provides Lenny
images and you can migrate to one of those. I decided not to wait
and didn't get bit. Still, I don't feel comfortable recommending
it to just anyone.
> If you don't see reasons against this update: Would you
recommend an
> installation using debootstrap, or is it fine to do the
following?
>
> 1) /etc/apt/sources.list : Change occurences of etch to lenny
> 2) aptitude update
> 3) apt-get install aptitude
> 4) aptitude dist-upgrade
I recommend following the steps given in the release notes for
Lenny. Each Debian release provides instructions for upgrading
from the previous release.
> I have simulated the above, and realised that there are some
dependency
> problems, but they seem to result from the fact that it is a
minimal
> install
> without X server etc. and thus there are unmet dependencies
> ("depends") even
> now in the current installation.
aptitude shouldn't let you get into a state like that, and will
try and fix it for you if your system is in that state. I suggest
getting your package management system in a consistent state (i.e.
all Depends satisfied, among other things) before doing any
installation or upgrade of packages.
Now, aptitude likes having Recommends relationships satisfied by
default as well, and will try and pull in packages that are not
strictly necessary. If you are trying to keep your system minimal
or simply trying to avoid something like X, it may be good to
instruct it to not attempt to keep Recommends satisfied. Setting
"Aptitude::Recommends-Important" to "false" in your apt.conf (or
apt.conf.d) should do that.
(I also use "Aptitude::Keep-Recommends" "true" and
"Aptitude::Keep-Suggests" "true", but that is so I can keep more
packages marked as "automatically" installed.)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.