Bug#443487: hwclock.sh is running too late
On Tuesday, September 25, 2007 at 13:42:36 -0600, LaMont Jones wrote: -rw-r--r-- root/root 2916 2007-09-21 22:12 ./usr/share/doc/util-linux/README.Debian.hwclock I see no .gz on that file as delivered. There was previously, and now there is not. Ok, I had not noticed. When I was testing, it was failing attempting to _WRITE_ /etc/adjtime in that invocation. Hence the test for writablility. hwclock --hctosys never writes to an existing adjfile. There are only two meaningfull cases for hwclock --hctosys without --noadjfile on a read-only filesystem: -1) If the adjfile doesn't exist: hwclock tries to create it, and fails. -2) If the adjfile exists and is readable: hwclock reads it, and everything works OK. Using --noadjfile if [ ! -w /etc/adjtime ] saves case #1, but breaks case #2 (because --noadjfile prevents reading /etc/adjtime). Using --noadjfile if [ ! -r /etc/adjtime ] saves case #1 (because ! -e implies ! -r), and preserves case #2. Clearly better, isn't it? Alain. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443487: hwclock.sh is running too late
Hello LaMont, On Saturday, September 22, 2007 at 9:21:17 -0600, LaMont Jones wrote: http://incoming.debian.org/util-linux_2.13-7_i386.deb for starters, source is there too. After today's dinstall run (2:50ish ET), it'll be in the archive for sid. If I didn't fix the bug, please let me know which case I missed... There are 3 minor problems in hwclock.sh 2.13-7: -1) The README.Debian.hwclock .gz extension lacks in comments (the return of the revenge of the recently closed bug #393539). -2) If /etc/adjtime is not writable, the --noadjfile option will be added to hwclock. This --noadjfile will force --hctosys to ignore an existing /etc/adjtime, it will then be unable to compensate past drift, and will set a wrong system time (corrected only later at S11). The goal here is to use --noadjfile when /etc/adjtime does not exist and can't be created, not when it is readable. I'd propose to change the test to [ ! -r /etc/adjtime ]. -3) If the --hctosys call requires $HWCLOCKPARS (perhaps --directisa), the --adjust call most probably requires it also. The attached patch should fix those 3 quirks, and add a short comment about where to set --directisa when necessary (helps bugs #435102 and #439593). Alain. fixes 3 minor quirks in hwclock.sh 2.13-7 see Debian bug #443487 Signed-off-by: Alain Guibert [EMAIL PROTECTED] --- ulng-7/debian/hwclock.sh.orig Tue Sep 25 13:37:30 2007 +++ ulng-7/debian/hwclock.shTue Sep 25 14:20:29 2007 @@ -12,7 +12,7 @@ # - Added comments to alert users of hwclock issues # and discourage tampering without proper doc reading. -# WARNING: Please read /usr/share/doc/util-linux/README.Debian.hwclock +# WARNING: Please read /usr/share/doc/util-linux/README.Debian.hwclock.gz # or /usr/share/doc/util-linux/README.Debian.hwclock # before changing this file. You risk serious clock # misbehaviour otherwise. @@ -28,7 +28,8 @@ FIRST=no # debian/rules sets this to 'yes' when creating hwclockfirst.sh # Set this to any options you might need to give to hwclock, such -# as machine hardware clock type for Alphas. +# as machine hardware clock type for Alphas, or --directisa direct +# access option for machines without proper RTC interrupt. HWCLOCKPARS= hwclocksh() @@ -68,7 +69,7 @@ hwclocksh() echo 0.0 0 0.0 /etc/adjtime fi - if [ ! -w /etc/adjtime ]; then + if [ ! -r /etc/adjtime ]; then NOADJ=--noadjfile else NOADJ= @@ -92,10 +93,10 @@ hwclocksh() # to a very different value and hwclock --adjust is being # used. # - # Please read /usr/share/doc/util-linux/README.Debian.hwclock + # Please read /usr/share/doc/util-linux/README.Debian.hwclock.gz # before enablig hwclock --adjust. - #hwclock --adjust $GMT $BADYEAR + #hwclock --adjust $GMT $HWCLOCKPARS $BADYEAR : fi
Bug#443487: hwclock.sh is running too late
On Tue, Sep 25, 2007 at 03:20:53PM +0200, Alain Guibert wrote: On Saturday, September 22, 2007 at 9:21:17 -0600, LaMont Jones wrote: -1) The README.Debian.hwclock .gz extension lacks in comments (the return of the revenge of the recently closed bug #393539). -rw-r--r-- root/root 2916 2007-09-21 22:12 ./usr/share/doc/util-linux/README.Debian.hwclock I see no .gz on that file as delivered. There was previously, and now there is not. -2) If /etc/adjtime is not writable, the --noadjfile option will be added to hwclock. This --noadjfile will force --hctosys to ignore an existing /etc/adjtime, it will then be unable to compensate past drift, and will set a wrong system time (corrected only later at S11). The goal here is to use --noadjfile when /etc/adjtime does not exist and can't be created, not when it is readable. I'd propose to change the test to [ ! -r /etc/adjtime ]. When I was testing, it was failing attempting to _WRITE_ /etc/adjtime in that invocation. Hence the test for writablility. -3) If the --hctosys call requires $HWCLOCKPARS (perhaps --directisa), the --adjust call most probably requires it also. This one actually makese sense to apply. I'll add it. lamont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443487: hwclock.sh is running too late
On Fri, Sep 21, 2007 at 02:07:57PM -0600, LaMont Jones wrote: On Fri, Sep 21, 2007 at 01:48:43PM -0400, Theodore Ts'o wrote: Hence, I believe the correct answer is to restore hwclockfirst.sh, and to make it be at run at /etc/rcS.d/S08hwclockfirst.sh. Feel up to testing my fix? Otherwise, I'll find a machine and get it tested. Sure, I have a crash and burn machine that I can use for testing; Where do you want me to grab your fix? I'll grab it, set my clock to tick localtime with a European timezone, and give it a whirl Thanks, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443487: hwclock.sh is running too late
On Sat, Sep 22, 2007 at 09:21:17AM -0600, LaMont Jones wrote: On Sat, Sep 22, 2007 at 08:25:24AM -0400, Theodore Tso wrote: Sure, I have a crash and burn machine that I can use for testing; Where do you want me to grab your fix? I'll grab it, set my clock to tick localtime with a European timezone, and give it a whirl I did some testing yesterday afternoon - would still love you to pound on it more. http://incoming.debian.org/util-linux_2.13-7_i386.deb for starters, source is there too. After today's dinstall run (2:50ish ET), it'll be in the archive for sid. If I didn't fix the bug, please let me know which case I missed... I tested on my laptop with the hwclock ticking Germany local time, and it worked just fine. Many thanks for getting this fixed! It's been broken for a long time. Fortunately not too many Debianites in Europe apparently run with hwclock ticking loclatime, but I'm getting a lot more complaints from folks running Ubuntu; I'm guessing Ubuntu users are more likely dual-booting with Windows... - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443487: hwclock.sh is running too late
Package: util-linux Version: 2.12r-14 The priority of hwclock.sh keeps getting bounced around, and currently it is priority 11, as of 2.12r-14 (and it still is, as of 2.13~rc3-6): util-linux (2.12r-14) unstable; urgency=low * Make that 11 for hwclock.sh, since we need / to be writable for the adjfile. It really needs to be before S10, so that the time is correct for those people who want their CMOS clock to tick localtime, and who live east of the GMT timezone. It was at 8, which worked, but per the problem of / needing to be writable for adjfile: util-linux (2.12r-13) unstable; urgency=low * Move hwclock.sh to 8 since localtime is now a file, not a symlink. Adds Depends: tzdata (=2006c-2) Closes: #342887 The real fix for this is to have hwclock.sh and hwclockfirst.sh, which unfortunately disappeared here: util-linux (2.12r-12) unstable; urgency=low * drop hwclockfirst.sh, and put hwclock.sh back at 50. See #50572 and Closes: #342887 If you read through all of the bug report for #342887 it makes it very clear that hwclock needs to be run before S10checkroot, and that /etc/localtime must be on the root filesystem. The reason for hwclockfirst.sh was precisely because hwclock needs to be run to adjust the time before / is remounted read/write. Hence, I believe the correct answer is to restore hwclockfirst.sh, and to make it be at run at /etc/rcS.d/S08hwclockfirst.sh. Thanks for your consideration. - Ted P.S. I have my own workaround for this, which involves adding an entry to /etc/e2fsck.conf [options] buggy_init_scripts = 1 which I'm going to have to do for Ubuntu, because of an intransigence with their installer people (apparently they think users shouldn't be bothered to set the clock correctly at install time, or be asked what timezone they are in, so the clock might always be busted after the install). But hopefully this is one place where Debian can be better than Ubuntu. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443487: hwclock.sh is running too late
On Fri, Sep 21, 2007 at 01:48:43PM -0400, Theodore Ts'o wrote: Hence, I believe the correct answer is to restore hwclockfirst.sh, and to make it be at run at /etc/rcS.d/S08hwclockfirst.sh. Feel up to testing my fix? Otherwise, I'll find a machine and get it tested. lamont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
