How to upgrade Vanilladpup to latest version?

[Feek]

I've been using VanillaDpup for about 2 months now and since then I've been seeing similar things as described by Duprate. These are time shifts (always 2 hours back).
There is win7 on the hard drive. All Linux OS´s have local time set (Fatdog64, VanillaDpup64, Fossapup64).
Sometimes the time shift happens, sometimes not. If it happens, I solve it by setting it manually in the given OS (including win7).
I don't know the cause, maybe VanillaDpup is innocent in this.

[dimkr]

I've been using VanillaDpup for about 2 months now and since then I've been seeing similar things as described by Duprate.

Is it configured to use local time and uses the correct time zone?

[dimkr]

Please do not set my hardware clock without asking permission.

Do you click "Ok" or just close the "Quick setup" wizard?

[Duprate]

Hi! I use vanilladpup-x86-9.x.x from alpha and beta to the latest, vanilladpup-x86-9.0.47. I believe that during all this time I have tested and collaborated with the developer as much as possible. When I do tests, I usually write down everything I do so I can redo it, go back to the original state, or discover any mistakes I made. When quoting about the date change, I had already exhaustively done all the necessary tests (CMOS internal battery charge, all systems configured as UTC, then all as Local), I restarted countless times each one of the systems and checked the time and it was all right. The problem of changing the internal time by +3 hours, only happens with the UPPER VERSIONS of Vanilladpup 9.x.x.
As everyone, including myself, must already be annoyed with this subject, I won't talk about it anymore! We'll put the matter over and forgotten.

Regarding a possible unofficial update of the vanilladpup-x86-9.0.47 version that could be done by the user (since it is based on Debian), it was not my intention to change this version to a higher one, but to update some packages, if possible and for security reasons if necessary.....

Good morning everyone, and sorry for anything that didn't go well!

[Feek]

I've been using VanillaDpup for about 2 months now and since then I've been seeing similar things as described by Duprate.

Is it configured to use local time and uses the correct time zone?

The file "clock" in /etc contains: HWCLOCKTIME='localtime'
Symbolic link "localtime" in /etc points to the right location in /usr/share/zoneinfo/...
The file "timezone" in /etc contains: Etc/UTC
Typing "date" in the terminal shows CEST (central european summer time), which is correct (UTC/GMT +2 hours).
Would be the solution to use syncing with a time server in all my linux systems?

[dimkr]

The problem of changing the internal time by +3 hours, only happens with the UPPER VERSIONS of Vanilladpup 9.x.x.

Like I said, 9.2.x has changes incompatible with 9.1.x and 9.0.x, hence the difference in version numbers: don't expect them to behave exactly the same. The change to UTC (rather than localtime) as the default in 9.2.0 (as requested by some users) will cause a 3 hour time drift if in you're in GMT +3 and currently using local time, unless you change the default from UTC to local time in the "quick setup" wizard or the timezone change tool.

Would be the solution to use syncing with a time server in all my linux systems?

ConnMan synchronizes the clock using NTP, so Vanilla Dpup shouldn't be affected by hardware clock changes, as long as you chose the correct timezone. If you set the wrong time and reconnect to the internet, you'll see this synchronization in action.

[Feek]

ConnMan synchronizes the clock using NTP, so Vanilla Dpup shouldn't be affected by hardware clock changes, as long as you chose the correct timezone. If you set the wrong time and reconnect to the internet, you'll see this synchronization in action.

I just tried it. It works as you say. Nice.

---------------------------------------------------------------------------------------------------------------------------------------------
I got an idea. At the beginning I created a savefolder and during about 2 months of using VanillaDpup I created 4 backups using the Pupsave Backup utility. They were all continuously created from the same savefolder. The timezone and hardware clock type settings (use local time) were done at the beginning using the quick setup wizard and never changed.
I checked the /etc/clock in each of them and strangely 2 of those backups have HWCLOCKTIME='localtime' in /etc/clock and 2 of them have HWCLOCKTIME='utc'. As I say, I haven't changed this setting since the beginning. I have no idea how this is possible.

[dimkr]

Maybe your system clock trouble will be gone soon, once the post-https://github.com/puppylinux-woof-CE/woof-CE/pull/3493 kernels are built. This fix will go into 9.2.20.

[dimkr]

@Feek @williams2 @Duprate Does 9.2.20 solve your clock-related issues?

[Feek]

@Feek @williams2 @Duprate Does 9.2.20 solve your clock-related issues?

It seems not, unfortunately.

I tried to check the times in different places:

• reboot -> go to bios and check the time -> time is ok

• boot into Fossapup64 -> the time after typing "date" in the terminal and the time in the tray are correct; after typing "hwclock" the time is +2 hours (which surprised me a bit)

• then reboot -> go to bios and check the time -> time is ok

• boot into VanillaDpup -> after typing "date" and "hwclock" in the terminal the times are correct

• then reboot -> go to bios and check the time -> time is -2 hours

[Feek]

@Feek @williams2 @Duprate Does 9.2.20 solve your clock-related issues?

It seems not, unfortunately.

I ended up settling on a configuration that uses UTC on all my linuxes.
So far I have followed the opinions and recommendations that the setting when using "localtime" will display the correct time in both windows and linux. However, I've also read that it doesn't always work 100%.
I very rarely use windows7 on my hard drive and I don't go online anyway (could be risky). The problem with unwanted time drifts wasn't actually in the confrontation of windows vs. linux, but between multiboot multiple linuxes (from the PL family) with the configuration that uses localtime.
So I hope the setting that uses UTC will work fine. I will also have to accept that windows will probably show the wrong time, but I don't mind.