Updating xen package does not 'refresh' grub.cfg

[Dario Faggioli]

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

[M A Young]

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

[Dario Faggioli]

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

[Roberto Fichera]

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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/xen

[Dario Faggioli]

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

[M A Young]

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

[W. Michael Petullo]

> > > 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

[Dario Faggioli]

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:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=738085

Yep, and also here (although, for F16, but the issue is still there):

https://bugzilla.redhat.com/show_bug.cgi?id=783851

Dario

[Dario Faggioli]

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

[Dario Faggioli]

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