Arch Linux

How is this better from current implementation in Arch?

Certain clocks need extra parameters when using hwclock. This moves that out to an external file so local changes to rc.sysinit won't get overwritten.

OK, maybe it worth to move clock settings to conf.d. Maybe not in 0.7.2, but in 0.7.3 I hope.

status?

This would help greatly with problems like  FS#7667  and  FS#8437 . They have been declared non-bugs which is technically correct because they don't occur on real hardware, but are still pain in the ass for us VirtualBox users. Having the hwclock parameters in a separate place like conf.d or rc.conf would allow us to change them without manually patching rc.{sysinit,shutdown} scripts on each upgrade.

Well, could you please describe the parameters you'd need? We currently abstract the hwclock params a but with HARDWARECLOCK="utc" in rc.conf, so if we could cover it with a similar variable, it'd be nicer. I'm going to guess the only discrepancy is --directisa?

Yes, at least for me it's only --directisa. Still, for possible future expansion it would be nice if it was a variable where you could set arbitrary additional parameters, rather than being something overly specific like USEDIRECTISA="yes/no".

The problem is that adding a generic variable like this is going to cause issues with the existing functionality. What happens with "--localtime --utc" or vice versa?

It's something I'd like to avoid. Even more so, I'd like to avoid moving yet more functionality outside of rc.conf for something like this. I've heard a lot of "rc.conf is awesome" but never "editing 30 files in /etc/conf.d is awesome"

I see your point about --localtime etc. Well, I guess my argument about "possible future expansion" is hand-waving at best, so for me a USEDIRECTISA type variable would be more than enough (I'm not the original bug submitter though and I wouldn't want to hijack this bug report just to scratch my particular itch).

As for rc.conf vs conf.d, as I said in my earlier comment above I have no preference, either one is fine by me as long as it spares me from editing rc.sysinit and rc.shutdown all the time. I know the title of this bug report specifies conf.d, but if the original submitter has no objection I vote for rc.conf too.

An alternative would be to remove all the hwclock calls and put them in a custom /etc/rc.d/hwclock script. It *might* make things cleaner... opinions?

Wouldn't that bring us right back to the problem of user customizations being overwritten on each package update?

One possible approach is to have a generic HWCLOCKPARAMS variable after all, but if a user specifies parameters that are used internally by the script (such as --utc, --localtime, etc), a warning could be printed and those parameters ignored.

I don't mean an /etc/rc.d/hwclock that you hand edit - we don't do that anywhere in arch. I mean a hwclock script with a corresponding conf.d/ configuration

Oh, sorry for the confusion. Yeah, that would be perfect.

/etc/rc.d/hwclock will break everything! hwclock is called way before any rc.d can be.
We've spent alot of time for tracking all time-related bugs.
If you need some extra parameters - no problem implementing them in rc.conf or conf.d, but rc.d/hwclock - no way!

Just to clarify Roman's point: hwclock is called before the rc.d scripts are loaded

So it appears we cannot use a rc.d script as the clock is needed well before we get to that point.

If so, Roman can you explain what problems this would cause? See on my system right now, I can set the time any time after /dev is loaded. And it works fine. Could you please explain the reasoning, as "no way!" doesn't really give me very much info.

Why hwclock handling should not be touched:  FS#5444 ,  FS#5445 ,  FS#5529 ,  FS#6063  (it took a *lot* of time and work to get it to a really good working state)
(in short - what correct hwclock handling must take into considerations: UTC/localtime in BIOS, timezone, is /usr separate?, is / read-only, what timezone was on previous mount etc.)
Why --directisa should be made configurable:  FS#4929 ,  FS#8437 

Roman, for the record, I am well aware of what it requires to boot a machine and get it in working order. It is, in a way, what I do. I never once suggested "why don't I move this and neglect everything that's been done while re-introducing about 5 different regressions". 3 of the original 4 bug reports hard nothing to do with the ordering of the hwclock call, only one of them does. I understand very well when the proper system time is needed and when it is not.

The difference here, is that your stance is "it works, don't touch it", where my stance is "we can do this better".

However, I'm getting offtrack here. I will fall in line with the "it works, don't touch it" crowd for simplicity and brevity:
http://code.phraktured.net/?p=initscripts.git;a=commitdiff;h=9bf2014b750579d9720c13c9dfb9d358e0c27665

*EDIT* amended the commit, new URL

Aaron, I've mentioned that info for reference purposes, not for teaching. :)

> See on my system right now, I can set the time any time after /dev is loaded. And it works fine.
ehm..  FS#8665  ;)
Anyway, we cannot set hwclock in rc.d because of  FS#5445 .
I didn't mean that the code shouldn't be touched *just* because it works, but because I don't see any way to make it better by moving hwclock setting to rc.d.

Your patch for USEDIRECTISA is good (you forgot about rc.shutdown though).
I think this report can be closed after releasing new initscripts.