12:42 a.m.
Hi,
Can you give a try of the workaround in
https://bugzilla.redhat.com/show_bug.cgi?id=1727987#c0 ?
At least it works for RHEL 8 (and most probably CentOS 8).
Best Regards,
Strahil NikolovOn Nov 3, 2019 12:14, Mathieu Simon <mathieu.simon(a)gymneufeld.ch>
wrote:
Hi
Am Sa., 2. Nov. 2019 um 08:51 Uhr schrieb Strahil Nikolov
<hunter86_bg(a)yahoo.com>:
> Have you tried with another ISO ?
This is quite weird, still better than my initial testing but here it
goes. I've slimmed down my attempts to Q35 and UEFI (both on and off):
- Server 2019 ISO boots into installer with or without SecureBoot
enabled (I clearly remember it didn't work in any combination I've
tried, but now it did, anyhow). The OS installes and boots with
SecureBoot enabled
- Server 2016 ISO fails to boot right at the windows bootloader*,
however I don't care for Server 2016 that much anymore at that point
in time, and it could well be that the ISO image could be of an older
revision
(MS does release updated images from time to time)
- Debian 10 boots of the CD, however it doesn't seem like NVRAM
changes are saved in oVirt / RHV guests yet. So at boot the OS doesn't
start and you have to once boot from file (EFI disk -> EFI -> debian
-> shimx64.efi)
After the boot you you have to copy all (or only shimx64.efi?) to
/boot/efi/EFI/BOOT as BOOTX64.EFI like Windows. Debian 10 has a
Microsoft-signed shim loader so SecureBoot actually works.
- Ubuntu 18.04 boots of the disc, installs and boots since their
installer puts a copy of shimx64.efi into /boot/efi/EFI/BOOT which is
where OVMF looks for a loader
I'm I correctly guessing based on looking at the "VM devices" list per
VM that oVirt/RHV doesn't yet provide a way to provide a persistent
NVRAM image to guests?
Sso for the time being we're actually stuck on Linux systems to have a
EFI/BOOT/BOOTX64.EFI present? Is this the issue you wrote about?
(I've encountered this very same issue on plain KVM and Proxmox, in
both cases a small disk image is required per VM to make the content
of the NVRAM persistent across VM reboots)
Regards
Mathieu
* See screenshot uploaded here: https://imgur.com/a/ZsnbCOM
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PTQRSIUTCWI...
11:20 p.m.
New subject: oVirt/RHV 4.3.6: How to boot a Q35/UEFI VM from CD?
Hi
The first issue of booting UEFI guests at all is resolved, honestly I
don't know what I messed up the first time with Windows guests.
TL;DR: Q35 and UEFI (with or without SecureBoot) should do the job in
many cases.
Can you give a try of the workaround in
https://bugzilla.redhat.com/show_bug.cgi?id=1727987#c0 ?
At least it works for RHEL 8 (and most probably CentOS 8).
Thanks for pointing to
this Bugzilla. But no, I'm pretty certain it's
only partially related in the case for Debian.
I've tried to replicate your findings with both RHEL and CentOS 8.0
ISOs but failed to get the guests booted into the installed
(Stops at "pciehp... Failed to check link status") nonetheless I'll
share my findings with Debian on that bug if possible.
TL;DR: The issue affecting Debian and openSuse however ends up being the same:
Lack of a persistent NVRAM in oVirt guests as Michael Skrivanek as
outlined there.
While openSuse has its own signing keys but in the "default
right"place for OVMF (boot/bootx64.efi), Debian has obtained a
Microsoft-signed shim loader like RHEL but doesn't put in the place
where the non-persisted OVMF is looking for (debian/shimx64.efi).
("mokutil --db" from a UEFI guest shows the 2 main Microsoft UEFI CAs
included in the OVMF image of oVirt guests.)
Ubuntu - confirmed with 18.04 - seems to do something clever: They
seem to put an extra copy of ubuntu/shimx64.efi into the
default location boot/boox64.efi where even the most broken UEFI
implementations (read: often old physical ones in my experience) look
for a loader.
RHEL8 seems to do a similar thing on other UEFI platforms, but I've
only been able to get RHEL8 booted/installed in UEFI mode on (FreeBSD)
bhyve
as of writing.
Debian doesn't do that sort of thing (yet) so you need to copy
debian/shimx64.efi to BOOT/BOOTX64.EFI then booting works.
You need to manually update that copy on Debian whenever they ship a
new version of that binary but at least it does work.
Regards,
Mathieu
1636
days inactive
1637
days old
1 comments
2 participants
participants (2)
-
Mathieu Simon -
Strahil