From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OG7pZ-0002Bo-7L for mharc-grub-devel@gnu.org; Sun, 23 May 2010 05:50:49 -0400 Received: from [140.186.70.92] (port=50274 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OG7pW-0002Bg-4V for grub-devel@gnu.org; Sun, 23 May 2010 05:50:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OG7pU-0006UK-2h for grub-devel@gnu.org; Sun, 23 May 2010 05:50:45 -0400 Received: from mail-wy0-f169.google.com ([74.125.82.169]:43306) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OG7pT-0006U9-Rw for grub-devel@gnu.org; Sun, 23 May 2010 05:50:44 -0400 Received: by wyf22 with SMTP id 22so788242wyf.0 for ; Sun, 23 May 2010 02:50:42 -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; bh=MDlltN9Vsb0A+r+TUj0Qpj/NHTffaVyEfHsZqN8HjWM=; b=qM3UHO6BOqzp9P3dw2d31hIdEMClGvgjD0RgojOIFgfnitTG01EShwIM4CQpaVzW2j aiR466l+kddoJnEXId8niQlyXZJ7aAUcRgBwgKYyCkU40lnP0+q6Sr2Umx6MM7FtfdcF CwkiHxFRpEH4hghUY+BQuww9PsmrrxX1o/PPk= 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; b=ay6mPDdADFUKJ36IajFk9KcSJRqRiwqnJdWV6YTTYLsYvpUQ2BcZFyN9KXHBmYH/9r 5admFB4s8UOpMVxbSpobRg6eWhiK9+tgnWBIt0qRm+FxgiWv2u2SigBRyNjRKSH5ivz3 U9mMqW2gt3ygmima/A11HmR8VaBilQMRuG4W8= Received: by 10.227.136.10 with SMTP id p10mr3773993wbt.7.1274608242573; Sun, 23 May 2010 02:50:42 -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 l23sm22376907wbb.14.2010.05.23.02.50.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 23 May 2010 02:50:42 -0700 (PDT) Message-ID: <4BF8FA66.5060702@gmail.com> Date: Sun, 23 May 2010 11:50:30 +0200 From: =?UTF-8?B?R3LDqWdvaXJlIFN1dHJl?= 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 References: <4BF2DE4F.7070209@gmail.com> <4BF2F68E.8090906@gmail.com> <4BF42759.1010503@gmail.com> <4BF43302.6080106@gmail.com> <4BF43A0A.80801@gmail.com> In-Reply-To: <4BF43A0A.80801@gmail.com> Content-Type: multipart/mixed; boundary="------------050500050700040106040205" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Are BSD partitions not supported? 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: Sun, 23 May 2010 09:50:47 -0000 This is a multi-part message in MIME format. --------------050500050700040106040205 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 05/19/2010 09:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: [snip] - delta = grub_partition_get_start (disk->partition); + delta = grub_le_to_cpu32 (whole_disk_be.offset); As dicsussed on irc, this makes the delta completely dependent on the c: entry of the disklabel, which could be bogus. For instance, on NetBSD/i386, the system seems to work fine with random entries for c: in the disk label stored on the disk. Even a null offset is fine. The in-core disklabel shown by the command disklabel (without -r) is the correct one. I give an example below, which was obtained on system booted from wd0. IMHO, the current code is better for the cases where the offsets in the disklabel are absolute addresses, since it performs exactly the inverse translation of the one done in grub_partition_get_start(), which AFAICS is supposed to return the absolute address. What we want here is to diverge from that code when the disklabel offsets are relative. I believe that testing whether c: has a null offset gives the answer. I changed Vladimir's second patch to do that. We still have the problem that NetSBD uses c: for the whole-disk partition on many ports (but it's d: on i386 and amd64), see [1]. For those ports, the normal offset for c: is 0. But maybe it's fair to assume that, on those ports, the NetBSD slice is never embedded in another partition? Grégoire [1] http://nxr.netbsd.org/source/s?defs=RAW_PART&project=/src On-disk label niagara# disklabel -r wd0 16 partitions: # size offset fstype a: 263088 10233405 4.2BSD b: 2097648 10496493 swap c: 82345673 0 unused d: 117210240 0 unused . . . ------------------------------------------------------------------------- In-core label niagara# disklabel wd0 # /dev/rwd0d: . . . 16 partitions: # size offset fstype a: 263088 10233405 4.2BSD b: 2097648 10496493 swap c: 58605120 10233405 unused d: 117210240 0 unused . . . --------------050500050700040106040205 Content-Type: text/x-patch; name="bsdlabel_v3.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="bsdlabel_v3.diff" === modified file 'include/grub/bsdlabel.h' --- include/grub/bsdlabel.h 2010-02-06 17:43:37 +0000 +++ include/grub/bsdlabel.h 2010-05-23 09:21:04 +0000 @@ -63,6 +63,8 @@ #define GRUB_PC_PARTITION_OPENBSD_TYPE_NTFS 18 #define GRUB_PC_PARTITION_OPENBSD_TYPE_RAID 19 +#define GRUB_PC_PARTITION_BSD_LABEL_WHOLE_DISK_PARTITION 2 + /* The BSD partition entry. */ struct grub_partition_bsd_entry { === modified file 'partmap/bsdlabel.c' --- partmap/bsdlabel.c 2010-03-26 14:44:13 +0000 +++ partmap/bsdlabel.c 2010-05-23 09:30:11 +0000 @@ -49,15 +49,37 @@ if (label.magic != grub_cpu_to_le32 (GRUB_PC_PARTITION_BSD_LABEL_MAGIC)) return grub_error (GRUB_ERR_BAD_PART_TABLE, "no signature"); + /* A kludge for disklabels with relative offsets. */ + if (GRUB_PC_PARTITION_BSD_LABEL_WHOLE_DISK_PARTITION + < grub_cpu_to_le16 (label.num_partitions)) + { + struct grub_partition_bsd_entry whole_disk_be; + + pos = sizeof (label) + GRUB_PC_PARTITION_BSD_LABEL_SECTOR + * GRUB_DISK_SECTOR_SIZE + sizeof (struct grub_partition_bsd_entry) + * GRUB_PC_PARTITION_BSD_LABEL_WHOLE_DISK_PARTITION; + + if (grub_disk_read (disk, pos / GRUB_DISK_SECTOR_SIZE, + pos % GRUB_DISK_SECTOR_SIZE, sizeof (whole_disk_be), + &whole_disk_be)) + return grub_errno; + + if (grub_le_to_cpu32 (whole_disk_be.offset) == 0) + delta = 0; + } + pos = sizeof (label) + GRUB_PC_PARTITION_BSD_LABEL_SECTOR * GRUB_DISK_SECTOR_SIZE; for (p.number = 0; p.number < grub_cpu_to_le16 (label.num_partitions); - p.number++) + p.number++, pos += sizeof (struct grub_partition_bsd_entry)) { struct grub_partition_bsd_entry be; + if (p.number == GRUB_PC_PARTITION_BSD_LABEL_WHOLE_DISK_PARTITION) + continue; + p.offset = pos / GRUB_DISK_SECTOR_SIZE; p.index = pos % GRUB_DISK_SECTOR_SIZE; @@ -68,11 +90,9 @@ p.len = grub_le_to_cpu32 (be.size); p.partmap = &grub_bsdlabel_partition_map; - if (be.fs_type != GRUB_PC_PARTITION_BSD_TYPE_UNUSED) + if (p.len != 0) if (hook (disk, &p)) return grub_errno; - - pos += sizeof (struct grub_partition_bsd_entry); } return GRUB_ERR_NONE; --------------050500050700040106040205--