On Wed, 2013-01-23 at 15:15 +0100, Roberto Fichera wrote:
I've the same exact problem. I had to manually run grub2-mkconfig
in
my
all F17 boxes.
Happened again! Sorry I'm coming back to this thread so late, but I
couldn't access my Fedora test box for a while...
Ok, here's the thing. I booted the 'Fedora with Xen...' menu entry, so
I'm sure it was working.
I run `yum upgrade', and that involved installing a new version of the
Xen packages (at the end of the update, I have 4.2.1-7).
Now, here it is what I have in my /boot/grub2/grub.cfg:
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
}
OTOH, if I run `grub2-mkconfig | less', here's what I see:
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
echo 'Loading initial ramdisk ...'
module /initramfs-3.7.6-201.fc18.x86_64.img
}
So, again, since I was able to boot _before_ the upgrade, I'm sure the
initrd entry was there. Therefore, it seems the upgrade is re-running
grub2-mkconfig, but for some reason that does not result in adding the
initramfs module loading part. It looks weird to me that, running the
script by hand later, put it back there.
Michael, does running grub2-mkconfig from within the update do something
different than running it by hand?
If I can do any more digging that can help you investigate the issue,
please, tell me. :-)
Thanks and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D,
http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)