Re: setting the system clock before launching operating system

[Robert Millan <rmh@aybabtu.com>]

On Sun, Sep 14, 2008 at 10:44:35AM +0300, Vesa Jääskeläinen wrote:
> Daniel Kahn Gillmor wrote:
> > On Sat 2008-09-13 00:52:47 -0400, Arthur Marsh wrote:
> > 
> >> Vesa Jääskeläinen wrote, on 2008-09-13 00:13:
> >>> Geoff Karl wrote:
> >>>> I would like to be able to set the clock to a particular time
> >>>> automatically before launching an operating system.
> >>>>
> >>>> Anyone have any ideas if this can be done during the boot loader process?
> >>> Yes it can be done. But why?
> >> Some machines (e.g. a Compaq Armada 1750) don't have the option to set
> >> the time via BIOS or set-up boot floppy.
> >>
> >> When the time had been lost, I'd have start-up problems with fsck
> >> checking when the file system had last been checked.
> > 
> > The same is true for many older PowerPC machines whose mainboard
> > batteries have begun to fail.  Being able to automate the bootloader
> > to say "look, if the hardware clock thinks it is 1904 (or 1900, or
> > 1970, or anytime before the turn of the century) it is probably wrong;
> > set it to at least 2008" at every boot would be pretty useful.
> 
> Well... replace the battery ;)
> 
> > This is especially useful on 32-bit architectures with a default
> > hardware epoch date so far in the past that crappier NTP
> > implementations think that it's actually in the future.  I've dealt
> > with this at the OS level (for various OSes) on older PowerPC
> > machines, and it's doable, but a pain.  Being able to guarantee that
> > no matter what OS you're booting, the initial clock will be at least
> > set to time X would be pretty handy.
> 
> ...and update your NTP software ;)
> 
> Should we one day support NTP time synchronization within GRUB 2, then
> it would be usable. Personally I do not see need for this.
> 
> I would propose that you use your OS startup script to handle this case
> in case you refuse to/can't replace your battery.

I agree. Having ad-hoc code to workaround limitations somewhere else sucks.

But if we can support it simply by having an interface to get/set the date
(which we already do), and generic scripting support, why not?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."