help-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grub install fails on single boot Mint 17, 3TB RAID1, GPT & EFI


From: jeff
Subject: Re: Grub install fails on single boot Mint 17, 3TB RAID1, GPT & EFI
Date: Fri, 2 Jan 2015 09:35:55 -0800 (PST)

Andrei; My comments in-line below.

>-----Original Message-----
>From: "Andrei Borzenkov" <address@hidden>
>Sent: Thursday, January 1, 2015 9:24pm
>To: address@hidden
>Cc: address@hidden
>Subject: Re: Grub install fails on single boot Mint 17, 3TB RAID1, GPT & EFI
>
>В Thu, 1 Jan 2015 14:43:54 -0800 (PST)
>address@hidden пишет:
>
>> Greetings -
>> 
>> I am trying to install Linux Mint 17.1 onto a new Dell Precision and am 
>> getting a grub-install failed error from the installer. This is a new 
>> single-boot UEFI system with 2 blank 3 TB drives. Specifically the error is:
>> 
>> Running grub-install /dev/md127
>> Unable to install GRUB in /dev/md127
>> Executing ‘grub-install /dev/md127’ failed
>> This is a fatal error
>> 
>> Since this is the only error information that I have, I am assuming that it 
>> could be a result of the raid and partitioning setup that the installer 
>> balks at when installing Grub2. So I will start by clearly stating what my 
>> objective is, then my disk setup.
>
>You should look at distribution specific log files to find out more
>information. Or run "grub-install" manually and copy-paste command
>invocation and output. If you are using grub2 with EFI install device
>is redundant and will be ignored by grub-install anyway.
>
>> 
>> My objective is to have Mint installed onto a software RAID1 system that is 
>> bootable if either drive failes (or is removed from the system), with 
>> minimal downtime by just installing a new drive and resyncing the RAID. I 
>> want to avoid additional steps that involve reinstalling grub or the boot 
>> files after the failure to make the system bootable again.
>> 
>> A summary of my disk setup steps are as follows.
>> 1. Boot to SystemRescueCD and from a terminal window create a RAID1 array 
>> from both drives.
>> root# mdadm --create --verbose /dev/md127 --level=1 --raid-devices=2 
>> /dev/sda /dev/sdb
>> 
>> This displays the standard warning about ensuring that your resulting boot 
>> loader understands md/v1.x metadata. Then defaults to using version 1.2 
>> metadata. According to the Grub2 manual, Section 1.3, Grub2 can read files 
>> directly from LVM and RAID devices, therefore version 1.2 should be ok.
>> 
>> 2. In GParted, selected the raid device (/dev/md127) and assigned a GPT 
>> partition to it.
>> 
>> 3. Using GParted created 3 partitions on the raid array.
>> md127p1 /boot/efi 550 MB FAT32 EFI System Partition, boot & esp flags set
>
>EFI partition cannot be part of MD RAID unless this MD RAID is can also
>be accessed by firmware. Command you used creates standard RAID, not
>associated with any firmware RAID. 
>

Ok, I suspect this is my problem then.  I had previously test installed CentOS 
7 on this system, and verified that with either drive removed it would boot.  
But looking back at my notes, I had used the Intel BIOS Raid on that 
installation.  I have wanted to use a pure software raid because (a) I didn't 
spend the additional $500 for a hardware raid card, and (2) wanted to stay away 
from the fake raid cards that just implement software raid.  So it looks like 
my basic installation premise is incorrect, in that it is not possible to 
software raid entire drives with an EFI booting system.  All the Googling I see 
about this now has a lot of fancy work-arounds which might be more of a 
headache later when a disk fails.

If you have a good reference that explicitly statea and describes why the EFI 
boot partition can not be on software raid I would be interested in reading 
more about this.  I looked through the UEFI specification document 
(http://www.uefi.org/specifications, ver. 2.4, June 2013) this morning and only 
found one casual reference to raid devices on page 516 that made this statement 
in reference to partition discovery:

"If a disk contains a recognized RAID structure (e.g. DDF structure as defined 
in The Storage Networking Industry Association Common RAID Disk Data Format 
Specification--see Glossary), the data on the disk must be ignored, unless the 
driver is using the RAID structure to produce a logical RAID volume."

I briefly looked at the RAID Disk Data Format Specs referenced 
(http://www.snia.org/tech_activities/standards/curr_standards/ddf), but didn't 
see any thing there.

Since I would like to have a raided system that minimizes the effort to replace 
a failed drive, it looks like I am going to have to take the approach of using 
the Intel BIOS raid setup.  I will try that next.  Thanks.

>If you want to use legacy BIOS booting, this will not work in this
>configuration either - you need to create partitioned disks, assemble
>MD RAIDs from each partition and install bootloader in MBR (outside of
>Linux MD).
>>
>> md127p2 /boot 550 MB FAT32
>> md127p3 2.73 TB Lvm2 Physical Volume
>> 
>> If I recall correctly, GParted leaves 1 MB untouched before the first 
>> partition. Then I left 100 MB unallocated after md127p3.
>> 
>> 4. From the terminal window, create the following logical volumes.
>> root# lvcreate -L 8G -n lv_mintroot vg_jab
>> root# lvcreate -L 4G -n lv_mintvar vg_jab
>> root# lvcreate -L 2G -n lv_mintswap vg_jab
>> root# lvcreate -L 80G -n lv_minthome vg_jab
>> root# lvcreate -L 1000G -n lv_mintgis vg_jab
>> 
>> Side Note: Mint will be a KVM host that will also run a Win7 guest with a 
>> couple of additional logical volumes for the Windows guest, hence the naming 
>> of logical volumes. I use a similar setup on my CentOS 6 KVM Host Server 
>> with several guests and it makes managing the storage easy and 
>> understandable.
>> 
>> 5. Eject the SystemRescueCD and reboot to the Linux Mint LiveCD installer. 
>> Do some housekeeping to get Mint to recognize the raid array.
>> 
>> address@hidden sudo apt-get update
>> address@hidden sudo apt-get remove dmraid
>> address@hidden sudo apt-get install mdadm
>> address@hidden sudo mdadm --examine --scan
>>  ARRAY /dev/md/127 metadata=1.2 UUID baf72191:8d8bb4e4:6b31b91a:c0efe33e 
>> name=sysresccd:127
>> address@hidden sudo mdadm --assemble --scan
>>  mdadm: /dev/md/127 has been started with 2 drives
>> address@hidden cat /proc/mdstat
>>  Personalities : [raid1]
>>  md127 : active raid1 sda[0] sdb[1]
>> 
>> 6. Start the Mint installer and select custom partitioning. The custom 
>> partitioning dialog correctly recognizes the raid array, all previously 
>> configured partitions, logical volumes, and boot flags.
>> 
>> 7. Select each partition and logical volume established in steps #2 and #3 
>> above and identify the mount point and assign the appropriate file system. 
>> The /boot/efi and /boot partitions were formated as shown in step #2 above. 
>> The LVM logical volumes were formatted as XFS file systems, except swap.
>> 
>> 8. In Mint there is a menu list below the custom partitioning to identify 
>> and select the location for installing the boot loader. The RAID1 device 
>> (/dev/md127) was selected for installing the boot loader (not an individual 
>> partition or a single drive).
>> 
>> 9. Installation progressed normally until the point of installing grub, 
>> which resulted in the following error:
>> 
>> Running grub-install /dev/md127
>> Unable to install GRUB in /dev/md127
>> Executing ‘grub-install /dev/md127’ failed
>> This is a fatal error
>> 
>> It is my understanding that Mint17.1 is based on Ubuntu 14.04, which 
>> includes Grub2. And looking at the documentation for Grub2 includes support 
>> for Linux software (mdadm) RAID1, EFI, and GPT. So I don't know what I am 
>> missing with this configuration that causes grub-install to fail. I can 
>> provide more diagnostic information if necessary, but don't know what may be 
>> needed, and I am looking here for some expert advice.
>> 
>> I am open to suggestions that are oriented towards my objective of having a 
>> bootable software RAID1 installation if there is something else I need to 
>> consider. Thanks for reading my (long) post.
>> 
>> Please cc me directly on any replies, as I am subscribed to the daily digest.
>> Jeff
>> 
>> 
>> _______________________________________________
>> Help-grub mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/help-grub

Jeff






reply via email to

[Prev in Thread] Current Thread [Next in Thread]