Create Debian 9 (Stretch) minimal ISO similar to DebianDog

[rufwoof]

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.

[anikin]

If Windows must co-exist with Linux:

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

[rcrsn51]

@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.

[fredx181]

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

[fredx181]

*** 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

[rcrsn51]

@Fred: Don't bother - I'm happy with the program now as is. The final v1.2 is posted above.

[fredx181]

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

[rcrsn51]

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?

[fredx181]

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: Select all

TZ='Australia/South' date
Sat Nov  4 23:51:54 ACDT 2017

Fred

[jd7654]

...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.

[jd7654]

New mklive-stretch:
mklive-stretch script

Didn't try latest yet but assume it is the same:

My favorite Dog now is ChromeDog.(probably favorite lightweight OS too) Openbox, PcManFM and Chrome gets the job done. I build from template/recipe in gui and then modify. I also make ChromeDog without Chrome...meaning I take it out of the packages, and instead use a premade squashfs chrome module added back in at the end. This way it easy to update ISO to latest Chrome just by dropping in the new SFS.

I noticed that if you use a config file, it does not contain the specification of the zz*squashfs modules from the template. I added back in at the end, but not sure if there is anything else that is customized and not in the config file? Anyway, some notation and/or functionality to include any zz*squashfs modules from Full Dog templates in the config output to feed back to the input would be nice.

[rcrsn51]

I noticed that DebLive-Stretch 32-bit does not write the RTC from system time on shutdown

Mine does. I can see the message at shutdown and can confirm it in the BIOS.

But my Stretch-Live is an old build.

[jd7654]

I noticed that DebLive-Stretch 32-bit does not write the RTC from system time on shutdown

Mine does. I can see the message at shutdown and can confirm it in the BIOS.

Withdrawn. I mainly use 64-bit. Did a few tests on another 32-bit machine and saw that, but cannot reproduce here on 64-bit machine with 32-bit StretchDog.

[fredx181]

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.

Can you (or anyone) try attached deb package ? (remove fake .gz)
(has dependencies: python-requests and ntpdate)

It uses python script that can detect your time zone and change automatically, see here:
https://github.com/cdown/tzupdate
To only show your timezone (not change), run:

Code: Select all

tzupdate.py -p

Included in /root/Startup there's script "start-ntpdate" that waits until there is a network connection and then runs tzupdate.py and ntpdate.
Also it disables hardware clock access by setting "HWCLOCKACCESS=no" in /etc/default/hwclock. (so doesn't unexpectedly change the time in the BIOS)
So getting the correct time for your time zone depends ONLY on a network connection, doesn't matter how the BIOS clock is set or how /etc/adjtime is configured
Rebooting or restarting X will activate.
Of course this is experimental and probably conflicts with other time(zone) setting tools.
Don't know how well tzupdate.py works (if it can detect all timezones), but for me it works OK.

EDIT: On a "Full" type of build this will take only 2MB ( but much more on a minimal build without python installed)

EDIT2: New version v1.1.0 attached, changes:
- Instead of startup script in /root/Startup there's included initscript /etc/init.d/start-tzupdate, which calls /usr/local/bin/start-ntpdate
This is to support multi-user (normal user needs root access to modify timezone and time (so a script in e.g. /home/puppy/Startup wouldn't work, the initscript runs (as root) before login stage)
- Added menu entry in System category "Enable/Disable Auto Timezone", so automatic detecting/changing timezone and time can be disabled or enabled as desired (default after install is enabled), see pic below.
- After install the automatic timezone change will be activated directly (not needed to reboot or restart X)
EDIT: However when using xfce4-panel, a X restart might be needed to display the correct time.

Added this new version also to custom repos, so can be installed with Synaptic or apt-get.

Fred

[rcrsn51]

I did a clean install of Stretch-Live. The default mode was UTC and the zone was Etc/UTC, so the local time was wrong. (My hwclock was set to Greenwich time.)

I installed tzupdate and peasyclock. I restarted X to launch the startup script.

It located my correct zone and auto-adjusted the date.

PeasyClock had everything correct.

I didn't bother to do a manual hwclock update, but I'm assuming that it would have worked correctly.

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

I booted another machine that was in LOCAL mode and manually reset it to a different time zone.

I installed and ran tzupdate. It detected my correct zone and set the time. Using PeasyClock, I updated the hwclock in LOCAL mode.

On a reboot, everything was correct.

Very nice.

[fredx181]

Thanks!
To clarify about what I meant with "conflicting with other time setup tools":
Having tzupdate installed, changes the behaviour when setting up time using Peasyclock.
Setting the time in peasyclock would normally write to the hardware clock at reboot/shutdown, done by initscript hwclock.sh, but it doesn't in case tzupdate is activated because hwclock.sh initscript is disabled ("HWCLOCKACCESS=no" in /etc/default/hwclock)
Also setting 'Mode' to LOCAL or UTC makes in fact no difference, because tzupdate doesn't care about that (just reads time from ntp.ubuntu.com according to the timezone).

Not sure yet, but I'm thinking of adding another script to the package (with menu entry e.g. "Enable/Disable tzupdate") that gives the user choice of (de)activating tzupdate, so that standard behaviour can be restored.

Fred

[rcrsn51]

Also setting 'Mode' to LOCAL or UTC makes in fact no difference, because tzupdate doesn't care about that (just reads time from ntp.ubuntu.com according to the timezone).

You're right of course, But if I was dual-booting, I might want to update the hwclock in the right mode for the other OS's.

Last night we switched from daylight saving to standard time. It was seamless.

I have posted v1.3 final above with a few more features.

[fredx181]

Time goes on and on... some say it exist only in our imagination, but the last pages of this thread prove that it it really exists, lol.

Thanks Bill, peasyclock version 1.3 added to repos.

Fred

[jd7654]

Can you (or anyone) try attached deb package ? (remove fake .gz)
(has dependencies: python-requests and ntpdate)

Test of a minimum configed DebLive-Stretch Full Dog, install tzupdate .deb+dependencies failed. Ran it on StretchDog with already updated apt-get and installed OK, pulling in dependencies.

Worked fine. I had the test setup to boot with incorrect time and zone in default LOCAL mode. When tzupdate ran it fixed system time for HST.

I still prefer the default action of most Linux distros to update RTC whenever they perform a NTP time sync, so I added "hwclock --systohc" at end of start-ntpdate script. Works for me.

I know you prefer the "live" operation and not touching the RTC, and that is your prerogative as the distro builder.

[belham2]

Time goes on and on... some say it exist only in our imagination, but the last pages of this thread prove that it it really exists, lol.

Thanks Bill, peasyclock version 1.3 added to repos.

Fred

Hi Fred & everyone,

Is Peasyclock going to help with Trinity's scatterbrains when it comes to keeping time?

I've given up on it, actually, and just expect that every time i use Trinity (applies to the Ddogs too) that I'll be fixing the time correctly at boot. For Trinity as an example, despite using it's own "Trinity Control Center" to set the correct timezone & time, saving and rebooting, it still changes it either an hour forward and/or back of the real time----depending on its mood, lol. I know the bios is correct, because I check and because all the other pups & such are showing correct time. And everything is set correctly in /etc/adjtime and /etc/timezone, so.......

I just have real problems in Trinity and in most all of the Ddogs. I've used and tried "dpkg-reconfigure tzdata', "date --set H:M:S"--followed by---"date --set YEAR-MONTH-DAY", have even went so far (like jd above in the previous msg) to try "hwclock --systohc". Nothing works with these scatterbrained Trinity(s) and some of the Ddogs. Quite honestly I am so used to it now that I expect it is 'normal' behavior and if it doesn't happen, i get worried.

The pic below: I am in Trinity32 right now, correct time has been set numerous times (and I've checked in etc to make sure adjtime, and timezone are correct), rebooted, but after reboot it still screws up. It is showing OUR (Amsterdam) time as an hour ahead (right now, it is 19:13, but it is showing 20:13.....lol, it is maddening. Next time, too drive me crazy, when I boot in it will probably show an hour earlier-----and cause my head to spin around a few times like the Exorcist

Is Peasyclock the answer to these woes in Trinity/Ddogs??