[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |