Discuss the 6.0.4 release

[milen]

Hello!

Just upgraded on Windows 7.

For some reason there is no optical disc and it can not be added: the buttons are inactive. Here is the screenshot:

https://www.dropbox.com/s/dxkk2b47la133 ... 6.png?dl=0

Best Regards,
Milen

[mpack]

Is the VM running at the time? Note that being in a suspended state counts as running. Most changes to the VM settings are grayed out when the VM is running.

p.s. Please attach images as a local attachments, we should not have to visit the DropBox site to find out what your problem is.

[_nobody_]

I know that you, guys, hate mentioning of Vagrant (I do not like Vagrant myself).

But I have couple of Debian VBox VM designs (other VBox VMs are Debian preseed design), which are working with Vagrant. The bash and Vagrant scripts do work with latest VBox 5.2.26 seamlessly:

Code: Select all   Expand viewCollapse view

[vuser@fedora29-ssd lava-dispatcher-vm]$ ./importbox.sh
LinuxDistro Fedora
Here are the current components of the new host Fedora Lava test Debian VM:
VBoxExtpack 5.2.26
VBoxVersion with Revision 5.2.26r128414
VBoxVersion 5.2.26
Vagrant version Vagrant 2.2.3
VBox components in sync: VBoxExtpack=5.2.26 = VBoxVersion=5.2.26!
Usage: ./importbox.sh pathToBoxLocation boxName
[vuser@fedora29-ssd lava-dispatcher-vm]$

None of 6.0.x (6.0.0, 6.0.2 and 6.0.4) does work with Vagrant!

_nobody_

[socratis]

@_nobody_

Are you actually posting in the VirtualBox 6.0.4 specific thread, to mention that the Vagrant scripts do not work with 6.0.x?

Please do not repeat that, or next time your irrelevant post will find its way to /dev/null faster than you can say "scripts".

[Dave B]

Sound regression.

While realise ReactOS is still alpha, following mentioned in case also relevant for other OS.

Since upgrading to VirtualBox 6.0.4 noticed ReactOS guest no longer produces sound. Switching back to 6.0.2 fixes the issue.

- OS tested
Host: Linux Mint 19.1 Cinnamon -> Guest: ReactOS 0.4.11 RC-22
Host: Linux Mint 19.1 Cinnamon -> Guest: ReactOS 0.4.11 RC-33
Host: Linux Mint 19.1 Cinnamon -> Guest: ReactOS 0.4.11 RC-34
(also tested nested)
Host: Linux Mint 19.1 Cinnamon -> Guest: Linux Mint 19.1 Cinnamon -> Guest: ReactOS 0.4.11 RC-34

- VirtualBox versions tested
6.0.2-128162~Ubuntu~bionic_amd64.deb (host + guest)
6.0.4-128413~Ubuntu~bionic_amd64.deb (host + guest)
6.0.5-128682-Linux_amd64.run (guest)
6.0.97-128693-Linux_amd64.run (guest)

- Guest Additions tested
5.2.27
6.0.5-128691 (this version (or newer) required due to Oracle fix)

- Default ReactOS audio settings
Host Audio Driver: PulseAudio
Audio Controller: ICH AC97
Extended Features: (checked) Enable Audio Output

[BlueLagoon]

Host PC – ASUS ZX753VD-GC266T 17” Laptop running Windows 10 Home 64 bit v1809 Build 17763.292 with latest updates and VB Software – version 6.0.4
Guest – Windows 10 Pro 64 bit v1809 Build 17763.292 with latest updates

Since installing version 6.0.4 I have been unable to start VB getting “Error In supR3HardenedWinReSpawn” I have tried: -

Uninstalling VBox
Deleting C:\Program Files\Oracle folder
ReBooting
Installing VBox 6.0.4
Installing the Extension Pack
ReBooting

But this is not resolving the issue.
I have attached screen grabs and the VBoxHardening.log

Any advice would be greatly appreciated.

Thank you

Added later - Just installed ver 5.2.26 and managed to start the VM okay.

[socratis]

I think I've found a new issue between 6.0.2 and 6.0.4...

On all my VMs I have 1 shared folder, non-mapped, non-automount, read-only, named ingeniously... "Shared". For my Win VMs I can navigate from the Explorer and find it in "\\VBoxSvr\Shared".

On all my Win VMs that I've tested so far from XP to 10, I can see the directories and browse just fine. But as soon as I try to copy a file (DnD if that matters) from the share to the desktop, the copy process never finishes. Not DnD from the host to the guest, everything is taking place within the guest.

The VM is still alive and kicking, only the copy process hangs. If I try to shut down the VM, it never does, it logs the active user off and then it stays at the "Shutting down" phase. I repeat, the VM is alive, I can keep on performing other tasks just fine...

Can anyone verify please?

[mpack]

Can anyone verify please?

Dragging and dropping is entirely a guest process (in the scenario described), so it shouldn't be relevant. However, for the sake of answering the question asked - I can confirm that dragging a 15MB file from a 6.0.4 VM shared folder (6.0.0 GAs) onto a Win7-64bit guest desktop - works instantly and correctly. No sign of a problem.

I don't want to update the GAs in that VM until the fullscreen bug is fixed in an official build.

Windows 10 1803 host.

Could you be seeing a permissions issue on an OS X host?

[socratis]

Could you be seeing a permissions issue on an OS X host?

Nah, it's working fine with 6.0.2. It's the 6.0.4 that... hits the fan. But you jolted me into something. Now that my grandpa PC is alive and kicking again (on steroids) I can try it on a Win7 and a Win10 host...

[socratis]

OK, I tried it on my Win10 host. Working just fine. I think it's an OSX problem. Will keep on investigating with another OSX host and a Win7 host.

[mpack]

I established earlier that the host can't be interfering with drag and drop since that's a guest software function. It can't be interfering with networking since it isn't a network... I can't think of what it could be, other than a host permissions problem.

[socratis]

Forget a minute about DnD, I shouldn't have mentioned it, it threw the scent away.

It could be an implementation detail of the shared folder mechanism on the host side, which is platform-specific. The copy pretty much gets stuck at the "Preparing to copy..." state.

It is not a permissions issue because I try with 6.0.2, it works, switch to 6.0.4 it fails, switch to 6.0.2 it works, 6.0.4 fails, ad nauseam. Same share, same folder.

HOW
I have my VM "stuck" at 5.1.26 GAs with a snapshot. Install 6.0.x, update the GAs, reboot the VM, try to copy. Fails or works I then revert the snapshot and try with the different version.

[_nobody_]

Are you actually posting in the VirtualBox 6.0.4 specific thread, to mention that the Vagrant scripts do not work with 6.0.x?

Please do not repeat that, or next time your irrelevant post will find its way to /dev/null faster than you can say "scripts".

OK. Vagrant scripts do not work with particular VBox 6.0.4. But I already mention that you, guys, do not like Vagrant (now 2.2.3), and I just wanted to notify you all. And what I did not mention is that you admins do not like me (even more than Vagrant). Well...

_nobody_

[Air Force One]

socratis

Looks like my ticket here, I have this since last November. The other possibility is the ticket here.

[socratis]

And what I did not mention is that you admins do not like me (even more than Vagrant)

I'm not going to speak for the rest of the admins/moderators, but I don't particularly like or dislike a specific user. What I don't like is posts that have nothing to do with the issue that's been discussed on a specific thread:

• This thread is for the 6.0.4 release specifically, you talked about all 6.x
• You know very well the Vagrant is not supported. It's not that we like it or don't like it. It's not supported here.

So, your may were well intended, but in the wrong place and at the wrong time. And we've both managed to divert the discussion from 6.0.4 to something irrelevant, the very thing that I wanted to avoid from the beginning, so we'd better leave it as is...