Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

aboutblank · 2016-03-07 06:44

1) I believe I'm asking the obvious, but here goes: If one wants to test Q4OS using Virtual Box under Windows 7 (32 bit OS running on a 64 bit cpu), can one use the 64 bit version of Q4OS? Or must one use the 32 bit version of Q4OS, because the Windows 7 version is 32 bit?

(A related but different scenario would be testing Q4OS on a 64 bit PC using Windows 7 64 bit: I assume that using Virtual Box, one could test either the 64 bit or the 32 bit version of Q4OS?)

2) If I have installed Q4OS version 1.4.4 on my laptop, and the currently available version is 1.4.7. Is there an "easy" way to upgrade to the latter version (assuming both versions are the same 'bit version', e.g., 64 bit)? That is, can I accomplish the upgrade without having to reinstall application software that I had to hunt for, download, install, and configure, all over again?

(I've created 3 partitions for the initial Q4OS install, / (root), /home, and swap, if that helps to understand my setup.)

I'm more than happy to read about testing, and upgrade procedures, if someone could just point me in the right direction.

Thanks!

aboutblank
March 7, 2016

Dai_trying · 2016-03-07 09:00

I'm pretty sure you will need 64 bit os to host another 64 bit one, I recall trying to install (by mistake) a 64bit os onto 32bit system and it threw it out before installation even started, I guess the true test would be try it, but i think it would be a non-starter. And yes you are right a 64bit host will handle both 64 and 32 bit guest systems.
Usually if you run updates it will be almost identical to the current version, although there are a few minor differences. if you run from the command line

 sudo apt-get dist-upgrade

it should give you all distribution upgrades and report the current version of your installed system as 1.4.7 but I'm not 100% sure on this one, maybe the dev's could confirm this.
If you have downloaded installed and configured software from outside of the normal channels (ap-get/synaptic/software center) it would be almost impossible to say exactly what would happen if the rest of your system was updated, custom installed apps tend to be the cause of many issues for users of all distributions. I think the only way to find out would be to bite the bullet and cross your fingers

q4osteam · 2016-03-07 09:13

Dai_trying wrote:

... if you run updates it will be almost identical to the current version, although there are a few minor differences. if you run from the command line 'sudo apt-get dist-upgrade' it should give you all distribution upgrades and report the current version of your installed system as 1.4.7 but I'm not 100% sure on this one, maybe the dev's could confirm this.

Correct, we can confirm.

Dai_trying · 2016-03-07 09:26

Thank you and if you type in a console

get-q4os-version

it will display your current q4os version.

aboutblank · 2016-03-14 07:04

q4osteam wrote:

Dai_trying wrote:
... if you run updates it will be almost identical to the current version, although there are a few minor differences. if you run from the command line 'sudo apt-get dist-upgrade' it should give you all distribution upgrades and report the current version of your installed system as 1.4.7 but I'm not 100% sure on this one, maybe the dev's could confirm this.
Correct, we can confirm.
Thank you :>) and if you type in a console
get-q4os-version
it will display your current q4os version.

Thank you both!

Sorry for the delay, for some reason, I wasn't subscribed to my own topic!

aboutblank
March 14, 2016

Dai_trying · 2016-03-14 10:38

You are welcome

aboutblank · 2016-03-26 05:00

I tried:
sudo apt-get dist-upgrade
from a Konsole. The command appeared to run too quickly (a second or two), then reported "0" for all the categories it reports on (downloaded, etc.), then ended. Checking the OS version, it was exactly the same, so it appears that the upgrade failed.

Am I doing something wrong?

Thanks!

PS: I was wondering why I must always correct my clock's time setting when I (dual boot) back into Windows 7 after using Q4OS. Does anyone have a clue as to how to prevent this from happening? Thanks!

aboutblank
March 25, 2016

Dai_trying · 2016-03-26 10:32

dist-upgrade : Did you first run sudo apt-get update? this wil refresh the repository information ready for upgrading packages.

time: Could this be a failing battery? there is usually a small battery on the motherboard which maintains things like the time. I would suspect replacing that might prevent time change issues, I haven't experience an issue like this without hardware being the culprit.

JimW · 2016-03-26 13:50

Another possible reason for the time error is one I have ran into. If you have the wrong time zone in either os then it will show the incorrect time. Possibly you didn't select the time zone in Q4OS? Like I said, I have made that mistake!

Dai_trying · 2016-03-26 13:56

I haven't experienced JimW's problem before, but my systems clocks are always UTC and os's usually set their own time from it and never (normally) change it. But it is definitely worth checking.

bin · 2016-03-26 14:33

With regard to the time problem, I'm pretty sure q4os does some kind of time sync on shutdown - I'm sure I've seen a message to that effect after the GUI has gone but before power off...something like 'syncing to hardware clock........?????'
So, first of all, boot up and go to BIOS check to see what time it shows and if it is UTC.
Assuming it is correct current to your TZ, boot windows.
If the time is correct in windows check to see if you're using ntp to get time information and that your time zone is correct for your location and that it is set to adjust for daylight saving.
Reboot to Q4os. As suggested make sure you've got the correct regional settings and time zone - at command prompt type 'date' which should confirm everything is correct (or not).

If the problem still happens is it exactly an hour out or just a random value?
If random value then the advice given above about realtime clock battery applies.
If one hour then it's a daylight saving or Local vs UTC time thing.

q4osteam · 2016-03-26 15:35

The right configuration is to set BIOS time to UTC and in Q4OS set correct timezone:
$ sudo dpkg-reconfigure tzdata

Q4OS is syncing time from Internet to be accurate, but never changes the configured timezone.

aboutblank · 2016-03-27 08:04

Dai_trying wrote:

dist-upgrade : Did you first run sudo apt-get update? this wil refresh the repository information ready for upgrading packages.
time: Could this be a failing battery? there is usually a small battery on the motherboard which maintains things like the time. I would suspect replacing that might prevent time change issues, I haven't experience an issue like this without hardware being the culprit.

q40steam wrote:

The right configuration is to set BIOS time to UTC and in Q4OS set correct timezone:
$ sudo dpkg-reconfigure tzdata
Q4OS is syncing time from Internet to be accurate, but never changes the configured timezone.

Thanks to all who responded!

I'm fairly certain that the battery in the laptop is not my problem. If I stay in Windows and shutdown/reboot, the time is always correct.

I did not run the "sudo dpkg-reconfigure tzdata" command. When I installed Q4OS, I seem to recall selecting my time zone. What I did to observe the problem once again is this: I shutdown Windows (7) after observing the time, which was correct (being updated through the internet, intermittently). I entered the BIOS and observed the time, it, too, was correct. I noted that in the BIOS there is no indication of "UTC", just hour:minute:second and date. (Does "set BIOS time to UTC" mean to set it to Greenwich Mean Time, with "zero" offset?!) After observing the correct BIOS time, I rebooted into Q4OS and observed the time, it too, was correct. I checked the time zone, and it appeared not to be set (middle button click on the mouse didn't reveal my time zone, and when I went into the configuration, my time zone was not checked. So, I checked my time zone in the config, exited, and middle-button clicked on the time in the taskbar, and now my time zone was revealed, and was correct. All this time the taskbar clock displayed the correct time, even before selecting my time zone. After checking the time, I then rebooted, and immediately entered BIOS to check the time there. Now, the BIOS time had been changed to what I'm guessing is Greenwich Mean Time, as the time was 4 hours later than my time zone. (I am UTC-5, New York Time.)

[This last point is murky, as unfortunately, here we have been on Daylight Savings Time for a couple of weeks, but in London, they are setting their clocks ahead on this very night to Daylight Savings Time! Before they set it ahead, it was 2 am here and 6 am in London (4 hours later), but after the switch to Daylight Savings Time, we are back to 5 hours difference! - 2 am here and 7 am in London.]

It appears to me that Q4OS decided to set my hardware clock to Greenwich Mean Time on shut down, and (when it's running) it picks the time to display based upon what time zone I've told it I'm in. If I understand q4osteam, Windows should do the same thing, if I set my BIOS time to UTC+0, and tell it that I'm in time zone UTC-5?! It's a bit confusing, as on boot up, Q4OS leaves my time alone, and it displays correctly; it's only on shutdown and rebooting to Windows that I see the incorrect time in my taskbar!

I will play with this a bit, and report back.

Dai_trying, thanks for the suggestion, it was indeed my failure to run "sudo apt-get update" that was the problem. Once I did that, the update to the new version with "sudo apt-get dist-upgrade" ran without a hitch. I think it took about 20 minutes, and checking the version before and after, I went from version 1.4.4 to 1.4.8, as I recall. Thanks again!

aboutblank
March 27, 2016

aboutblank · 2016-03-27 08:57

aboutblank wrote:

I will play with this a bit, and report back....

I rebooted several times, and will describe what is happening with the on-board clock, as I understand it:

Windows 7 is set to update its displayed time through the internet. It does this once every seven days, so if the time is incorrect, one must right-click the task bar time, select internet time, and tell it to update "now". When Windows contacts the server successfully, the time is immediately updated. At some point, either during the update or when shutting down, Windows changes the time in the BIOS to the time it believes is correct for the time zone I'm in; it does NOT leave the time set to Greenwich Mean Time (UTC=0)!

When Q4OS boots up, it displays the same time as Windows has been displaying, correctly. HOWEVER, when shutting down, Q4OS apparently writes the time to the BIOS. At the present time, even though I am 5 hours earlier than Greenwich, it is writing the time as 4 hours earlier to the BIOS. For instance, if it's 3 am in New York "here" (I'm not actually in NY, but am in the same time zone!), and 8 am in Greenwich, upon shutdown and restart, my BIOS reports the time as 7 am, and Windows reports the time as 7 am when I boot into it. Because of the delay, Windows doesn't change this time to the correct 8 am unless I manually tell it to update the internet time.

After shutting down Q4OS and checking the BIOS, even though the time "here" is now 4 hours off, if I immediately reboot back into Q4OS, the time in the task bar is displayed correctly. Upon shut down, if I check the BIOS, it hasn't changed, it is still 4 hours different from "here" (and 1 hour different from Greenwich). Booting into Windows, I see the time as 4 hours off, and must monkey with the internet update to correct it, as described above.

Is there some way to tell Q4OS "NOT" to update the BIOS time upon shut down?! If it would just leave my BIOS alone, it appears that the time would display correctly in both operating systems, no matter which one I boot into! If anyone knows of a way to prevent a change to the BIOS time, I'd appreciate hearing about it!

Thanks again!

aboutblank
March 27, 2016

Last edited by aboutblank (2016-03-27 09:00)

bin · 2016-03-27 09:23

Looks like this is Debian Jessie rather than Q4OS. There's a script /etc/init.d/hwclock.sh which runs at shutdown which is responsible - I think.

There are some bug reports about this - not sure how to stop it running or the impact of doing so yet - hopefully the Q4OS team can come up with a solution.

Dai_trying · 2016-03-27 10:37

I just had a quick look at the file pointed out by bin and if you change the file /etc/default/hwclock so the line that reads "HWCLOCKACCESS=yes" becomes "HWCLOCKACCESS=no" (and don't forget to remove the # from the beginning of the line) it should prevent q4os (or debian really) from altering the hardware clock.
And the battery issue was aimed at desktop systems sorry

Last edited by Dai_trying (2016-03-27 10:38)

aboutblank · 2016-03-28 07:25

Dai_trying wrote:

I just had a quick look at the file pointed out by bin and if you change the file /etc/default/hwclock so the line that reads "HWCLOCKACCESS=yes" becomes "HWCLOCKACCESS=no" (and don't forget to remove the # from the beginning of the line) it should prevent q4os (or debian really) from altering the hardware clock.

Thanks again.

I did some experimentation and testing, and found that the 'HWCLOCKACCESS=no' made no difference, no matter which one of the two files was modified. (I tested each modification separately.) I even tried (separately) modifying the hwclock.sh file by remarking out the "unset TZ" line, but that didn't affect the end result, which was that on shutdown, Q4OS is changing the hardware clock by moving it ahead 4 hours (not 5 hours, as one might expect from the UTC-5 vs UTC-0 difference).

I am not sure what is going on during shutdown with the hwclock.sh script, or behind the scenes, but I think it is more complicated than the suggested modifications presume. For instance, if one detects a time error while running Q4OS, and corrects it by hand or by updating the clock over the internet, I'd think one would want that correction to be written to the hardware clock, much as Windows does at some point after a time correction. If the update were prevented from occurring, then the correction would presumably be lost, so that upon rebooting into Q4OS, the old time error would reappear. There is apparently something else happening, and how it comes up with a modification of exactly 4 hours is beyond me!

I sure hope that someone picks up on this, though admittedly, it does not seem to affect the time in Q4OS; it's only upon rebooting to Windows that I notice it! (And if Windows would be forced to sync the time with the time server upon reboot, I probably would not have noticed it! But it is scheduled to do that only every 7 days, so the time error is always immediately apparent.)

Finally, on another topic: Windows is able to show its version (the build number) on the desktop, in the lower right-hand corner. Is there a way of similarly showing the Q4OS version number on the desktop background?

Thanks to any and all for your help!

aboutblank
March 28, 2016

aboutblank · 2016-03-28 08:52

aboutblank wrote:

....Q4OS is changing the hardware clock by moving it ahead 4 hours (not 5 hours, as one might expect from the UTC-5 vs UTC-0 difference)

After checking the time for various locales at http://time.is/ (a great site, imho!), I realize that UTC time is not adjusted for Daylight Savings Time. So, where the difference in time between New York and London is 5 hours (both currently on Daylight Savings Time), the difference between New York and UTC time in London is only 4 hours. So (I think) that accounts for the 4 hour time difference between the time displayed in the task bar in Q4OS and the time posted to the BIOS clock on shutdown.

Now, if it were possible to "coax" Q4OS on shutdown to write the current 'task bar time' to the BIOS, rather than the UTC-0 time, that might solve the problem. Does anyone have an idea that I'd be able to test?

Thanks again.

aboutblank
March 28, 2016

Dai_trying · 2016-03-28 10:21

I'm no expert with windows, but wouldn't it be easier to tell windows that the system time is in utc and then they would all play nicely.

aboutblank · 2016-03-29 05:14

Dai_trying wrote:

I'm no expert with windows, but wouldn't it be easier to tell windows that the system time is in utc and then they would all play nicely.

There is no facility in Windows 7 (that I know of) to tell Windows to treat the time set in the BIOS as 'UTC'. It's quite simple, one sets one's local time in Windows and tells Windows what time zone one is in. Windows at some point updates the BIOS with the time shown in the taskbar (current local time).

That is, I've always used it that way. But come to think, if that were all there was to it, I'm not sure of the point of having to set the time zone! It might be convenient for someone who traveled a lot, I suppose, to get off the plane and merely adjust the time zone, and not the time itself.

It might be possible to set the time in Windows while one has 'London' set as one's time zone (not sure if 'UTC' is a choice!), and then adjust the time zone, which should change the time to local time. I will have to experiment with this, then report back!

Thanks for the idea!

aboutblank
March 29, 2016

aboutblank · 2016-03-29 08:52

aboutblank wrote:

It might be possible to set the time in Windows while one has 'London' set as one's time zone (not sure if 'UTC' is a choice!), and then adjust the time zone, which should change the time to local time. I will have to experiment with this, then report back!

After some testing, I'm reporting back. The bad news is that changing the local time zone to "UTC" (which *is* a choice in Windows 7), rebooting, then changing back to my local time zone made no difference. Windows writes the time shown in the taskbar (the local time) to the real time clock in the BIOS, not the UTC time. It makes no difference whether the 'local time' is the actual local time, or the UTC time.

The good news is that with some reading and experimentation, I've arrived at a solution to the problem.

To explain a bit, the problem occurs because, unlike almost any other operating system, Windows has traditionally, and still does, write the local time to the BIOS clock, not the UTC time. The reason for this is mainly "tradition", that is, it's been inherited from the early days of DOS through current systems. (It did not make much sense to early users, not connected to the internet or even a local lan, to be setting their BIOS clock to UTC time; they set it to local time, and DOS used that time when it needed to.)

Linux and other operating systems have apparently been using UTC in the BIOS since day 1, so it's natural for any new distribution to carry on that tradition. I can't speak for other distributions, but Q4OS appears to connect to the internet while on the sign-in screen, as I've noticed that the analog clock on that screen will show a random time, then suddenly jump to the correct time, as the time is synchronized. The OS must know from some config file what the local time zone is (or the last used one), and sets the clock accordingly. So, it's never a problem coming from Windows or wherever, no matter what the BIOS clock says, the time sync takes care of getting the correct time. The problem (for Windows) is that on shut-down (apparently), Q4OS writes the UTC-0 time into BIOS clock, as that's what it expects to see on the next boot up. When Windows gets to run on the next boot up, it reads the UTC-0 time and thinks it is the local time, and displays it in the taskbar.

As I noted in an earlier post, the default for Windows is to update the clock from an internet time server every 7 days. What I didn't realize (but probably should have) is that this behavior is programmed through the Task Scheduler (as are many, many other tasks Windows performs on a scheduled basis, that one often doesn't even know are taking place!). Hence, the solution was to find the appropriate entry in Task Scheduler for 'SynchronizeTime' (under Task Scheduler (Local) - Task Scheduler Library - Microsoft - Windows - Time Synchronization). Once I found the task, I went to "Triggers" and added a new one, "At startup", to run the time sync 'At system startup'. This worked like a charm! No matter what the time is in the BIOS, when Windows 7 syncs with the internet time server, the task bar time is corrected to local time. The first time I tested this, I signed on very quickly, and noted that the time changed while I was looking at the (wrong) time in the task bar, to the correct time. On my second test, I delayed signing in for about 15 seconds, and when I got to my desktop, the time had already been corrected to the current local time.

So, problem solved!

For completeness, I found a number of URL's dealing with this issue, which I'll list below. The solution I used is not the only one, there are at least two others, one dealing with a modification to some obscure configuration file in the bowels of Linux, the other with a Windows registry modification. The third, the one I used, uses a common Windows utility and seemed to me to be the least intrusive and least risky of the three, though it does require that one have internet access. Easy access to the internet is pretty common in most places nearby, so I elected to use the Task Scheduler solution, and it so far has worked flawlessly.

Here are those URL's:

Why Does Windows Keep Your BIOS Clock On Local Time:
https://blogs.msdn.microsoft.com/oldnew … /?p=37983/

Force Windows 8 to use UTC when dealing with BIOS clock:
http://superuser.com/questions/494432/f … bios-clock

IBM PC Real Time Clock should run in UT:
http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html

Does Windows 7 support UTC as BIOS time?:
http://superuser.com/questions/185773/d … -bios-time

Clock time is off on dual boot:
http://askubuntu.com/questions/169376/c … -dual-boot

That's all for now. Thanks to all who helped!

aboutblank
March 29, 2016

Dai_trying · 2016-03-29 11:58

Thanks for the info, I'm sure it will be a handy reference when it happens to other users. And your option certainly does seem like the easiest and least intrusive one, I haven't had this issue before, but I haven't really used windows much in the last 10 years or so...

Q4OS Forum

#1 2016-03-07 06:44

Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#2 2016-03-07 09:00

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#3 2016-03-07 09:13

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#4 2016-03-07 09:26

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#5 2016-03-14 07:04

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#6 2016-03-14 10:38

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#7 2016-03-26 05:00

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#8 2016-03-26 10:32

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#9 2016-03-26 13:50

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#10 2016-03-26 13:56

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#11 2016-03-26 14:33

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#12 2016-03-26 15:35

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#13 2016-03-27 08:04

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#14 2016-03-27 08:57

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#15 2016-03-27 09:23

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#16 2016-03-27 10:37

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#17 2016-03-28 07:25

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#18 2016-03-28 08:52

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#19 2016-03-28 10:21

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#20 2016-03-29 05:14

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#21 2016-03-29 08:52

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

#22 2016-03-29 11:58

Re: Two Questions re: 1) Testing under Virtual Box 2) Upgrade Procedure

Board footer