On Sun, Jan 23, 2011 at 00:01, Tom Gundersen <[email protected]> wrote: > Further to my previous mail about hwclock, I'm struggling to get my > head around what is the "proper" way to handle hwclock's adjfile. > > These are my assumptions: > > /etc is in principle mounted read-only (not yet possible, but that's > the goal, right?) > /var is in principle not available during early boot > the drift of the hardware clock is updated at regular intervals and > cannot be on a read-only filesystem (but it is ok that we don't know > the drift at early boot (is this true?)) > we need to know whether or not the hardware clock is in utc during > early boot (is this actually required? if not, could someone point me > to a discussion/documentation?) > > If all of this is correct, it seems to me that the only solution > (without changing hwclock) is to ignore the utc/localtime part of > adjfile and have a config file in /etc that stores whether or not we > use utc (resp., localtime) and always invoke hwclock with > "--adjfile=/var/hwclock/adjfile --utc" (resp., > "--adjfile=/var/hwclock/adjfile --localtime"). > > I realise that if someone oblivious to this policy were to call > hwclock without --adjfile, havoc would ensue, but this is the best I > could come up with. > > I'd be happy to prepare a patch, if someone can confirm that my > approach is sound.
All that adjfile hackery should probably just be left alone. If you need proper time, use ntp, if not, leave the rtc as it is. I really doubt its usefulness these days. Is that stuff really useful for you, or do you just port-over old stuff? Kay _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
