Re: Detecting boot drive

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

 



>
> On Fri, Jan 29, 2016 at 12:53 PM, Hajducko, Steven <Steven_Hajducko@xxxxxxxxxx> wrote:
> Is there a way to consistently detect the boot-drive, across multiple hardware platforms?
>
> We have several different hardware types - but it remains consistent that we always want the OS installed on the first drive in boot order.  We played around with --on-bios-disk, but that doesn't always work ( it fails, for instance, on Dell R820's with the PERC RAID controller ).  We've also tried specifying /dev/disk/by-id/edd-int13_dev80, which works on the Dell's, but fails on VMs.  ( And then throw HP and it's cciss into the whole mix.. ).  /dev/sda isn't always the boot disk - this happens to us with certain RAID configs like 1 logical drive and 8 JBOD's.   The JBOD's get detected as /dev/sda-h and the RAID drive ( which is the boot drive ), ends up as /dev/sdi.
>
> Just curious if anyone else has come up with a solid way to always figure out what the boot drive is.
>

I don't have HP servers in my mix, but I have Dell servers all the way from PE2850s up to the newest R730xd's.  Additionally, we support static, DHCP and
PXE builds which seem to enumerate the disks slightly differents.  (As you say, the desired disk is not always /dev/sda).

By beaucoup testing, I was able to determine my first disk always had a certain pattern.

In my ks.cfg files, I have a %pre section where I interrogate the SCSI sub-system to find disks of the pattern I desire.

Here's my relevant %pre section:

%pre
# This *definitely* works.  See %include ignoredisk discussion above.
FIRST_PERC_VOL=$(ls -1 /dev/disk/by-path/pci-*-scsi-0:[1-9]:0:0 | grep -v usb)

echo "ignoredisk --only-use=$FIRST_PERC_VOL" > /tmp/ignoredisk
echo "clearpart --all --initlabel --drives=$FIRST_PERC_VOL" >> /tmp/ignoredisk

Here is my main section (I embed my research on the various builds and various server models as comments so that I remember
why I ended up with this specific pattern).

## Make sure that the USB disk(s) and FC LUNs are ignored during discovery.
#  And that we use the first PERC vol as our system disk.

# For static builds:
#   1. Virtual media (USB) detected as /dev/sda, first PERC vol as /dev/sdb.
#   2. Physical USB media detected as /dev/sda, first PERC vol as /dev/sdb.
#   3. *However*!! if both virtual media + physical USB media present,
#       virtual media detected as /dev/sda (I think), physical USB media as
#       /dev/sdb (I think) and first PERC vol as /dev/sdc.
#   4. "ignoredisk" directive no longer tolerates a "--drives=" flag with a
#       "--only-use=" flag. One or the other, not both.
#
#  Same rules apply for DHCP builds, as they're also based on virtual or
#  physical boot media.  We want to use first PERC vol (/dev/sdb for DHCP
#  builds).
#
#  For PXE builds, first PERC vol is /dev/sda. (Mark's boot media is loaded
#  into mem I guess.)
#
# YUCK!!! Instead of considering all those ugly cases --
#
# Consistently, the 1st PERC vol seems to be enumerated as [0:2:0:0] on
# M620s and R620s.  Here's example output from lsscsi -g:
#
# #lsscsi -g
#  [0:0:32:0]   enclosu DP       BACKPLANE        1.07  -          /dev/sg0
#  [0:2:0:0]    disk    DELL     PERC 6/i         1.22  /dev/sda   /dev/sg1
#  [0:2:1:0]    disk    DELL     PERC 6/i         1.22  /dev/sdb   /dev/sg2
#
# ks.cfg now allows /dev/disk/by-path/ and /dev/disk/by-id shell-like globs.
# See http://fedoraproject.org/wiki/Anaconda/Kickstart, Special Notes for
#     Referring to Disks.
#
# So /dev/disk/by-path/pci-*-usb-* captures all USB media,
#    /dev/disk/by-path/pci-*-scsi-* captures all PERC vols,
#    /dev/disk/by-path/pci-*-scsi-0:2:0:0 captures first PERC vol (on a M620),
#    /dev/disk/by-path/pci-*-fc-* captures all FC LUNs.

# bootloader --driveorder
#
# Specifies which drive is first in the BIOS boot order. For example:
# bootloader --driveorder=sda,hda
#
# When we boot OS, the PERC vols are first in BIOS boot order.
bootloader --location=mbr --driveorder=/dev/disk/by-path/pci-*-scsi-*

# The boot media on a M710HD enumerates disk as so:
#    /dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0 ???
#    /dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.1-scsi-0:0:0:0 ???
#    /dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.2-scsi-0:0:0:0 USB key
#    /dev/disk/by-path/pci-0000:01:00.0-scsi-0:1:0:0 first PERC volume
#
# Would the following line work to lay down partitions only on 1st PERC
# volume?  Would this work on all server models?
#ignoredisk --only-use=/dev/disk/by-path/pci-*-scsi-0:[1-9]:0:0

# Thus, would the following line remove all partitions, but only from 1st PERC
# vol?  For all server models?
#clearpart --all --initlabel --drives=/dev/disk/by-path/pci-*-scsi-0:[1-9]:0:0

# This *definitely* works.  See %pre section.
%include /tmp/ignoredisk

Also one more comment.  Long ago, there was a particular Dell mode (R710).  Its
low-end PERC controller was forever flip-flopping the disks from one boot to the next.

That is, after OS is installed on the disk and server rebooted, this first
PERC vol was no longer /dev/sda, but now /dev/sdb.  I believe some later rev of
the PERC firmware eventually solved this problem.

But in the meantime we found that this killed some of our builds, not others.

We found if we created all our OS partitions as LVMs, then they'd be discovered and
mounted, regardless of whether your boot disk was /dev/sda, sdb, or sdc
today.

This works because grub identifies its boot partition by SCSI ID -- for instance hd(0,0).
Once grub loads the boot vmlinuz/initramfs, the boot kernel does a lvscan.  And it finds
your LVMs wherever they reside today.

Moral of this story: It's good to create your OS filesystems as LVMs.  For this and
other reasons.

Spike

_______________________________________________
Kickstart-list mailing list
Kickstart-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list

[Index of Archives]     [Red Hat General]     [CentOS Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux