Discuss the 5.2.10 release

[The Raven]

Since upgrading to VirtualBox 5.2.10 I am getting the following error messages in the Kernel log
every time I start a Virtual machine.

kernel: [ 306.296314] AssertLogRel /home/vbox/vbox-5.2.10/src/VBox/VMM/VMMAll/PGMAllPhys.cpp(2345) VBOXSTRICTRC pgmPhysReadHandler(PVM, PPGMPAGE, RTGCPHYS, void*, size_t, PGMACCESSORIGIN): PGM_HANDLER_PHYS_IS_VALID_STATUS(rcStrict, false)
kernel: [ 306.296317] rcStrict=2624 GCPhys=00000000f0804030


For each virtual machine start they are repeated approx. 480 times, so the kernel log is filled with almost 1000 messages.

I have checked the kernel logs from before I installed 5.2.10 and no error messages like this were produced.

I have tried the latest build (5.2.11-122245) but still receive these error messages.

The messages only appear when the virtual machine is started - once running no more appear and guest operation seems unaffected.
It happens for both my Windows 7 guest and all my debian based guests.

Host is running Debian 9 (stretch) with the 4.15.11 kernel.

[socratis]

This was not a release upgrade, but only a "maintenance release" an the minor release number changed from 5.1.34 -> 5.1.36.

ingo2,
There is one solution. Do not use saved states. There's no point in beating a dead horse. So, use whatever last version of VirtualBox was working for you to properly shutdown the VM. Then upgrade your VirtualBox version. Start from a cold boot the VM.

Anything else involving saved-states won't get any of our attention, we've been repeating that in every way possible. You may not "like" it, but I don't "like" to see message after message after message about the same thing.

The solution is there looking you in the eye. Use it.

[klaus]

Saved state should work - if we'd get useful reports (and effectively this needs passing the .sav and .vbox file to Oracle - no, doesn't need making public, this can be sensitive as it's VM memory content) about such breakages we'd fix this if possible.

[socratis]

From what I know they should work between minor releases, and these are not always guaranteed, but if it's within the same major release, they should work. Otherwise it's a bug. So, restoring from 5.2.x to 5.2.10 and that is failing; that's a bug. Restoring from 4.3.x to 5.2.10 and that's failing; that's expected.

This is as different as hardware "presented" to a VM as possible. (well, you could be using 3.x I guess...). A restore from such a different "architecture" is not only going to have good chances to fail, it's a guaranteed way to fail!

[BrianG61UK]

Saved state should work - if we'd get useful reports (and effectively this needs passing the .sav and .vbox file to Oracle - no, doesn't need making public, this can be sensitive as it's VM memory content) about such breakages we'd fix this if possible.

I don't understand why anybody uses saved states.

It's like those twits that always hibernate their laptops and wonder why everything's still not working right after they un-hibernate when they've been told to try restarting it.

Get things set up so that rebooting the VM isn't a major problem for you. You know you're gong to need to at some point, modern computers are like that.

[socratis]

I don't understand why anybody uses saved states.

I've used them a couple of times, even live ones, but there were very, very specific reasons for my choice (testing commands at a specific stage of a really long complicated process, modifying the system with unknown/questionable outcome, etc). And mind you, never, ever across VirtualBox versions, even minor ones.

It's never a good idea to have a long-term strategy that is based on either saved states, or snapshots.

And don't get me wrong, I *do* use snapshots. Just a single snapshot per VM, with the minimal state changes, a virgin snapshot if you will. I'm testing let's say an upgrade on a VM, and if things *don't* go as planned, I see the snapshot as an "Undo". If this *do* go as planned, I immediately merge the snapshot, leaving only one, virgin snapshot.

[Jacob Klein]

Every day, I refresh the following two links, to see if the "Windows" versions still say "Size: 0"
https://download.virtualbox.org/virtualbox/5.2.10/
https://download.virtualbox.org/virtualbox/5.1.36/

Every day, I come back to this thread, looking for a real and full explanation, that provides the technical details of the delay.

Every day, I'm met with a bit of disappointment, and so I try to remain patient.

The community sure would appreciate another update on this.

Edit:
I do appreciate some of the devs hopping in and giving good hints. I guess the best hint/reason we have, currently, is from Klaus:

If the 5.2.11 test build works for you then everything is perfect. We just know that for some people it isn't (and if that's the case one gets complaints about unsigned drivers), and ultimately that's the reason why 5.2.10 is still in the works.

I wonder if this means that the Windows 5.2.10 build, will be a build that is built AFTER some of the 5.2.11 Test Builds

I hope you guys are making progress. We're clearly rooting for you!

Thanks,
Jacob Klein

[socratis]

FYI, 'ingo2' has opened a new ticket for the restore problem: #17712: ed stat Guest VM with OS/2 does not resume from saved state.

Edit: According to a developer, the issue has been fixed in the latest Test Builds: Fix is in 5.2 r122179 and 5.1 r122180. Trunk in r122177.

[Armando]

Regarding snapshots and saved states, I'd like to quickly share my bit of experience (hoping I won't fall under the off topic's ax :] ).

I consider snapshots very useful, at least as fast "undos" when experimenting something in a VM and also as some kind of "virgin backups" of VMs, as Socratis himself suggested.

I use saved states regularly because I quite like to open a VM very quickly and get it's environment just as I left it, with all needed programs already open and running and set as I need. I know sometimes a saved state can get broken, but after all it's not such a big risk; provided, obviously, all sensible open files are properly saved (maybe also outside the VM) before closing the VM (which should be done always, anyway).

About upgrades, I usually upgrade only from a major release to another. Maybe it's because the host system has been the same for many years or maybe I've just been quite lucky, but in most cases I had no problems at all in opening VMs with snapshots and saved states.

[socratis]

About upgrades, I usually upgrade only from a major release to another.

There are two kinds of non-official-release options; the Test builds and the Development snapshots:

• Test builds include code that *is* going to make it to the next official release. Proven code, so much so, that you can actually file a bug report against a Test build. Think of them as intermediate releases in between the official releases. Things are not "complete" in terms of the User Manual for example, but the main components are.
  
  They do *not* include new or untested code, they mainly contain bug fixes, such as the bug with the restoration of saved-state VMs (see above and tickets #17711 and #17712), or a crash for specific Win95/WinME bootable media if there's no VT-x (#17690, I expect that one to be addressed in the next test builds batch). If you were bitten by these bugs (or others that you've been notified about), I would strongly urge you to try the test build. Unless you prefer to crash...
• Development snapshots on the other hand, is what you'd call an alpha, or a nightly build. They include code that might, or might not, make it in the next release. For example, the new user interface in 5.2? Well, that was in the Development snapshots for months before it became a reality. Why? So that adventurous, developers and power users could check it out and provide feedback to a long brewing feature.
  
  Development snapshots are the ones that they use to create the next Beta cycle for example. You cannot file a ticket against a Dev. build. Only on the developer's mailing list, or on IRC.
  
  For example, one thing that's "brewing" right now is getting rid of the HiDPI as an option and VirtualBox figuring out by itself whether you're in HiDPI mode (or even higher). Obviously you do not get to know if or when it's going to make it in the next release. I believe not even the developers could answer that one with 100% certainty, because it's not solid enough yet (I got seriously bitten by that one, thankfully I had backups ).

[ingo2]

@ socratis
Many thanks for the information on test builds!
Unfortunately for 5.1 branch it's not available and patches are not available separately.
It really would be helpful if meaningful and detailed changelogs were made available, so one can decide whether a test build already addressed the issue.

[socratis]

Unfortunately for 5.1 branch it's not available and patches are not available separately.

Fix is in 5.2 r122179 and 5.1 r122180. Trunk in r122177.

Wait until the next test build, or switch to 5.2.x. You'll have to switch eventually...

It really would be helpful if meaningful and detailed changelogs were made available, so one can decide whether a test build already addressed the issue.

Too much hassle for something that may change tomorrow. Also, there might be a chance that the changelog in the user manual of the test build, might contain that information. Chapter 15...

[Armando]

There are two kinds of non-official-release options; the Test builds and the Development snapshots: ...

I thank you for your kind and clear explanation about releases.
My habits about upgrades come from many years of dealing with technology, during which I gradually developed the feeling that once you have something which is working well ( = doing what you need in a reasonably good and reliable way) you should be very careful in... touching it. Specially when the alleged "upgrade" is not expected to bring fixes or features which are actually significant to your needs. That is, significant enough to be worth the risk of incurring in those problems that always can arise when you put hands on some... running engine. :]

This feeling of mine is not just about VBox, but VBox also contributed to its consolidation when, years ago, a VBox upgrade messed up my host's NIC (?) in such a bad way I had to totally reinstall the host OS and programs.

This does not mean, obviously, no upgrades at all. It just means very careful and spaced ones. :]

[socratis]

once you have something which is working well ( = doing what you need in a reasonably good and reliable way) you should be very careful in... touching it.

+1. Also known as "If it ain't broke, don't fix it".

One of the most knowledgeable volunteers that I know, has been running 4.3.x for the longest time on his production VMs (File servers, Active directory, etc.), not because he doesn't want to keep up with VirtualBox (he does run the Test and Development builds on his own computer), but because he wants to "let sleeping dogs lie".



Definition of "Let sleeping dogs lie":

• Avoid interfering in a situation that is currently causing no problems, but may well do so as a result of such interference.

[The Raven]

Regarding the Changelog for both 5.2.10 and 5.1.36, is there any (good) reason why
there is no mention of the fact those releases included fixes for 11 CVE's ?