From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Rvvit-0000zc-In for mharc-grub-devel@gnu.org; Fri, 10 Feb 2012 14:01:31 -0500 Received: from eggs.gnu.org ([140.186.70.92]:34892) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rvvir-0000zD-F4 for grub-devel@gnu.org; Fri, 10 Feb 2012 14:01:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rvvip-00025y-Is for grub-devel@gnu.org; Fri, 10 Feb 2012 14:01:29 -0500 Received: from mail-ww0-f49.google.com ([74.125.82.49]:43421) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rvvip-00025m-AU for grub-devel@gnu.org; Fri, 10 Feb 2012 14:01:27 -0500 Received: by wgbdt13 with SMTP id dt13so2350543wgb.30 for ; Fri, 10 Feb 2012 11:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Wl8vGYpBBMCDUIAyOCJBTfAoHjVpGfI//QCNnO5ysi0=; b=lMpMdkRTil6fQDvfl5i7+Ngs42LYQfoFt4W9R6oBjJTsycmSEeMPAmsKGBYW7btvKg +nQ+CKbgUTBZ9ohMoGhEdjWcOzd9E0zaD9HpUeAp79PJJ9WIMqtWddHYTPszTcslluxr N8uyJMUydXq6zBze4MqjVr0vVVtMfv7SNMCvw= Received: by 10.180.87.8 with SMTP id t8mr5011220wiz.15.1328900486120; Fri, 10 Feb 2012 11:01:26 -0800 (PST) Received: from debian.x201.phnet (93-93.203-62.cust.bluewin.ch. [62.203.93.93]) by mx.google.com with ESMTPS id eq5sm20598044wib.2.2012.02.10.11.01.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 11:01:24 -0800 (PST) Message-ID: <4F356983.40905@gmail.com> Date: Fri, 10 Feb 2012 20:01:23 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: Lennart Sorensen Subject: Re: Various build failures in current bzr tree References: <20120209190204.GW27742@caffeine.csclub.uwaterloo.ca> <20120209193301.GX27742@caffeine.csclub.uwaterloo.ca> <20120209205045.GY27742@caffeine.csclub.uwaterloo.ca> <20120209205603.GZ27742@caffeine.csclub.uwaterloo.ca> <4F34509C.5050005@gmail.com> <20120210155450.GB27742@caffeine.csclub.uwaterloo.ca> <4F3541A4.10502@gmail.com> <20120210181823.GD27742@caffeine.csclub.uwaterloo.ca> In-Reply-To: <20120210181823.GD27742@caffeine.csclub.uwaterloo.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 74.125.82.49 Cc: The development of GNU GRUB X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 19:01:30 -0000 On 10.02.2012 19:18, Lennart Sorensen wrote: > On Fri, Feb 10, 2012 at 05:11:16PM +0100, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> Imagine following setup: 2 disks with msdos and one with gpt. GPT >> one is missing on install time and so no part_gpt is inserted. On >> boot time is then one of msdos disks is missing and so GPT one is >> needed to complete a readable device but it's inaccessible since no >> GPT module is loaded. > Well I only hit this because one of Debian's update-grub scripts tried to > do a grub-probe and failed. It wasn't an important one in my case, > so I disabled that script. I do think most people would have a fully > working system before installing the boot loader so not a major problem. I agree that it should be fixed but the question is how. >> This and the rest of your e-mail is because of confusion of 2 >> concepts: grub_device and install_device. >> grub_device is whereever GRUB modules reside and is determined from >> $boot_directory/grub (default is /boot/grub) >> install_device is whereever the core is and is the argument to grub-install. >> They are independent since you want to put core wherever firmware >> will find it independently of where your root is. >> install_device is not infered from grub_device or vice-versa. >> In mdraid example grub_device=mduuid/ but install_device is >> still /dev/sdaX > So if I tell grub-install to use /dev/sda1 as install_device, should > it not include the partition table support for sda? No > Currently it only > tries to include partition table support for grub_device, which being > an md raid returns nothing. This is a problem. It should return the partmap of underlying device and we have code for that. What does grub-probe -t partmap -d /dev/mdX is? -- Regards Vladimir 'φ-coder/phcoder' Serbinenko