Create Debian 9 (Stretch) minimal ISO similar to DebianDog

[rufwoof]

I just run

# dpkg-reconfigure tzdata

but that may be systemd specific ???

[rcrsn51]

I just run # dpkg-reconfigure tzdata

But which mode are you in? UTC or LOCAL?

[zagreb999]

WITH ALL RESPECT , FRED...

PLEASE, CAN YOU TEST
tzclock_3.0.6-1_i386.deb BEFORE
COMMENTING...
APSSOLUTELY IT IS
INCOMPARABLE WITH

PeasyClock
KIND REGARDS.

[jd7654]

...All I tried to mention is that manually editing /etc/adjtime to set to LOCAL may be not needed at all (although it does not harm of course), configuring your program the right way does it all from what I tested.

Are you in UTC zone? Only then it would not matter.

For the rest of us, there is a bit of complication in getting time correct in Dogs. Puppy is easy, if a bit messy with a bunch of time, zone and PSync utilities, but it works. Just set zone, and check/activate Internet time sync and all is good.

Dog and DebLive only include the Time Zone tool by default, but they are set up with different time Standard, which is part of the confusion.
DebDog comes with: LOCAL time standard, and default zone UTC
DebLive comes with: UTC time standard, and default zone UTC.

I always setup and fix the time/zone/standard whenever I setup Linux, whether it is Systemd, or Puppy, or whatever. So I've gone through this a lot. A sample fix for DebLive:

Current time around 10:46PM:

Code: Select all

root@live:~# date
Wed Nov  1 22:46:14 UTC 2017
root@live:~# hwclock
2017-11-01 22:46:16.265059+0000

Change time zone to HST:

Code: Select all

root@live:~# date
Wed Nov  1 12:48:02 HST 2017
root@live:~# hwclock
2017-11-01 12:48:04.479502-1000

System time and RTC time are both now wrong, -10 hours,

Edit time standard in /etc/adjtime to LOCAL:

Code: Select all

root@live:~# date
Wed Nov  1 12:50:51 HST 2017
root@live:~# hwclock
2017-11-01 22:50:52.374192-1000

System time is still wrong, RTC is correct.

Fix system time to be same as RTC time:

Code: Select all

root@live:~# hwclock --hctosys
root@live:~# date
Wed Nov  1 22:53:06 HST 2017
root@live:~# hwclock
2017-11-01 22:53:09.890005-1000

Time is now correct: time standard (localtime/Windows), time zone, system and hardware clocks.

Peasyclock takes care of the above time zone and time standard issues with a gui, but still leaves the last part of system time and rtc time out of sync. Also, fixes should be added to include back Etc/UTC in the zone selection list after first use, and have it read the /etc/adjtime value instead of only displaying local default.

And to make Dog automatically adjust to NTP server, can install NTP client package ntpdate. That would probably be a nice default package for DDog, DebLive and StretchDog to have. Antix also includes the small ntpdate instead of full ntp package.

[fredx181]

Hi All, did some further testing PeasyClock and did WITHOUT changing /etc/adjtime manually first (so it's set to UTC (as by default)
My time in the BIOS is set to localtime, at this point around 11:08, the time is synchronized, but it's set to utc time (/etc/timezone has Etc/UTC)

Code: Select all

root@live:~# date 
Thu Nov  2 11:08:04 UTC 2017
root@live:~# hwclock 
2017-11-02 11:08:09.561478+0000

I will change to localtime now by setting up my timezone
Next I run peasyclock, (time shows 11:09, changed timezone to Europe/Amsterdam and click "Set" and then "Refresh"
Now the time showed in peasyclock is one hour later 12:09 and date and hwclock are around the same:

Code: Select all

root@live:~# date
Thu Nov  2 12:10:08 CET 2017
root@live:~# hwclock
2017-11-02 12:10:15.233405+0100

Then I changed the time in peasyclock to the correct time (one hour back) and clicked "Set", now current time is correct but the hardware clock is not synchronized with the current time:

Code: Select all

root@live:~# date
Thu Nov  2 11:11:04 CET 2017
root@live:~# hwclock
2017-11-02 12:11:09.295938+0100

Next I clicked "Set" next to "Update the hardware clock" ('Local time' is checked)
And the result is exactly as it should be IMO

Code: Select all

root@live:~# date
Thu Nov  2 11:12:07 CET 2017
root@live:~# hwclock
2017-11-02 11:12:13.420914+0100

Also the file /etc/adjtime did change to LOCAL (previous step did that, I think):

Code: Select all

root@live:~# cat /etc/adjtime
0.000000 1509617396 0.000000
1509617396
LOCAL

After reboot all was still fine

Fred

[rcrsn51]

Hi Fred:

Here (I think) is a source of confusion. You would expect that the "hwclock" command would simply show you what's currently in the BIOS clock.

But it doesn't always. Sometimes, it shows the BIOS time adjusted according to some time zone.

The only real test is to reboot and check the BIOS. Then let Stretch start.

In my tests, that works correctly without doing a PeasyClock hwclock update.

Here's where it gets really confusing. If you take your laptop to a different time zone and reset the zone, it looks like Stretch auto-changes the BIOS clock to match the new zone.

Windows won't like that because it will now have a mismatch between its local time and zone.

[fredx181]

The only real test is to reboot and check the BIOS. Then let Stretch start.

In my tests, that works correctly without doing a PeasyClock hwclock update.

When I do NOT manually set /etc/adjtime to LOCAL and do NOT update the hardware clock in Peasyclock, the BIOS time is wrong after reboot (one hour earlier than local time)
But if I do as I wrote in my previous post, the time in the BIOS is correct local time.
Or am I now confused about what could be the confusion ?

Fred

[rcrsn51]

I am assuming that your original BIOS time was correct - your local time like Windows would have it.

Are you saying that Stretch immediately changed that on its own?

In my tests, if you start with a clean install where the initial zone is Etc/UTC, that does NOT happen.

[fredx181]

I am assuming that your original BIOS time was correct - your local time like Windows would have it.

Yes it was.

Are you saying that Stretch immediately changed that on its own?

Yes, I thought that's normal, what --systohc does.
To be sure I just tested using different timezones and also with UTC, and every time the BIOS time changed.

In my tests, if you start with a clean install where the initial zone is Etc/UTC, that does NOT happen

So, after configure with peasyclock you have to go in the BIOS to change the time ?
Maybe it's machine dependent (I'm on a 10 years old HP compaq 6710b)

Fred

[rcrsn51]

Yes, I thought that's normal, what --systohc does.

But who is running that command? If the BIOS clock is already correct, there is no reason to run it.

To be sure I just tested using different timezones and also with UTC, and every time the BIOS time changed.

That was my observation above. If you are in LOCAL mode and change zones, Stretch WILL change the BIOS clock. I guess it thinks that it is doing you a favour.

So, after configure with peasyclock you have to go in the BIOS to change the time ?

On the initial setup, I don't have to. The BIOS clock is still correct. Nothing has changed it.

I suspect that the result of this discussion will be "find whatever works for you and stick with it". But I think that PeasyClock covers all the possibilities.

Or stay in UTC mode and all the problems go away.

[fredx181]

fredx181 wrote:
Yes, I thought that's normal, what --systohc does.
rcrsn51 wrote:
But who is running that command? If the BIOS clock is already correct, there is no reason to run it.

As you know, peasyclock runs it when updating hardware clock but there's also initscript that runs at boot and shutdown '/etc/init.d/hwclock.sh'
Btw, as it is by default Etc/UTC and having the BIOS time set to localtime works OK for me, but it's better to set your timezone to avoid little problems e.g sending mail to someone and the "sendtime" doesn't correspond with the receiver's time.(also I read about similar problems when using Twitter)

I suspect that the result of this discussion will be "find whatever works for you and stick with it". But I think that PeasyClock covers all the possibilities.

Yes, anyway for me Peasyclock is really an improvement compared to the build in "Setup Timezone" menu entry (in most 'Dogs')

Fred

[rcrsn51]

I quit. If Stretch is going to update the hardware clock through hwclock.sh at the end of a session, then doing it through PeasyClock should be irrelevant.

This is why clock management in Puppy appears to make more sense. It isn't doing any of that stuff behind the scenes.

In any case, I posted v1.1 above. It also updates the file /etc/timezone, in case that's important.

[wiak]

I don't use a timeserver normally, but I use the typical series of clock-setting commands that begin with checking BIOS clock is okay, sets the timezone, and end with clock set to local time correctly. That works fine unless some other program or OS incorrectly (or OS init/shutdown script?) sets or resets the BIOS clock inappropriately.

Of course, if any playing with the time or timezone happens whilst OS is running and anythin in the OS ever then calls up hwclock.sh and changes the BIOS time then all is mucked up. In my opinion nothing in the OS should ever automatically change the BIOS time except as a Menu choice to adjust the time or you are asking for trouble. Anway, if hwclock.sh is being called during system scripts and if that does reset BIOS clock then I'll be hunting these system scripts down and taking that out on my own system at least cos I certainly don't need or want that.

wiak

[fredx181]

I don't use a timeserver normally, but I use the typical series of clock-setting commands that begin with checking BIOS clock is okay, sets the timezone, and end with clock set to local time correctly. That works fine unless some other program or OS incorrectly (or OS init/shutdown script?) sets or resets the BIOS clock inappropriately.

Of course, if any playing with the time or timezone happens whilst OS is running and anythin in the OS ever then calls up hwclock.sh and changes the BIOS time then all is mucked up. In my opinion nothing in the OS should ever automatically change the BIOS time except as a Menu choice to adjust the time or you are asking for trouble. Anway, if hwclock.sh is being called during system scripts and if that does reset BIOS clock then I'll be hunting these system scripts down and taking that out on my own system at least cos I certainly don't need or want that.

wiak

I can't see what's the problem. The BIOS time gets changed only if you configure the timezone and/or choose to use LOCAL or UTC, but anyway for info, to disable the initscript hwclock.sh:

Code: Select all

insserv -r hwclock.sh

EDIT: Another way (probably better) to disable hardware clock access, see here:
http://murga-linux.com/puppy/viewtopic. ... 093#973093

Fred

[dancytron]

Sorry, I got busy and didn't get a chance to do any testing on the time issue.

I will try to get to it tonight sometime . . .

[wiak]

I can't see what's the problem. The BIOS time gets changed only if you configure the timezone and/or choose to use LOCAL or UTC, but anyway for info, to disable the initscript hwclock.sh:

Code: Select all

insserv -r hwclock.sh

Fred

Ah, Fred, your statement may be true for many but not for all. Linux is a system often used by tinkerers, who sometime adjust time for some reason or other - if they happen to switch off without thinking of returning time back to normal then hwclock.sh will mess up their time settings on next reboot since actual BIOS time changed. Probably explains why I rarely have to reset time on Puppy systems, if Puppy leaves BIOS clock well alone, but has often been a problem with the dogs. which knowing now of hwclock.sh being called unexpectedly maybe solves that issue for me at least. I also don't see the point of the OS system files regularly re-writing back an already satisfactory BIOS clock time.

wiak

[fredx181]

Hi wiak, yes you got a point, I remember also that my BIOS time had changed unexpectedly (with earlier dogs and other (debian based) live distros).
Obviously the Debian default is "HWCLOCKACCESS=yes" can be set in /etc/default/hwclock, so another way to disable (probably better way than I described earlier) is to set it to "HWCLOCKACCESS=no"

Fred

[jd7654]

Obviously the Debian default is "HWCLOCKACCESS=yes" can be set in /etc/default/hwclock, so another way to disable (probably better way than I described earlier) is to set it to "HWCLOCKACCESS=no"

I think it would be better to retain hwclock access, as RTC does need to be written to and updated from system time because the RTC drifts pretty badly. The true Time is from a Stratum 1 NTP server, that is the master. The RTC is just a temporary approximation and storage of time for offline use.

Just about all Linux distros come build in with some network time function. Most major distros use systemd-timesyncd. Puppy has Psync. And you can always install/run ntp. Heck, even Windows does network time and updates RTC. I always have any OS I'm running do NTP updates to hardware clock.

Since DebLive-Stretch is a Dog construction set, it does not necessarily need to have network time included, you can choose what you want.)or not) But maybe one of the full Dog recipes or the release StretchDog should have a network time component. Either ntpdate client like antiX distro has, or the full ntp package.

[fredx181]

Since DebLive-Stretch is a Dog construction set, it does not necessarily need to have network time included, you can choose what you want.)or not) But maybe one of the full Dog recipes or the release StretchDog should have a network time component. Either ntpdate client like antiX distro has, or the full ntp package.

The way it is now with every type of build and StretchDog, is that after reboot the BIOS clock has NOT changed (if you don't take any action by e.g. changing timezone or any command for setting the hardware clock). I think it should be like that, so if you boot e.g. puppy afterwards, the time is still OK.
Tried booting a build with ntp installed and the consequence is that the BIOS clock has changed after reboot, which IMO is exactly not how a live system should behave.

Fred

[rcrsn51]

At the risk of beating this exercise to death, I did the following:

I set up a machine with Stretch and Puppy. In addition to /etc/adjtime, Puppy uses its own file /etc/clock with values localtime|utc. I have a puppified version of PeasyClock that recognizes this setting.

I set both systems on UTC. Once everything was synced, I could switch back and forth correctly and I could change timezones seamlessly.

Here's the trick: because Stretch is going to auto-update the BIOS clock at the end of a session, it's essential that you have the zone and local time set correctly BEFORE you quit. Otherwise, the clock will be messed up for other systems.

Then there is no need to run a PeasyClock hardware clock update in either system, unless the time has drifted.

Update: I checked Stretchdog32 - it comes up in LOCAL mode. But if I switched it to UTC and set everything else with PeasyClock BEFORE restarting, there were no problems.

I have posted v1.2 above with a Mode button that gives you quick access to /etc/adjtime.

Update: I switched one of the Stretches to LOCAL. The current time was correct, so I rebooted. It came up correct. The BIOS now had the local time.

I then booted another Stretch. It was still on UTC, so the time was wrong. I switched it to LOCAL, fixed the time and rebooted. Both Stretches came up correct.

I fixed the Puppies the same way.

I then tried switching timezones in LOCAL mode. This also worked except that the Stretches sometimes needed a reboot before the tray clock would sync up.

Update: Here is what happens in a dual-boot system with Windows XP, assuming that the Linux systems are in LOCAL mode.

If your computer has NOT changed zones, Windows will be happy with the local BIOS time.

If you HAVE changed zones, Windows will see the right local time but the old zone. After you get Windows synced up, it will write the correct local time for the new zone back to the BIOS. The Linuxes will be happy with that.

----------------------