On Mon, 2013-02-11 at 20:37 +0000, M A Young wrote:
menuentry 'Fedora, with Xen hypervisor' --class gnu-linux --class gnu --class os --class xen $menuentry_id_option 'xen-gnulinux-simple-86a900c9-aa88-49f1-a007-0facdf17b732' { insmod part_msdos insmod ext2 set root='hd0,msdos8' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos8 --hint-efi=hd0,msdos8 --hint-baremetal=ahci0,msdos8 20f18f9a-c006-4d92-93d2-bf053c163638 else search --no-floppy --fs-uuid --set=root 20f18f9a-c006-4d92-93d2-bf053c163638 fi echo 'Loading Xen xen ...' multiboot /xen.gz placeholder echo 'Loading Linux 3.7.6-201.fc18.x86_64 ...' module /vmlinuz-3.7.6-201.fc18.x86_64 placeholder root=/dev/mapper/host-fedora_root ro }
Did you update the kernel at the same time?
Well, it can definitely be. In this specific case, I `yum upgrade'-ed the system after a while and it installed both a new kernel and a new Xen (along with a bunch of other stuff, of course).
That looks like what you might get with grubby which is run (which doesn't handle xen very well, which is why xen-hypervisor runs grub2-mkconfig).
Mmm... I see. Well, I think it's quite possible that a kernel and a xen update happen at the same time, so this seems quite an issue to me... Am I wrong?
What can we do to improve the situation? Should I open a bug against grubby?
Thanks and Regards, Dario