From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KL2tr-0002b6-9I for mharc-grub-devel@gnu.org; Mon, 21 Jul 2008 17:26:31 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KL2tp-0002ah-8W for grub-devel@gnu.org; Mon, 21 Jul 2008 17:26:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KL2tm-0002aU-QH for grub-devel@gnu.org; Mon, 21 Jul 2008 17:26:27 -0400 Received: from [199.232.76.173] (port=50569 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KL2tm-0002aR-LY for grub-devel@gnu.org; Mon, 21 Jul 2008 17:26:26 -0400 Received: from c60.cesmail.net ([216.154.195.49]:56618) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.60) (envelope-from ) id 1KL2tm-00066h-5q for grub-devel@gnu.org; Mon, 21 Jul 2008 17:26:26 -0400 Received: from unknown (HELO relay.cesmail.net) ([192.168.1.81]) by c60.cesmail.net with ESMTP; 21 Jul 2008 17:26:24 -0400 Received: from [192.168.0.21] (static-72-92-88-10.phlapa.fios.verizon.net [72.92.88.10]) by relay.cesmail.net (Postfix) with ESMTP id 9CBDB618F22 for ; Mon, 21 Jul 2008 17:26:22 -0400 (EDT) From: Pavel Roskin To: The development of GRUB 2 In-Reply-To: <20080719151410.GE23778@thorin> References: <1216040584.9995.52.camel@dv> <200807160115.07363.okuji@enbug.org> <1216164117.9604.8.camel@dv> <200807160132.18470.okuji@enbug.org> <1216165935.9604.26.camel@dv> <20080716071126.170a1d58@gibibit.com> <1216224537.26635.32.camel@dv> <20080719151410.GE23778@thorin> Content-Type: text/plain Date: Mon, 21 Jul 2008 17:26:17 -0400 Message-Id: <1216675577.11291.40.camel@dv> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Subject: Re: device.map (Re: Next release?) 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 Jul 2008 21:26:29 -0000 On Sat, 2008-07-19 at 17:14 +0200, Robert Millan wrote: > > As I understand it, there are two cases where we have to hardcode the > > drive number. > > > > 1) MBR and core.img (embedded or not) are on different drives. > > If embedded, then they're not different drives (core.img is put right after > MBR). > > Otherwise it's a no-go, and device.map won't solve your problem since it's > merely guessing which drive it'll be. I think it's better to detect this at > install time and fail, than make the user rely on our guesswork. We could do it in theory. Even with device.map. It's not much more insane than having /boot/grub on a different drive. The boot drive can have a "bad" geometry with too few sectors per track. Or it could be formatted as one partition. Or it could be a slow floppy drive. Or it could be in ROM. Or BIOS may not report the boot drive correctly. How can we fail to support this configuration and claim that the elimination of device.map would reduce flexibility? If we card about flexibility, let's support hardcoding the boot drive into the bootloader. Actually, the groundwork is already present in grub-setup and the bootsector, but grub-install doesn't have an option to force a drive for core.img embedding. > > 2) core.img and /boot/grub are on different drives. > > > > The second case can be mitigated because core.img can search all > > available drives. We can even tell it whether to search only hard > > drives or only floppies. After switching to lzma, we have some space in > > core.img we can use for that logic. > > This is mostly implemented already. I sent a proof of concept in a mail > titled "[PATCH] disk/fs_uuid.c". > > It will only search hard drives unless no match is found (in that case your > boot is broken, so you wouldn't care much that floppy is being probed ;-) Then all be need it to have an option in grub-install to enable this logic. -- Regards, Pavel Roskin