Xen must be on a 2Mb boundary

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Xen must be on a 2Mb boundary

jim burns
I get the error msg in the Subject when trying to boot xen via xen.efi on
Fedora 25, kernels 4.8 - 4.10, xen 4.7 or 4.8.

My grub2 stanza is:

menuentry "Xen EFI" --class os {
    insmod part_gpt
    insmod search_fs_uuid
    insmod chain
    set root='hd0,gpt8'
    chainloader (hd0,gpt8)/EFI/fedora/xen-4.8.0.efi
}

and my xen.cfg is:

[global]
default=fedora
chain=grub.cfg

[fedora]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz ro root=/dev/mapper/vg_insp3847-lv_root microcode.early=y
earlyprintk=vga
ramdisk=initramfs.img
ucode=GenuineIntel.bin

[kernel 4.9.10]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz-4.9.10-200.fc25.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
microcode.early=y earlyprintk=vga
ramdisk=initramfs-4.9.10-200.fc25.x86_64.img
ucode=GenuineIntel.bin

[kernel 4.8.16]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz-4.8.16-300.fc25.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
microcode.early=y earlyprintk=vga
ramdisk=initramfs-4.8.16-300.fc25.x86_64.img
ucode=GenuineIntel.bin

[kernel 4.7.9]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz-4.7.9-300.fc24.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
microcode.early=y earlyprintk=vga
ramdisk=initramfs-4.7.9-300.fc24.x86_64.img
ucode=GenuineIntel.bin

[kernel 4.6.7]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz-4.6.7-300.fc24.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
microcode.early=y earlyprintk=vga
ramdisk=initramfs-4.6.7-300.fc24.x86_64.img
ucode=GenuineIntel.bin


I've tried xen.cfg w/o the extra kernel 4.x stanzas. All files are in the same
sub directory of the ESP.

Anybody have any ideas? Thx.


_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Xen must be on a 2Mb boundary

Mark Pryor
Hello,

I see "All files are in the same
sub directory of the ESP."


As noted above, you might try with efibootmgr to make a menu entry in the EFI bios. I think this is a simpler approach than chain loading via grub.

Are you using the Xen rpms from distro, or did you build from source? I have a spec and SRPM from xen-4.7 & fc25 that should work with xen-4.8, but have not done that particular build yet.

PryMar56


On Wednesday, February 22, 2017 9:10 AM, jim burns <[hidden email]> wrote:


I get the error msg in the Subject when trying to boot xen via xen.efi on
Fedora 25, kernels 4.8 - 4.10, xen 4.7 or 4.8.

My grub2 stanza is:

menuentry "Xen EFI" --class os {
    insmod part_gpt
    insmod search_fs_uuid
    insmod chain
    set root='hd0,gpt8'
    chainloader (hd0,gpt8)/EFI/fedora/xen-4.8.0.efi
}

and my xen.cfg is:

[global]
default=fedora
chain=grub.cfg

[fedora]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz ro root=/dev/mapper/vg_insp3847-lv_root microcode.early=y
earlyprintk=vga
ramdisk=initramfs.img
ucode=GenuineIntel.bin

[kernel 4.9.10]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz-4.9.10-200.fc25.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
microcode.early=y earlyprintk=vga
ramdisk=initramfs-4.9.10-200.fc25.x86_64.img
ucode=GenuineIntel.bin

[kernel 4.8.16]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz-4.8.16-300.fc25.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
microcode.early=y earlyprintk=vga
ramdisk=initramfs-4.8.16-300.fc25.x86_64.img
ucode=GenuineIntel.bin

[kernel 4.7.9]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz-4.7.9-300.fc24.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
microcode.early=y earlyprintk=vga
ramdisk=initramfs-4.7.9-300.fc24.x86_64.img
ucode=GenuineIntel.bin

[kernel 4.6.7]
options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
kernel=vmlinuz-4.6.7-300.fc24.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
microcode.early=y earlyprintk=vga
ramdisk=initramfs-4.6.7-300.fc24.x86_64.img
ucode=GenuineIntel.bin


I've tried xen.cfg w/o the extra kernel 4.x stanzas. All files are in the same
sub directory of the ESP.

Anybody have any ideas? Thx.


_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users


_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Xen must be on a 2Mb boundary

jim burns
Forgot to mention that any replies should cc: me. Thx, Mark, for doing so.

On Wednesday, 22 February 2017, 17:53:43 EST, Mark Pryor wrote:
> Hello,
> I see "All files are in the same
> sub directory of the ESP."
> https://wiki.xenproject.org/wiki/Xen_EFI
>
> As noted above, you might try with efibootmgr to make a menu entry in the
> EFI bios. I think this is a simpler approach than chain loading via grub.

Saw that page. At the bottom is the very grub stanza I'm using. I could try
efibootmgr, but I would have to change it every time xen bumps up it's version
number, and I wanted to try this stanza. Editing xen.cfg is fairly painless,
and you still need it to tell xen.efi what kernel and ramdisk to use, and what
options to use. You think grub is messing with the memory map, and that's why
xen.efi is not loading correctly?

> Are you using the Xen rpms from distro, or did you build from source? I
> have a spec and SRPM from xen-4.7 & fc25 that should work with xen-4.8, but
> have not done that particular build yet. PryMar56

The only time I compile Fedora's xen .srpm is when I add "--enable-ovmf" to
the configure command, and all I want from that is hvmloader. My win10 guest
is efi. I only do this once for every version of xen, and not for each of the
Fedora sub-revisions that don't change the xen version. Most of the time, I'm
using Fedora's official xen.efi, from rawhide.

Side note: this worked fine for xen 4.6 & 4.7. For xen 4.8, the compiled
hvmloader won't load my win10 guest (with bios='ovmf' in it's config), but the
old hvmloader from xen 4.7 still works. The 4.8 hvmloader is also smaller than
4.7, and there is a separate ovmf.bin, instead of being folded in to
hvmloader, like in previous versions.
 

>     On Wednesday, February 22, 2017 9:10 AM, jim burns
> <[hidden email]> wrote:
>
>
>  I get the error msg in the Subject when trying to boot xen via xen.efi on
> Fedora 25, kernels 4.8 - 4.10, xen 4.7 or 4.8.
>
> My grub2 stanza is:
>
> menuentry "Xen EFI" --class os {
>     insmod part_gpt
>     insmod search_fs_uuid
>     insmod chain
>     set root='hd0,gpt8'
>     chainloader (hd0,gpt8)/EFI/fedora/xen-4.8.0.efi
> }
>
> and my xen.cfg is:
>
> [global]
> default=fedora
> chain=grub.cfg
>
> [fedora]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz ro root=/dev/mapper/vg_insp3847-lv_root microcode.early=y
> earlyprintk=vga
> ramdisk=initramfs.img
> ucode=GenuineIntel.bin
>
> [kernel 4.9.10]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz-4.9.10-200.fc25.x86_64 ro
> root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> ramdisk=initramfs-4.9.10-200.fc25.x86_64.img
> ucode=GenuineIntel.bin
>
> [kernel 4.8.16]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz-4.8.16-300.fc25.x86_64 ro
> root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> ramdisk=initramfs-4.8.16-300.fc25.x86_64.img
> ucode=GenuineIntel.bin
>
> [kernel 4.7.9]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz-4.7.9-300.fc24.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
> microcode.early=y earlyprintk=vga
> ramdisk=initramfs-4.7.9-300.fc24.x86_64.img
> ucode=GenuineIntel.bin
>
> [kernel 4.6.7]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz-4.6.7-300.fc24.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
> microcode.early=y earlyprintk=vga
> ramdisk=initramfs-4.6.7-300.fc24.x86_64.img
> ucode=GenuineIntel.bin
>
>
> I've tried xen.cfg w/o the extra kernel 4.x stanzas. All files are in the
> same sub directory of the ESP.
>
> Anybody have any ideas? Thx.
>
>
> _______________________________________________
> Xen-users mailing list
> [hidden email]
> https://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Xen must be on a 2Mb boundary

Mark Pryor
Looking at:
$rpm2cpio xen-hypervisor-4.8.0-5.fc26.x86_64.rpm | cpio -ivd *.config
./boot/xen-4.8.0.config
6484 blocks

I see that livepatch is enabled. If you think that the grub-chainboot-xen.efi failure is new with the livepatch support, it might be a good idea to turn it off and  `make xen` again.

I would test this, but I have no EFI hardware to test dom0.

PryMar56



On Wednesday, February 22, 2017 3:54 PM, jim burns <[hidden email]> wrote:


Forgot to mention that any replies should cc: me. Thx, Mark, for doing so.

On Wednesday, 22 February 2017, 17:53:43 EST, Mark Pryor wrote:
> Hello,
> I see "All files are in the same
> sub directory of the ESP."
> https://wiki.xenproject.org/wiki/Xen_EFI
>
> As noted above, you might try with efibootmgr to make a menu entry in the
> EFI bios. I think this is a simpler approach than chain loading via grub.

Saw that page. At the bottom is the very grub stanza I'm using. I could try
efibootmgr, but I would have to change it every time xen bumps up it's version
number, and I wanted to try this stanza. Editing xen.cfg is fairly painless,
and you still need it to tell xen.efi what kernel and ramdisk to use, and what
options to use. You think grub is messing with the memory map, and that's why
xen.efi is not loading correctly?

> Are you using the Xen rpms from distro, or did you build from source? I
> have a spec and SRPM from xen-4.7 & fc25 that should work with xen-4.8, but
> have not done that particular build yet. PryMar56

The only time I compile Fedora's xen .srpm is when I add "--enable-ovmf" to
the configure command, and all I want from that is hvmloader. My win10 guest
is efi. I only do this once for every version of xen, and not for each of the
Fedora sub-revisions that don't change the xen version. Most of the time, I'm
using Fedora's official xen.efi, from rawhide.

Side note: this worked fine for xen 4.6 & 4.7. For xen 4.8, the compiled
hvmloader won't load my win10 guest (with bios='ovmf' in it's config), but the
old hvmloader from xen 4.7 still works. The 4.8 hvmloader is also smaller than
4.7, and there is a separate ovmf.bin, instead of being folded in to
hvmloader, like in previous versions.

>    On Wednesday, February 22, 2017 9:10 AM, jim burns
> <[hidden email]> wrote:
>
>
>  I get the error msg in the Subject when trying to boot xen via xen.efi on
> Fedora 25, kernels 4.8 - 4.10, xen 4.7 or 4.8.
>
> My grub2 stanza is:
>
> menuentry "Xen EFI" --class os {
>    insmod part_gpt
>    insmod search_fs_uuid
>    insmod chain
>    set root='hd0,gpt8'
>    chainloader (hd0,gpt8)/EFI/fedora/xen-4.8.0.efi
> }
>
> and my xen.cfg is:
>
> [global]
> default=fedora
> chain=grub.cfg
>
> [fedora]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz ro root=/dev/mapper/vg_insp3847-lv_root microcode.early=y
> earlyprintk=vga
> ramdisk=initramfs.img
> ucode=GenuineIntel.bin
>
> [kernel 4.9.10]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz-4.9.10-200.fc25.x86_64 ro
> root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> ramdisk=initramfs-4.9.10-200.fc25.x86_64.img
> ucode=GenuineIntel.bin
>
> [kernel 4.8.16]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz-4.8.16-300.fc25.x86_64 ro
> root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> ramdisk=initramfs-4.8.16-300.fc25.x86_64.img
> ucode=GenuineIntel.bin
>
> [kernel 4.7.9]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz-4.7.9-300.fc24.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
> microcode.early=y earlyprintk=vga
> ramdisk=initramfs-4.7.9-300.fc24.x86_64.img
> ucode=GenuineIntel.bin
>
> [kernel 4.6.7]
> options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> kernel=vmlinuz-4.6.7-300.fc24.x86_64 ro root=/dev/mapper/vg_insp3847-lv_root
> microcode.early=y earlyprintk=vga
> ramdisk=initramfs-4.6.7-300.fc24.x86_64.img
> ucode=GenuineIntel.bin
>
>
> I've tried xen.cfg w/o the extra kernel 4.x stanzas. All files are in the
> same sub directory of the ESP.
>
> Anybody have any ideas? Thx.
>
>
> _______________________________________________
> Xen-users mailing list
> [hidden email]
> https://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Xen must be on a 2Mb boundary

jim burns
On Friday, 24 February 2017, 06:56:58 EST, Mark Pryor wrote:
> Looking at:$rpm2cpio xen-hypervisor-4.8.0-5.fc26.x86_64.rpm | cpio -ivd
> *.config./boot/xen-4.8.0.config 6484 blocks
>
> I see that livepatch is enabled. If you think that the
> grub-chainboot-xen.efi failure is new with the livepatch support, it might
> be a good idea to turn it off and  `make xen` again. I would test this, but
> I have no EFI hardware to test dom0.
> PryMar56

Well, I didn't say anything about livepatch, only asked if grub2 might be
messing with the memory map. However, I tried it anyway, and no difference.

I changed CONFIG_LIVEPATCH=y to =n, and recompiled the 4.8.0-1 .srpm, and
installed it. (The current Fedora rawhide version is 4.8.0-6 - it contains the
latest XSAs / CVEs). Still automatically rebooted when selecting the xen.efi
stanza in grub2. I then installed my old 4.6.3-1 rpms (from before livepatch
was available). No difference.

As long as I was doing all that rebooting anyway, I tried your efibootmgr
suggestion. Again, no difference - it just rebooted. The error msg in the
Subject goes by too quickly, so I can't be sure that it rebooted with the same
error. I used the command "efibootmgr -c -d /dev/sda8 -l EFI/fedora/
xen-4.8.0.efi -L xen", if you can see anything I omitted. (I then changed the
boot order, so "Xen" wasn't first.) None-the-less, I'm willing to say grub2
isn't having any negative effect.

BTW, now I remember why I didn't try efibootmgr before: when you boot into xen
via grub2's multiboot, the efi filesystem is not exposed. IE - there is no /
sys/firmware/efi, so efibootmgr doesn't work. You have to boot bare metal to
use efibootmgr. That's actually why I'm trying to get booting with xen.efi to
work, because it does expose the efi filesystem. Supposedly, grub2's
multiboot2 protocol should do that also, but I've never been able to get that
to work, and there is virtually no docs on it in grub 2.02. Blindly changing
multiboot to multiboot2 just gives you a "no header" error, so I'm guessing
that the xen.cfg file is different.
 

>     On Wednesday, February 22, 2017 3:54 PM, jim burns
> <[hidden email]> wrote:
>
>
>  Forgot to mention that any replies should cc: me. Thx, Mark, for doing so.
>
> On Wednesday, 22 February 2017, 17:53:43 EST, Mark Pryor wrote:
> > Hello,
> > I see "All files are in the same
> > sub directory of the ESP."
> > https://wiki.xenproject.org/wiki/Xen_EFI
> >
> > As noted above, you might try with efibootmgr to make a menu entry in the
> > EFI bios. I think this is a simpler approach than chain loading via grub.
>
> Saw that page. At the bottom is the very grub stanza I'm using. I could try
> efibootmgr, but I would have to change it every time xen bumps up it's
> version number, and I wanted to try this stanza. Editing xen.cfg is fairly
> painless, and you still need it to tell xen.efi what kernel and ramdisk to
> use, and what options to use. You think grub is messing with the memory
> map, and that's why xen.efi is not loading correctly?
>
> > Are you using the Xen rpms from distro, or did you build from source? I
> > have a spec and SRPM from xen-4.7 & fc25 that should work with xen-4.8,
> > but
> > have not done that particular build yet. PryMar56
>
> The only time I compile Fedora's xen .srpm is when I add "--enable-ovmf" to
> the configure command, and all I want from that is hvmloader. My win10 guest
> is efi. I only do this once for every version of xen, and not for each of
> the Fedora sub-revisions that don't change the xen version. Most of the
> time, I'm using Fedora's official xen.efi, from rawhide.
>
> Side note: this worked fine for xen 4.6 & 4.7. For xen 4.8, the compiled
> hvmloader won't load my win10 guest (with bios='ovmf' in it's config), but
> the old hvmloader from xen 4.7 still works. The 4.8 hvmloader is also
> smaller than 4.7, and there is a separate ovmf.bin, instead of being folded
> in to hvmloader, like in previous versions.
>
> >    On Wednesday, February 22, 2017 9:10 AM, jim burns
> >
> > <[hidden email]> wrote:
> >  I get the error msg in the Subject when trying to boot xen via xen.efi on
> >
> > Fedora 25, kernels 4.8 - 4.10, xen 4.7 or 4.8.
> >
> > My grub2 stanza is:
> >
> > menuentry "Xen EFI" --class os {
> >
> >    insmod part_gpt
> >    insmod search_fs_uuid
> >    insmod chain
> >    set root='hd0,gpt8'
> >    chainloader (hd0,gpt8)/EFI/fedora/xen-4.8.0.efi
> >
> > }
> >
> > and my xen.cfg is:
> >
> > [global]
> > default=fedora
> > chain=grub.cfg
> >
> > [fedora]
> > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > kernel=vmlinuz ro root=/dev/mapper/vg_insp3847-lv_root microcode.early=y
> > earlyprintk=vga
> > ramdisk=initramfs.img
> > ucode=GenuineIntel.bin
> >
> > [kernel 4.9.10]
> > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > kernel=vmlinuz-4.9.10-200.fc25.x86_64 ro
> > root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> > ramdisk=initramfs-4.9.10-200.fc25.x86_64.img
> > ucode=GenuineIntel.bin
> >
> > [kernel 4.8.16]
> > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > kernel=vmlinuz-4.8.16-300.fc25.x86_64 ro
> > root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> > ramdisk=initramfs-4.8.16-300.fc25.x86_64.img
> > ucode=GenuineIntel.bin
> >
> > [kernel 4.7.9]
> > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > kernel=vmlinuz-4.7.9-300.fc24.x86_64 ro
> > root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> > ramdisk=initramfs-4.7.9-300.fc24.x86_64.img
> > ucode=GenuineIntel.bin
> >
> > [kernel 4.6.7]
> > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > kernel=vmlinuz-4.6.7-300.fc24.x86_64 ro
> > root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> > ramdisk=initramfs-4.6.7-300.fc24.x86_64.img
> > ucode=GenuineIntel.bin
> >
> >
> > I've tried xen.cfg w/o the extra kernel 4.x stanzas. All files are in the
> > same sub directory of the ESP.
> >
> > Anybody have any ideas? Thx.
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > [hidden email]
> > https://lists.xen.org/xen-users
>
> _______________________________________________
> Xen-users mailing list
> [hidden email]
> https://lists.xen.org/xen-users



_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Xen must be on a 2Mb boundary

Dario Faggioli-2
With the foreword that I don't know anything about EFI, so I may very
well talk nonsense, but...

On Mon, 2017-02-27 at 19:28 -0500, jim burns wrote:

> As long as I was doing all that rebooting anyway, I tried your
> efibootmgr 
> suggestion. Again, no difference - it just rebooted. The error msg in
> the 
> Subject goes by too quickly, so I can't be sure that it rebooted with
> the same 
> error. I used the command "efibootmgr -c -d /dev/sda8 -l EFI/fedora/
> xen-4.8.0.efi -L xen", if you can see anything I omitted. (I then
> changed the 
> boot order, so "Xen" wasn't first.) None-the-less, I'm willing to say
> grub2 
> isn't having any negative effect.
>
If it's Xen that is rebooting, there is a 'noreboot' command line
option.

But in general, if you think you're hitting a bug, or a configuration
that was working with a certain version of Xen, and is no longer
working right now/on a later one, please consider reporting this whole
thing to xen-devel.

You're probably know already most of all what's in this page, but just
in case, and FTR:
https://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project

Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Xen must be on a 2Mb boundary

jim burns
On Wednesday, 1 March 2017, 13:15:08 EST, Dario Faggioli wrote:

> With the foreword that I don't know anything about EFI, so I may very
> well talk nonsense, but...
>
> On Mon, 2017-02-27 at 19:28 -0500, jim burns wrote:
> > As long as I was doing all that rebooting anyway, I tried your
> > efibootmgr
> > suggestion. Again, no difference - it just rebooted. The error msg in
> > the
> > Subject goes by too quickly, so I can't be sure that it rebooted with
> > the same
> > error. I used the command "efibootmgr -c -d /dev/sda8 -l EFI/fedora/
> > xen-4.8.0.efi -L xen", if you can see anything I omitted. (I then
> > changed the
> > boot order, so "Xen" wasn't first.) None-the-less, I'm willing to say
> > grub2
> > isn't having any negative effect.
>
> If it's Xen that is rebooting, there is a 'noreboot' command line
> option.

Thanx - I would have considered that if I had gotten ANY Xen boot msgs.
However, I'm just getting the brief err msg in the Subject, when I can see it,
and then a reboot. And booting with grub2 multiboot works fine, so I was
hoping someone would notice something that could be tweaked in my xen.cfg.

> But in general, if you think you're hitting a bug, or a configuration
> that was working with a certain version of Xen, and is no longer
> working right now/on a later one, please consider reporting this whole
> thing to xen-devel.

It has in fact worked a handful of times, just mostly not. Unfortunately, I
did not record what versions of Xen and the kernel it worked for, so I can't
duplicate it. If I can get more info on the problem, it might be worth
reporting to xen-devel.

> You're probably know already most of all what's in this page, but just
> in case, and FTR:
> https://wiki.xen.org/wiki/Reporting_Bugs_against_Xen_Project
>
> Regards,
> Dario
> --
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Xen must be on a 2Mb boundary

jim burns
In reply to this post by Dario Faggioli-2
On Wednesday, 1 March 2017, 13:15:08 EST, Dario Faggioli wrote:
> But in general, if you think you're hitting a bug, or a configuration
> that was working with a certain version of Xen, and is no longer
> working right now/on a later one, please consider reporting this whole
> thing to xen-devel.

Searching Markmail for that error msg, it turns out Jan Beulich did the
original EFI boot code implementation in 2011, and patched it again in 2013.
That error msg is in xen/arch/x86/efi/efi-boot.h, and removed from xen/common/
efi/boot.c in 2014.

Interestingly enough, "grep -a boundary" on xen.efi does NOT turn up this
error msg, so I don't know who is printing it.

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Xen must be on a 2Mb boundary

Dario Faggioli-2
On Wed, 2017-03-01 at 19:23 -0500, jim burns wrote:

> Searching Markmail for that error msg, it turns out Jan Beulich did
> the 
> original EFI boot code implementation in 2011, and patched it again
> in 2013. 
> That error msg is in xen/arch/x86/efi/efi-boot.h, and removed from
> xen/common/
> efi/boot.c in 2014.
>
> Interestingly enough, "grep -a boundary" on xen.efi does NOT turn up
> this 
> error msg, so I don't know who is printing it.
>
I see. Well, I'm sorry of not being able to help on the specific
subject, as I've never played with it.

Again, I can only advise to consider sending an email xen-devel, Cc-ing
relevant maintainers and involved party.

Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Xen must be on a 2Mb boundary - Solved!

jim burns
In reply to this post by jim burns
Not top-posting the solution, as per list etiquette. Pls cc: me w/ any
response.

On Monday, 27 February 2017, 19:28:27 EST, jim burns wrote:

> On Friday, 24 February 2017, 06:56:58 EST, Mark Pryor wrote:
> > Looking at:$rpm2cpio xen-hypervisor-4.8.0-5.fc26.x86_64.rpm | cpio -ivd
> > *.config./boot/xen-4.8.0.config 6484 blocks
> >
> > I see that livepatch is enabled. If you think that the
> > grub-chainboot-xen.efi failure is new with the livepatch support, it might
> > be a good idea to turn it off and  `make xen` again. I would test this,
> > but
> > I have no EFI hardware to test dom0.
> > PryMar56
>
> Well, I didn't say anything about livepatch, only asked if grub2 might be
> messing with the memory map. However, I tried it anyway, and no difference.
>
> I changed CONFIG_LIVEPATCH=y to =n, and recompiled the 4.8.0-1 .srpm, and
> installed it. (The current Fedora rawhide version is 4.8.0-6 - it contains
> the latest XSAs / CVEs). Still automatically rebooted when selecting the
> xen.efi stanza in grub2. I then installed my old 4.6.3-1 rpms (from before
> livepatch was available). No difference.
>
> As long as I was doing all that rebooting anyway, I tried your efibootmgr
> suggestion. Again, no difference - it just rebooted. The error msg in the
> Subject goes by too quickly, so I can't be sure that it rebooted with the
> same error. I used the command "efibootmgr -c -d /dev/sda8 -l EFI/fedora/
> xen-4.8.0.efi -L xen", if you can see anything I omitted. (I then changed
> the boot order, so "Xen" wasn't first.) None-the-less, I'm willing to say
> grub2 isn't having any negative effect.
>
> BTW, now I remember why I didn't try efibootmgr before: when you boot into
> xen via grub2's multiboot, the efi filesystem is not exposed. IE - there is
> no / sys/firmware/efi, so efibootmgr doesn't work. You have to boot bare
> metal to use efibootmgr. That's actually why I'm trying to get booting with
> xen.efi to work, because it does expose the efi filesystem. Supposedly,
> grub2's multiboot2 protocol should do that also, but I've never been able
> to get that to work, and there is virtually no docs on it in grub 2.02.
> Blindly changing multiboot to multiboot2 just gives you a "no header"
> error, so I'm guessing that the xen.cfg file is different.
>
> >     On Wednesday, February 22, 2017 3:54 PM, jim burns
> >
> > <[hidden email]> wrote:
> >  Forgot to mention that any replies should cc: me. Thx, Mark, for doing
> >  so.
> >
> > On Wednesday, 22 February 2017, 17:53:43 EST, Mark Pryor wrote:
> > > Hello,
> > > I see "All files are in the same
> > > sub directory of the ESP."
> > > https://wiki.xenproject.org/wiki/Xen_EFI
> > >
> > > As noted above, you might try with efibootmgr to make a menu entry in
> > > the
> > > EFI bios. I think this is a simpler approach than chain loading via
> > > grub.
> >
> > Saw that page. At the bottom is the very grub stanza I'm using. I could
> > try
> > efibootmgr, but I would have to change it every time xen bumps up it's
> > version number, and I wanted to try this stanza. Editing xen.cfg is fairly
> > painless, and you still need it to tell xen.efi what kernel and ramdisk to
> > use, and what options to use. You think grub is messing with the memory
> > map, and that's why xen.efi is not loading correctly?
> >
> > > Are you using the Xen rpms from distro, or did you build from source? I
> > > have a spec and SRPM from xen-4.7 & fc25 that should work with xen-4.8,
> > > but
> > > have not done that particular build yet. PryMar56
> >
> > The only time I compile Fedora's xen .srpm is when I add "--enable-ovmf"
> > to
> > the configure command, and all I want from that is hvmloader. My win10
> > guest is efi. I only do this once for every version of xen, and not for
> > each of the Fedora sub-revisions that don't change the xen version. Most
> > of the time, I'm using Fedora's official xen.efi, from rawhide.
> >
> > Side note: this worked fine for xen 4.6 & 4.7. For xen 4.8, the compiled
> > hvmloader won't load my win10 guest (with bios='ovmf' in it's config), but
> > the old hvmloader from xen 4.7 still works. The 4.8 hvmloader is also
> > smaller than 4.7, and there is a separate ovmf.bin, instead of being
> > folded
> > in to hvmloader, like in previous versions.
> >
> > >    On Wednesday, February 22, 2017 9:10 AM, jim burns
> > >
> > > <[hidden email]> wrote:
> > >  I get the error msg in the Subject when trying to boot xen via xen.efi
> > >  on
> > >
> > > Fedora 25, kernels 4.8 - 4.10, xen 4.7 or 4.8.
> > >
> > > My grub2 stanza is:
> > >
> > > menuentry "Xen EFI" --class os {
> > >
> > >    insmod part_gpt
> > >    insmod search_fs_uuid
> > >    insmod chain
> > >    set root='hd0,gpt8'
> > >    chainloader (hd0,gpt8)/EFI/fedora/xen-4.8.0.efi
> > >
> > > }
> > >
> > > and my xen.cfg is:
> > >
> > > [global]
> > > default=fedora
> > > chain=grub.cfg
> > >
> > > [fedora]
> > > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > > kernel=vmlinuz ro root=/dev/mapper/vg_insp3847-lv_root microcode.early=y
> > > earlyprintk=vga
> > > ramdisk=initramfs.img
> > > ucode=GenuineIntel.bin
> > >
> > > [kernel 4.9.10]
> > > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > > kernel=vmlinuz-4.9.10-200.fc25.x86_64 ro
> > > root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> > > ramdisk=initramfs-4.9.10-200.fc25.x86_64.img
> > > ucode=GenuineIntel.bin
> > >
> > > [kernel 4.8.16]
> > > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > > kernel=vmlinuz-4.8.16-300.fc25.x86_64 ro
> > > root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> > > ramdisk=initramfs-4.8.16-300.fc25.x86_64.img
> > > ucode=GenuineIntel.bin
> > >
> > > [kernel 4.7.9]
> > > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > > kernel=vmlinuz-4.7.9-300.fc24.x86_64 ro
> > > root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> > > ramdisk=initramfs-4.7.9-300.fc24.x86_64.img
> > > ucode=GenuineIntel.bin
> > >
> > > [kernel 4.6.7]
> > > options=dom0_mem=min:4G,max:16G cpufreq=xen loglvl=all guest_loglvl=all
> > > ucode=scan tmem=1 tmem_dedup=1 tmem_compress=1 nmi=dom0 vpmu=1
> > > kernel=vmlinuz-4.6.7-300.fc24.x86_64 ro
> > > root=/dev/mapper/vg_insp3847-lv_root microcode.early=y earlyprintk=vga
> > > ramdisk=initramfs-4.6.7-300.fc24.x86_64.img
> > > ucode=GenuineIntel.bin
> > >
> > >
> > > I've tried xen.cfg w/o the extra kernel 4.x stanzas. All files are in
> > > the
> > > same sub directory of the ESP.
> > >
> > > Anybody have any ideas? Thx.
> > >
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > [hidden email]
> > > https://lists.xen.org/xen-users
> >
> > _______________________________________________
> > Xen-users mailing list
> > [hidden email]
> > https://lists.xen.org/xen-users

Cleaning up old error posts.

It was my fault. Even tho' I said 'ramdisk=initramfs.img' in my config file, I
was calling the file initramfs in EFI/fedora on the ESP :-( :-( it works fine
now!

Still having a problem with multiboot2 tho'. Since (I think) xen 4.9, grub2 no
longer complains about 'no header file' when using multiboot2 / module2.
Instead, that grub2 stanza,as below, just prints out the 'echo's, then hangs.
I have to hard reset by holding down the power button for a count of 10.
However, I don't think I've tried it since upgrading from Fedora 26 to 27.
Something's changed: grub2-mkconfig didn't used to automatically put in
multiboot2 / module2, with the corresponding insmods. I had to manually edit
the stanza at boot time. If it still is a problem, I will post back to the
list. (I also noticed that https://wiki.xen.org/wiki/Xen_EFI has changed since
this thread was originally posted in Feb, but no real clues there - if it is
indeed still a problem.)

menuentry 'Fedora, with Xen hypervisor' --class fedora --class gnu-linux --
class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-
simple-585a3a81-9488-4a25-b52a-462d49f259e8' {
        insmod part_gpt
        insmod lvm
        insmod xfs
        set root='lvmid/O9lzrN-0X2i-PC0D-3mep-YqgN-kKeg-9ITZr7/UdGj2y-MkkI-
bwJ4-RZth-UtvW-NOuC-aw1G3w'
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root --hint='lvmid/O9lzrN-0X2i-
PC0D-3mep-YqgN-kKeg-9ITZr7/UdGj2y-MkkI-bwJ4-RZth-UtvW-NOuC-aw1G3w'  
585a3a81-9488-4a25-b52a-462d49f259e8
        else
          search --no-floppy --fs-uuid --set=root 585a3a81-9488-4a25-
b52a-462d49f259e8
        fi
        echo    'Loading Xen 4.9.0 ...'
        if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
            xen_rm_opts=
        else
            xen_rm_opts="no-real-mode edd=off"
        fi
        insmod module2
        insmod multiboot2
        multiboot2      /boot/xen-4.9.0.gz placeholder dom0_mem=min:4G,max:16G
cpufreq=xen loglvl=all guest_loglvl=all ucode=scan tmem=1 tmem_dedup=1
tmem_compress=1 nmi=dom0 vpmu=1 iommu=dom0-passthrough noreboot #dom0=pvh
#watchdog=tru
e  ${xen_rm_opts}
        echo    'Loading Linux 4.15.0-0.rc0.git1.1.fc28.x86_64 ...'
        module2 /boot/vmlinuz-4.15.0-0.rc0.git1.1.fc28.x86_64 placeholder
root=/dev/mapper/vg_insp3847-lv_root ro microcode.early=y earlyprintk=vga
iommu=soft
        echo    'Loading initial ramdisk ...'
        insmod module2
        module2 --nounzip   /boot/
initramfs-4.15.0-0.rc0.git1.1.fc28.x86_64.img
}


_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xen.org/xen-users
Reply | Threaded
Open this post in threaded view
|

Grub2 multiboot2 hangs (was Re: Xen must be on a 2Mb boundary - Solved!)

jim burns
Pls cc me w/any replies.

On Friday, 17 November 2017, 14:09:14 EST, jim burns wrote:

> Still having a problem with multiboot2 tho'. Since (I think) xen 4.9, grub2
> no longer complains about 'no header file' when using multiboot2 / module2.
> Instead, that grub2 stanza,as below, just prints out the 'echo's, then
> hangs. I have to hard reset by holding down the power button for a count of
> 10. However, I don't think I've tried it since upgrading from Fedora 26 to
> 27. Something's changed: grub2-mkconfig didn't used to automatically put in
> multiboot2 / module2, with the corresponding insmods. I had to manually
> edit the stanza at boot time. If it still is a problem, I will post back to
> the list. (I also noticed that https://wiki.xen.org/wiki/Xen_EFI has
> changed since this thread was originally posted in Feb, but no real clues
> there - if it is indeed still a problem.)
>
> menuentry 'Fedora, with Xen hypervisor' --class fedora --class gnu-linux --
> class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-
> simple-585a3a81-9488-4a25-b52a-462d49f259e8' {
>         insmod part_gpt
>         insmod lvm
>         insmod xfs
>         set root='lvmid/O9lzrN-0X2i-PC0D-3mep-YqgN-kKeg-9ITZr7/UdGj2y-MkkI-
> bwJ4-RZth-UtvW-NOuC-aw1G3w'
>         if [ x$feature_platform_search_hint = xy ]; then
>           search --no-floppy --fs-uuid --set=root --hint='lvmid/O9lzrN-0X2i-
> PC0D-3mep-YqgN-kKeg-9ITZr7/UdGj2y-MkkI-bwJ4-RZth-UtvW-NOuC-aw1G3w'
> 585a3a81-9488-4a25-b52a-462d49f259e8
>         else
>           search --no-floppy --fs-uuid --set=root 585a3a81-9488-4a25-
> b52a-462d49f259e8
>         fi
>         echo    'Loading Xen 4.9.0 ...'
>         if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then
>             xen_rm_opts=
>         else
>             xen_rm_opts="no-real-mode edd=off"
>         fi
>         insmod module2
>         insmod multiboot2
>         multiboot2    /boot/xen-4.9.0.gz placeholder dom0_mem=min:4G,max:16G
> cpufreq=xen loglvl=all guest_loglvl=all ucode=scan tmem=1  tmem_dedup=1
> tmem_compress=1 nmi=dom0 vpmu=1 iommu=dom0-passthrough noreboot #dom0=pvh
> #watchdog=true  ${xen_rm_opts}
>         echo    'Loading Linux 4.15.0-0.rc0.git1.1.fc28.x86_64 ...'
>         module2 /boot/vmlinuz-4.15.0-0.rc0.git1.1.fc28.x86_64 placeholder
> root=/dev/mapper/vg_insp3847-lv_root ro microcode.early=y earlyprintk=vga
> iommu=soft
>
>         echo    'Loading initial ramdisk ...'
>         insmod module2
>         module2 --nounzip   /boot/
> initramfs-4.15.0-0.rc0.git1.1.fc28.x86_64.img
> }

Nope - still hanging on me. The "insmod module2"s above are unnecessary, since
module2 is a sub function of multiboot2, and in fact they cause a harmless
error msg to be printed out. Removing the "insmod module2"s still produces a
hang. Removing all "insmod module2/multiboot2"s still produces a hang. (The
.mod's are on the module search path.) (And the xen 4.9.0's are now 4.9.1)

Maybe this is a grub2 error, but I'm sure that the xen devs had a hand in this
too.

_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users
Reply | Threaded
Open this post in threaded view
|

Re: Grub2 multiboot2 hangs - Solved

jim burns

Pls cc me w/any replies.

 

On Wednesday, 29 November 2017, 19:52:39 EST, jim burns wrote:

> On Friday, 17 November 2017, 14:09:14 EST, jim burns wrote:

> > Still having a problem with multiboot2 tho'. Since (I think) xen 4.9,

> > grub2

> > no longer complains about 'no header file' when using multiboot2 /

> > module2.

> > Instead, that grub2 stanza,as below, just prints out the 'echo's, then

> > hangs. I have to hard reset by holding down the power button for a count

> > of

> > 10. However, I don't think I've tried it since upgrading from Fedora 26 to

> > 27. Something's changed: grub2-mkconfig didn't used to automatically put

> > in

> > multiboot2 / module2, with the corresponding insmods. I had to manually

> > edit the stanza at boot time. If it still is a problem, I will post back

> > to

> > the list. (I also noticed that https://wiki.xen.org/wiki/Xen_EFI has

> > changed since this thread was originally posted in Feb, but no real clues

> > there - if it is indeed still a problem.)

> >

> > menuentry 'Fedora, with Xen hypervisor' --class fedora --class gnu-linux

> > --

> > class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-

> > simple-585a3a81-9488-4a25-b52a-462d49f259e8' {

> >

> > insmod part_gpt

> > insmod lvm

> > insmod xfs

> > set

> > root='lvmid/O9lzrN-0X2i-PC0D-3mep-YqgN-kKeg-9ITZr7/UdGj2y-MkkI-

> >

> > bwJ4-RZth-UtvW-NOuC-aw1G3w'

> >

> > if [ x$feature_platform_search_hint = xy ]; then

> >

> > search --no-floppy --fs-uuid --set=root

> > --hint='lvmid/O9lzrN-0X2i-

> >

> > PC0D-3mep-YqgN-kKeg-9ITZr7/UdGj2y-MkkI-bwJ4-RZth-UtvW-NOuC-aw1G3w'

> > 585a3a81-9488-4a25-b52a-462d49f259e8

> >

> > else

> >

> > search --no-floppy --fs-uuid --set=root 585a3a81-9488-4a25-

> >

> > b52a-462d49f259e8

> >

> > fi

> > echo 'Loading Xen 4.9.0 ...'

> > if [ "$grub_platform" = "pc" -o "$grub_platform" = "" ]; then

> >

> > xen_rm_opts=

> >

> > else

> >

> > xen_rm_opts="no-real-mode edd=off"

> >

> > fi

> > insmod module2

> > insmod multiboot2

> > multiboot2 /boot/xen-4.9.0.gz placeholder

> > dom0_mem=min:4G,max:16G

> >

> > cpufreq=xen loglvl=all guest_loglvl=all ucode=scan tmem=1 tmem_dedup=1

> > tmem_compress=1 nmi=dom0 vpmu=1 iommu=dom0-passthrough noreboot #dom0=pvh

> > #watchdog=true ${xen_rm_opts}

> >

> > echo 'Loading Linux 4.15.0-0.rc0.git1.1.fc28.x86_64 ...'

> > module2 /boot/vmlinuz-4.15.0-0.rc0.git1.1.fc28.x86_64 placeholder

> >

> > root=/dev/mapper/vg_insp3847-lv_root ro microcode.early=y earlyprintk=vga

> > iommu=soft

> >

> > echo 'Loading initial ramdisk ...'

> > insmod module2

> > module2 --nounzip /boot/

> >

> > initramfs-4.15.0-0.rc0.git1.1.fc28.x86_64.img

> > }

>

> Nope - still hanging on me. The "insmod module2"s above are unnecessary,

> since module2 is a sub function of multiboot2, and in fact they cause a

> harmless error msg to be printed out. Removing the "insmod module2"s still

> produces a hang. Removing all "insmod module2/multiboot2"s still produces a

> hang. (The .mod's are on the module search path.) (And the xen 4.9.0's are

> now 4.9.1)

>

> Maybe this is a grub2 error, but I'm sure that the xen devs had a hand in

> this too.

 

Turns out if you do a major upgrade, like from Fedora 26 -> 27, it is advisable to refresh (copy over) the files in /boot/efi/EFI/fedora/x86_64-efi from /usr/lib/grub/x86_64-efi. Fortunately, it was not necessary to reinstall the boot tracks also. It works fine now.


_______________________________________________
Xen-users mailing list
[hidden email]
https://lists.xenproject.org/mailman/listinfo/xen-users