Grub cause problems while loading xen.efi on many machines, mostly
because xen.efi support loading dom0 kernel and initramfs only via EFI
services and xen.efi needs to be loaded through them too. But grub in
some cases uses own filesystem handling code instead, leaving xen.efi
without dom0 kernel.
This should improve when xen.efi will get multiboot2 support (Xen 4.10?)
- then grub could load dom0 kernel and initramfs too and pass them to
xen.efi.
For now, bypass grub and launch xen.efi directly. This have unfortunate
effect of not having boot menu, so choose the most universal option:
verbose, with all known workarounds for UEFI applied.
FixesQubesOS/qubes-issues#3505
When installation image is written on Windows, it automatically (by the
OS) gets mounted and Windows create "System Volume Information" there.
This obviously means the installation media is modified and then fails
verification.
This is really wrong from the Windows side to automatically modify some
files behind users back. But since we can prevent this with really low
cost by just creating those files ourself and reduce a lot of user
confusion, just do it.
Thanks @pbatard for the help.
FixesQubesOS/qubes-issues#2051
xen.efi needs to call EFI services to access kernel and initramfs
images. For that it needs correct device handle. Grub set it to 'root'
device, regardless of which device was really used to load xen.efi.
Apparently all but first parameters are passed to xen.efi, so it is possible to
select which config section should be used. This makes xen.efi copy
unnecessary.
Anaconda/pungi doesn't support multiple versions of the same package at
the time, so place all kernels on installation media in separate
directory and install them in %post script.
...even if NetworkManager is running.
Actually it is started by anaconda (and needed to provide D-Bus
interface) even if service disabled in systemd configuration.
