Re: Issues with device detection in an EFI/GPT scenario

[Andrei Borzenkov]

You just sent twice over 4 MB each time (second time being duplicate)
to public mailing list without even being asked for it. Please realize
that some people may still have limited connectivity and not everyone
on this list may be interested in these screenshots.

On Thu, Jan 28, 2016 at 11:50 PM, Andreas Loew <address@hidden> wrote:
>
> While the GRUB menu works fine and my installation boots fine (which is only
> due to the fact that GRUB and RHEL 7.2 identify all partitions by UUIDs;
> trying to address devices by GRUB and Linux device names would clearly have
> failed completely), it prints out multiple error messages before the GRUB
> menu is displayed: "error: failure reading sector <...> from 'hd0'" and
> "error: failure reading sector <...> from 'hd9' (see first screenshot).
>
> I was specifically wondering about what would be wrong with my (hd0) drive
> and why GRUB at all detected a ten HDDs up to a (hd9) drive, so I have just
> completed some investigation around this by adding more verbose debug
> messages into file grub-core/disk/efi/efidisk.c and would like to inform you
> about the results:
>
> As you can see from the two attached screenshots, device detection in method
>
> static void name_devices (struct grub_efidisk_data *devices)
>
> currently does not work as intended in the following ways:

What makes you believe it does not work as intended and how is it
intended to work?

>
> It adds (hd<n>) devices for optical drives that currently don't have
> removable media inserted in both the ATAPI and the SATA case - see (hd0) for
> ATAPI and (hd9) for SATA
>
> For these drives, the above "failure reading sector" message is printed on
> an unsuccessful attempt to read from the empty drive
> PATA CD drives (ATAPI) can be detected by having ACPI type 3
> (GRUB_EFI_MESSAGING_DEVICE_PATH_TYPE) and subtype 1
> (GRUB_EFI_ATAPI_DEVICE_PATH_SUBTYPE)
> SATA CD drives (at least in my UEFI) seem to present the exact same
> type/subtype values as "empty" unformatted SATA HDDs, namely type 3
> (GRUB_EFI_MESSAGING_DEVICE_PATH_TYPE) and subtype 18
> (GRUB_EFI_SATA_DEVICE_PATH_SUBTYPE)
>
> It also adds hd<n> devices for empty removable USB mass storage devices,
> i.e. empty card reader slots - see (hd1) to (hd4)
>
> These present as type 3 (GRUB_EFI_MESSAGING_DEVICE_PATH_TYPE) and subtype 2
> (GRUB_EFI_SCSI_DEVICE_PATH_SUBTYPE) - it looks like they can only be
> distinguished from true SCSI HDDs by scanning backwards in the ACPI device
> path (subtype 5 one ACPI level above?)
>
> The issue with this is less the fact that GRUB adds these devices at all,
> but rather the fact that
>
> optical drives get "hd<n>" device IDs assigned rather than "cd<n>"
> USB mass storage devices get lower "hd<n>" device IDs (hd1 to hd4) assigned
> than SSDs/HDDs
>
>
> So in my case the error messages "failure reading sector" from (hd0) and
> (hd9) are caused by the fact that GRUB sees my empty PATA DVD drive as (hd0)
> and my empty SATA BluRay drive as (hd9). Note that once I insert a valid
> media into either drive, the respective drive will be properly detected as
> (cd0).
>

"Properly" is rather misnomer. GRUB absolutely does not care whether
device is HDD, CD, DVD, RDX or anything else. Seeing confusion it
causes I'd rather name them all "efiblockX" to avoid any
misinterpretation.

cdX simply means that firmware detected ISO image with EFI El Torito
boot catalog entry. Nothing more. If you write this image to hard
disk, it would be presented as "cd" as well, which it obviously is
not.

And how would it help if you got error message for reading cd0 instead of hd9?

> I would rather expect the four true SSDs and hard disks to be detected as
> (hd0) to (hd3), but currently they will be known as (hd5) to (hd8), which
> typically would be quite catastrophic. The only reason that GRUB can still
> at all boot my system is that the RHEL configuration searches the root
> partition "by UUID"...
>

Devices are named in order they are enumerated by firmware. Again -
their names are completely irrelevant and should be treated as opaque
tokens.

> Please let me know whether how to proceed, especially whether you would like
> me to create (one or more?) bug(s) for these issues.
>

What exactly you consider a bug here? Order of device enumeration is
not a bug and is not going to be changed without very good reasons.
Errors when you explicitly try to read from drive without inserted
media are normal and expected - how do you suggest to handle this
situation? You cannot pretend read was successful.

Now if these errors are printed during internal scan initiated by GRUB
(e.g. when trying to search for device) - that is something that
should be considered a bug. After quick glance I do not see where
search would print such errors, so you would need to investigate where
these errors come from.