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

[jim burns <jim_burn@xxxxxxxxxxxxx>]

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
> > 
> > <jim_burn@xxxxxxxxxxxxx> 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
> > > 
> > > <jim_burn@xxxxxxxxxxxxx> 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
> > > Xen-users@xxxxxxxxxxxxx
> > > https://lists.xen.org/xen-users
> > 
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxx
> > 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
Xen-users@xxxxxxxxxxxxx
https://lists.xen.org/xen-users