Discuss the 5.2.10 release

[michael]

Discuss the 5.2.10 release here.
You can download the release here.
Mainly a regression-fix release for 5.2.8.

[mipri]

Hello Michael,

at the moment, the Windows version is an empty file.

Michael

[socratis]

@mipri
Did you notice the following in the Downloads page?

Important: the Windows package below is known to be 0 bytes. For technical reasons this package will be made available later.

[Jacob Klein]

For technical reasons, may I ask for more details about the technical reasons for the delay?
I mainly ask, because BOINC sometimes includes VirtualBox installer versions, and I'd like to know details on what has happened with 5.2.10 for Windows.

PS: I have tested 5.2.11 Test Build 122125, and 5.1.37 Test Build 122139... and they both work great on Windows 10 v1803 Build 17134.1.

[ingo2]

Host system is Debian-Stretch 64-bit.
Guest-VM is OS/2 4.5.2 was running smoothly since years.
The guest has survived in saved state since June 2015 und undergone all upgrades starting with Debian-Jessie and VBox 4.3.30.

After upgrading VBox 5.1.34 to 5.1.36 it was no longer possible to preserve the VM in saved state when host system gets rebooted. It starts up, but stalls after a some seconds. Displayed error message is

Code: Select all

Für die virtuelle Maschine OS2 konnte keine neue Sitzung eröffnet werden.

The VM session was aborted.

Fehlercode:NS_ERROR_FAILURE (0x80004005)
Komponente:SessionMachine
Interface:ISession {7844aa05-b02e-4cdd-a04f-ade4a762e6b7}

As the guest had to be rebooted anyhow, I decided to perform the upgrade to VBox 5.2.10. Unfortunately this version shows the very same beheaviour:
VM does not survive in saved state when host is rebooted or shutdown. Wihout shutting down the host I can put the VM into saved state and resume is fine as expected. I tested that several times and as long as I do not shutdown the host, all is fine.

Appears, there is some information which is not saved and thus not persistent when host is rebooted.

Corresponding vbox.log does not tell any crash, it just ends with theese lines:

Code: Select all

.....
00:00:02.262518 HGCM: restoring [VBoxSharedFolders]
00:00:02.262527 HGCM: restoring [VBoxGuestControlSvc]
00:00:02.262531 HGCM: restoring [VBoxGuestPropSvc]
00:00:02.262535 HGCM: restoring [VBoxDragAndDropSvc]
00:00:02.262538 HGCM: restoring [VBoxSharedClipboard]
00:00:02.262551 Starting host clipboard service
00:00:02.262557 Shared clipboard: Initializing X11 clipboard backend
00:00:02.264198 Shared clipboard: Starting shared clipboard thread
00:00:02.264310 VMMDev: Guest Additions information report: Interface = 0x00010004 osType = 0x00040000 (OS/2, 32-bit)
00:00:02.264498 GUI: UISession::sltAdditionsChange: GA state really changed, notifying listeners.
00:00:02.264516 GUI: UIMachineViewNormal::adjustGuestScreenSize: Adjust guest-screen size if necessary.
00:00:02.264521 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners.
00:00:02.264524 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=13
00:00:02.264531 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners.
00:00:02.264534 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=13

When the guest resumes fine (host not rebooted) the log continues like this:

Code: Select all

....
00:00:03.335492 VMMDev: Guest Additions information report: Interface = 0x00010004 osType = 0x00040000 (OS/2, 32-bit)
00:00:03.335710 GUI: UISession::sltAdditionsChange: GA state really changed, notifying listeners.
00:00:03.335728 GUI: UIMachineViewNormal::adjustGuestScreenSize: Adjust guest-screen size if necessary.
00:00:03.335732 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners.
00:00:03.335735 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=13
00:00:03.335743 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners.
00:00:03.335746 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=13
00:00:03.338926 Changing the VM state from 'LOADING' to 'SUSPENDED'
00:00:03.338980 Changing the VM state from 'SUSPENDED' to 'RESUMING'
00:00:03.339245 Changing the VM state from 'RESUMING' to 'RUNNING'
00:00:03.339263 Console: Machine state changed to 'Running'
00:00:03.351432 Display::handleDisplayResize: uScreenId=0 pvVRAM=00007fcd7414f000 w=1152 h=864 bpp=32 cbLine=0x1200 flags=0x0
00:00:03.351461 GUI: UIFrameBufferPrivate::NotifyChange: Screen=0, Origin=0x0, Size=1152x864, Sending to async-handler
00:00:03.355933 GUI: UIMachineView::sltHandleNotifyChange: Screen=0, Size=1152x864
00:00:03.355958 GUI: UIFrameBufferPrivate::handleNotifyChange: Size=1152x864
00:00:03.355963 GUI: UIFrameBufferPrivate::performResize: Size=1152x864, Directly using source bitmap content
00:00:03.853583 GUI: UIMachineViewNormal::adjustGuestScreenSize: Adjust guest-screen size if necessary.
00:00:03.856318 GUI: 2D video acceleration is disabled
00:00:03.856337 GUI: HID LEDs sync is not supported on this platform
00:00:03.867569 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5
00:00:08.351415 PCNet#0: The link is back up again after the restore.

I do attach both logs with suffix crash and ok for both cases

[ingo2]

Additional information:

checking /var/log/vbox-install.log reveals

Code: Select all

make V=1 CONFIG_MODULE_SIG= -C /lib/modules/4.9.0-6-amd64/build SUBDIRS=/tmp/vbox.0 SRCROOT=/tmp/vbox.0 INSTALL_MOD_PATH= INSTALL_MOD_DIR=misc modules_install
make -C /usr/src/linux-headers-4.9.0-6-amd64 KBUILD_SRC=/usr/src/linux-headers-4.9.0-6-common \
-f /usr/src/linux-headers-4.9.0-6-common/Makefile modules_install
test -e include/generated/autoconf.h -a -e include/config/auto.conf || (		\
echo >&2;							\
echo >&2 "  ERROR: Kernel configuration is invalid.";		\
echo >&2 "         include/generated/autoconf.h or include/config/auto.conf are missing.";\
echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it.";	\
echo >&2 ;							\
/bin/false)
mkdir -p /lib/modules/4.9.0-6-amd64/misc
make -f /usr/src/linux-headers-4.9.0-6-common/scripts/Makefile.modinst
  mkdir -p /lib/modules/4.9.0-6-amd64/misc ; cp /tmp/vbox.0/vboxpci.ko /lib/modules/4.9.0-6-amd64/misc ; true /lib/modules/4.9.0-6-amd64/misc/vboxpci.ko ; true /lib/modules/4.9.0-6-amd64/misc/vboxpci.ko || true && true /lib/modules/4.9.0-6-amd64/misc/vboxpci.ko
  /bin/bash /usr/src/linux-headers-4.9.0-6-common/scripts/depmod.sh /sbin/depmod 4.9.0-6-amd64 ""

So there appears to be something wrong with my kernel configuration.
However, I never applied any modifications to my kernel, it is the stock kernel as currently active in Stretch. Includes the Spectre and Meltdown patches of course:

Code: Select all

$ uname -a
Linux tux 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux

and those messages show up alltogether 92 times in the log, which means since I have installed VBox the first time in Stretch.

VBox was running rock solid for almost 1 year now up to version 5.1.34 and the claimed "missing files" are present:

Code: Select all

$ locate autoconf.h
/usr/src/linux-headers-4.9.0-6-amd64/include/generated/autoconf.h
$ locate auto.conf
/usr/src/linux-headers-4.9.0-6-amd64/include/config/auto.conf

I have manually recompiled and installed the kernel modules another time by executing

Code: Select all

/usr/lib/virtualbox/vboxdrv.sh setup

which produces another set of 8 ERROR-entries in the log. All modules load fine.

[yogesh]

Is there any update / timescale for the Windows installation Binary being re-released.

It's all well and good pulling it due to it being a zero-byte file, but it has been five days now and there is still a dearth of updates from the Development team on this.

Time I think for you to post an update on what's happening.

Thanks.

[socratis]

Time I think for you to post an update on what's happening.

From what I've heard, the oven that they put the Windows-build in to bake, broke its flux capacitor. Since this is a specialized oven (of the infamous Mount Doom series), they have to travel to the Dagobah system to search for a suitable replacement.

They've run into some technical difficulties, but all is expected to be resolved promptly, "any time now"®™©...

[BrianG61UK]

But why can't we be told if it's safe to use 5.2.11 build which is available for Windows?

Why is the reason secret?

[socratis]

why can't we be told if it's safe to use 5.2.11 build which is available for Windows?

It is 100% safe to use the 5.2.11 builds.

Why is the reason secret?

Well, I could tell you, but then I'll have to ... "silence" you.

[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.

[Selin]

Does anybody met performance degradation after updating from 5.2.8 to 5.2.10?
With 5.2.8 average system load was 50-80%. Now it is almost always 100%.
The only change in host/guest - VirtualBox version.

[ingo2]

Unfortunately it seems that nobody is interested in my observation above.

Therefore I downgraded to my last proven version 5.1.34. Copying back my OS/2-VM in saved state from a backup - and all is fine. That VM was last shutdown 3 years ago and is now back and alive again!
So I supect there are some modifications in VBox 5.1.36 (and 5.2.10) which are not mentioned in the changelog/realease notes.

Now I have to downgrade the guest-additions in all the other VM's to keep them in line with the host version - or can I continue to use the 5.2.10 additions with 5.1.34 host?

[Martin]

Keeping saved states was never supported during a release upgrade, even when it worked sometimes.

[ingo2]

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

And changelog just metions

• VMM: Fixed missing NULL pointer check in MMIO code.
• Network: fixed VERR_INTNET_FLT_IF_NOT_FOUND when bridging to some adapters on
Windows hosts (possibly related bugs #15294, #15060, #13481)

Where the second item does not apply for Linux (Debian) hosts.

And - don't forget, the VM which sowed the problenm was last rebooted under Debian-Jessie with VBox 4.3.30 and since then has undergone a host upgrade to Stretch and all the VBox versions since then.
And now the VM does not survive a single shutdown of the host system? Of course I have shut down the VM and have returned to the Snapshot before testing, so there is no release upgrade involved - it anyhow does not preserve the VM in saved state over a reboot of the host.

And VBox 5.2.10 has exactly the same porblem. Maybe the "problematic and secret feature" has been backported?