Bug 1164492 - Please drop libvirt 'default' network dependency for F28 GA (also Beta?), disrupts livecd networking
Summary: Please drop libvirt 'default' network dependency for F28 GA (also Beta?), dis...
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-boxes
Version: 27
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Christophe Fergeau
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException AcceptedBlocker
Keywords: Reopened
Depends On:
Blocks: F28BetaFreezeException F28FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2014-11-15 19:14 UTC by Cole Robinson
Modified: 2018-03-29 19:22 UTC (History)
15 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2018-03-29 19:22:11 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1146232 None CLOSED no VM networking; 'default' network in the VM conflicts with 'default' network on the host 2019-04-19 01:57 UTC

Internal Trackers: 1146232

Description Cole Robinson 2014-11-15 19:14:38 UTC
gnome-boxes pulls libvirt-daemon-config-network into the F21 workstation livecd. This is problematic when running the livecd inside a VM that is using the libvirt 'default' virtual network with the same address range, the end result is that the VM has no network access to the outside world.

We've tried to mitigate this at the libvirt level, but it doesn't fix the livecd case. For context, see https://bugzilla.redhat.com/show_bug.cgi?id=1146232

I suggest we drop the gnome-boxes hard dependency for F21 GA. It can then be reintroduced with a gnome-boxes update after F21 is out the door, since installing libvirt-daemon-config-network on a per VM basis should be safe, it's just an issue having the same address range hardcoded for every F21 install from livecd.

Comment 1 Cole Robinson 2014-11-15 19:16:03 UTC
Proposing as an F21 final blocker, since no network connectivity inside a livecd VM likely violates some install criteria.

Comment 2 Cole Robinson 2014-11-18 20:46:33 UTC
Just noticed now that the libvirt bug, bug 1146232, is marked as a final release blocker.

boxes guys, thoughts on this? will boxes gracefully revert back to using usermode networking if the default network isn't around? any volunteers to make this change and test it?

Comment 3 Christophe Fergeau 2014-11-19 08:27:00 UTC
I think it should yeah, Zeeshan, can you confirm?

Comment 4 Mike Ruckman 2014-11-19 16:50:29 UTC
Discussed in 2014-11-19 blocker review meeting. "This bug tries to solve the same issue as bug 1146232 which is already blocker."

Comment 5 Cole Robinson 2014-11-19 17:00:32 UTC
(In reply to Mike Ruckman from comment #4)
> Discussed in 2014-11-19 blocker review meeting. "This bug tries to solve the
> same issue as bug 1146232 which is already blocker."

Yeah but... this is where the fix is going to be, and it isn't going to fully 'fix' bug 1146232.

If a gnome-boxes update is pushed referencing the libvirt bug, is the QA process going to let it through even though the components are mismatched?

Comment 6 Kamil Páral 2014-11-20 15:57:16 UTC
Sorry for incomplete info. We don't need to solve the root problem completely, we just need to satisfy the criteria, therefore networking must work in VMs, regardless of circumstances (in a reasonable extent). We assumed this is just one avenue how to fix it, therefore we didn't want to block on it. It's true that it would require us to watch it more carefully to see which package update is supposed to fix the bug (adding a comment in the approved blocker bug would help us).

Alternatively, we can transfer the blocker status here, if boxes maintainers are OK with the change and nobody else sees any other option how to fix it in the nearest future (~two weeks).

Comment 7 Zeeshan Ali 2014-11-20 16:50:24 UTC
(In reply to Christophe Fergeau from comment #3)
> I think it should yeah, Zeeshan, can you confirm?

Sorry, I totally missed a few comments out. Yes, the code in Boxes reverts back to old usermode networking if virbr0 is not up. However, this is only done for new machines. while Boxes updates existing machines to use virbr0 when/if it is available, it doesn't do the opposite. i-e existing machines using virbr0 will continue to do so.

Comment 8 Cole Robinson 2014-11-20 16:58:06 UTC
(In reply to Zeeshan Ali from comment #7)
> (In reply to Christophe Fergeau from comment #3)
> > I think it should yeah, Zeeshan, can you confirm?
> 
> Sorry, I totally missed a few comments out. Yes, the code in Boxes reverts
> back to old usermode networking if virbr0 is not up. However, this is only
> done for new machines. while Boxes updates existing machines to use virbr0
> when/if it is available, it doesn't do the opposite. i-e existing machines
> using virbr0 will continue to do so.

I don't think that should be a problem, the only thing we care about is what packages get baked into the livecd. After GA is out, we can push a boxes update with the dependency restored, and in practice I don't think anyone will be affected.

Comment 9 Fedora Update System 2014-11-21 15:13:36 UTC
gnome-boxes-3.14.2-2.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/gnome-boxes-3.14.2-2.fc21

Comment 10 Fedora Update System 2014-11-22 20:21:07 UTC
Package gnome-boxes-3.14.2-2.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-boxes-3.14.2-2.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-15596/gnome-boxes-3.14.2-2.fc21
then log in and leave karma (feedback).

Comment 11 M. Edward (Ed) Borasky 2014-11-22 22:40:58 UTC
Also fixes https://bugzilla.redhat.com/show_bug.cgi?id=1146232

Comment 12 Adam Williamson 2014-11-24 20:02:33 UTC
I think it's clearer to transfer the blocker status here from #1146232 , now I think about it, as this doesn't exactly 'fix' that bug but works around a specific case of it for the F21 release. We don't want to close that bug when this update goes out, I don't think, so it's not appropriate to rely on that bug's dependency on this one, it makes it clearer to have this as the blocker directly.

So, marking as an AcceptedBlocker.

Comment 13 Fedora Update System 2014-11-25 03:06:03 UTC
gnome-boxes-3.14.2-2.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Zeeshan Ali 2015-01-05 19:18:40 UTC
(In reply to Cole Robinson from comment #8)
> (In reply to Zeeshan Ali from comment #7)
> > (In reply to Christophe Fergeau from comment #3)
> > > I think it should yeah, Zeeshan, can you confirm?
> > 
> > Sorry, I totally missed a few comments out. Yes, the code in Boxes reverts
> > back to old usermode networking if virbr0 is not up. However, this is only
> > done for new machines. while Boxes updates existing machines to use virbr0
> > when/if it is available, it doesn't do the opposite. i-e existing machines
> > using virbr0 will continue to do so.
> 
> I don't think that should be a problem, the only thing we care about is what
> packages get baked into the livecd. After GA is out, we can push a boxes
> update with the dependency restored, and in practice I don't think anyone
> will be affected.

Time to add it back Cole?

Comment 15 Cole Robinson 2015-01-05 19:19:40 UTC
Yes it should be fine to push an update now

Comment 16 M. Edward (Ed) Borasky 2015-01-05 19:36:21 UTC
This is going to break my current remix process (see bug 1146232) but I'm not a big fan of GNOME Boxes when Virtual Machine Manager is available, so I can just delete GNOME Boxes during the ISO creation and give the user the option of putting it back. ;-)

Comment 17 Zeeshan Ali 2015-01-06 17:21:56 UTC
(In reply to M. Edward (Ed) Borasky from comment #16)
> This is going to break my current remix process (see bug 1146232) but I'm
> not a big fan of GNOME Boxes when Virtual Machine Manager is available, so I
> can just delete GNOME Boxes during the ISO creation and give the user the
> option of putting it back. ;-)

I hope the decision is not up to you? Virt-manager is targetted as a super user tool that is mostly just a nicer interface to edit libvirt's xml configuration while Boxes is designed for ordinary users who want simply run different operating systems in a safe/contained environment or connect to remove machines using a slick UI.

All I see in bug#1146232 is you repeating your naive opinions w/o any arguments and now simply restating them, once again without any compelling argument.

Please tell me that you have no power to make any such decisions?

Comment 18 Zeeshan Ali 2015-01-06 17:34:51 UTC
(In reply to M. Edward (Ed) Borasky from comment #16)
> This is going to break my current remix process (see bug 1146232) but I'm
> not a big fan of GNOME Boxes when Virtual Machine Manager is available, so I
> can just delete GNOME Boxes during the ISO creation and give the user the
> option of putting it back. ;-)

I was just informed that you have been talking about your own remixes rather than official Fedora ISOs. If that is the case, kindly keep your naive opinions to yourself in future and do as you please with your remixes.

Comment 19 Fedora Update System 2015-01-06 18:31:49 UTC
gnome-boxes-3.14.2-3.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/gnome-boxes-3.14.2-3.fc21

Comment 20 Adam Williamson 2015-01-06 19:24:14 UTC
Zeeshan: I really don't think that tone was necessary. It's perfectly legitimate to point out that the approach of changing the libvirt configuration when Fedora isn't building official images doesn't work well for people doing respins; we do have, for instance, the sort of quarter-official respins done by southern_gentleman / jbwilliams - http://jbwillia.wordpress.com/ - which live on a Fedora server, at https://alt.fedoraproject.org/pub/alt/live-respins/ .

Comment 21 Zeeshan Ali 2015-01-07 14:53:48 UTC
(In reply to Adam Williamson (Red Hat) from comment #20)
> Zeeshan: I really don't think that tone was necessary. It's perfectly
> legitimate to point out that the approach of changing the libvirt
> configuration when Fedora isn't building official images doesn't work well
> for people doing respins;

Sure but thats not what this dude did. He simply expressed his lack of knowledge and pressented a conclusion based on that. Moreover, I see no connection of his comments (which are essentially the same) to either of the bugs he posted them on.

> we do have, for instance, the sort of
> quarter-official respins done by southern_gentleman / jbwilliams -
> http://jbwillia.wordpress.com/ - which live on a Fedora server, at
> https://alt.fedoraproject.org/pub/alt/live-respins/ .

Thanks for the info. As long as some random person is not allowed to remove my software from main/official ISOs of Fedora without any compelling reasons, I really don't care of what people do with re-spins etc.

Now lets stop this irrelevant discussion here.

Comment 22 Adam Williamson 2015-01-07 17:15:16 UTC
er, it seemed pretty clear to me that he was talking about deleting Boxes during "during the ISO creation" of "[his] current remix process", nothing to do with 'deleting' it from Fedora (which isn't a thing you can do anyway).

Comment 23 Fedora Update System 2015-02-11 12:40:37 UTC
gnome-boxes-3.14.3.1-1.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/gnome-boxes-3.14.3.1-1.fc21

Comment 24 Fedora Update System 2015-02-21 04:25:38 UTC
gnome-boxes-3.14.3.1-1.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 25 Cole Robinson 2015-04-02 17:28:06 UTC
Reopening, since this is hitting us again with F22 live media.

Laine is going to look at extending libvirt with his suggestion at https://bugzilla.redhat.com/show_bug.cgi?id=1146232#c17

But until that's done we should probably re-drop the network dep so beta media doesn't suffer from the 'no network access' problem

Comment 26 Fedora Blocker Bugs Application 2015-04-02 17:31:34 UTC
Proposed as a Blocker for 22-beta by Fedora user crobinso using the blocker tracking app because:

 With this dep in place, the live media running in a VM can have broken network access. It may only affect live media in a VM running on a host that was _also_ installed via live media, but regardless the failure scenario sucks here so we should avoid it for beta.

Comment 27 Kamil Páral 2015-04-03 11:13:29 UTC
Adjusting whiteboard for F22 blocker proposal.

Comment 28 Adam Williamson 2015-04-06 16:44:53 UTC
Discussed at 2015-04-06 blocker review meeting: https://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-06/f22-blocker-review.2015-04-06-16.00.log.txt .  Accepted as a blocker as in F21 cycle, until someone comes up with a better approach for this, we'll have to keep doing the same dodge. Boxes folks, please do a build with the dep dropped for now...

Comment 29 Fedora Update System 2015-04-07 21:23:39 UTC
gnome-boxes-3.16.0-2.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/gnome-boxes-3.16.0-2.fc22

Comment 30 Fedora Update System 2015-04-08 18:35:52 UTC
Package gnome-boxes-3.16.0-2.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing gnome-boxes-3.16.0-2.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-5751/gnome-boxes-3.16.0-2.fc22
then log in and leave karma (feedback).

Comment 31 Adam Williamson 2015-04-08 18:57:40 UTC
This looks right in RC1, the package is not on the Workstation live.

Comment 32 Adam Williamson 2015-04-14 14:51:22 UTC
also with RC2.

Comment 33 Fedora Update System 2015-04-17 02:30:50 UTC
gnome-boxes-3.16.0-2.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 34 Zeeshan Ali 2015-06-09 16:44:31 UTC
Can we bring the dependency back now? Do we have to go through this each release?

Comment 35 Fedora Update System 2015-06-09 17:24:42 UTC
gnome-boxes-3.16.2-3.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/gnome-boxes-3.16.2-3.fc22

Comment 36 Cole Robinson 2015-06-09 18:37:57 UTC
(In reply to Zeeshan Ali from comment #34)
> Can we bring the dependency back now? Do we have to go through this each
> release?

The bug report in comment #0 has all the details about the current state of this... it still isn't fully fixed at the libvirt level so as of now this will break again come f23. ideas and patches welcome

Comment 37 M. Edward (Ed) Borasky 2015-06-10 05:14:14 UTC
(In reply to Cole Robinson from comment #36)
> (In reply to Zeeshan Ali from comment #34)
> > Can we bring the dependency back now? Do we have to go through this each
> > release?
> 
> The bug report in comment #0 has all the details about the current state of
> this... it still isn't fully fixed at the libvirt level so as of now this
> will break again come f23. ideas and patches welcome

Ideas I've got plenty of - patches not so much. ;-)

The intended use case for the Workstation Live media is
    a. Try out Fedora Workstation on real hardware, and
    b. Install Fedora Workstation to said hardware if you like it and want to use it.

It is *not* a specialty spin or a rescue CD or something you'd use as part of your day-to-day workflow in most cases. Even with a USB 3.0 device it's frustratingly slow on significant operations. And it is not intended as a way to build a Fedora virtual machine running in any virtual host. LiveMedia Creator and a kickstart file does that very well. ;-)

IIRC I was the one that first ran into this and filed the original bug during F21 alpha or beta. I don't recall exactly why I was running an alpha or beta live ISO in a virtual machine but it's not something I'd do in production. I use 'netinstall' on a USB stick for rescue and to do installs; getting the updated RPMs more than compensates for the longer install from the downloads.

So my idea is simply to create Workstation media with the disclaimer that you may not have networking in a VM, or add a desktop icon that enables networking. See https://bugzilla.redhat.com/show_bug.cgi?id=1146232#c5 for the command-line operation to get networking up (at least it worked on F21).

Comment 38 Fedora Update System 2015-06-13 06:36:10 UTC
gnome-boxes-3.16.2-3.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 39 Cole Robinson 2016-05-04 22:23:48 UTC
Reopening, this is a problem with F24 again. See the continuing discussion in libvirt bug 1146232

Maybe there's some more stable workaround we can make with livecd kickstart/livesys startup scripts or whatnot, but I don't really have the time to investigate that in the near future. The simplest fix again seems to be to revert the boxes dep until after GA, and kick the can down the road some more until libvirt grows some magic config option to avoid this situation

Comment 40 Kamil Páral 2016-05-06 11:02:58 UTC
This was accepted before, I guess we should propose either this or bug 1146232 as F24 blocker.

Comment 41 Geoffrey Marr 2016-05-09 19:28:35 UTC
Discussed during the 2016-05-09 blocker review meeting: [1]

Originally accepted as a blocker in F21 release, until this is resolved (or a solution is developed), this will remain a blocker. Suggestion is to create a build with the dependency removed. 


[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-05-09/f24-blocker-review.2016-05-09-16.00.txt

Comment 42 Michael Catanzaro 2016-05-11 02:24:33 UTC
We need to stop doing this. I understand this is needed to get F24 out the door, but I ask that bug #1146232 be prioritized for F25. It looks like some action is occurring there, which is great.

Comment 43 Cole Robinson 2016-05-11 02:40:42 UTC
(In reply to Michael Catanzaro from comment #42)
> We need to stop doing this. I understand this is needed to get F24 out the
> door, but I ask that bug #1146232 be prioritized for F25. It looks like some
> action is occurring there, which is great.

Then someone needs to volunteer to champion it and propose patches.

Just speaking for myself, I'm not all that excited about adding potentially invasive code in libvirt, that may be triggered by all usage of the default network, all to accomodate the specific case of

- how fedora composes its livecd
- the fact that gnome-boxes is on the livecd by default
- the fact that gnome-boxes Requires: libvirt-daemon-config-network even though the functionality isn't strictly required

But maybe there's another simple solution we can come up with on the distribution side. Ideas welcome

Comment 44 Chris Murphy 2016-05-13 18:17:42 UTC
bug 1146232#c50 seems non-invasive, simple, designed for this use case, is tested, and if it somehow failed to fix the problem or inhibits libvirtd to start it'd be a considerable systemd bug. Is there a use case for libvirtd to ever run in a VM?

Comment 45 Cole Robinson 2016-05-13 18:25:28 UTC
(In reply to Chris Murphy from comment #44)
> Is there a use case for libvirtd to ever run in a VM?

Yes, for developing virt related packages (for example, openstack) it's quite common. Same with QA testing say Fedora releases in a VM, you want to be able to test the virt stack is working.

Comment 46 Adam Williamson 2016-05-23 17:30:59 UTC
sure, but I'd say the cases for running libvirtd in a *live session* in a VM are rather smaller, and for the few cases where you'd want to do that you still can by overriding the unit file or just starting it directly.

Comment 47 Cole Robinson 2016-05-23 17:38:55 UTC
(In reply to Adam Williamson from comment #46)
> sure, but I'd say the cases for running libvirtd in a *live session* in a VM
> are rather smaller, and for the few cases where you'd want to do that you
> still can by overriding the unit file or just starting it directly.

agreed, but following that logic I'd rather remove gnome-boxes from the livecd than try to convince libvirt to not run in the live environment. or rework gnome-boxes deps to do what virt-manager has always done and not have a hard requirement on libvirt-daemon-config-network (or even libvirt-daemon... isn't gnome boxes also supposed to be the official VNC/SPICE client? it doesn't strictly need virt either AFAIK)

Comment 48 Adam Williamson 2016-05-23 17:40:53 UTC
"agreed, but following that logic I'd rather remove gnome-boxes from the livecd than try to convince libvirt to not run in the live environment"

I don't think that would fly. Boxes is explicitly part of Workstation. If we remove it from the live, that also means that when you install from the live, you don't get it - and installing from the live is the primary deployment method for Workstation.

Fiddling with boxes' deps is more likely to fly.

Comment 49 Michael Catanzaro 2016-05-23 18:37:14 UTC
(In reply to Adam Williamson from comment #48)
> I don't think that would fly.

Yup. It's indeed for remote desktop access as well as virtualization, and it's a core component of GNOME and Workstation.

> Fiddling with boxes' deps is more likely to fly.

If need be, a F25-timeframe compromise would be for Boxes to install its dependencies via PackageKit when they're not available. But bug 1146232#c50 seems like a better solution TBH. Overriding a unit file is the sort of thing we can expect users who want to run VMs inside VMs to know how to do.

Comment 50 Fedora Update System 2016-05-25 14:46:21 UTC
gnome-boxes-3.20.2-2.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-dfe706e35e

Comment 51 Fedora Update System 2016-05-26 05:01:34 UTC
gnome-boxes-3.20.2-2.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-dfe706e35e

Comment 52 Fedora Update System 2016-05-26 17:31:52 UTC
gnome-boxes-3.20.2-2.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 53 Kamil Páral 2016-05-31 09:50:25 UTC
I tested this with Fedora-Workstation-Live-x86_64-24-20160529.n.0.iso containing gnome-boxes-3.20.2-2.fc24. I installed a default install to a bare metal machine, then ran the same image as a VM guest in gnome-boxes and virt-manager. Network access worked out of the box in guest VM. So tldr works OK.

Comment 54 Adam Williamson 2017-09-11 18:52:07 UTC
Re-opening for F27, and re-proposing as a blocker; we still didn't come up with a permanent fix for 1146232, so we're going to need this workaround again.

Comment 55 Kamil Páral 2017-09-11 19:00:07 UTC
Discussed during blocker review [1]:

#1146232 - RejectedBlocker (Final), #1164492 - AcceptedBlocker (Final) - we think the problem here constitutes a blocker, but as with previous releases, we will make #1164492 the blocker as we may fix it with a short-term workaround rather than a real fix (again)

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-09-11/

Comment 56 Cole Robinson 2017-10-19 21:01:32 UTC
Change hasn't been made yet.

FWIW I'm happy to handle this dep hacking for all fedora dev releases until we come up with a libvirt feature that handles this convoluted case. If someone from gnome-boxes/desktop side just wants to give me the go ahead. Will probably save everyone a lot of cycles... 

(Easiest way I think is to keep the network dep disabled in rawhide, and only enable it in a zero day update once GA is out)

Comment 57 Fedora Update System 2017-10-24 13:02:46 UTC
gnome-boxes-3.26.1-4.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-fc8a65f619

Comment 58 Fedora Update System 2017-10-25 15:24:54 UTC
gnome-boxes-3.26.1-4.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-fc8a65f619

Comment 59 Adam Williamson 2017-11-02 00:23:44 UTC
Confirmed that spin-kickstarts-0.27.1-1.fc27 is in the RC-1.2 compose, does not have the dependency, and indeed libvirt-daemon-config-network is not included in the Workstation live image.

Comment 60 Adam Williamson 2017-11-02 00:25:02 UTC
of course I meant gnome-boxes-3.26.1-4.fc27 , sigh.

Comment 61 Fedora Update System 2017-11-04 16:53:56 UTC
gnome-boxes-3.26.1-4.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

Comment 62 Adam Williamson 2017-11-08 19:58:31 UTC
Update was pushed stable, closing for F27 (we can re-open and do this dance again for F28 if we don't figure out a better fix in the meantime).

Comment 63 Adam Williamson 2018-03-23 05:52:23 UTC
Welp, time to dance again.

Comment 64 Adam Williamson 2018-03-23 05:52:59 UTC
Also proposing as Beta FE, we have a few days to get this into Beta too if we want.

Comment 65 Michael Catanzaro 2018-03-23 16:40:07 UTC
(In reply to Michael Catanzaro from comment #42)
> We need to stop doing this. I understand this is needed to get F24 out the
> door, but I ask that bug #1146232 be prioritized for F25. It looks like some
> action is occurring there, which is great.

That was two years ago... something has to change here. We can't keep doing this.

Comment 66 Adam Williamson 2018-03-23 17:20:19 UTC
Well, the problem is that no-one can actually figure out what the 'real' fix for this ought to be. It's a very difficult problem to solve, really.

Comment 67 Cole Robinson 2018-03-23 18:26:53 UTC
Latest idea: Maybe weak deps can help. Have gnome-boxes add Recommends: libvirt-daemon-config-network. As part of the workstation kickstart, remove the package, and manually delete /etc/libvirt/network/default.xml and /etc/libvirt/network/autostart/default.xml

That way the conflicting network doesn't end up on the livecd, but after VM install and the first 'yum update' the Recommends: will be pulled in, the install logic in libvirt-daemon-config-network can check against the runtime VM network and install with a non-conflicting IP address range

Comment 68 Geoffrey Marr 2018-03-26 18:47:37 UTC
Discussed during the 2018-03-26 blocker review meeting: [1]

The decision to classify this bug as an AcceptedFreezeException was made as we want to avoid networking on Workstation live boots being broken by this, and we still haven't figured out a permanent fix.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-03-26/f28-blocker-review.2018-03-26-16.01.txt

Comment 69 Geoffrey Marr 2018-03-26 19:05:22 UTC
Discussed during the 2018-03-26 blocker review meeting: [1]

The decision to classify this bug as an AcceptedBlocker was made as it violates all blocker criteria related to networking, in the case of libvirt guests booting/installing from the Workstation live image.

[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2018-03-26/f28-blocker-review.2018-03-26-16.01.txt

Comment 70 Fedora Update System 2018-03-26 21:39:51 UTC
gnome-boxes-3.27.92-2.fc28.1 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-45c3d50109

Comment 71 Cole Robinson 2018-03-27 14:03:40 UTC
(In reply to Cole Robinson from comment #56)
> FWIW I'm happy to handle this dep hacking for all fedora dev releases until
> we come up with a libvirt feature that handles this convoluted case. If
> someone from gnome-boxes/desktop side just wants to give me the go ahead.
> Will probably save everyone a lot of cycles... 
> 
> (Easiest way I think is to keep the network dep disabled in rawhide, and
> only enable it in a zero day update once GA is out)

Since this never received a yes or no, I'm going ahead with this plan to save everyone the recurring hassle until we find a long term solution. Here's the comment I will be adding to rawhide and f28 gnome-boxes:


# Pulls in the libvirtd NAT 'default' network
# Original request: https://bugzilla.redhat.com/show_bug.cgi?id=1081762
#
# However, the 'default' network does not mix well with the Fedora livecd
# when it is run inside a VM. The whole saga is documented here:
#
#   boxes: https://bugzilla.redhat.com/show_bug.cgi?id=1164492
#   libvirt: https://bugzilla.redhat.com/show_bug.cgi?id=1146232
#
# Until a workable solution has been determined and implemented, this
# dependency should stay disabled in rawhide and fedora development
# branches so it does not end up on the livecd. Once a Fedora GA is
# released, a gnome-boxes update can be pushed with this dependency
# re-enabled. crobinso will handle this process, see:
#   <link to this bz comment>
#Requires:>.libvirt-daemon-config-network


When F28 and all future Fedora are frozen for GA, I will queue an update to re-enable the dep

Comment 72 Adam Williamson 2018-03-27 16:05:08 UTC
I already did the change for F28 (see above), but I'm certainly fine with you taking it on for the future, Cole! Note I did the build with the bump after the dist ('.fc28.1') to ensure it's behind Rawhide's build (and so that we don't wind up with two different -3s, one in F28 with the dependency off, one in Rawhide with it on).

Comment 73 Fedora Update System 2018-03-27 17:52:35 UTC
gnome-boxes-3.27.92-2.fc28.1 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-45c3d50109

Comment 74 Fedora Update System 2018-03-29 19:22:11 UTC
gnome-boxes-3.27.92-2.fc28.1 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.