Re: was -> wasn't Re: [VirtualBox] Use systemd-detect-virt to detect if we can install

On Wednesday, 30 November 2016 at 22:10, Sérgio Basto wrote: > > On Qua, 2016-11-30 at 21:22 +0100, Nicolas Chauvet wrote: > > > > 2016-11-30 18:07 GMT+01:00 Sérgio Basto <sergio(a)serjux.com&gt;: > > .... > > > > > > > > > The only problem is "We should avoid installation of > > > VirtualBox- > > > guest- > > > additions on bare metal", have you any suggestion that can > > > improve > > > this > > > solution ? > > > > You have wrong premise. You want to avoid the "installation" to > > avoid > > the conflict where you only need to avoid the "activation" of the > > guest additions, when relevant. > > So at the end it should be possible to even install the > > VirtualBox-guest-additon on bare hardware, or hypervisor or kvm > > guest, > > etc. > No, Conflicts in rpm packages was artificial, to avoid installation > of VirtualBox-guest-additions on bare metal and that was the only > propose of conflicts.  We know that. That was not the point. > > Again, VirtualBox-guest-additions should not be installed in bare > metal > or in any other place that isn't a VirtualBox vm.  Package have > kernel > modules, udev rules, xinit autostart, desktop autostart, services > that > try synchronize time, share clipboard, usb proxies etc , that we > should > avoid install on bare metal. No. You don't understand. Installation does not have to equal activation or loading of the modules/rules/services etc. Nicolas and I are trying to explain to you that it's most likely possible to adapt the package so that it can be installed on bare metal without any adverse effects.

> > > > > Also I don't understand why you mix kvm and oracle, the action of > > the > > virtualbox-guest-addion is "not" relevant on kvm guest, not at > > all. > Systemd of RHEL7 says that Virtualization is kvm instead oracle, to > guest-additions work on EPEL7, we need add kvm rule. Then do that only on EPEL7 and add a comment to the SPEC file. > > > > > For example, if you add ConditionVirtualization=|oracle to > > vboxservice.service, you can probably add multiple ExecStartPre > > lines > > that have the list of modules only needed by the guest. > > Then you can drop /usr/lib/modules-load.d/VirtualBox-guest.conf. > > > > In, fedora you are probably using modesettiing driver by default > > as > > Xorg driver, but you can probably use something like in nvidia > > /usr/share/X11/xorg.conf.d/vboxvideo.conf > > Section "OutputClass" > >     Identifier "vboxvideo" > >     MatchDriver "vboxvideo" > >     Driver "vboxvideo" > > EndSection > No, to load of vboxvideo doesn't need that lines , that why guest- > additions breaks X11 ( I had that experience , now with new > vboxvideo > model I don't know)  .  I still don't understand why having that driver present breaks existing X11 configuration if the virtual hardware for that driver isn't present. Certainly having drivers for different graphics cards on my machine doesn't break my configuration. > > > > > I'm not sure to understand why the other are bad ? For example, > > there > > is no conflict with udev 60-vboxguest.rules if the modules are > > not > > loaded. > if we copy file to udev the rules are loaded  Why does that break anything? > > > > > So Sergio, do you understand the concept here ? > No , the question is we need make a mechanism to avoid installation > of guest-additions in host systems , old mechanism was add > conflicts > between host packages and guest package, but as bug 3425 some would > like install VirtualBox also on guest .  You don't understand. Please stop trying to prevent guest-additions installation on any system and start trying to fix it so that it doesn't break anything. Regards, Dominik