DragonFlyBSD

Did you set the clock and timezone during the install process for
DragonFly? As I recall, there's a separate installer step for that; the
DragonFly installer may assume UTC or a lack of it, depending.

tzsetup(8)

Tried tzsetup. Telling DFly that the system clock is either UTC or localtime
does not change the reported time at all. On booting the live CD, if I log in as
root, the clock is off by the same offset (+ 4 hours from the correct GMT time)
as after installation, when it's + 4 hours to the correct EST/EDT time.

Might be a qemu/KVM problem, actually. I'll install DFly on a real partition in
a couple of days to get a feel of how tzsetup is supposed to behave -- just want
to mention that FreeBSD on KVM behaves perfectly fine -- apart from the infamous
qemu clock drift.

Hi,

Have you tried to pass -localtime option to kvm when starting?

Regards,
Antonio Huete
> New submission from Michel Salim <salimma@fedoraproject.org>:
>
> Using kvm-74-3.fc10.x86_64 on Fedora 10 beta.
>
> Host machine is set to EST/EDT. The guest FreeBSD 7 installation reports the
> correct time (whether UTC or local), but the DragonFly 2.0.1 installer, and the
> installed system, is ahead by 4 hours.
>
> It appears that, for some reason, the DragonFly/KVM combo is wrongly
> compensating, presumably assuming (wrongly) that the host clock is set to
> localtime (UTC-4) and thus adding four hours to it. Any difference in the way
> the DragonFly and FreeBSD kernels handle the system clock?
>
> ----------
> messages: 5455
> nosy: msylvan
> priority: bug
> status: unread
> title: Incorrect clock under KVM
>
> _____________________________________________________
> DragonFly issue tracker <bugs@lists.dragonflybsd.org>
> <https://bugs.dragonflybsd.org/issue1144&gt;
> _____________________________________________________
>
H

Still buggy. With -localtime, DFly correctly reads the actual localtime (the
installation live CD reported it as GMT, because no timezone has been selected).
After using tzdata on the installed system, even though I answered 'no' to the
question 'is system clock set to UTC', it still treated the system clock as UTC
anyway, so my clock is now 4 hours early.

Bizarre.