From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1MpPLN-0003Iv-Gr for mharc-grub-devel@gnu.org; Sun, 20 Sep 2009 12:32:57 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MpPLK-0003IY-FI for grub-devel@gnu.org; Sun, 20 Sep 2009 12:32:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MpPLF-0003IM-QJ for grub-devel@gnu.org; Sun, 20 Sep 2009 12:32:54 -0400 Received: from [199.232.76.173] (port=49384 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MpPLF-0003IJ-Ke for grub-devel@gnu.org; Sun, 20 Sep 2009 12:32:49 -0400 Received: from mail-px0-f171.google.com ([209.85.216.171]:54184) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MpPLF-0006ey-6i for grub-devel@gnu.org; Sun, 20 Sep 2009 12:32:49 -0400 Received: by pxi1 with SMTP id 1so1907962pxi.1 for ; Sun, 20 Sep 2009 09:32:48 -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 :x-enigmail-version:content-type:content-transfer-encoding; bh=vyZlt1I/hFyUrNf5Lpf8xw4V4zqraRYOmqpqXc/A/U8=; b=kum+sMl4u5nw7Hfwohix1/Djz3EJdWJiAy4xZkI6jSyJ9IvTi6vm7zIq4YDin/zxY8 p9TZwuitZ0KWemjeAOSrN7V1UxwDQrUs3IxjCgRqpyliNaxGMx0mdSKM+b4C1+8QF4Q0 w6Q3KGKvFKVAiTgMBa2rlykNSWbmWaTitssrY= 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:x-enigmail-version:content-type :content-transfer-encoding; b=KdE8Kb2w5y+Sfg7nFDzPZEsFT65gj4TZSKTQxspHIb2LiuWdFyntSzcZRNvIGN8ZDH 0q+KlZypyykPC+ZUCHpmToiVxXL05v0AN70zScvb/7UIdHZLyJ0NWLPvRnyx+JVrkBEk gLZjesV5zmXZxJpvphRJlo4WL67f88CqowCC8= Received: by 10.115.65.11 with SMTP id s11mr6704267wak.170.1253464368015; Sun, 20 Sep 2009 09:32:48 -0700 (PDT) Received: from ?192.168.1.101? (or-71-53-64-80.dhcp.embarqhsd.net [71.53.64.80]) by mx.google.com with ESMTPS id 22sm1897083pzk.14.2009.09.20.09.32.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 20 Sep 2009 09:32:47 -0700 (PDT) Message-ID: <4AB6592E.7050704@gmail.com> Date: Sun, 20 Sep 2009 09:32:46 -0700 From: Dean Loros User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090918 Shredder/3.0pre MIME-Version: 1.0 To: grub-devel@gnu.org References: <4ab6528a.9153f10a.3360.ffffaa79SMTPIN_ADDED@mx.google.com> In-Reply-To: <4ab6528a.9153f10a.3360.ffffaa79SMTPIN_ADDED@mx.google.com> X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: 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: Sun, 20 Sep 2009 16:32:55 -0000 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. During the 3+ minutes, there is constant drive activity. Colin had asked at one time for me to do a debug run which was one of the most painful times I have had in current memory--the system worked for more than 20min without going to menu & required booting with a LiveCD to repair problems from the outside. It looks like Grub2 needs to scan all the drives for all the supported filesystems several times before it "finds" the /boot that works. I will also note that I do not have any other grub installs other than my main Grub2 install, so there is only one /boot in the system. MBR is on SDA (storage drive)--I also have one install on SDB, my /boot is on SDC with a second install & two more operating systems are on SDD for a total of five operating systems (Two testing Karmic & several other installs). My thought is: Is there a way to "tag" the Grub2 /boot so time to locate is acceptable? Or is there another way to scan filesystems? Maybe a way to "tag" the type of filesystem in use? Bug report is: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/420933 With supporting information. IF you need more information or want me to do further testing, please contact me @ ubuntu1user at gmail.com Thank you for your time in this matter. -- Dean Loros autocrosser at ubuntuforums.org Performance by Design Ltd.