On Tue, Jun 30, 2020 at 04:23:59PM +0200, Felipe Borges wrote: > On Tue, Jun 30, 2020 at 4:01 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote: > > > > * Jóhann B. Guðmundsson: > > > > > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream > > > changes it beg the question if now would not be the time to stop > > > supporting booting in legacy bios mode and move to uefi only supported > > > boot which has been available on any common intel based x86 platform > > > since atleast 2005. > > > > Even for virtualization? Not sure if that can be done. > > It can, but not much :) I recently reverted the GNOME Boxes change > that installed guests with uefi. I wrote a [humorous] commit message > about it with a few details > https://gitlab.gnome.org/GNOME/gnome-boxes/-/commit/c486da262f6566326fbcb5ef45c5f64048f16a6e > > Long story short, Libvirt/qemu don't seem to be able to perform AND > revert to snapshots of UEFI guests. Yeah, that's a pretty frustrating bug that's been causing pain for countless years. The main problem is at the QEMU level, because its "savevm" command does not provide any way to mark certain block devices as skipped/ignored. Conceptually, fixing that problem is easy, but it has come up against the fact that "savevm" has a pile of other problems in QEMU. Any suggestion to fix the easy problem has ended up blocked by requirement to fix the hard problems. I think this is a mistake on QEMU's part - given that no one has made any serious proposal to fix the hard problem in 10 years, it is unreasonable for QEMU to block fixes for the easy problems. Unfortunately getting someone motivated to fix any of this is hard as the big mgmt tools like oVirt and OpenStack don't care about internal snapshots, instead using the more general external snapshots. It is all rather an unpleasant mess :-( Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx