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 <phco...@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.4060...@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 > >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
