|
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. | 
