Bug 617504 - Installing to MD RAID1 /boot results in an unbootable system
Installing to MD RAID1 /boot results in an unbootable system
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: anaconda (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Anaconda Maintenance Team
Release Test Team
: RHELNAK
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-23 05:46 EDT by Gordan Bobic
Modified: 2010-07-28 14:12 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-28 14:12:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gordan Bobic 2010-07-23 05:46:00 EDT
Description of problem:
It would seem that anaconda creates MD RAID devices with v1.x metadata by default. When this is applied to a RAID1 device to be used as the /boot volume, boot fails because v1.x metadata is at the front of the disk, which makes grub fail. With the version of grub used, only metadata=0.90 MD devices can be used for /boot. Anaconda needs to be aware of this and act accordingly, until grub is updated to work with metadata=1.x devices.

Version-Release number of selected component (if applicable):
RHEL6 beta 2

How reproducible:
Every time.

Steps to Reproduce:
During the install, create a MD RAID1 device and set it to be mounted under /boot. The system will fail to boot up when the installation is complete.
Comment 2 Hans de Goede 2010-07-23 06:02:37 EDT
Hi,

Are you sure you are seeing this with a separate /boot ? There is a known
(documented and fixed) issue in beta2 where if you have / on an mdraid mirror without having a separate /boot, it will use 1.1 metadata for / (and thus for /boot). But if you have a separate /boot beta2 will use 1.0 metadata, which just like 0.9 metadata lives at the end of the partition and thus is not a problem.

Regards,

Hans
Comment 3 RHEL Product and Program Management 2010-07-23 06:17:43 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 4 Gordan Bobic 2010-07-23 06:20:26 EDT
I am positively sure it's a separate /boot, since the root was RAID5.

It occurs to me, however, that the disks I was installing onto were used in a RAID stripe before, so it is possible there was some leftover metadata on there that confused things. To prevent that being a problem, perhaps the partitions/devices should be cleared with --zero-superblock before the RAID devices are created just to make sure?
Comment 5 RHEL Product and Program Management 2010-07-23 06:37:40 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 6 Hans de Goede 2010-07-23 07:00:23 EDT
Hi,

(In reply to comment #4)
> I am positively sure it's a separate /boot, since the root was RAID5.

Ok.

> It occurs to me, however, that the disks I was installing onto were used in a
> RAID stripe before, so it is possible there was some leftover metadata on there
> that confused things. To prevent that being a problem, perhaps the
> partitions/devices should be cleared with --zero-superblock before the RAID
> devices are created just to make sure?    

We already clear the first and last 5 MB of a partition before using it, so that should not be a problem.

Can you try to reproduce this, and at the end of the installation (so before rebooting), switch to the shell at tty2 (ctrl + alt + F2), and collect all the /tmp/*log files (you can for example use scp), and then attach those log files here?

Thanks & Regards,

Hans
Comment 7 David Cantrell 2010-07-28 14:12:33 EDT
Feel free to reopen the bug if you can provide the information requested in comment #6.

Note You need to log in before you can comment on or make changes to this bug.