[node-devel] ovirt-node uefi status update

[Jim Meyering]

Joey Boggs wrote:
> On 01/05/2012 01:42 PM, Matthew Garrett wrote:
>> On Thu, Jan 05, 2012 at 01:36:45PM -0500, Joey Boggs wrote:
>>
>>> Just to throw out multipath/dev-mapper  If I mount /dev/mapper/XXXXX
>>> its there, if I kill multipath and partprobe /dev/sda it there as
>>> well.
>>>
>>> It's an asus p8h61-m le motherboard I'm testing with that has the ez
>>> bios if that adds anything
>> Ok. Just to avoid some other corner cases - does it work if you just do
>> a normal EFI install to the bare metal?
>>
> fresh boot, killed everything running/mounted from the /dev/mapper lvm devices
> multipath -F
> service multipathd stop
>
> dd'd the first 50MB of the disk then ran:
>
> parted /dev/sda
> mklabel gpt
> mkpart efi 0M 255M
> set 1 boot on
> mkpart root 256M 512M
> partprobe /dev/sda
> sda1/sd2 exist
> mkfs.vfat -F32 /dev/sda1
> mount /dev/sda2 /liveos
> mkdir /liveos/efi
> mount /dev/sda1 /liveos/efi
> grub2-efi-install /dev/sda --boot-directory=/liveos
> # successful, no errors
> efibootmgr -v
> # looks the same
> umount /liveos/efi
> umount /liveos
> reboot
>
> Now I get a grub prompt, anything else I can possibly rule out to
> narrow it down? its a start now :)

Hi Joey,

Here are a few suggestions (although unrelated to the current problem,
taking these suggestions may help avoid confusion and performance
problems in actual use, i.e., if you happen to use an SSD or a disk
for which alignment makes a difference):

  - Do not use "primary" as a GPT partition name.
    "primary" makes sense when using an msdos partition table, but not
    with a GPT table.  There, it suggests a misunderstanding.  Use a
    meaningful name instead, as below.

  - Do not use the "M" suffix, because e.g., 256M translates to
    byte 256000000, which may let parted give you a partition that
    is not well-aligned.  For some types of disks, the resulting
    systems would then have unnecessarily poor I/O performance.
    With parted-3.1, you will be able to use "MiB" as a suffix, and it
    will do the right thing, but for now, that is not portable to RHEL.

  - I see you invoked parted only once above, but in case it's run more than
    once for a given device in the code... invoking parted multiple times is
    not needed/desired.  It's more efficient and has less duplication to do
    it like this (note use of "--" to avoid the need to keep the "-34" from
    being interpret as an option):

      k=1024
      m=$((k*k))
      parted -s /dev/mapper/XXXXX --				\
        mklabel gpt						\
        mkpart efi         34s         $((256*m-1))b		\
        mkpart root        $((256*m))b $((512*m-1))b		\
        mkpart root-backup $((512*m))b $((768*m-1))b		\
        mkpart data        $((768*m))b -34s

The 34s (34 sectors) is to allow room for the primary GPT header.
The -34s as endpoint of final partition says to use everything up to the
end of the disk, but leaving 34 sectors for the backup GPT header.
Note that I've used meaningful partition names and that all other partition
start and end offsets are specified in bytes (note the "b" suffixes), and
each partition other than the first one starts on a byte address that is
a multiple of 256MiB (not 256MB).  The EFI partition is used only once,
at boot, so its alignment does not matter.

-------------------------------------
Maybe relevant,

I noticed you wrote this:

    set 1 boot on

Did you mean to use "bios_grub" instead of "boot"?

    set 1 bios_grub on

-------------------------------------
To try the above, I did this:
(this uses 1GB of memory, so be sure you have at least that much free)

modprobe scsi_debug dev_size_mb=1000
dev=/dev/sdd
k=1024
m=$((k*k))
parted -s $dev -- \
  mklabel gpt \
  mkpart efi         34s         $((256*m-1))b \
  mkpart root        $((256*m))b $((512*m-1))b \
  mkpart root-backup $((512*m))b $((768*m-1))b \
  mkpart data        $((768*m))b -34s

parted -s $dev u mi p u s p

Model: Linux scsi_debug (scsi)
Disk /dev/sdd: 1000MiB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start    End      Size    File system  Name         Flags
 1      0.02MiB  256MiB   256MiB               efi          bios_grub
 2      256MiB   512MiB   256MiB               root
 3      512MiB   768MiB   256MiB               root-backup
 4      768MiB   1000MiB  232MiB               data

Model: Linux scsi_debug (scsi)
Disk /dev/sdd: 2048000s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start     End       Size     File system  Name         Flags
 1      34s       524287s   524254s               efi          bios_grub
 2      524288s   1048575s  524288s               root
 3      1048576s  1572863s  524288s               root-backup
 4      1572864s  2047966s  475103s               data

If you convert those start sector numbers to hexadecimal,
you see that they are well-aligned:

        80000
        100000
        180000

-------------------------------------
Note that using the commands you listed above,
I do end up with well-aligned partitions,
but with an 800KB free gap between the two partitions:

  # dev=/dev/sdd
  # parted -s $dev -- mklabel gpt mkpart efi 0 255M mkpart root 256M 512M
  # parted -s $dev u s p free

Model: Linux scsi_debug (scsi)
Disk /dev/sdd: 2048000s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start    End       Size      File system  Name  Flags
 1      34s      498046s   498013s                efi
        498047s  499711s   1665s     Free Space
 2      499712s  999423s   499712s                root
        999424s  2047966s  1048543s  Free Space