All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: Current Grub2 & problem with /boot on different drive
Date: Mon, 21 Sep 2009 16:23:48 +0200	[thread overview]
Message-ID: <4AB78C74.6060400@gmail.com> (raw)
In-Reply-To: <4AB78965.8000606@gmail.com>

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 <phcoder@gmail.com>
> Subject: Re: Current Grub2 & problem with /boot on different drive
> To: The development of GRUB 2 <grub-devel@gnu.org>
> Message-ID: <4AB689CD.4060501@gmail.com>
> 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
>
>   




  reply	other threads:[~2009-09-21 14:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4ab726d8.9d53f10a.2065.414bSMTPIN_ADDED@mx.google.com>
2009-09-21 14:10 ` Current Grub2 & problem with /boot on different drive Dean Loros
2009-09-21 14:23   ` Vladimir 'phcoder' Serbinenko [this message]
     [not found] <4ac08697.aa53f10a.0da9.fffff585SMTPIN_ADDED@mx.google.com>
2009-09-28 13:51 ` Dean Loros
     [not found] <4abfef16.8353f10a.4973.5642SMTPIN_ADDED@mx.google.com>
2009-09-27 23:35 ` Dean Loros
2009-09-28  7:27   ` Vladimir 'phcoder' Serbinenko
2009-09-27 14:53 Dean Loros
2009-09-27 14:56 ` Felix Zielcke
     [not found] <4abc89a6.8153f10a.3583.7e59SMTPIN_ADDED@mx.google.com>
2009-09-25 14:07 ` Dean Loros
2009-09-25 14:21   ` Vladimir 'phcoder' Serbinenko
  -- strict thread matches above, loose matches on Subject: below --
2009-09-25  4:45 Dean Loros
2009-09-25  6:31 ` Vladimir 'phcoder' Serbinenko
     [not found] <4ab7a42f.8353f10a.25a9.4896SMTPIN_ADDED@mx.google.com>
2009-09-22  3:17 ` Dean Loros
2009-09-22  7:56   ` Vladimir 'phcoder' Serbinenko
     [not found] <4ab6528a.9153f10a.3360.ffffaa79SMTPIN_ADDED@mx.google.com>
2009-09-20 16:32 ` Dean Loros
2009-09-20 20:00   ` Vladimir 'phcoder' Serbinenko
2009-09-21 14:16     ` Colin Watson
2009-09-21 14:22       ` Vladimir 'phcoder' Serbinenko
2009-09-21 14:58         ` Colin Watson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AB78C74.6060400@gmail.com \
    --to=phcoder@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.