In kernel 2.6.27 there is a config setting "RTC_HCTOSYS" which allows the kernel to set the system time from RTC during startup and resume. Gentoo also has an init script "hwclock" which does the same thing in INIT phase. I don't like redundancy so there should be a option in /etc/conf.d/hwclock to control if the user wants the script to set system time in startup. It could be called "clock_hctosys". It is safer to do the system time update as early in boot process as possible. The changes to hwclock should be pretty simple. Reproducible: Always
Or remove hwclock from the boot runlevel. You can do this with OpenRC, but not baselayout-1.
I actually use OpenRC. But this is what I want: 1. Let the kernel set system time from hw clock during kernel load. 2. Let the init script set hw clock from system time during shutdown. (Because NTP makes sure system time will be "perfect"). So removing hwclock removes the latter. I don't want that. IMO, the best and easiest thing is to allow hwclock do both things as the user wants. I'll try to provide a patch but first I have to learn how the scripts work...
Created attachment 193721 [details, diff] CLOCK_HCTOSYS option to /etc/conf.d/clock and handling through /etc/init.d/clock I attach a small patch against sys-apps/baselayout-1.12.11.1 which adds CLOCK_HCTOSYS option to /etc/conf.d/clock and handles it through /etc/init.d/clock. Note that this requires >=sys-apps/util-linux-2.15 as it uses hwclock --systz option.
Assigning to openrc. Mike, since this bug has a patch for baselayout-1 are you interested in implementing it there?
i didnt notice (or i forgot) about the baselayout-1 patch. i dont have a problem with adding that (patch looks good to me as is), but it would seem odd to add functionality to baselayout-1 that openrc itself doesnt provide.
(In reply to comment #5) > i didnt notice (or i forgot) about the baselayout-1 patch. i dont have a > problem with adding that (patch looks good to me as is), but it would seem odd > to add functionality to baselayout-1 that openrc itself doesnt provide. I agree, and I was thinking about putting it in openrc. The only reason I asked you about bl1 was that the bug has a patch. We can just put it in openrc if you prefer and remove base-system from this bug. Would that be the better way forward?
Mike, I have the beginnings of this in my local repo for openrc. However, I am thinking that it might be better to reverse the logic of the patch, as follows: clock_hctosys="YES" # hwclock will set the system clock during bootup. clock_hctosys="NO" # hwclock will not set the system clock during bootup. That brings it in line with the way clock_systohc already works. The default will be yes, so that we don't lose compatibility. So, if you prefer, I am leaning toward just doing this in openrc. What do you think?
Mike/all, My patch, with the reversed logic from the original, has been added to openrc, commit fa1fef. Feel free to add a similar patch to baselayout-1 if you like, or feel free to close this bug and just state that this has been added in openrc.
there were some bugs in the original baselayout-1 patch, but they should be fixed in what i committed: http://sources.gentoo.org/baselayout?rev=3183&view=rev William: your commit for openrc is fine, but it doesnt address the whole issue. you want to let people run just `hwclock --systz`.
Created attachment 261682 [details] openrc-systz.patch Mike, does this patch to what we have correct the issue?
looks good to me ... thanks
The patch in comment #10 is applied, commit ebd7939. I am closing this because fixes are applied to both baselayout-1 and openrc. Feel free to re-open if necessary.
