Hi Gianfranco, On 15.10.2015 19:18, Gianfranco Costamagna wrote: > Hi folks, as said, "--force" is not implemented, and the call exits with > > Progress state: NS_ERROR_FAILURE > VBoxManage: error: Failed to uninstall "Oracle VM VirtualBox Extension Pack" > VBoxManage: error: The installer failed with exit code 2: > VBoxExtPackHelperApp: error: Unknown option: '--forced' > VBoxManage: error: rcExit=2 > VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component > ExtPackManagerWrap, interface IExtPackManager > VBoxManage: error: Context: "RTEXITCODE handleExtPack(HandlerArg*)" at line > 1199 of file VBoxManageMisc.cpp > > > looking at > > ./src/VBox/Main/src-all/ExtPackManagerImpl.cpp:2727 > the --forced is passed (while the documentation says --force) > > but > ./src/VBox/Main/src-helper-apps/VBoxExtPackHelperApp.cpp:134 is not accepting > that parameter.
Correct analysis of the immediate error, but the root cause is totally unrelated (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800034). There should be no need to force uninstallation of the extpack, which is why it went unnoticed for so long that it isn't working (since the introduction of extension packs in VirtualBox 4.0.0, 5 years ago). Uninstalling an extpack expects to do a rename() syscall for the extpack directory name successfully, but instead gets EXDEV. This means that the filesystem structure is very unexpected. Either the Debian live setup uses a non-posix compliant union filesystem or it stitches together filesystems in very creative ways (the extpack directory most likely being a mount point). Both are violating the basic assumptions of the code, and even if forcing would be implemented I wonder if it could/should avoid the renaming, as it's making the removal safe (effectively atomic). Klaus > > cheers, > > G. _______________________________________________ vbox-dev mailing list vbox-dev@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev
