[CentOS] CentOS 7 grub.cfg missing on new install

[Jeff Boyce]

----- Original Message ----- 
From: "Gordon Messmer" <gordon.messmer at gmail.com>
To: "CentOS mailing list" <centos at centos.org>
Cc: "Jeff Boyce" <jboyce at meridianenv.com>
Sent: Thursday, December 11, 2014 9:45 AM
Subject: Re: [CentOS] CentOS 7 grub.cfg missing on new install


> On 12/10/2014 10:13 AM, Jeff Boyce wrote:
>> The short story is that got my new install completed with the 
>> partitioning I wanted and using software raid, but after a reboot I ended 
>> up with a grub prompt, and do not appear to have a grub.cfg file.
> ...
>> I initially created the sda[1,2] and sdb[1,2] partitions via GParted 
>> leaving the remaining space unpartitioned.
>
> I'm pretty sure that's not necessary.  I've been able to simply change the 
> device type to RAID in the installer and get mirrored partitions.  If you 
> do your setup entirely in Anaconda, your partitions should all end up 
> fine.

It may not be absolutely necessary, but it appears to me to be the only way 
to get to my objective.  The  /boot/efi  has to be on a separate partition, 
and it can not be on a RAID device.  The  /boot  can be on LVM according to 
the documentation I have seen, but Anaconda will give you an error and not 
proceed if it is.   Someone pointed this out to me a few days ago, that this 
is by design in RH and CentOS.  And within the installer I could not find a 
way to put  /boot  on a non-LVM RAID1 while the rest of my drive is setup 
with LVM RAID1.  So that is when I went to GParted to manually setup the 
/boot/efi  and  /boot  partitions before running the installer.

>> At this point I needed to copy my /boot/efi and /boot partitions from 
>> sda[1,2] to sdb[1,2] so that the system would boot from either drive, so 
>> I issued the following sgdisk commands:
>>
>> root#  sgdisk -R /dev/sdb1 /dev/sda1
>> root#  sgdisk -R /dev/sdb2 /dev/sda2
>> root#  sgdisk -G /dev/sdb1
>> root#  sgdisk -G /dev/sdb2
>
> sgdisk manipulates GPT, so you run it on the disk, not on individual 
> partitions.  What you've done simply scrambled information in sdb1 and 
> sdb2.
>
> The correct way to run it would be
> # sgdisk -R /dev/sdb /dev/sda
> # sgdisk -G /dev/sdb

Point taken, I am going back to read the sgdisk documentation again.  I had 
assumed that this would be a more technically accurate way to copy sda[1,2] 
to sdb[1,2] rather than using dd as a lot of how-to's suggest.

> However, you would only do that if sdb were completly unpartitioned.  As 
> you had already made at least one partition on sdb a member of a RAID1 
> set, you should not do either of those things.
>
> The entire premise of what you're attempting is flawed.  Making a 
> partition into a RAID member is destructive.  mdadm writes its metadata 
> inside of the member partition.  The only safe way to convert a filesystem 
> is to back up its contents, create the RAID set, format the RAID volume, 
> and restore the backup.  Especially with UEFI, there are a variety of ways 
> that can fail.  Just set up the RAID sets in the installer.

I need some additional explanation of what you are trying to say here, as I 
don't understand it.  My objective is to have the following layout for my 
two 3TB disks.

sda1    /boot/efi
sda2    /boot
sda3    RAID1 with sdb3

sdb1    /boot/efi
sdb2    /boot
sdb3    RAID1 with sda3

I just finished re-installing using my GParted prepartitioned layout and I 
have a bootable system with sda1 and sda2 mounted, and md127 created from 
sda3 and sdb3.  My array is actively resyncing, and I have successfully 
rebooted a couple of times without a problem.  My goal now it to make sdb 
bootable for the case when/if sda fails.  This is the process that I now 
believe I failed on previously, and it likely has to do with issueing the 
sgdisk command to a partition rather than a device.  But even so, I don't 
understand why it would have messed with my first device that had been 
bootable.

>> I then installed GRUB2 on /dev/sdb1 using the following command:
>> root#  grub2-install /dev/sdb1
>>    Results:  Installing for x86_64-efi platform.  Installation finished. 
>> No error reported.
>
> Again, you can do that, but it's not what you wanted to do.  GRUB2 is 
> normally installed on the drive itself, unless there's a chain loader that 
> will load it from the partition where you've installed it.  You wanted to:
> # grub2-install /dev/sdb

Yes, I am beginning to think this is correct, and as mentioned above am 
going back to re-read the sgdisk documentation.

>> I rebooted the system now, only to be confronted with a GRUB prompt.
>
> I'm guessing that you also constructed RAID1 volumes before rebooting, 
> since you probably wouldn't install GRUB2 until you did so, and doing so 
> would explain why GRUB can't find its configuration file (the filesystem 
> has been damaged), and why GRUB shows "no known filesystem detected" on 
> the first partition of hd1.
>
> If so, that's expected.  You can't convert a partition in-place.
>
>> Looking through the directories, I see that there is no grub.cfg file.
>
> It would normally be in the first partition, which GRUB cannot read on 
> your system.
>
>> So following the guidance I had I issued the following commands in grub 
>> to boot the system.
>>
>> grub#  linux /vmlinuz -3.10.0-123.el7.x86_64 root=/dev/sda2 ro
>> grub#  initrd /initramfs-3.10.0-123.el7.x86_64.img
>> grub#  boot
>>
>> Unfortunately the system hung on booting, with the following information 
>> in the "journalctl" file:
>> #  journalctl
>> Not switching root: /sysroot does not seem to be an OS tree. 
>> /etc/os-release is missing.
>
> On your system, /dev/sda2 is "/boot" not the root filesystem.  Your 
> "root=" arg should refer to your root volume, which should be something 
> like "root=/dev/mapper/vg_jab-hostroot".  dracut may also need additional 
> args to initialize LVM2 volumes correctly, such as 
> "rd.lvm.lv=vg_jab/hostroot".  If you had encrypted your filesystems, it 
> would also need the uuid of the LUKS volume.
>