Hi folks, I have a couple of boards that ship by default without RTC devices and boot time always incurs the following nasty messages in multiplicity. ... * One of the files in /etc/{conf.d,init.d} or /etc/rc.conf * has a modification time in the future! * One of the files in /etc/{conf.d,init.d} or /etc/rc.conf * has a modification time in the future! ... A very simple solution was be to maintain an /etc/sanetime file that would set a time other than the epoch at boot. Something within the last day, month, year, or decade even ;-) There's a fallback sanetime in /etc/init.d/sanetime just in case /etc/sanetime doesn't exist, and it works naturally because time is monotonically increasing (last I checked). Also, it would seem that /etc/clock doesn't fail gracefully when there is no rtc, even when there are provisions to 'fakeit' for other reasons. ... * Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method.Can not access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. * Failed to set clock You will need to set the clock yourself [ !! ] ... It was just a matter of adding an /etc/init.d/sanetime script, slightly patching /etc/init.d/clock & /sbin/rc (AFAIK this only works for sysvinit, not openrc). See the attached files. Cheers, C Reproducible: Always Steps to Reproduce: 1. boot 2. 3. Actual Results: ... * One of the files in /etc/{conf.d,init.d} or /etc/rc.conf * has a modification time in the future! * One of the files in /etc/{conf.d,init.d} or /etc/rc.conf * has a modification time in the future! ... ... * Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method.Can not access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. * Failed to set clock You will need to set the clock yourself [ !! ] ... Expected Results: Setting system clock using the hardware clock [OK]
Created attachment 280847 [details, diff] add-sanetime-to-etc-init.d-clock.patch applies to sys-apps/baselayout-1.12.14-r1
Created attachment 280849 [details, diff] add-sanetime-to-sbin-rc.patch applies to sys-apps/baselayout-1.12.14-r1
Created attachment 280851 [details] /etc/init.d/sanetime new init script
With openrc, you should be able to replace the hwclock service in your boot runlevel with swclock and have the same functionality by running these commands as root: rc-update del hwclock boot rc-update add swclock boot Let me know if that works for you.
Your sanetime code is extremely similar to the swclock functionality. Please test that first. The only difference is that if the saved time is not available from a file, swclock errors out instead of using a default value. If we really need a default value, I think we should take the mtime of the swclock or openrc binaries.
I just looked at this, and we print a message if the file doesn't exist, but because the swclock script uses the --warn switch with the binary, it complains but doesn't return an error condition.
(In reply to comment #4) > With openrc, you should be able to replace the hwclock service in your > boot runlevel with swclock and have the same functionality by running > these commands as root: > > rc-update del hwclock boot > rc-update add swclock boot > > Let me know if that works for you. I didn't even realize swclock existed - thanks for the tip!
since the init.d hardcodes /sbin/runscript already, might as well use that
In comment #5, it wasn't stated for sure that we need to have a default time if the shutdowntime file doesn't exist. If we do, I think we should open another bug for that. Can you please revert the summary back to what it was?
an error confuses people. taking the default from /sbin/runscript is reasonable. feel free to clone to make a new bug and revert summary to mark this invalid if you really want. doesnt matter to me.
Christopher, were you able to get swclock to work for you? Once I know you have it set up I will close this bug then we can open another about the default file for reading the time if we need one. Thanks, William
(In reply to comment #10) > an error confuses people. taking the default from /sbin/runscript is > reasonable. The swclock binary can take a file name on the command line, so I will look into modifying the startup script to fix this. > feel free to clone to make a new bug and revert summary to mark this invalid if > you really want. doesnt matter to me. I do not have the original email for this bug any longer, so I do not have the original wording of the summary. So I guess we'll stay with this bug for now.
Hi William, (In reply to comment #11) > were you able to get swclock to work for you? Once I know you have it > set up I will close this bug then we can open another about the default > file for reading the time if we need one. I'm using a precompiled stage3 for the panda board from armin76, and that one only uses baselayout rather than OpenRC. I haven't upgraded to OpenRC yet, but will do today to see if I can close the applicable OpenRC issue. Maybe the same swclock functionality should be added to baselayout too? C
This has been fixed in git, commit 3688c85, and will be included in the next release as shown by the bug blocking the tracker.
(In reply to comment #13) > (In reply to comment #11) > > were you able to get swclock to work for you? Once I know you have it > > set up I will close this bug then we can open another about the default > > file for reading the time if we need one. > > I'm using a precompiled stage3 for the panda board from armin76, and that one > only uses baselayout rather than OpenRC. I haven't upgraded to OpenRC yet, but > will do today to see if I can close the applicable OpenRC issue. > > Maybe the same swclock functionality should be added to baselayout too? openrc takes care of this functionality with baselayout-2. You will have to upgrade both. Also, if you have any issues, please open another bug; this one wound up being used to fix the lack of a default reference file for swclock. Thanks much, William
Hi William, Thanks for your suggestions. The swclock init script worked well, except for when initially called with "restart". In that case, the file that it reads the time from (/lib/rc/lastshutdowntime?) did not already exist (and the parent directory might not have existed either). However, just running with argument "start" and then "stop" fixed the issue. OpenRC is actually much speedier than the baselayout-1 init system too, (of course I know this already from many years of gentooing) so I'm happy to upgrade. There are no more issues with the original bug, so good luck resolving the hijacking bug (Yar!) C (In reply to comment #11) > Christopher, > > were you able to get swclock to work for you? Once I know you have it > set up I will close this bug then we can open another about the default > file for reading the time if we need one. > > Thanks, > > William
(In reply to comment #12) just click the "History" link in bugzilla near the "Modified" field (right above the "CC" field). you can view all the changes (such as summary) there.
Hi Christopher, both issues covered in this bug should be resolved when 0.8.4 is released, which I'm thinking will happen pretty soon. William
