Clock won't keep setting after reboot(Solved)

[fanthom]

I then checked rc.s and found that the hardware clock is being set based on the cheat code 'utc' if it is present. It is not being based on the setting in the hardwareclock file.

if rc.S discovers 'timezone=' cheatcode then looks for 'utc' flag and sets the system according to these.
if you want the system to respect settings in /etc/hardwareclock then remove 'timezone=' cheat and set the symlinks manually.

you need to stick to one method (cheatcodes) or other (manual file manipulation) as currently you are mixing them and that's why it does not work.

[Rava]

I wonder why my system (XFCe x86-64, 3.0.1) after a fresh boot keeps setting the time 2 hours off, 2 hours too early.

I use this cheat code in porteus.cfg: timezone=Europe/Berlin
The current /boot/docs/cheatcodes.txt as part of 3.0.1 x86_64 says:

timezone=region/zone

... Tell Porteus the correct timezone for your location. By default,
this assumes that your hardware clock is set to localtime.

Code: Select all

root@porteus:/etc# cat hardwareclock 
# /etc/hardwareclock
#
# Tells how the hardware clock time is stored.
# You should run timeconfig to edit this file.

localtime

root@porteus:/etc# ls -l hardwareclock 
-rw-r--r-- 1 root root 128 Sep 26 07:50 hardwareclock

(Seems, /etc/hardwareclock is written anew with every new start of Port...)

So... me thinks I did all right. I use the cheatcodes, and not created any symlinks (as mentioned on the previous page)... so why won't it work like it should?

[tome]

Do you use timezone=Europe/Berlin for both - fresh and persistent boot mode?

[Rava]

Do you use timezone=Europe/Berlin for both - fresh and persistent boot mode?

I never use the changes cheatcode, everything that gets saved in Port is saved by me manually, the rest should be forgotten. (Me being quite a bit on the more secure side when it comes to stuff like that.) I use rootcopy when the boot device is a Linux filesystem; otherwise I create an extra xzm for my local settings and stuff like recent browser bookmarks and such...

[Rava]

I forgot to add: I also set this in /etc/profile:

Code: Select all

TZ='Europe/Berlin'; export TZ

But that could not cause any issues, now, could it?

[fanthom]

i have a nice solution in kiosk but it requires internet access and ntpdate utility to sync the clock.
will add it to rc1 and see what people thinks about it.

[Rava]

^
ntpdate is a neat thingy to keep the hardwareclock close to the atomic clocks / real clock...

But there should be no reason why my system sets the clock wrong at every new start.

What do you suggest? I could add lines in the main setup files that wrote the current time into the same file (including which file did so, and where in that file...)

That should help in determine when the clock gets changed...
Which is the first executed setup-file after Linux started its init?

[fanthom]

rc.S -> rc.M -> rc.services (unique to porteus - not present in Slackware - it runs in background making booting little faster)

[Rava]

rc.S -> rc.M -> rc.services, okay... but now that I wanted to put debug date >>$filename in... I realized I forgot to ask one thing: which filesystems are already useable / writeable at the beginning of rc.S?
I read there:

Code: Select all

mount -nt proc proc /proc
mount -nt sysfs sysfs /sys
mount -nt devtmpfs devtmpfs /dev

That's all special devices I don't want to touch if I can help it...

Is the boot device already mounted rw? I sure want the current time/date into to be dumped in one file only, and not several..

[fanthom]

Is the boot device already mounted rw?

yes

[Rava]

So, I set some debug echo info in the mentioned system files, and saved that to /mnt/BOOTDEVICE/tmp/porteusdatedebug.info
(I put into /etc/profile.local a tweak that creates the syslink of /x that always points to the current boot / porteus media the system was booted from, using this code:
export PORTEUSDEV=`awk 'c-->0;/Booting device:/{c=1}' /mnt/live/var/log/livedbg`
(When /mnt/live/var/log/livedbg would change I have to revise / tweak this code snippet, of course)

Code: Select all

root@porteus:/x# cat tmp/porteusdatedebug.info
/etc/rc.d/rc.S BEGIN 02.10.2014 22:57:48 +0000 Local time zone must be set--see zic manual page
/etc/rc.d/rc.S END 03.10.2014 00:57:52 +0200 CEST
/etc/rc.d/rc.M BEGIN 03.10.2014 00:57:52 +0200 CEST
/etc/rc.d/rc.M PRIOR rc.services 03.10.2014 00:57:53 +0200 CEST
/etc/rc.d/rc.services BEGIN 03.10.2014 00:57:53 +0200 CEST
/etc/rc.d/rc.M END 03.10.2014 00:57:53 +0200 CEST
/etc/rc.d/rc.services AFTER rc.yp 02.10.2014 22:58:14 +0200 CEST
/etc/rc.d/rc.services END 02.10.2014 22:58:14 +0200 CEST
root@porteus:/x# date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z
02.10.2014 22:58:47 +0200 CEST

As you can see... my tweak Port starts with console mode, and when the system is up and running, but without any X (and X means: XFCe), the clock does get changed + 2 hrs, but then changed back again to the correct time...

I write this from the virtual console, without X started yet, now I start it and look if the clock stays set okay (which would be strange, since it malfunctioned all the time prior at boot time... and aside from putting in these debug lines into the 3 setup files, I did change nothing on the system at all.... so by all logic, the clock should be set wrongly again once I started X, and not only the X clock and the clock in the terminals, but also the clock for the whole system including the virtual terminals should be set wrongly...

Now, the current time prior startx is:

Code: Select all

root@porteus:~# date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z
02.10.2014 23:10:59 +0200 CEST

(Yes, I am a slow typer)

Now, let's start X and see what will happen...

And indeed... the clock was not altered by startx, and not by XFCe: XFCe told me it's 23:12, and the VT told me this:

Code: Select all

root@porteus:~# date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z
02.10.2014 23:12:39 +0200 CEST

Weird, eh? How can just some echo lines in the setup files fix an issue like that?

[brokenman]

The observer effect maybe. (joke)
http://en.wikipedia.org/wiki/Observer_effect_(physics)

Did you use any sleep commands?

[Rava]

Did you use any sleep commands?

Nope, here are all the lines I used/added:

Code: Select all

root@porteus:/etc/rc.d# grep "^echo /etc/rc.d/" * 2>/dev/null
rc.M:echo /etc/rc.d/rc.M BEGIN $(date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z) >>/x/tmp/porteusdatedebug.info
rc.M:echo /etc/rc.d/rc.M PRIOR rc.services $(date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z) >>/x/tmp/porteusdatedebug.info
rc.M:echo /etc/rc.d/rc.M END $(date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z) >>/x/tmp/porteusdatedebug.info
rc.S:echo /etc/rc.d/rc.S BEGIN $(date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z) >>/x/tmp/porteusdatedebug.info
rc.S:echo /etc/rc.d/rc.S END $(date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z) >>/x/tmp/porteusdatedebug.info
rc.services:echo /etc/rc.d/rc.services BEGIN $(date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z) >>/x/tmp/porteusdatedebug.info
rc.services:echo /etc/rc.d/rc.services AFTER rc.yp $(date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z) >>/x/tmp/porteusdatedebug.info
rc.services:echo /etc/rc.d/rc.services END $(date +%d.%m.%Y\ %H:%M:%S\ %z\ %Z) >>/x/tmp/porteusdatedebug.info

Still, it could be a tiny "sleep" phenomenon, any of these echo lines not takes much time, only a very small one... but still, maybe that very small time is in the right moment the thing that did the trick? Who knows.

Should I replace my 3 files with the originals from 3.0.1 to see if, at next new boot, the time is again set okay, or if the time is again set faulty?

[Rava]

Some Updates

Could be that the breaking apart power supply of that PC did most of the weird behaviour I listed above.
I now bought a new one (and even though it's a years old model, they still produce the very same power supply, so I chose the very same model) and after the first boot, for some weird reason, hwclock could not find any hardwareclock, and after suspend, the date & time was always set like 3 days into the future.
But after a new reboot (and including 001-core5.xzm for the first time, that is) all is well, the time is set okay, and hwclock is working as it should...

[Rava]

Finally, again done 2 reboots of 3.0.1 x86-64.

The first time all went well:

Code: Select all

/etc/rc.d/rc.S BEGIN 18.10.2014 08:52:13 +0000 Local time zone must be set--see
/etc/rc.d/rc.S END 18.10.2014 10:52:17 +0200 CEST
/etc/rc.d/rc.M BEGIN 18.10.2014 10:52:17 +0200 CEST
/etc/rc.d/rc.M PRIOR rc.services 18.10.2014 08:52:18 +0200 CEST
/etc/rc.d/rc.services BEGIN 18.10.2014 08:52:18 +0200 CEST
/etc/rc.d/rc.M END 18.10.2014 08:52:18 +0200 CEST
/etc/rc.d/rc.services AFTER rc.yp 18.10.2014 08:52:38 +0200 CEST
/etc/rc.d/rc.services END 18.10.2014 08:52:39 +0200 CEST

But the 2nd time, not:

Code: Select all

/etc/rc.d/rc.S BEGIN 22.10.2014 11:38:41 +0000 Local time zone must be set--see
/etc/rc.d/rc.S END 22.10.2014 13:38:44 +0200 CEST
/etc/rc.d/rc.M BEGIN 22.10.2014 13:38:44 +0200 CEST
/etc/rc.d/rc.M PRIOR rc.services 22.10.2014 11:38:45 +0200 CEST
/etc/rc.d/rc.services BEGIN 22.10.2014 11:38:45 +0200 CEST
/etc/rc.d/rc.M END 22.10.2014 11:38:45 +0200 CEST
/etc/rc.d/rc.services AFTER rc.yp 22.10.2014 11:39:05 +0200 CEST
/etc/rc.d/rc.services END 22.10.2014 11:39:06 +0200 CEST

The 1st boot was just a warm reboot, the 2nd not. There Port 3.0.1 crashed and not reacted at all, so I had to press the power button > 5 seconds to forcefully shut down the PC. That time at reboot, the time bug showed its ugly head as well...

Any ideas if I should add some more echo debug lines?