9 Feb
2011
9 Feb
'11
3:13 p.m.
Hi Bernard,
On Wed, Feb 09, 2011 at 12:45:32AM +0100, urb59(a)sfr.fr wrote:
How we've laid out the disks has changed several times over the last
3 years so some people will and some won't. Most customers installed
in the last 18 months have / directly on xvda (no partition table).
They won't experience this issue.
New customers have xvda partitioned and / on xvda1, and they also
won't see that problem.
It's only really customers from before this that had / on xvda1 but
with no actual xvda. Or even customers from a very long time ago
that have sda1 and no sda.
In any case I would recommend everyone boots and mounts things by
label or UUID. That is how we generally have set them up.
- check before
you upgrade that if you have root partition on
/dev/xvda1 that fdisk -l /dev/xvda works. If it doesn't you need your
xvda1 renaming to xvda, contact support.
Didn't encounter that problem. I noticed that xen.independent_wallclock (set to 0 in
/etc/sysctl.conf) was no
longer accessible after the upgrade.
/sys/devices/system/clocksource/clocksource0/current_clocksource
contains xen, so I am wondering if running ntpd now makes any sense?
On the -xen kernels, if xen.independent_wallclock is set to 0 (the
default without the sysctl we added) then you can't change your
system time. In that case time is supposed to be locked to that of
dom0 (host machine) and in theory you would not need to use ntp.
However, we found that there was often an offset or a drift which
could not be corrected because of xen.independent_wallclock being
set to 0.
So, we recommended it be set to 1 and everyone run ntp.
Under the new pvops kernels, xen.independent_wallclock doesn't exist
and you can change your time. I don't think it's meant to be locked
to that of the dom0, but even if it is I'd still recommend running
ntp.
Cheers,
Andy
--
http://bitfolk.com/ -- No-nonsense VPS hosting