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

[Andreas Loew]

Hello Andrei,

first of all, many thanks for your reply and sorry for my delayed reaction.

Am 29.01.2016 um 07:40 schrieb 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.

Secondly, I'm sorry one more time - I resent my message a second time on the 28th at 21:50 when my initial message dating from 20:27 was not shown on the list web interface and neither in my mailbox after almost 90 minutes (as you can see from the timestamps). This first message only appeared about two hours later on the list, well after my second message from 21:50, which probably was due to some kind of server issues...

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

The fact that that GRUB seems to try to access/read from "empty" optical drives, producing noise and no less than six "failure reading sector" error messages followed by "Press any key to continue..." as shown on my first screenshot.

"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 did not know before that (and do I assume correctly that this only holds true for an EFI scenario?) the device names are completely opaque and irrelevant. Instead, I simply assumed that the fact that optical devices were detected as hard disks was the reason for these error messages.

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.

So if I understand you correctly, indeed the bug seems to be that these errors are indeed printed during the internal scan after a boot menu entry is selected and before the actual boot process is initiated.

The control flow when these errors are displayed is (example here: (hd0) in my above epample, representing an optical PATA DVD-RW drive with no media inserted):

(now transcribing from the screen in "set debug=all" mode to avoid another JPEG screenshot attachment:)

disk/efi/efidisk:516: opening hd0
disk/efi/efidisk:546: m = 0x21b4d98, last block = 100, block size = 800
disk/efi/efidisk:558: opening hd0 succeeded
disk/diskfilter.c:135: Scanning for DISKFILTER devices on hd0
disk/efi/efidisk:595: reading 0x10 sectors at the sector 0xf0 from hd0
disk/efi/efidisk:595: reading 0x1 sectors at the sector 0xfc from hd0
kern/disk.c:384: hd0 read failed
error: failure reading sector 0xfc from 'hd0'
disk/efi/efidisk:595: reading 0x10 sectors at the sector 0xe0 from hd0
disk/efi/efidisk:595: reading 0x2 sectors at the sector 0xe0 from hd0
kern/disk.c:384: hd0 read failed
error: failure reading sector 0xe0 from 'hd0'
disk/efi/efidisk:595: reading 0x10 sectors at the sector 0x0 from hd0
disk/efi/efidisk:595: reading 0x1 sectors at the sector 0x0 from hd0
kern/disk.c:384: hd0 read failed
error: failure reading sector 0x0 from 'hd0'

i.e. method

static grub_err_t grub_efidisk_read (struct grub_disk *disk, grub_disk_addr_t sector, grub_size_t size, char *buf)

in efidisk.c which in this case returns grub_error (GRUB_ERR_READ_ERROR, ...):

status = grub_efidisk_readwrite (disk, sector, size, buf, 0);

  if (status != GRUB_EFI_SUCCESS)
    return grub_error (GRUB_ERR_READ_ERROR,
               N_("failure reading sector 0x%llx from `%s'"),
               (unsigned long long) sector,
               disk->name);

Another place which could potentially raise grub_error and causes similar error message printout and "press any key" message is here in method

static grub_err_t grub_efidisk_open (const char *name, struct grub_disk *disk):

  if (m->block_size & (m->block_size - 1) || !m->block_size)
    return grub_error (GRUB_ERR_IO, "invalid sector size %d", m->block_size);


Does this help in finding out why these messages are printed? And do you agree that - in case device names do not matter at all - no errors should be returned and no error messages be printed here when accessing an empty optical drive without media inserted like 'hd0' and 'hd9'in my example?

Thanks again for your help & best regards,
Andreas