Re: Probing for the existence of a device.

[João Ricardo Sares Teles de Matos]

On 06/23/2013 07:55 PM, Jordan Uggla wrote:
> On Sat, Jun 22, 2013 at 2:44 PM, João Ricardo Sares Teles de Matos
> <address@hidden> wrote:
>> I couldn't find a reliable way to do something like this:
>>
>> if drive_exists_p (hd1); then
>>   menuentry_to_chainload_drive (hd1)
>> fi
>>
>> Where the missing piece is the pseudo-command "drive_exists_p", which has a 
>> zero return when the device exists.
> insmod regexp
>
> function drive_exists_p {
>
>   for drive in *; do
>     if [ "$drive" = "$1" ]; then
>       return 0;
>     fi
>   done
>
>   return 1
> }
>
> That said, I dislike testing for a hard coded static device name when,
> as shown above, we can iterate through all available drives, or as
> shown by
> Andrey Borzenkov we can search for a device by UUID (of a filesystem
> within a partition or other abstraction), either of which will allow
> for the possibility that the BIOS will enumerate drives differently at
> different times.
Having learned about globbing, this what I'd like to do:

insmod  regexp
for drive in *; do
    menuentry "Chainload $drive" {
        set root=$drive
        chainloader +1
        boot
    }
  fi
done

However, it doesn't work as one would initially expect.
This example illustrates the problem:

for drive in (hd0) (hd1) (hd2); do
  menuentry "Echo the value of \$drive (it should be $drive)" {
       echo "The value of \$drive is $drive"
       sleep 5
  }
done

This creates three menu entries, with (hd0), (hd1) and (hd2) in the title.
When choosing the menu, however, all three entries echo "The value of $drive is 
(hd2)".

The expansion of $drive within the menuentry is deferred to the moment when the 
menu entry is activated, which causes all menu entries to expand to the last 
value assigned to the variable drive, (hd2).

This behavior is to be expected of function definitions, and menu entries are 
similar to functions, so I can see how this would happen.

This being the case, if there is a way to build menu entries iteratively I'm at 
a loss as to how.

I'm not familiar with GRUB's architecture, so I'm making some assumptions: 
Perhaps copies of the symbol table's contents should be saved with menuentry 
definitions, so that when they are executed they have the right context: a new 
scope with the saved state as their (only?) parent.


>> The "probe --driver" command sort of does the job, but it prints error 
>> messages and causes a "Press any key to continue..." prompt when the device 
>> doesn't exist.
>>
>> The idea is having automatically (dis)appearing menu entries to chainload 
>> devices that may be (un)plugged, which is useful in an environment where USB 
>> thumb drives are frequently used as boot devices.
> Are you looking for a specific drive, or are you wanting entries for
> any drive that happens to be plugged in? If the former, I'd recommend
> searching by UUID. If the latter, I'd recommend
> http://askubuntu.com/questions/141381/ubuntu-in-usb-boot-from-fixed-hdd
> .
>
>> The test command with -e or -d doesn't work unless the device contains a 
>> filesystem that GRUB can read.
>>
>> Am I missing something, or is this something that can't be done without 
>> extending GRUB?
>>
>> By the way, is this sort of message appropriate for this mailing list?
>> I'd hate to be spamming the list with offtopic queries.
> This question is definitely appropriate for this mailing list.
>

-- 
João Ricardo Sares Teles de Matos
address@hidden

Administração de Sistemas da Rede das Novas Licenciaturas
Instituto Superior Técnico

web: https://www.rnl.ist.utl.pt
email: address@hidden
telefone: +351 218 41 77 71

signature.asc
Description: OpenPGP digital signature