Bug 728953

Summary: grub will not boot from non-primary virtio disk
Product: Red Hat Enterprise Linux 4 Reporter: Matthew Booth <mbooth>
Component: grubAssignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.8   
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 728947 Environment:
Last Closed: 2012-06-20 16:10:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 728947    
Bug Blocks: 728951    

Description Matthew Booth 2011-08-08 13:19:19 UTC
+++ This bug was initially created as a clone of Bug #728947 +++

Description of problem:
A guest has 2 virtio disks: vda and vdb. /boot resides on /dev/vdb1. Grub is installed on /dev/vda, which is also where the guest is configured to boot from.

Firstly, a fresh installation in the above configuration will cause the boot to fail with 'Hard Disk Error' (screenshot rhel6-grub-hd_error)[1].

If you attempt to fix the problem by manually running 'grub-install /dev/vda' from the rescue environment you  get Error 21 trying to load stage 1.5 (screenshot rhel6-error_21).

The above configuration works fine if the disks are IDE. It also works fine if the drives are swapped so that /dev/vdb1 becomes /dev/vda1 and grub is manually installed on the new /dev/vda. The problem seems to be specific to attempting to read /boot from a drive other than the first one.

I have replicated this problem on RHEL 4.8, RHEL 5.4 and RHEL 6.0, all of which support VirtIO. I have also replicated the problem on a RHEL 5 KVM host, which uses Bochs BIOS, and an F14 host, which uses SeaBIOS. The behaviour is the same in all cases, although the error messages from RHEL 4 and RHEL 5 grub are slightly more verbose.

[1] I'd expect the behaviour to be identical immediately after installation to behaviour after running 'grub-install /dev/vda', so could this indicate a secondary problem in anaconda?

Comment 1 Jiri Pallich 2012-06-20 16:10:04 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.