Package Details: virtualbox-bin 7.2.10-2

Git Clone URL: https://aur.archlinux.org/virtualbox-bin.git (read-only, click to copy)
Package Base: virtualbox-bin
Description: Powerful x86 virtualization for enterprise as well as home use (Oracle branded non-OSE)
Upstream URL: https://www.virtualbox.org/
Keywords: machine oracle virtualization vm
Licenses: GPL-3.0-only
Conflicts: virtualbox, virtualbox-host-dkms, virtualbox-host-modules-arch
Provides: virtualbox, virtualbox-host-dkms, VIRTUALBOX-HOST-MODULES
Replaces: virtualbox-sun, virtualbox_bin
Submitter: Rainmaker
Maintainer: dbermond
Last Packager: dbermond
Votes: 62
Popularity: 0.120001
First Submitted: 2015-08-18 09:16 (UTC)
Last Updated: 2026-06-27 14:38 (UTC)

Required by (13)

Sources (12)

Pinned Comments

dbermond commented on 2022-10-21 19:08 (UTC)

Notice:

To avoid crashes when upgrading Guest Additions from version 6.x to 7.x on Windows guests, uninstall the old Guest Additions first, then reboot, and then install the new ones. It's recommended to do all these operations in Safe Mode. See this upstream bug ticket for more details.

Latest Comments

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 16 Next › Last »

dbermond commented on 2020-04-21 23:26 (UTC)

@joerg-krause AUR helpers are not supported. Please use makepkg.

No malicious code on this PKGBUILD, it's just extracting the main source file.

joerg-krause commented on 2020-04-16 06:30 (UTC)

The Aura package manager fails to build this package to avoid potentially malicious code:

sudo aura -Ax virtualbox-bin
aura >>= Determining dependencies...
aura >>= WARNING: The PKGBUILD of `virtualbox-bin` contains blacklisted bash expressions.

    sh "VirtualBox-${pkgver}-${_build}-Linux_amd64.run" --target "${pkgname}-${pkgver}" --nox11 --noexec

aura >>= `sh` can be used to execute arbitrary code not tracked by this PKGBUILD.
aura >>= Do you wish to quit the build process? [Y/n] 
aura >>= Cancelled further processing to avoid potentially malicious bash code.

Ralf_Mardorf commented on 2020-04-06 11:12 (UTC) (edited on 2020-04-06 11:12 (UTC) by Ralf_Mardorf)

Romario74, see the "Update" added to my original comment. I noticed that the extension pack needed to be reinstalled already before you replied. However, there's still an issue displayed for one guest's settings, even while the guest seems to be usable. After doing some further testing virtualbox-bin 6.1.4-2 seems not to work when booted to the real-time patched kernel 5.6.2, it seems to work when booted to the real-time patched kernel 4.19.106. "Seems", since I only made short tests and those failed when booted to the kernel 5.6.2, but worked when booted to the kernel 4.19.106. Now I'll try to backup two tablets with the Windows 7 and with the Windows 10 guest, while booted into 5.6.2-arch1-2 with "threadirqs". Until now the Windows 7 guest works. If I don't report anything else within the next hours, it continued to work without failure and the Windows 10 guest worked, too.

Romario74 commented on 2020-04-05 20:37 (UTC)

You have to reinstall the extension pack. This is what gives you USB support for your VMs. No need to restore from backup. And thanks for the virtualbox update, works fine with kernel 5.6.

Ralf_Mardorf commented on 2020-04-05 18:18 (UTC) (edited on 2020-04-05 20:17 (UTC) by Ralf_Mardorf)

A self-build real-time patched kernel 5.6.2-rt1 as well as 5.6.2-arch1-2 from Testing, with virtualbox-bin 6.1.4-2, trying to start a Windows 10 or Windows 7 guest fails with "Implementation of the USB 2.0 controller not found!" The same happens for a self-build real-time patched 4.19.106-rt46. After downgrading to virtualbox-bin 6.1.4-1, the self-build real-time patched kernel 4.19.106-rt46, that could be used before the upgrade to virtualbox-bin 6.1.4-2, still results in the same error. Even while I'm loading and unloading the modules on demand, I restarted the machine to no avail. FWIW all modules were build. The vbox and vbox-prev files do only contain different timestamps, anything else doesn't differ. The snapshots were not touched at all. Since it worked a few hours before I upgraded virtualbox-bin, nothing else was upgraded, I'll restore the guests from backups or what ever else might be broken.

Update: There was no need to restore from a backup, I just needed to reinstall the extension pack, so perhaps it even works with kernel 5.6. I can't test it now. Both Windows guests can be used again, but an invalid setting for the Windows 7 guest is detected, it's just not mentioned what setting.

dbermond commented on 2020-04-05 16:46 (UTC)

@Romario74 I've added a patch for linux 5.6.

Romario74 commented on 2020-03-31 14:41 (UTC)

dkms modules do not build with kernel 5.6

Ralf_Mardorf commented on 2019-07-28 16:29 (UTC)

It isn't solved. I've run out of ideas.

Ralf_Mardorf commented on 2019-07-28 14:14 (UTC) (edited on 2019-07-28 14:14 (UTC) by Ralf_Mardorf)

[solved] Virtualbox quite suddenly can't access shared folder anymore

Ralf_Mardorf commented on 2019-07-27 17:50 (UTC) (edited on 2019-07-27 17:51 (UTC) by Ralf_Mardorf)

Hi, a Windows 7 guest quite suddenly can't access a shared folder anymore. If I open the shared folder, I get a BlueScreen and Windows 7 immediately crashes and restarts, see aur-general. In the meantime I tested 3 different kernels and restored Windows 7 from a snapshot, as well as Windows 7 and ~/.VirtualBox/ from a backup. Windows doesn't provide useful information, but the VirtualBox logs mention "Failed to open "/dev/vboxdrvu", errno=13, rc=VERR_VM_DRIVER_NOT_ACCESSIBLE", which seems to lead to a vboxdrv.rules issue. However, even after getting rid of the "Failed to open "/dev/vboxdrvu", errno=13, rc=VERR_VM_DRIVER_NOT_ACCESSIBLE" message, by using vboxdrv.rules from the community package, the Windows guest still crashes, see aur-general.

« First ‹ Previous 1 .. 5 6 7 8 9 10 11 12 13 14 15 16 Next › Last »