Re: Current Grub2 & problem with /boot on different drive

[Vladimir 'phcoder' Serbinenko]

Dean Loros wrote:
> Today's Topics:
>   
>>    7. Re: Current Grub2 & problem with /boot on different drive
>>       (Vladimir 'phcoder' Serbinenko)
>>
>>
>> ----------------------------------------------------------------------
>>   
>>     
>
> Message: 7
> Date: Sun, 20 Sep 2009 22:00:13 +0200
> From: Vladimir 'phcoder' Serbinenko <address@hidden>
> Subject: Re: Current Grub2 & problem with /boot on different drive
> To: The development of GRUB 2 <address@hidden>
> Message-ID: <address@hidden>
> Content-Type: text/plain; charset=UTF-8
>
> Dean Loros wrote:
>
>   
>>> Greetings--
>>>
>>> Ubuntu has been testing Grub2 for a number of months now & a
>>> "interesting" problem has surfaced. If your /boot is on a different
>>> drive than the MBR, you will have several minutes of drive use before
>>> you get to the Grub2 menu. My current timing is 3min 50sec to menu--this
>>> is with a i7-920 system with four internal drives--all SATA-II. My first
>>> bug report on Launchpad was dated 8-28-2009 & this had started a few
>>> days earlier. Before that date, Grub2 would take only 3~5 seconds to get
>>> to menu. Updates after this have not cured this issue. The current
>>> "work-around" in the bug report is to re-set MBR & /boot to the first
>>> drive. This problem only shows up in multi-boot/multi-drive systems.
>>>
>>>   
>>>       
>>   
>>     
> We have theoretically discussed this problem with Robert but weren't
> sure if instances of it exist. The problem is that (UUID=..) syntax
> rescans all drives on every access. We devised a solution to split
> search.mod into search_uuid.mod, search_file.mod and so on but we agreed
> that it will be done after 1.97 due to amount of changes it requires.
> I'm ok to implement it, it's not much work but I can't make any promises
> about my current disponibility.
> As a workaround for time being you can use one or more of the following:
> 1) Increase cache size. Can this be done in 1.97?
> Change include/grub/disk.h and replace
> #define GRUB_DISK_CACHE_NUM     1021
> with a bigger number
> 2) Modify scripts to hardcode boot device and not use UUID. If you
> change disk order it will result in boot failure but it may be a local
> workaround
> 3) add search -s -u <UUID> as first command of your grub.cfg
>
>
> Hi Vladimir--
>
> I have tried option #3 & have a question about syntax--should it be just 
> search -s -u UUID number or should the number be in <> ?
>
> I tried without the <> & grub took the same ammount of time as before--I have 
> edited grub.cfg with the <>, but have not rebooted with it in that form until 
> I hear from you on this.
>   
It's without <>. Well I extected it to have only partial effect since
grub.cfg is parsed quite lately
> Thanks!!!!
> Dean Loros
>
>