[vbox-dev] VBoxManage extpack uninstall [--force] <name> doesn't work

[Klaus Espenlaub]

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.