From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Mpd18-0006IF-DG for mharc-grub-devel@gnu.org; Mon, 21 Sep 2009 03:08:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mpd16-0006Hy-Ho for grub-devel@gnu.org; Mon, 21 Sep 2009 03:08:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mpd12-0006HO-5D for grub-devel@gnu.org; Mon, 21 Sep 2009 03:08:56 -0400 Received: from [199.232.76.173] (port=48363 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mpd11-0006HL-Uc for grub-devel@gnu.org; Mon, 21 Sep 2009 03:08:51 -0400 Received: from mx20.gnu.org ([199.232.41.8]:34334) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Mpd11-0005DT-DF for grub-devel@gnu.org; Mon, 21 Sep 2009 03:08:51 -0400 Received: from mail-fx0-f205.google.com ([209.85.220.205]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mpd10-0004YU-Om for grub-devel@gnu.org; Mon, 21 Sep 2009 03:08:50 -0400 Received: by fxm1 with SMTP id 1so2089490fxm.31 for ; Mon, 21 Sep 2009 00:08:49 -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=up0WcjiKWOOjfK76JksyDWpDNuf9PEqKFH9DyJg0FvM=; b=Gcq5ql9Yo/iLWaw2rRQZc8Zexun9/5F7s0te/GJrIDf12Wxi2Cxff9yv3ZixGovzEf xdTvslwNB/FFOpuT4LxA5SLMb2H6yRdR+axrHX9XG7TNarqFKawhph6mXjT/2b3L7HWR zlQGq4SHtj5q+uTr+02KhILaZ0DjEKtUZke8M= 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=jfeaNAOWSDsXQ0c6HIgbZ/ezitAcfrvm9n3emXayNW9FvxuUTIQANhOpUjWTMdi4Ny bxeIXFDeJ5wxApWzMEY/PW/BxKqx+lfZif4HxglUyP8Vce40s3c/qWyfUtiYt1iy6J87 Nexq9TBv1v804Bm4OM5mEVUjJpAEiRaKr1VTY= Received: by 10.86.169.3 with SMTP id r3mr4326992fge.15.1253516929615; Mon, 21 Sep 2009 00:08:49 -0700 (PDT) Received: from ?82.130.80.149? (hg-public-dock-149-dhcp.ethz.ch [82.130.80.149]) by mx.google.com with ESMTPS id d4sm5969393fga.13.2009.09.21.00.08.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 21 Sep 2009 00:08:48 -0700 (PDT) Message-ID: <4AB689CD.4060501@gmail.com> Date: Sun, 20 Sep 2009 22:00:13 +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: <4ab6528a.9153f10a.3360.ffffaa79SMTPIN_ADDED@mx.google.com> <4AB6592E.7050704@gmail.com> In-Reply-To: <4AB6592E.7050704@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-detected-operating-system: by mx20.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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 07:08:56 -0000 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