Hi Sérgio, could you explain the idea here? Why was there an explicit Conflicts: before and why is it better to fail the transaction if you're not running inside VirtualBox or KVM?

From now on, we may install VirtualBox and VirtualBox-guest-additions

Also, what if calling systemd-detect-virt fails for some reason?

Regards, Dominik

Hi, On Ter, 2016-11-29 at 14:17 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > Hi Sérgio, > could you explain the idea here? Why was there an explicit > Conflicts: > before and why is it better to fail the transaction if you're not > running inside VirtualBox or KVM? It is a long story, bug reports about this [2]. With this solution (which took sometime to figure out), we can install VirtualBox-guest and VirtualBox in a vm guest [1] I think in middle of bug 3425 , I realize that the root of the problem is we can't install VirtualBox- guest-additions in master (host) system because breaks X11, etc .  So instead use an artificial rpm conflicts, BTW the solution *wasn't* made my me, it was already there when I arrived, I check in %pre if     $(systemd-detect-virt | grep -iP "oracle|kvm" -c) -eq 0

if systemd-detect-virt doesn't say that is in one oracle or kvm vm , I don't let package (VirtualBox-guest-additions) be installed . I also check kvm because in epel7 vbox vm, systemd-detect-virt says that is in kvm instead oracle ...   From now on, we may install VirtualBox and VirtualBox-guest-additions under a vm , that is the main goal of this change .  Have you any suggestion or something where I can improve ?  > > >  Also, what if calling systemd-detect-virt > fails for some reason? packages requires systemd  %{?systemd_requires} BuildRequires: systemd if systemd-detect-virt doesn't work we should be fixed , one La Palice answer :) .  > > > Regards, > Dominik [1]  https://bugzilla.rpmfusion.org/show_bug.cgi?id=3425#c7 [2] https://bugzilla.rpmfusion.org/show_bug.cgi?id=3425 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3426 https://bugzilla.rpmfusion.org/show_bug.cgi?id=1357 https://bugzilla.rpmfusion.org/show_bug.cgi?id=1468 https://bugzilla.rpmfusion.org/show_bug.cgi?id=2430 https://bugzilla.rpmfusion.org/show_bug.cgi?id=2442 https://bugzilla.rpmfusion.org/show_bug.cgi?id=2722 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3126 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3506 https://bugzilla.rpmfusion.org/show_bug.cgi?id=3918 Cheers,

On Tuesday, 29 November 2016 at 19:46, Sérgio Basto wrote: > > On Ter, 2016-11-29 at 14:17 +0100, Dominik 'Rathann' Mierzejewski > wrote: > > > > could you explain the idea here? Why was there an explicit > > Conflicts: > > before and why is it better to fail the transaction if you're not > > running inside VirtualBox or KVM? > It is a long story, bug reports about this [2]. With this solution > (which took sometime to figure out), we can install VirtualBox- > guest > and VirtualBox in a vm guest [1] I think in middle of bug 3425 , I > realize that the root of the problem is we can't > install VirtualBox- > guest-additions in master (host) system because breaks X11, etc .  > So instead use an artificial rpm conflicts, BTW the solution > *wasn't* > made my me, it was already there when I arrived, I check in %pre > if  > >    $(systemd-detect-virt | grep -iP "oracle|kvm" -c) -eq 0 > > if systemd-detect-virt doesn't say that is in one oracle or kvm vm > , I > don't let package (VirtualBox-guest-additions) be installed . > > I also check kvm because in epel7 vbox vm, systemd-detect-virt says > that is in kvm instead oracle ... >   > From now on, we may install VirtualBox and VirtualBox-guest- > additions > under a vm , that is the main goal of this change .  > > Have you any suggestion or something where I can improve ?  Ok, I read bug 3425. You shouldn't forbid installation of VirtualBox-guest-additions on bare metal by failing in %pre. I still don't understand why it can't be installed. From what was written in the bug report, you only need to make sure that either bothi vboxvideo kmod and X11 driver are present or none of them.

On Tuesday, 29 November 2016 at 22:39, Sérgio Basto wrote: > > On Ter, 2016-11-29 at 22:16 +0100, Dominik 'Rathann' Mierzejewski > wrote: > > > > On Tuesday, 29 November 2016 at 19:46, Sérgio Basto wrote: > > > > > > > > > On Ter, 2016-11-29 at 14:17 +0100, Dominik 'Rathann' > > > Mierzejewski > > > wrote: > > > > > > > > > > > > could you explain the idea here? Why was there an explicit > > > > Conflicts: > > > > before and why is it better to fail the transaction if you're > > > > not > > > > running inside VirtualBox or KVM? > > > It is a long story, bug reports about this [2]. With this > > > solution > > > (which took sometime to figure out), we can install VirtualBox- > > > guest > > > and VirtualBox in a vm guest [1] I think in middle of bug 3425 > > > , I > > > realize that the root of the problem is we can't > > > install VirtualBox- > > > guest-additions in master (host) system because breaks X11, etc > > > .  > > > So instead use an artificial rpm conflicts, BTW the solution > > > *wasn't* > > > made my me, it was already there when I arrived, I check in > > > %pre > > > if  > > > > > >    $(systemd-detect-virt | grep -iP "oracle|kvm" -c) -eq 0 > > > > > > if systemd-detect-virt doesn't say that is in one oracle or kvm > > > vm > > > , I > > > don't let package (VirtualBox-guest-additions) be installed . > > > > > > I also check kvm because in epel7 vbox vm, systemd-detect-virt > > > says > > > that is in kvm instead oracle ... > > >   > > > From now on, we may install VirtualBox and VirtualBox-guest- > > > additions > > > under a vm , that is the main goal of this change .  > > > > > > Have you any suggestion or something where I can improve ?  > > Ok, I read bug 3425. You shouldn't forbid installation of > > VirtualBox-guest-additions on bare metal by failing in %pre. > > I still don't understand why it can't be installed. From what was > > written in the bug report, you only need to make sure that either > > bothi vboxvideo kmod and X11 driver are present or none of them. > No, VirtualBox-guest-additions breaks hosts (that is the main > problem).  > We must forbid installation of VirtualBox-guest-additions on bare > metal > else (at least) X11 won't start, that is the point .  Breaks hosts how? Why won't X11 start, then? What about Wayland?

> Previous solution was make VirtualBox conflicts with VirtualBox- > guest- > additions. So end user, ends by choose install VirtualBox in host, > but > by that (conflicts solution) both packages can't also be installed > in a > guest system, which is fixed with this brilliant solution.  Failing in %pre, which happens during dnf/rpm transation *after* the package had been downloaded already is not brilliant at all in my opinion. I'd like to think there is a better way, but I first need to understand the issue.

Regards, Dominik

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.

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.

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

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.

So Sergio, do you understand the concept here ?

i'm not givin you the final solution,here, just the path to follow. You will be able to remove the conflict only when all conflicting situation are solved.

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