On Tue, 2014-10-07 at 20:21 +0200, Michael Biebl wrote: > Am 07.10.2014 um 19:14 schrieb Andreas Henriksson: > > Control: reopen -1 > > Control: found -1 2.25.1-4 > > > > Hello! > > > > I'm reopening this bug report regarding using --hctosys in the util-linux > > hwclock-set script. The change was proposed for the benefit of arm > > systems where RTC drivers are built as modules and when they get loaded > > the previous scheme didn't work. > > > > Unfortunately it was reported that the new scheme breaks systems which > > (AIUI) the hardware clock is set to local time (and using the new > > initramfs-tools 0.118 scheme where time set set up in the initramfs). > > > > As I overheard discussions about building the RTC drivers on ARM into > > the kernel I'm going to revert this change in hwclock-set as well. > > This should unbreak all versions for now..... > > > > I'm thus reopening this bug and hope for feedback on how we best handle > > this in the future or if it's just ok to have a requirement on RTC drivers > > needing to be built-in. > > Fwiw, it was me, how experiences this issue. > After the switch from systz to hctosys in /lib/udev/hwclock-set, my > hardware clock is no longer properly set under systemd. It works for me. Which version of systemd are you using? > Afaics, this is because systemd set's the clock internally and doesn't > care for the flag file that is created by hwclock-set. Also hwclock-set explicitly checks for running under systemd and then does nothing. Ben. > Under sysvinit, I don't encounter this problem. > > When switching hwclock-set back to systz, it works properly for both > systemd and sysvinit. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky
Attachment:
signature.asc
Description: This is a digitally signed message part