From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OGvcr-0001lV-OO for mharc-grub-devel@gnu.org; Tue, 25 May 2010 11:01:01 -0400 Received: from [140.186.70.92] (port=41668 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGvco-0001ja-CM for grub-devel@gnu.org; Tue, 25 May 2010 11:00:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGvch-0004SF-EZ for grub-devel@gnu.org; Tue, 25 May 2010 11:00:58 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:35782) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGvch-0004Rc-8m for grub-devel@gnu.org; Tue, 25 May 2010 11:00:51 -0400 Received: by wyf19 with SMTP id 19so124609wyf.0 for ; Tue, 25 May 2010 08:00: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:content-type :content-transfer-encoding; bh=chX7BtaY0Pv8regg6QxL99sfoXICAPWVDYPccRADt0A=; b=RIXew6iAJGrYD8bZFH004x2kJj5/rOYHTi4Sgtq++L08h9hwjXrfN0M3UPaloLLgLS F2ybBR0XnoMYSSyXRqOQdTqSTUhuXlzXis2hK4XSeVqM0qaBCc9+FZYbBb0g7luSU4+9 pE01tdCvEzv+bXXlsxvhdlX/WQmrmmgZLhgc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=PYT0iXaNbhV20BE9CE72lcjtTn5ZFBK1BJ9F967EFeo0ABtb7t9ueP+alpUOd7kRW6 I/ImnZKlW21pXzdLJ7vVjmuYVd2YlmmNlaAHFqY/GO9/eDQbeBY5s7h8ze0yfMQZLuVg B+65lC8roHO0w8+Gy5pLevXMRq3zPDOK7OYMA= Received: by 10.227.137.135 with SMTP id w7mr7037634wbt.10.1274799649519; Tue, 25 May 2010 08:00:49 -0700 (PDT) Received: from [192.168.1.50] (c2433-1-88-160-112-182.fbx.proxad.net [88.160.112.182]) by mx.google.com with ESMTPS id f8sm39973129wbe.23.2010.05.25.08.00.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 25 May 2010 08:00:49 -0700 (PDT) Message-ID: <4BFBE619.6090204@gmail.com> Date: Tue, 25 May 2010 17:00:41 +0200 From: =?ISO-8859-1?Q?Gr=E9goire_Sutre?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100411 Icedove/3.0.4 MIME-Version: 1.0 To: The development of GNU GRUB Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: grub-setup failure with (primary) BSD disklabel X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 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: Tue, 25 May 2010 15:00:59 -0000 Hi, When there is both a MBR partition table and a (primary) BSD disklabel, grub-setup returns an error: No DOS-style partitions found. Yet, the partition containing the GRUB images is in the MBR. But we are actually lucky, since it could be worse. Below is a detailed example on NetBSD/i386 starting with an empty disk (actually, a virtual disk vnd(4)). First disklabel the disk for NetBSD use, say we get: # size offset fstype a: 4000 100 4.2BSD d: 16384 0 unused The disklabel is stored in the second sector of the disk (at offset 1). Now, assume that we also want to use the disk with another OS. We create an MBR partition for it, and add the partition to the NetBSD disklabel. We initialize its filesystem. We get: Partition table: 0: Linux native (sysid 131) start 8064, size 8064 (4 MB, Cyls 3/60/1-7/55/32) PBR is not bootable: All bytes are identical (0x00) 1: 5 partitions: # size offset fstype a: 4000 100 4.2BSD d: 16384 0 unused e: 8064 8064 Linux Ext2 Let us now try to install grub on the disk: $ mount /dev/vnd0e /mnt/disk $ grub2-install --debug --root-directory=/mnt/disk /dev/rvnd0d grub2-setup: info: setting the root device to `/dev/rvnd0d,5'. grub2-setup: info: dos partition is 4, bsd partition is -1. grub2-setup: error: No DOS-style partitions found. AFAICS, grub-setup sees e: as (vnd0d,bsd5) and therefore complains that the (primary) partmap is not msdos. This is actually not so bad. Indeed, e: could have been detected as (vnd0d,msdos1), in which case grub-setup would have destroyed the NetBSD disklabel (stored at offset 1). AFAICS, the only reason why e: is detected as (vnd0d,bsd5) is the order of the partmap_modules in the file grub_setup_init.lst generated by the build. This order depends on the order of the .c files obtained by the make command $(filter %.c,$^). For instance, if all occurences of $(filter %.c,...) are replaced by $(sort $(filter %.c,...)) in conf/common.rmk, then e: is detected as (vnd0d,msdos1), grub-setup succeeds and the NetBSD disklabel is effectively destroyed (but grub successfully boots -- tested in qemu). IMHO, implicitly relying on the order of $(filter %.c,...) is not robust. I thought of several options to solve this issue: (a) declare that the order in which the partmap modules are loaded is critical, and make sure that we get the right order. (b) check that each sector to be written by grub-setup does not contain a disklabel, and abort if any is found (unless e.g. --force was specified). We have at most 62 sectors to check, and there is room for optimization (by taking into account the size of core.img). (c) as (b), but do not abort if there is a sufficiently large contiguous embedding area. I would prefer (c) as it would allow the installation of grub when a BSD disklabel is at offset 1 (we would only lose one sector as embedding space). That is, if grub-setup searches a DOS-style partmap in all primary partmaps instead of stoping at the first one. Thanks for reading all of this :-) Comments welcome, Grégoire