Bug 893390

Created attachment 675377 [details]
i386_348_After_Start.jpg

Created attachment 675378 [details]
x86_64_GRUB_After_Start.jpg

Hi K.Y. ,

What do you think about this matter?

Thanks!

I have never seen something like this! Have you tested this on a bare maetal install to see if the problem can be reproduced there. I was under the impression that Hashir had tested all the upgrade paths. I am copying Hashir to get his input.

Hi,

What i understand from your problem description is that the grub.conf was somehow corrupted:
 The guest was started after correcting the grub. 

If the problem is grub.conf, then it probably is not bug in grub itself, but rather in tool grubby.

So what did you mean by "correcting the grub"? Could you provide grub.conf causing this issue?

We tested  the upgrade paths from 6.3 to 6.4.

This is  unique way of testing kernel upgrades within 6.4 itself. 

Neither Hyper-V, nor LIS is responsible for updating the grub after a kernel upgrade... and I also don't believe that they are impeding this update in anyway since RHEL internal tools are successfully updating the grub upon reboot.  



Furthermore, it is good practice to Not Turn-off the system after a kernel upgrade like this  without rebooting but to use shutdown instead.

I would submit therefore that at best, this is a documentable best practices issue from our side 

Regards

(In reply to comment #6)
> Hi,
> 
> What i understand from your problem description is that the grub.conf was
> somehow corrupted:
>  The guest was started after correcting the grub. 
> 

Yes.

> If the problem is grub.conf, then it probably is not bug in grub itself, but
> rather in tool grubby.
> 

The grub.conf file is right before 'turn off' the guest via Hyper-V Manager.
So i have no idea it is a bug about grub or grubby. 


> So what did you mean by "correcting the grub"? Could you provide grub.conf
> causing this issue?

For i386 guests:
When started the guest with the previous kernel, the grub was described as bellow:
'        root (hd0,0)
        kernel /vmlinuz-2.6.32-345.el6.i686 ro root=/dev/mapper/vg_dhcp6672126-lv_root rd_LVM_LV=vg_dh'
Modified the kernel line and added the initrd line to the grub:
'        root (hd0,0)
        kernel /vmlinuz-2.6.32-345.el6.i686 ro root=/dev/mapper/vg_dhcp6672126-lv_root rd_LVM_LV=vg_dhcp6672126/lv_swap rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=vg_dhcp6672126/lv_root  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM
        initrd /initramfs-2.6.32-345.el6.i686.img'
Then started the guest with the previous kernel successfully. 

For x86_64 guest, the GRUB information lost. When modified the grub and added 'root','kernel','initrd', started the guest successfully. 


Met the same issue when test the upgrade to kernel-2.6.32-353.el6.

Hi,

This really doesn't seem to be the grub issue. Grubby component is responsible for creating grub.conf, but I guess the problem will be in your Turning-Off machine by Hyper-V Manager - data is not synced properly to disk when you turn off the machine.

Try to use command "sync" before you turn off the machine, if it helps, I will close it as NOTABUG.

Habdi, maybe it would be useful to extend documentation of best practices as you noted.

Regards

Vaclav Pavlin

(In reply to comment #9)
Follow as steps described above, upgrade 345 -> 348, came up with same problem. 
> Hi,
> 
> This really doesn't seem to be the grub issue. Grubby component is
> responsible for creating grub.conf, but I guess the problem will be in your
> Turning-Off machine by Hyper-V Manager - data is not synced properly to disk
> when you turn off the machine.
> 
> Try to use command "sync" before you turn off the machine, if it helps, I
> will close it as NOTABUG.
> 

Before manually restart, execute #sync , have not found grub info missing, can always boot up successfully.

> Habdi, maybe it would be useful to extend documentation of best practices as
> you noted.
> 
> Regards
> 
> Vaclav Pavlin

Downgrade 348 -> 345. Do not run #sync before manually reboot.
As to x64, 40% grub.conf was somehow corrupted; 40% turned into grub shell interface, boot up after manually specify the 'kernel' and 'initrd' in the grub command interface failed, turn to panic. 
As to x86, 80% turn to be grub shell interface, boot up after manually specify the 'kernel' and 'initrd' in the grub command interface failed, turn to panic also.
When run #sync before manually restart, can boot up normally.

And I changed the component to Grubby.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

I'll follow up internally and document this issue as a post update sync requirement before manual restart. Suggest we close this issue

Hello Václav and Peter,
As there is no such problem found after executing command sync before Turn Off the guest, it's clearly to be a problem related to MSFT rather than grub/grubby. While, could this problem be closed as CANTFIX or WONTFIX? Also suggest to add a release note to this problem to inform the RHEL6.4 customer.

Closing per comment #13.  Leaving the technical notes text in the field so it remains in the release and/or technical notes.