2010/5/18 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com>: > This bsdlabel has 2 strangenesses. First one is seen in your log: > > a: 497936 16 unused 0 0 > In other words for some strange reason it's declared as unused entry slot.
Ah, you're right! My mistake. I'll edit the type to "4.2BSD" and will try again. > Second one is that offsets are stored relative to host partition, not > relative to disk start. Hmmm, that's interesting. On my (host) FreeBSD/amd64 system (not the disk image), the bsdlabel looks like this: phenom# bsdlabel /dev/ada0s1 # /dev/ada0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 2097152 0 4.2BSD 0 0 0 b: 8388608 2097152 swap c: 209712447 0 unused 0 0 # "raw" part, don't edit d: 16777216 10485760 4.2BSD 0 0 0 e: 16777216 27262976 4.2BSD 0 0 0 f: 41943040 44040192 4.2BSD 0 0 0 g: 123729215 85983232 4.2BSD 0 0 0 So it starts at offset 0. A separate slice (s3) on the same disk with a single partition starts at offset 16 though: phenom# bsdlabel /dev/ada0s3 # /dev/ada0s3: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 209712494 16 4.2BSD 0 0 0 c: 209712510 0 unused 0 0 # "raw" part, don't edit It starts at offset 16, as specified in bsdlabel(8): offset The offset of the start of the partition from the beginning of the drive in sectors, or * to have bsdlabel calculate the correct offset to use (the end of the previous partition plus one, ignor- ing partition `c'). For partition `c', * will be interpreted as an offset of 0. The first partition should start at offset 16, because the first 16 sectors are reserved for metadata. Strange.... Now, I'm somewhat confused. The man page says that it is relative to the beginning of the *drive*, but bsdlabel shows offsets relative to the beginning of the *slice*. Here's the code of bsdlabel.c (and yes, I confirm that I'm using this very precise SVN revision): http://svn.freebsd.org/viewvc/base/stable/8/sbin/bsdlabel/bsdlabel.c?revision=196384&view=markup&pathrev=196384 > While the first can be easily fixed by checking length instead of type, > second one isproblematic since it would break all other images (I've > checked with FreeBSD andNetBSD images I had under my hand). > So we need areliable way to determine which way is used. I'd say, don't worry about the type: this was clearly my mistake. For the second one, please refer to the bsdlabel.c source code above. I think this is the authoritative source, because that's the one that creates this label in the first place. I didn't edit it manually (just looked at it with "bsdlabel -e"). > I found few differing bytes between your image and my FreeBSD > image (specifically bytes 0x(80)30-0x(80)3f) but nothing that would > allow a reliable detection. If you can find out the reason and a way > of detecting this diskrepancy it will help That's interesting too. Will have to dig deeper into this. All I know is that FreeBSD groks this image perfectly, when used as md(4) device: I can edit and view slices with fdisk, set (and edit) the bsdlabel, newfs a filesysteme on it, mount it, change it etc... So it is clearly a valid image, at least as far as FreeBSD is concerned. > === modified file 'partmap/bsdlabel.c' > --- partmap/bsdlabel.c 2010-03-26 14:44:13 +0000 > +++ partmap/bsdlabel.c 2010-05-18 20:00:06 +0000 > @@ -64,11 +72,13 @@ bsdlabel_partition_map_iterate (grub_dis > if (grub_disk_read (disk, p.offset, p.index, sizeof (be), &be)) > return grub_errno; > > - p.start = grub_le_to_cpu32 (be.offset) - delta; > + p.start = grub_le_to_cpu32 (be.offset);// - delta; > p.len = grub_le_to_cpu32 (be.size); > p.partmap = &grub_bsdlabel_partition_map; > > - if (be.fs_type != GRUB_PC_PARTITION_BSD_TYPE_UNUSED) > + grub_dprintf ("bsdlabel", "%d, %d, %d\n", be.offset, be.size, > be.fs_type); > + > + if (p.len != 0) > if (hook (disk, &p)) > return grub_errno; I'll try this patch as soon as I can (hopefully tomorrow, I'm away from that system right now). Will get back to you and report back what it says. ;-) Thanks again for your help. Greatly appreciated. -cpghost. -- Cordula's Web. http://www.cordula.ws/ _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel