Hello,
I just noticed that he thing described in the subject happens, when I 'yum upgrade' both a F18 or a rawhide system, and when the updates include a new version of xen-XXX.
In some more details, what I noticed is after doing the following: - yum upgrade, and the upgrade included a new version of xen-xxx - reboot and choose 'Fedora with Xen Hypervisor' Makes the system no longer able to boot.
Just booting another option, executing manually `grub2-mkconfig -o /boot/grub/grub.cfg' and rebooting again did the trick.
So, it looks like, while installing the xen package for the first time correctly creatte the GRUB2 menu entry, updating it does not properly refreshes it. Is this happening only to me? Is this intended/supposed to happen?
If so, sorry for bothering. :-) If no, let me know if I should file a bug, or whatever else I can do to help fixing this.
Thanks and Regards, Dario
On Wed, 23 Jan 2013, Dario Faggioli wrote:
Just booting another option, executing manually `grub2-mkconfig -o /boot/grub/grub.cfg' and rebooting again did the trick.
The standard Fedora location for the grub2 configuration file is /boot/grub2/grub.cfg and this is updated for me when the xen-hypervisor package is updated, so I am not sure why your configuration is there.
Michael Young
On Wed, 2013-01-23 at 12:17 +0000, M A Young wrote:
On Wed, 23 Jan 2013, Dario Faggioli wrote:
Just booting another option, executing manually `grub2-mkconfig -o /boot/grub/grub.cfg' and rebooting again did the trick.
The standard Fedora location for the grub2 configuration file is /boot/grub2/grub.cfg
Yes, your right, and hat was what I meant (I always got it wrong because I come from Debian, where the '2' is not there). Sorry.
and this is updated for me when the xen-hypervisor package is updated, so I am not sure why your configuration is there.
As said above, config is in grub2.cfg for me too, and I'm sure that a plain reboot, following an upgrade, did not succeed, until I booted a non-xen option and rebuild the config manually. If it works for you, it must be something related to my installation, which is annoying, but less worrisome... I don't mind rerunning grub2-mkconfig, what I wanted to make sure is it wasn't something being hit by everyone using Xen. :-)
Thanks and Regards, Dario
On 01/23/2013 03:05 PM, Dario Faggioli wrote:
On Wed, 2013-01-23 at 12:17 +0000, M A Young wrote:
On Wed, 23 Jan 2013, Dario Faggioli wrote:
Just booting another option, executing manually `grub2-mkconfig -o /boot/grub/grub.cfg' and rebooting again did the trick.
The standard Fedora location for the grub2 configuration file is /boot/grub2/grub.cfg
Yes, your right, and hat was what I meant (I always got it wrong because I come from Debian, where the '2' is not there). Sorry.
and this is updated for me when the xen-hypervisor package is updated, so I am not sure why your configuration is there.
As said above, config is in grub2.cfg for me too, and I'm sure that a plain reboot, following an upgrade, did not succeed, until I booted a non-xen option and rebuild the config manually. If it works for you, it must be something related to my installation, which is annoying, but less worrisome... I don't mind rerunning grub2-mkconfig, what I wanted to make sure is it wasn't something being hit by everyone using Xen. :-)
I've the same exact problem. I had to manually run grub2-mkconfig in my all F17 boxes.
Thanks and Regards, Dario
-- xen mailing list xen@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/xen
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
On Mon, 11 Feb 2013, Dario Faggioli wrote:
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 }
Did you update the kernel at the same time? 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).
Michael Young
I've the same exact problem. I had to manually run grub2-mkconfig in my all F17 boxes.
Did you update the kernel at the same time? 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).
This is also discussed as an aside at:
https://bugzilla.redhat.com/show_bug.cgi?id=738085
On Mon, 2013-02-11 at 14:49 -0600, W. Michael Petullo wrote:
Did you update the kernel at the same time? 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).
This is also discussed as an aside at:
Yep, and also here (although, for F16, but the issue is still there):
https://bugzilla.redhat.com/show_bug.cgi?id=783851
Dario
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
On Tue, 2013-02-12 at 10:18 +0100, Dario Faggioli wrote:
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?
BTW, I just did that and created this: https://bugzilla.redhat.com/show_bug.cgi?id=912379
I hope I'll have some time to look into this bug even more, but I'm not sure when.
Dario
xen@lists.stg.fedoraproject.org