_0m0t3ur Posted June 9, 2018 Share Posted June 9, 2018 unRAID v6.5.2 Installed unRAID to USB. Boots fine. Pre-clearing disks. This is working fine. I've searched Lime-Tech and found various possible solutions to the two issues listed below. They usually require change to config files. Can someone recommend a good tutorial to get me started with working under the hood in Terminal? Note: I've found some Youtube tutorials on navigating in Linux using commands in Terminal such as, cd, ls, ls -l, ls -la, pwd. I'm getting a handle on navigating. The problem is that if something goes terribly wrong, I will be stuck in a hurry. So, at this point, I've decided that I am not putting any data on this system until I can get a better hold on how to resolve these kinds of problems. Two issues: a> Dynamix System Temp. 1> Perl installed via Nerdpack. 2> Then Dynamix System Temp installed. a. Worked. b. Now, only shows available drivers. Problem: sensors stopped showing. Just shows "Not used" as the only drop down option for sensors. b> BIOS Time shows a gain of 300 minutes (5 hours); no minutes gained, just hours. 1> Set BIOS time to current. 2> Reboot and load unRAID. 3> After some duration, reboot into BIOS. 4> BIOS time shows a 300 minute gain (no change in minutes) OR 1> Set BIOS time. 2> Allow BIOS to run for hours. 3> No time gain. Note: From my searching, looks like there is an issue where Linux causes the BIOS to advance time. Link to comment
Squid Posted June 9, 2018 Share Posted June 9, 2018 Time zone set accordingly in Date & Time settings? Link to comment
_0m0t3ur Posted June 9, 2018 Author Share Posted June 9, 2018 Just now, Squid said: Time zone set accordingly in Date & Time settings? Yes. I set the Time Zone in unRAID. Verified that unRAID shows the correct date and time. I also set the NTP to "yes" in unRAID. After booting into unRAID and then rebooting and entering BIOS, the issue is that the time in BIOS shows 5 hours advanced, only in "hours." That is, the minutes continue to match the atomic clock. I've searched the Web and apparently there is an issue in Linux where the Linux OS changes the BIOS time. By the way, since this is a used MB, I changed the CMOS battery, as I initially thought this might be the problem. Link to comment
Squid Posted June 9, 2018 Share Posted June 9, 2018 20 minutes ago, DoItMyselfToo said: Verified that unRAID shows the correct date and time. Maybe I'm missing something, but why would you care if the BIOS shows the wrong time so long as the OS reports correctly? Link to comment
_0m0t3ur Posted June 9, 2018 Author Share Posted June 9, 2018 For me, it's about trust. I have to trust that the system behavior is as expected. Also, I just bought this MB. I have a 30 day warranty. So, as I see things that are not making sense, I need to figure out whether they are a hardware issue, so I can RMA, or software, so I can find a fix and implement. Setting aside the time issue, what about sensors not accessible to my temp plugin? I literally, shut down my machine. Reapplied thermal paste to my heatsink/CPU and rebooted. Then the sensors stopped showing up. So, I search like crazy to find out that it looks like an issue where the temp sensor drivers are not be loaded by the kernal at boot. Pardon if my semantics is incorrect. Link to comment
Vr2Io Posted June 9, 2018 Share Posted June 9, 2018 This not a hardware fault ( even software fault ). It is about time / timezone management issue. Link to comment
_0m0t3ur Posted June 9, 2018 Author Share Posted June 9, 2018 Yeah, it's a GMT (UMT) issue vs real (local) time. Though, this can be resolved by making some changes in Linux to stop the behavior. Really, this post is about trying to get some direction to get in a better place with getting under the hood in unRAID. Because as soon as any little thing is not right, I am running down a rabbit hole of Google searches. Link to comment
pwm Posted June 9, 2018 Share Posted June 9, 2018 6 hours ago, DoItMyselfToo said: Yeah, it's a GMT (UMT) issue vs real (local) time. Though, this can be resolved by making some changes in Linux to stop the behavior. Linux can keep the hardware clock (the one you see in BIOS) in both UTC and local time. Normally Linux uses UTC for the hardware clock because UTC is the only time Linux uses internally - it's just when displaying a date/time that Linux applies any time zone information to the displayed time. You traditionally want to keep the hardware clock in UTC. It's only when you multi-boot between Linux and Windows that you want to force Linux to use local time with the hardware clock to avoid Linux and Windows fighting. In the end, it's not good to store local time in the hardware clock because for the large part of the world that has daylight savings in the summer, the hw clock has to be changed twice/year. Once the time needs to be moved forward, which creates a magical holes with a lots of seconds that never happened. And in the other direction the hw clock suddenly have to repeat the same time a second time. Only when the hw clock stores UTC time will it operate on continuous and strictly increasing time. Anyway - you say it's about trust. I don't see how trust is involved - just live with the fact that most BIOS do not understand time zones and so can't be relied on to display a meaningful local time. Link to comment
_0m0t3ur Posted June 9, 2018 Author Share Posted June 9, 2018 Anyway - you say it's about trust. I don't see how trust is involved - just live with the fact that most BIOS do not understand time zones and so can't be relied on to display a meaningful local time.I appreciate your lengthy reply. As for the “trust” part, please keep in mind that I am completely new to Linux. What I need is to have enough understanding to trust what is going on with unRAID. This will take time and some effort on my part. That is why I’m nit picking every little perceived discrepancy, issue, problem, alert, or what have you.As for unRAID, it’s awesome!Thanks again.Sent from my iPhone using Tapatalk Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.