[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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
Xen-users@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.