[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issues with device detection in an EFI/GPT scenario
From: |
Andrei Borzenkov |
Subject: |
Re: Issues with device detection in an EFI/GPT scenario |
Date: |
Sun, 31 Jan 2016 08:33:23 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
31.01.2016 05:05, Andreas Loew пишет:
>
>> 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
...
> kern/disk.c:384: hd0 read failed
> error: failure reading sector 0x0 from 'hd0'
>
...
>
> Does this help in finding out why these messages are printed?
Unfortunately, no, they are too low level. What is content of boot menu
entry? Execute each command one by one manually in CLI, and check which
command produces these errors.