Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Mon 20 Nov 2017, 23:08
All times are UTC - 4
 Forum index » Advanced Topics » Puppy Projects
Create Debian 9 (Stretch) minimal ISO similar to DebianDog
Moderators: Flash, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 54 of 58 [861 Posts]   Goto page: Previous 1, 2, 3, ..., 52, 53, 54, 55, 56, 57, 58 Next
Author Message
wiak

Joined: 11 Dec 2007
Posts: 371
Location: not Bulgaria

PostPosted: Thu 02 Nov 2017, 16:11    Post subject:  

Fredx181 wrote:
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:
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
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 2588
Location: holland

PostPosted: Thu 02 Nov 2017, 16:36    Post subject:  

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

_________________
Dog Linux website
Back to top
View user's profile Send private message 
jd7654

Joined: 06 Apr 2015
Posts: 256

PostPosted: Fri 03 Nov 2017, 02:14    Post subject:  

fredx181 wrote:
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.
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 2588
Location: holland

PostPosted: Fri 03 Nov 2017, 06:21    Post subject:  

jd7654 wrote:
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

_________________
Dog Linux website
Back to top
View user's profile Send private message 
rcrsn51


Joined: 05 Sep 2006
Posts: 11721
Location: Stratford, Ontario

PostPosted: Fri 03 Nov 2017, 09:49    Post subject:  

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.

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

Last edited by rcrsn51 on Sat 04 Nov 2017, 12:29; edited 7 times in total
Back to top
View user's profile Send private message 
rufwoof

Joined: 24 Feb 2014
Posts: 2163

PostPosted: Fri 03 Nov 2017, 10:23    Post subject:  

rcrsn51 wrote:
rufwoof wrote:
I just run # dpkg-reconfigure tzdata

But which mode are you in? UTC or LOCAL?

I just stick with UTC. All my multiboot *nix's are setup the same and use ntp so booting each/any just syncs to the same time ... for instance my OpenBSD comes with utc/ntp setup automatically (along with firewall etc.) https://www.openbsd.org/faq/faq8.html#OpenNTPD

I don't have/use Windows at all.
Back to top
View user's profile Send private message 
anikin

Joined: 10 May 2012
Posts: 963

PostPosted: Fri 03 Nov 2017, 11:00    Post subject:
Subject description: Force Windows to use UTC
 

If Windows must co-exist with Linux:
Quote:
Make Windows use UTC

Note: This method was not initially supported on Windows Vista and Server 2008, but came back with Vista SP2, Windows 7, Server 2008 R2 and Windows 8/8.1.

To make MS Windows calculate the time from the hardware clock as UTC.

Create a file named WindowsTimeFixUTC.reg with the following contents and then double click on it to merge the contents with the registry:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation]
"RealTimeIsUniversal"=dword:00000001

Note: Windows Time service will still write local time to the RTC regardless of the registry setting above on shutdown, so it is handy to disable Windows Time service with this command (if time sync is still required while in Windows use any third-party time sync solution):

sc config w32time start= disabled

read more here: https://help.ubuntu.com/community/UbuntuTime
Back to top
View user's profile Send private message 
rcrsn51


Joined: 05 Sep 2006
Posts: 11721
Location: Stratford, Ontario

PostPosted: Fri 03 Nov 2017, 15:28    Post subject:  

@Fred: I have redone the instructions on page 52. This now works with every scenario I can think of.

Can you try it with your setup? No promises. Wink
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 2588
Location: holland

PostPosted: Fri 03 Nov 2017, 15:39    Post subject:  

I'd be happy to test, but what/how exactly ?
(I ask because I was already satisfied how peasyclock works for me, from the way I tested earlier)

Fred

_________________
Dog Linux website
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 2588
Location: holland

PostPosted: Fri 03 Nov 2017, 16:18    Post subject:  

*** Update mklive-stretch ***

One small change that can be useful for someone:
- Added question yes/no at start of build to run Xterm after the install process.
To be able to run one or more more commands (in the chroot), e.g. synaptic to install more packages or any other command.

New mklive-stretch:
mklive-stretch script

Fred

_________________
Dog Linux website
Back to top
View user's profile Send private message 
rcrsn51


Joined: 05 Sep 2006
Posts: 11721
Location: Stratford, Ontario

PostPosted: Sat 04 Nov 2017, 06:19    Post subject:  

@Fred: Don't bother - I'm happy with the program now as is. The final v1.2 is posted above.
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 2588
Location: holland

PostPosted: Sat 04 Nov 2017, 06:33    Post subject:  

fredx181 wrote:
I'd be happy to test, but what/how exactly ?
(I ask because I was already satisfied how peasyclock works for me, from the way I tested earlier)


Hi rcrsn51, I guess you mean testing without setting the hardware clock in peasyclock and using LOCAL mode, so:

- My BIOS clock is set to correct localtime, booting a fresh Stretch-Live, run Peasyclock.
- Click the 'Mode' button (that's nice addition, btw) and change UTC to LOCAL
- Choose my timezone > Set > Refresh, the time displayed in peasyclock has changed
- Change it to my correct local time > Set
That's all I did and after reboot my BIOS time was still correct local time and all fine in Stretch

P.S. at the point of posting I see your message, v1.2 already added to repos, thanks again!

Fred

_________________
Dog Linux website
Back to top
View user's profile Send private message 
rcrsn51


Joined: 05 Sep 2006
Posts: 11721
Location: Stratford, Ontario

PostPosted: Sat 04 Nov 2017, 07:29    Post subject:  

Thanks. That's how it works for me, and the same sequence works in UTF mode.

Here is something I still don't understand. If you change the timezone, the date command immediately adjusts the local time to the new zone. How is it doing that?
Back to top
View user's profile Send private message 
fredx181


Joined: 11 Dec 2013
Posts: 2588
Location: holland

PostPosted: Sat 04 Nov 2017, 09:49    Post subject:  

rcrsn51 wrote:
Here is something I still don't understand. If you change the timezone, the date command immediately adjusts the local time to the new zone. How is it doing that?


I don't know, somehow monitored, or maybe the date command can read the configured timezone by itself, just like it can read the TZ variable, e.g:
Code:
TZ='Australia/South' date
Sat Nov  4 23:51:54 ACDT 2017


Fred

_________________
Dog Linux website
Back to top
View user's profile Send private message 
jd7654

Joined: 06 Apr 2015
Posts: 256

PostPosted: Sat 04 Nov 2017, 14:15    Post subject:  

fredx181 wrote:
...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


Just a few more notes on my usage:

Tried with the latest antiX 17 64-bit based on Stretch,(in frugal install) and it seems to match your preferred behavior, as it does not write RTC from system time on shutdown.

I installed ntpdate, the same small client ntp package that antiX uses, but it does not adjust time on startup in StretchDog like it does in antiX. In antiX, time sync is invoked in the if-up.d/ process, same place and files that get installed in Dog, but it didn't work. I had to put a link to ntpdate-debian in Startup and then it worked fine with Ethernet and Frisbee. There is some additional delay in Dog where the ntpdate default location fails to acquire time sync from the network. But that change did not work with PeasyWifi, as there is some additional delay in that tool coming up, so adding a 30sec delay to call ntpdate made it work.

For myself and probably most desktop users, the single time sync at startup is fine.(similar to Puppy Psync) Others may want continuous time sync and full ntp package, or systemd-timesyncd instead.

Last edited by jd7654 on Sat 04 Nov 2017, 17:32; edited 2 times in total
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 54 of 58 [861 Posts]   Goto page: Previous 1, 2, 3, ..., 52, 53, 54, 55, 56, 57, 58 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Puppy Projects
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0811s ][ Queries: 12 (0.0206s) ][ GZIP on ]