From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpjoA-00036a-QA for mharc-grub-devel@gnu.org; Mon, 21 Sep 2009 10:24:02 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpjo7-00034B-Sx for grub-devel@gnu.org; Mon, 21 Sep 2009 10:23:59 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mpjo3-000319-Ul for grub-devel@gnu.org; Mon, 21 Sep 2009 10:23:59 -0400 Received: from [199.232.76.173] (port=54971 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mpjo3-00030t-NX for grub-devel@gnu.org; Mon, 21 Sep 2009 10:23:55 -0400 Received: from mail-fx0-f205.google.com ([209.85.220.205]:49683) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mpjo3-0000b9-0h for grub-devel@gnu.org; Mon, 21 Sep 2009 10:23:55 -0400 Received: by fxm1 with SMTP id 1so2336587fxm.31 for ; Mon, 21 Sep 2009 07:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0o1Uasf8LDzZdwaF9grhnWUkfHziQHrTpq5j9OZmjPs=; b=fMWxYvan8697cbq8ViDyEnofvLmvSmVIyjEpeOu+T9Szsj2e9NSBNJFh8XXK+JuNL/ /7Nfv7H1FatC/udE/u/pZkyLIn9yw686Z52epDc5wXfkN/dgS6t3IBtXJnykIRSy6k/8 nFEbax47jjViBqWrRhOznridhY/4OTxHKeq1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ZvqWdrLHwaSwIeI8UhFF9u5EuWtViTjxhWPQrstj65ziSQyUyE2BEzn9Wk5ASzhzsE Z4G0MkNagWxIHOPdmzQKdLZUVWHi12t5aptyC64IgWeFtFedL7aTKYn1ikJ3ObbDjUh4 SR+rQZ/3f0w9bdQsMYikJ2GBgaifon/1VkZwM= Received: by 10.204.5.75 with SMTP id 11mr4337290bku.20.1253543032875; Mon, 21 Sep 2009 07:23:52 -0700 (PDT) Received: from ?82.130.79.152? (ifw-public-dock-152-dhcp.ethz.ch [82.130.79.152]) by mx.google.com with ESMTPS id 18sm174290fks.10.2009.09.21.07.23.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 21 Sep 2009 07:23:50 -0700 (PDT) Message-ID: <4AB78C74.6060400@gmail.com> Date: Mon, 21 Sep 2009 16:23:48 +0200 From: Vladimir 'phcoder' Serbinenko User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: The development of GRUB 2 References: <4ab726d8.9d53f10a.2065.414bSMTPIN_ADDED@mx.google.com> <4AB78965.8000606@gmail.com> In-Reply-To: <4AB78965.8000606@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Current Grub2 & problem with /boot on different drive X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:24:00 -0000 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 > Subject: Re: Current Grub2 & problem with /boot on different drive > To: The development of GRUB 2 > 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 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 > >