Peppermint OS
Support => Advanced Topics => Topic started by: VinDSL on August 21, 2016, 12:07:39 pm
-
Not really blowing steam, but here's a weird tale for you * ...
* I doubt that any of you running Dell OptiPlexs, but if you're experiencing the following, please let me know.
I bought a Dell OptiPlex 7010 SFF refurb, a few weeks ago, on the official Dell site. It was a low spec machine, sooo ...
Immediately, I replaced the 4GB RAM with 16GB, replaced the 120GB HDD with a 256GB SSD, and added a nVidia GT 710 video card.
After re-configuring the hardware, I flashed the BIOS with the latest version (critical upgrade according to Dell). Then, I installed Peppermint 7 in UEFI/Secure Boot mode.
A week or so later, I installed winders 10 pro, to see how it would interact with Peppermint 7.
And, even later, I installed the Ubu-Gnome 16.10 dev build.
Thus, I have Peppermint/Ubu/winders triple-booted on this machine -- all in UEFI mode (I disabled Secure Boot).
Somewhere along the line, I realized my RTC system clock setting (in BIOS) was gaining a few hours after every boot. I thought it might be a weak CR2032 battery, so I replaced it -- same problem.
Working on the assumption that the mobo was bad, I replaced it yesterday with one I bought on eBay (slighly newer model -- GXM1W instead of WR7PY) . Gotta love these Dells ! I got a fully tested pull, from a working system, from a top-rated dealer on eBay for USD $20 with free shipping. LoL ! :D
As soon as the package arrived, yesterday, I tore my Dell 7010 down to the bare chassis, and replaced the mobo.
I spent the next few hours running Dell diagnostics, and everything came back 100%.
Last night, before going to bed, I checked the system time, and guess what ?!?!? The RTC clock had gained 8 hours, again.
I might mention that only the hours are affected. The date is stable, the minutes and seconds remain accurate -- only the hours change.
Now that I knew it wasn't the mobo, I put an Admin password on BIOS. That seemed to work for awhile, but a few hours later I checked the time in BIOS, and it was several hours ahead, again.
Today, I decided to do an A-B-C comparison between booting into Peppermint/Ubu/winders.
As long as I'm booting/restarting winders, the RTC clock maintains the same time. However, when I boot/restart Peppermint or Ubu, the hours on the RTC jump ahead.
My considered opinion is that something in the Ubu UEFI config is janky, and changing the hours on my RTC system clock. And, that's on two different mobos.
Heh ! I'm gonna have to think about this one for awhile ... :-\
Luckily, it doesn't affect the operation. Linux sucks in the NPT time during the boot process, but winders is a different animal. winders 10 by default only pulls in the NPT time, and checks it against the RTC clock once a week (I finally figured that one out).
Yet another reason not to boot into winders 10, eh what ???
-
Hrm ...
I was re-reading the message, looking for typos, when a thought occurred to me.
I wonder if the RTC would remain the same, if I disable the NTP (internet time server sync) feature in Ubu ?!?!?
I need to run, but I'll check it out when I get back later.
Any other ideas ?!?!? :)
-
I read somewhere that Unix/Linux systems read time differently from Windows and can cause issues in dual boot configurations
I came across this it may or may not be relevent to your problem
On Windows, the system RTC clock is traditionally kept in local time. In Unix and Linux, it's traditionally kept in UTC, and /etc/localtime is used to indicate the current timezone so that the displayed time is correct.
These two worldviews collide in dual-boot configurations, because there's only one RTC. Usually you tell Linux to assume that the RTC is local time (because Windows can't be told). This varies from one Linux to another, but since Mint is like Ubuntu you can probably set UTC=no in /etc/default/rcS. Then you can set the clock to local time in Windows and Linux will leave it alone after that.
Graeme
-
WoW ! Thx Graeme !!! Live n' learn, eh what ? :D
Okay, here's how it started out in Peppermint 7 ...
╭─vindsl@Boogaloo-5 ~
╰─➤ timedatectl status
Local time: Sun 2016-08-21 15:22:28 MST
Universal time: Sun 2016-08-21 22:22:28 UTC
RTC time: Sun 2016-08-21 22:22:28
Time zone: America/Phoenix (MST, -0700)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no
I ran this command ...
╭─vindsl@Boogaloo-5 ~
╰─➤ timedatectl set-local-rtc 1
And, this command ...
╭─vindsl@Boogaloo-5 ~
╰─➤ timedatectl set-ntp false
Now it looks like this ...
╭─vindsl@Boogaloo-5 ~
╰─➤ timedatectl status
Local time: Sun 2016-08-21 15:29:46 MST
Universal time: Sun 2016-08-21 22:29:46 UTC
RTC time: Sun 2016-08-21 15:29:46
Time zone: America/Phoenix (MST, -0700)
Network time on: no
NTP synchronized: yes
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode can not be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
So, now Peppermint is sync'ing via the RTC clock only, theoretically.
I'll do the same over in winders 10 (different process, of course) and we'll see how that goes.
You've introduced me to a whole world of possibilities to obsess on.
Thx, again ...
-
Aha ! Check this out ...
I was getting ready to reboot into winders, and I checked the RTC one last time.
╭─vindsl@Boogaloo-5 ~
╰─➤ timedatectl status
Local time: Sun 2016-08-21 16:26:04 MST
Universal time: Sun 2016-08-21 23:26:04 UTC
RTC time: Sun 2016-08-21 23:26:04
Time zone: America/Phoenix (MST, -0700)
Network time on: no
NTP synchronized: yes
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode can not be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
Look at my RTC time.
Something has reset the little bastard, in the last few minutes. :-[
Guess I'll be doing forensics in Peppermint, before tackling winders 10.
This is a real corker !
-
Okay, I sat here and watched this machine, while eating dinner/supper.
I reset the RTC to local time in BIOS, booted into Peppermint, and after 10 minutes or so, something resets the RTC clock from local time to UTC.
I guess it's trying to be helpful. ;D
For some reason, even though I've reconfigured this machine to use the RTC hardware clock -- as confirmed by 'timedatectl' & 'hwclock' status reports -- something or another still thinks it should reset my RTC clock to UTC time.
I'll keep poking around. Probably a damn kernel bug or something weird like that ...
-
This varies from one Linux to another, but since Mint is like Ubuntu you can probably set UTC=no in /etc/default/rcS. Then you can set the clock to local time in Windows and Linux will leave it alone after that.
Somehow I glossed over it, the first time, but you found the fix, Graeme !
I pulled up the '/etc/default/rcS' file and looked around, but didn't see anything 'UTC' in there, so I went my merry way.
After beating around the bush for a couple of hours, I knew I was overlooking something, so I re-read your message and checked the rcS man ...
LINK: http://manpages.ubuntu.com/manpages/xenial/man5/rcS.5.html
According to the man:
NOTE
The EDITMOTD, RAMRUN and UTC variables are no longer used. The UTC
setting is replaced by the UTC or LOCAL setting in /etc/adjtime, and
should have been migrated automatically. See hwclock(5) and hwclock(8)
for further details on configuring the system clock.
I went ahead and added the UTC variable to rcS file:
#
# /etc/default/rcS
#
# Default settings for the scripts in /etc/rcS.d/
#
# For information about these variables see the rcS(5) manual page.
#
# This file belongs to the "initscripts" package.
# okay mofo, take this !
UTC=no
<SNIP>
And, it automagically migrated to the adjtime file (as the note stated):
0.000000 1471824225 0.000000
1471824225
LOCAL
I've been on here for about a hafl-hour now, and the RTC clock hasn't changed:
╭─vindsl@Boogaloo-5 ~
╰─➤ timedatectl status 127 ↵
Local time: Sun 2016-08-21 18:30:46 MST
Universal time: Mon 2016-08-22 01:30:46 UTC
RTC time: Sun 2016-08-21 18:30:46
Time zone: America/Phoenix (MST, -0700)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode can not be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
Thx for helping me think this through. I owe you one !!! :)
-
Now, I'm backward engineering the fix. :D
Interesting bug: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1541532
Guess I'll quit goofing around and go fix Ubu-Gnome now ...
-
~ cool
RTC clock is staying the same in Ubu-Gnome, too !
Invoked:
timedatectl set-local-rtc 1
Then added 'UTC=no" in:
vindsl@StaPuft:~$ sudo gedit /etc/default/rcS
Bada bing ! Bada boom !
vindsl@StaPuft:~$ cat /etc/adjtime
0.0 0 0
0
LOCAL
vindsl@StaPuft:~$ timedatectl status
Local time: Sun 2016-08-21 19:58:27 MST
Universal time: Mon 2016-08-22 02:58:27 UTC
RTC time: Sun 2016-08-21 19:58:27
Time zone: America/Phoenix (MST, -0700)
Network time on: yes
NTP synchronized: no
RTC in local TZ: yes
Warning: The system is configured to read the RTC time in the local time zone.
This mode can not be fully supported. It will create various problems
with time zone changes and daylight saving time adjustments. The RTC
time is never updated, it relies on external facilities to maintain it.
If at all possible, use RTC in UTC by calling
'timedatectl set-local-rtc 0'.
-
Thx for helping me think this through. I owe you one !!!
You don't owe me anything, you worked most of it out yourself, glad you got it sorted :)
I actually heard about this on a tutorial on Freedom Penguin although you're the only one I've known to experience this issue,
I've had quite a few Linux/Windows dual boot setups in the past and never experienced it myself or at least not that I noticed.
Graeme
-
I'm not a gambling man, but ...
I'd be willing to bet I'm the only one that replaced the motherboard trying to fix the problem, too. LoL ! :D
Oh, well, never hurts to have a spare mobo. It's proprietary, and they'll disappear from the market, sooner or later.
Besides, Dell parts are dirt cheap on eBay -- pennies on the wholesale dollar.
BTW, I don't know what kind of thermal paste Dell uses, between the CPU and cooler, but that stuff was like silicone seal. I had a hell of a time getting it off -- had to use paint thinner and a rag. I'm sure it was acting more like an insulator. At least they could have used some Jap frag (http://www.ebay.com/itm/SEKISUI-5760-Double-sided-Thermal-Adhesive-Tape-for-Heatsink-100mm-X-200mm-/171112683534) ...
-
Bwahahahaha !
I guess Dell applies thermal paste the Kentucky Way ... :D
https://youtu.be/TnyoJtv9Cx0
-
UPDATE: It's been a few days now ...
I have Peppermint, Ubu-Gnome, and winders 10 syncing to their respective NTP servers, and the RTC clock is remaining set to the correct local time.
Just saying ...
-
Great stuff, and another thing learnt.
-
Just for reference here's a page dedicated Ubuntu time management with a section on dual boot conflicts
https://help.ubuntu.com/community/UbuntuTime (https://help.ubuntu.com/community/UbuntuTime)
Graeme
-
Just for reference here's a page dedicated Ubuntu time management with a section on dual boot conflicts
https://help.ubuntu.com/community/UbuntuTime (https://help.ubuntu.com/community/UbuntuTime)
The funny thing is, this all started as another one of my quirks -- time, so called.
I'm a 'detail guy' and I can't stand inaccurate timepieces. That's all I was concerned with -- the damn RTC clock in this Dell being several hours advanced, after every reboot. It bugged me soooo much that I went to the trouble of procuring a new mobo and installing into my 1-month old Dell refurb.
Now, that's a true obcession. LoL ! :D
After having the same prob with the new mobo, it narrowed down the possibilities considerably, so it wasn't a total waste of time n' money. But, it did leave me scratching my head, until you steered me down the right path.
Who would have guessed that Linux machines summarily *assume* that you have your RTC set to UTC ?
And, who would have guessed that THIS Dell allows Linux to reset the RTC to UTC time ?
I have three Dell machines -- a 7010 desktop PC, and two D-series laptops. This 7010 is the only one that allows Linux to sync the RTC to UTC time. My *guess* is -- with this PC being a 'business machine' -- it's made to sync/change/reset the hardware RTC to NTP server time (either local network NTPs or over the web).
We have 10s of 1000s on these Dell 7010s in my workplace. So, maybe they're a breed onto themselves. I've never owned another computer, in my life, that's allowed the OS to change the RTC clock. Evidently, some do and some don't, hence the articles you happened to run across.
If you look in the BIOS on this Dell 7010, there are whole sections devoted to allowing your IT department (for instance) to manipulate every aspect of these machines. That way, they can maintain hundreds or thousands of these Dell PCs over their WAN, rather than having an IT at every property, and having to make changes to every PC, in every office, in every location, et cetera.
It only makes sense that syncing the RTC to whichever NTP would be included in the BIOS feature-set. At least, that's my take on the situation. ;)
Thx, again, for the heads-up, Graeme !
-
You know, I was just thinking ...
Now that we came up with a solution to the time 'problem', maybe we should move this thread to a public area.
Thoughts ???
-
Considering it contains what some may see (if they don't read it all) as advice to swap battery/motherboard it may make more sense to wait until it comes up again.
My 2 cents .. but my other 2 cents (hey I'm rich) agrees with you so I'm easy either way (?)
-
Yeah, it would definitely need to go into an 'advanced' sub with appropriate warnings, up front.
I don't think any of us have run across this before, in the wild, but it's not a unique situation, otherwise there wouldn't be so many meta search engine results, covering every UNIX/Linux distro imaginable.
I was thinking it might be a good way to suck some 'advanced' users into the site, that wouldn't normally visit here, but that could be a double-edged sword, too.
Kinda provides a good example of how well the team works together, too, without giving away any 'house' secrets for future releases -- things that normally go in this area of this forum.
It's an interesting read, in lots of ways, IMO.
I'm good with whatever you decide -- watch n' wait is okay, if you think that's best. ;)
-
It **has** come up before, and it was YOU that suggested the fix ;)
https://forum.peppermintos.com/index.php/topic,4096.0.html
and it (UTC) came up in the beta test
https://forum.peppermintos.com/index.php/topic,3479.0.html
but not lately .. I thought it may have been fixed by one of the many tzdata and ntpdate updates that I've seen come down .. obviously not.
-
LoL ! just like Hansel & Gretel trying to find their way home by following breadcrumbs.
https://youtu.be/dOupRXFRHHY
Ever feel like a puppeteer ? I sometimes do ...
Okay, we'll investment in breadcrumb navigation and see how it goes. 8)
-
FIVE MONTHS LATER
As an ancillary note ...
The 'fix' is still working fine on my Dell OptiPlex 7010 SFF business desktop machine. And ...
I'm now in the process of baking a 'new' Dell Latitude E6430 professional laptop, and had to employ the same fix (above).
Same church, different pew ! This dual-boot Peppermint 7 / winders 10 Pro Latitude was acting the same as the OptiPlex.
Thanks again, Graeme ;)
-
You're more than welcome Vin and lets be fair you did most of the hard graft yourself :)
Graeme
-
You did most of the hard graft yourself :)
Heh ! I'm like a Harley, sometimes.
You gotta kick me to start ... ;D
-
You're more than welcome Vin and lets be fair you did most of the hard graft yourself :)
Graeme
Welcome to 2019
Had to haxor the RTC settings on my 'new' Dell Optiplex 7010 i7 dual-booter. This time, Peppermint 9 / winders 7 Pro.
I didn't even make it 24 hours, before the changing clock times were driving me crazy >:(
Thanks, again. Graeme!
-
Just ask Microsoft to do it 'properly' .. I'm sure they'll listen, they're heavily user focussed.
-
Ho, ho, hehe, hahahahahahaha. STOP IT!
My sides hurt. I can't breathe... :D
-
FIX IS STILL WORKING IN 2020
HP Compaq 8000 Elite SFF Business PC - Pep10/Win10 dual-booter.
I'm just saying...