Are BSD partitions not supported?

Are BSD partitions not supported?

[C. P. Ghost]

Hello,

is support for BSD partitions (or maybe ufs2) broken in grub2 (1.98)?

On FreeBSD 8.0-STABLE #0 r207730 amd64:

=== 1. Creating a disk image:

phenom# dd if=/dev/zero of=disk.img bs=512 count=500000
500000+0 records in
500000+0 records out
256000000 bytes transferred in 3.318285 secs (77148286 bytes/sec)

=== 2. Turning it into a memory device /dev/md4444:

phenom# mdconfig -a -t vnode -f disk.img -u 4444
phenom# ls -l /dev/md*
crw-r-----  1 root  operator    0, 152 May 16 17:40 /dev/md4444
crw-------  1 root  wheel       0,  58 May 16 17:01 /dev/mdctl

=== 3. Setting a partition table on it:

phenom# sysctl kern.geom.debugflags=16
kern.geom.debugflags: 0 -> 16

phenom# fdisk -u /dev/md4444

(...)

Information from DOS bootblock is:
1: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 497952 (243 Meg), flag 80 (active)
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 30/ head 254/ sector 63
2: <UNUSED>
3: <UNUSED>
4: <UNUSED>
Should we write new partition table? [n] y
fdisk: Class not found

phenom# ls -l /dev/md4444*
crw-r-----  1 root  operator    0, 152 May 16 17:43 /dev/md4444
crw-r-----  1 root  operator    0, 153 May 16 17:43 /dev/md4444s1

=== 4. Creating a disk label on it:

phenom# bsdlabel -w /dev/md4444s1
phenom# bsdlabel -e /dev/md4444s1

(...)

phenom# bsdlabel /dev/md4444s1
# /dev/md4444s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:   497936       16    unused        0     0
  c:   497952        0    unused        0     0         # "raw" part, don't edit

phenom# ls -l /dev/md*
crw-r-----  1 root  operator    0, 152 May 16 17:43 /dev/md4444
crw-r-----  1 root  operator    0, 153 May 16 17:45 /dev/md4444s1
crw-r-----  1 root  operator    0, 155 May 16 17:45 /dev/md4444s1a
crw-------  1 root  wheel       0,  58 May 16 17:01 /dev/mdctl

=== 5. Creating a file system:

phenom# newfs /dev/md4444s1a
/dev/md4444s1a: 243.1MB (497936 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 60.80MB, 3891 blks, 7808 inodes.
super-block backups (for fsck -b #) at:
 160, 124672, 249184, 373696
phenom# mount /dev/md4444s1a /mnt

=== 6. Installing grub on it:

phenom# grub-install --root-directory=/mnt /dev/md4444
/usr/local/sbin/grub-probe: error: no such partition.
Auto-detection of a filesystem module failed.
Please specify the module with the option `--modules' explicitly.

phenom# grub-install --root-directory=/mnt --modules=ufs2 /dev/md4444
/usr/local/sbin/grub-probe: error: no such partition.
/usr/local/sbin/grub-probe: error: no such partition.
/usr/local/sbin/grub-setup: error: no such partition.

Whatever happened here, the modules ARE now installed
in /mnt/boot/grub...

=== 7. Playing with grub-probe:

phenom# grub-probe --device /dev/md4444 --target=fs
grub-probe: error: unknown filesystem.
phenom# grub-probe --device /dev/md4444s1 --target=fs
grub-probe: error: unknown filesystem.
phenom# grub-probe --device /dev/md4444s1a --target=fs
grub-probe: error: no such partition.

phenom# grub-probe --device /dev/md4444s1a --target=drive
(/dev/md4444,1,a)

phenom# grub-probe --device /dev/md4444s1a --target=fs_uuid
grub-probe: error: no such partition.
phenom# grub-probe --device /dev/md4444s1 --target=fs_uuid
grub-probe: error: unknown filesystem.

phenom# grub-probe --device /dev/md4444s1 --target=partmap
part_msdos
phenom# grub-probe --device /dev/md4444s1a --target=partmap
grub-probe: error: no such partition.

=== 8. Umounting the disk image

phenom# umount /mnt
phenom# mdconfig -d -u 4444
phenom# sysctl kern.geom.debugflags=0
kern.geom.debugflags: 16 -> 0
phenom# chmod 666 disk.img

=== 9. Testing grub with qemu

% qemu -hda disk.img
Booting from Hard Disk
Missing operating system_

What am I missing here? BTW, if I repeat the steps above
with a different slice type (e.g. FAT<something>) and filesystem
type msdosfs, grub2 works as it should. So it must be something
with BSD slices/partitions or UFS/UFS2 support that appears
(or is?) broken.

Thanks,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[C. P. Ghost]

On Sun, May 16, 2010 at 6:24 PM, C. P. Ghost <cpghost@cordula.ws> wrote:
> is support for BSD partitions (or maybe ufs2) broken in grub2 (1.98)?

No replies so far? Could a developer *please* have a closer look
at this?

TIA,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

C. P. Ghost wrote:
> On Sun, May 16, 2010 at 6:24 PM, C. P. Ghost <cpghost@cordula.ws> wrote:
>   
>> is support for BSD partitions (or maybe ufs2) broken in grub2 (1.98)?
>>     
>
> No replies so far? Could a developer *please* have a closer look
> at this?
>
>   
Your mail is quite long and looks like a tech support request. If it is
such it's not right mailing list. Use help-grub@gnu.org or IRC. If it's
a bug report please supply an image file which triggers bug.
BSD partitions are supported as long as part_msdos and part_bsd (not
necessary in release) are loaded.
> TIA,
> -cpghost.
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Are BSD partitions not supported?

[C. P. Ghost]

2010/5/18 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> C. P. Ghost wrote:
>> On Sun, May 16, 2010 at 6:24 PM, C. P. Ghost <cpghost@cordula.ws> wrote:
>>
>>> is support for BSD partitions (or maybe ufs2) broken in grub2 (1.98)?
>>>
>>
>> No replies so far? Could a developer *please* have a closer look
>> at this?
>>
>>
> Your mail is quite long and looks like a tech support request. If it is
> such it's not right mailing list. Use help-grub@gnu.org or IRC. If it's
> a bug report please supply an image file which triggers bug.
> BSD partitions are supported as long as part_msdos and part_bsd (not
> necessary in release) are loaded.

(2nd try, mailer swallowed the attachment)

Thank you for replying.

Of course, it is a bug report. The steps to create the image are
very detailed and should be enough to reproduce the bug on a
FreeBSD/amd64 system.

Here's a 362k 7z-compressed image of a 25MB disk
that contains one slice 's1' with a BSD partition 'a' and
a UFS2 filesystem on it:

http://www.cordula.ws/tempdir/bsddisk.7z

Don't expect it to boot, because grub-install wasn't able
to complete the task (grub-probe failed as in the long mail).
The file system contains the /boot/grub/* files though: those
were properly installed by grub-install. Just not the MBR.

If I can provide more help, please do ask. :)

>> TIA,
>> -cpghost.
>
> --
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3259 bytes --]

C. P. Ghost wrote:
> 2010/5/18 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>   
>> C. P. Ghost wrote:
>>     
>>> On Sun, May 16, 2010 at 6:24 PM, C. P. Ghost <cpghost@cordula.ws> wrote:
>>>
>>>       
>>>> is support for BSD partitions (or maybe ufs2) broken in grub2 (1.98)?
>>>>
>>>>         
>>> No replies so far? Could a developer *please* have a closer look
>>> at this?
>>>
>>>
>>>       
>> Your mail is quite long and looks like a tech support request. If it is
>> such it's not right mailing list. Use help-grub@gnu.org or IRC. If it's
>> a bug report please supply an image file which triggers bug.
>> BSD partitions are supported as long as part_msdos and part_bsd (not
>> necessary in release) are loaded.
>>     
>
> (2nd try, mailer swallowed the attachment)
>
> Thank you for replying.
>
> Of course, it is a bug report. The steps to create the image are
> very detailed and should be enough to reproduce the bug on a
> FreeBSD/amd64 system.
>
> Here's a 362k 7z-compressed image of a 25MB disk
> that contains one slice 's1' with a BSD partition 'a' and
> a UFS2 filesystem on it:
>
> http://www.cordula.ws/tempdir/bsddisk.7z
>
> Don't expect it to boot, because grub-install wasn't able
> to complete the task (grub-probe failed as in the long mail).
> The file system contains the /boot/grub/* files though: those
> were properly installed by grub-install. Just not the MBR.
>
> If I can provide more help, please do ask. :)
>
>   
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.
Second one is that offsets are stored relative to host partition, not relative to disk start. 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 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



=== 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;
 



>>> TIA,
>>> -cpghost.
>>>       
>> --
>> Regards
>> Vladimir 'φ-coder/phcoder' Serbinenko
>>     
>
> -cpghost.
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Are BSD partitions not supported?

[C. P. Ghost]

2010/5/18 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@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/

Re: Are BSD partitions not supported?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 5706 bytes --]

Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> C. P. Ghost wrote:
>   
>> 2010/5/18 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>   
>>     
>>> C. P. Ghost wrote:
>>>     
>>>       
>>>> On Sun, May 16, 2010 at 6:24 PM, C. P. Ghost <cpghost@cordula.ws> wrote:
>>>>
>>>>       
>>>>         
>>>>> is support for BSD partitions (or maybe ufs2) broken in grub2 (1.98)?
>>>>>
>>>>>         
>>>>>           
>>>> No replies so far? Could a developer *please* have a closer look
>>>> at this?
>>>>
>>>>
>>>>       
>>>>         
>>> Your mail is quite long and looks like a tech support request. If it is
>>> such it's not right mailing list. Use help-grub@gnu.org or IRC. If it's
>>> a bug report please supply an image file which triggers bug.
>>> BSD partitions are supported as long as part_msdos and part_bsd (not
>>> necessary in release) are loaded.
>>>     
>>>       
>> (2nd try, mailer swallowed the attachment)
>>
>> Thank you for replying.
>>
>> Of course, it is a bug report. The steps to create the image are
>> very detailed and should be enough to reproduce the bug on a
>> FreeBSD/amd64 system.
>>
>> Here's a 362k 7z-compressed image of a 25MB disk
>> that contains one slice 's1' with a BSD partition 'a' and
>> a UFS2 filesystem on it:
>>
>> http://www.cordula.ws/tempdir/bsddisk.7z
>>
>> Don't expect it to boot, because grub-install wasn't able
>> to complete the task (grub-probe failed as in the long mail).
>> The file system contains the /boot/grub/* files though: those
>> were properly installed by grub-install. Just not the MBR.
>>
>> If I can provide more help, please do ask. :)
>>
>>   
>>     
> 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.
> Second one is that offsets are stored relative to host partition, not relative to disk start. 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 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
>
>   
My first thought was to use 'c' partition to find this base but I
dismissed it straight ahead because it's only a convention that 'c'
covers the whole disk. But then I played with bsdlabel and found out
that if I move 'c' partition FreeBSD itself is confused too. Since
nobody would consider it a bug if GRUB doesn't recognise properly a
partition not workable in FreeBSD itself I think we should go for
consistent behaviour for the lack of anything better. Try the patch:
=== modified file 'include/grub/bsdlabel.h'
--- include/grub/bsdlabel.h    2010-02-06 17:43:37 +0000
+++ include/grub/bsdlabel.h    2010-05-18 22:05:09 +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-18 22:13:37 +0000
@@ -37,9 +37,6 @@
   grub_disk_addr_t delta = 0;
   unsigned pos;
 
-  /* BSDLabel offsets are absolute even when it's embed inside
partition.  */
-  delta = grub_partition_get_start (disk->partition);
-
   /* Read the BSD label.  */
   if (grub_disk_read (disk, GRUB_PC_PARTITION_BSD_LABEL_SECTOR,
               0, sizeof (label), &label))
@@ -49,15 +46,36 @@
   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 to determine a base of be.offset.  */
+  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;
+
+      delta = grub_le_to_cpu32 (whole_disk_be.offset);
+    }
+
   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 +86,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;



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Are BSD partitions not supported?

[C. P. Ghost]

On Wed, May 19, 2010 at 12:06 AM, C. P. Ghost <cpghost@cordula.ws> wrote:
> 2010/5/18 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@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.

Okay, first with the original non-patched 1.98 grub2 version,
after setting the type to 4.2BSD in bsdlabel:

phenom# bsdlabel /dev/md5555s1
# /dev/md5555s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:    48116       16    4.2BSD        0     0     0
  c:    48132        0    unused        0     0         # "raw" part, don't edit

phenom# newfs /dev/md5555s1a
/dev/md5555s1a: 23.5MB (48116 sectors) block size 16384, fragment size 2048
        using 4 cylinder groups of 5.88MB, 376 blks, 768 inodes.
super-block backups (for fsck -b #) at:
 160, 12192, 24224, 36256

phenom# mount /dev/md5555s1a /mnt

phenom# grub-install --root-directory=/mnt --modules=ufs2 /dev/md5555
/usr/local/sbin/grub-probe: error: unknown filesystem.
Installation finished. No error reported.

This copies /boot/grub/* to /mnt as before. Now, if I run qemu, I get
dropped into grub-rescue:

% qemu -hda bsddisk.img
GRUB loading.
Welcome to GRUB!

error: unknown filesystem.
Entering rescue mode...
grub rescue> _

grub rescue> insmod part_msdos
grub rescue> insmod part_bsd
error: unknown filesystem.

Unfortunately, the patch doesn't apply cleanly (against the
bzr version):

% patch -p0 < ../../patch-002
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|--- partmap/bsdlabel.c    2010-03-26 14:44:13 +0000
|+++ partmap/bsdlabel.c    2010-05-18 22:13:37 +0000
--------------------------
Patching file partmap/bsdlabel.c using Plan A...
Hunk #1 succeeded at 37 with fuzz 1.
Hunk #2 succeeded at 46.
Hunk #3 failed at 86.
1 out of 3 hunks failed--saving rejects to partmap/bsdlabel.c.rej
Hmm...  Ignoring the trailing garbage.
done

% cat partmap/bsdlabel.c.rej
***************
*** 68,78 ****
        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 (hook (disk, &p))
        return grub_errno;
-
-       pos += sizeof (struct grub_partition_bsd_entry);
      }

    return GRUB_ERR_NONE;
--- 86,94 ----
        p.len = grub_le_to_cpu32 (be.size);
        p.partmap = &grub_bsdlabel_partition_map;

+       if (p.len != 0)
      if (hook (disk, &p))
        return grub_errno;
      }

    return GRUB_ERR_NONE;

Any idea?

Thanks,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 3156 bytes --]

C. P. Ghost wrote:
> On Wed, May 19, 2010 at 12:06 AM, C. P. Ghost <cpghost@cordula.ws> wrote:
>   
>> 2010/5/18 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@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.
>>     
>
> Okay, first with the original non-patched 1.98 grub2 version,
> after setting the type to 4.2BSD in bsdlabel:
>
> phenom# bsdlabel /dev/md5555s1
> # /dev/md5555s1:
> 8 partitions:
> #        size   offset    fstype   [fsize bsize bps/cpg]
>   a:    48116       16    4.2BSD        0     0     0
>   c:    48132        0    unused        0     0         # "raw" part, don't edit
>
> phenom# newfs /dev/md5555s1a
> /dev/md5555s1a: 23.5MB (48116 sectors) block size 16384, fragment size 2048
>         using 4 cylinder groups of 5.88MB, 376 blks, 768 inodes.
> super-block backups (for fsck -b #) at:
>  160, 12192, 24224, 36256
>
> phenom# mount /dev/md5555s1a /mnt
>
> phenom# grub-install --root-directory=/mnt --modules=ufs2 /dev/md5555
> /usr/local/sbin/grub-probe: error: unknown filesystem.
> Installation finished. No error reported.
>
> This copies /boot/grub/* to /mnt as before. Now, if I run qemu, I get
> dropped into grub-rescue:
>
> % qemu -hda bsddisk.img
> GRUB loading.
> Welcome to GRUB!
>
> error: unknown filesystem.
> Entering rescue mode...
> grub rescue> _
>
> grub rescue> insmod part_msdos
> grub rescue> insmod part_bsd
> error: unknown filesystem.
>
> Unfortunately, the patch doesn't apply cleanly (against the
> bzr version):
>
> % patch -p0 < ../../patch-002
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --------------------------
> |--- partmap/bsdlabel.c    2010-03-26 14:44:13 +0000
> |+++ partmap/bsdlabel.c    2010-05-18 22:13:37 +0000
> --------------------------
> Patching file partmap/bsdlabel.c using Plan A...
> Hunk #1 succeeded at 37 with fuzz 1.
> Hunk #2 succeeded at 46.
> Hunk #3 failed at 86.
> 1 out of 3 hunks failed--saving rejects to partmap/bsdlabel.c.rej
> Hmm...  Ignoring the trailing garbage.
> done
>
> % cat partmap/bsdlabel.c.rej
> ***************
> *** 68,78 ****
>         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 (hook (disk, &p))
>         return grub_errno;
> -
> -       pos += sizeof (struct grub_partition_bsd_entry);
>       }
>
>     return GRUB_ERR_NONE;
> --- 86,94 ----
>         p.len = grub_le_to_cpu32 (be.size);
>         p.partmap = &grub_bsdlabel_partition_map;
>
> +       if (p.len != 0)
>       if (hook (disk, &p))
>         return grub_errno;
>       }
>
>     return GRUB_ERR_NONE;
>
> Any idea?
>
>   
Mailer. Now I attach it
> Thanks,
> -cpghost.
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: bsdlabel.diff --]
[-- Type: text/x-diff; name="bsdlabel.diff", Size: 2592 bytes --]

=== modified file 'include/grub/bsdlabel.h'
--- include/grub/bsdlabel.h	2010-02-06 17:43:37 +0000
+++ include/grub/bsdlabel.h	2010-05-18 22:05:09 +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-18 22:13:37 +0000
@@ -37,9 +37,6 @@
   grub_disk_addr_t delta = 0;
   unsigned pos;
 
-  /* BSDLabel offsets are absolute even when it's embed inside partition.  */
-  delta = grub_partition_get_start (disk->partition);
-
   /* Read the BSD label.  */
   if (grub_disk_read (disk, GRUB_PC_PARTITION_BSD_LABEL_SECTOR,
 		      0, sizeof (label), &label))
@@ -49,15 +46,36 @@
   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 to determine a base of be.offset.  */
+  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;
+
+      delta = grub_le_to_cpu32 (whole_disk_be.offset);
+    }
+
   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 +86,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;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Are BSD partitions not supported?

[C. P. Ghost]

2010/5/19 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Mailer. Now I attach it

Ah, thanks. Patches fine now. I get a compile error:

gcc  -nostdlib -static-libgcc  -m32 -Wl,-r,-d -o pre-regexp.o
regexp_mod-gnulib_regex.o regexp_mod-commands_regexp.o
nm -g --defined-only -P -p pre-regexp.o | sed 's/^\([^ ]*\).*/\1
regexp/' > def-regexp.lst
gcc -Icommands -I./commands -I./include -I. -I./include -Wall -W
-ffreestanding  -Os -DGRUB_MACHINE_PCBIOS=1 -DMACHINE=I386_PC -Wall -W
-Wshadow -Wpointer-arith -Wmissing-prototypes                -Wundef
-Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1
-falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -m32
-fno-stack-protector -mno-stack-arg-probe -Werror -mrtd -mregparm=3
-DGRUB_FILE=\"commands/terminal.c\" -MD -c -o
terminal_mod-commands_terminal.o commands/terminal.c
cc1: warnings being treated as errors
commands/terminal.c: In function 'grub_cmd_terminal_input':
commands/terminal.c:204: warning: dereferencing type-punned pointer
will break strict-aliasing rules
commands/terminal.c:205: warning: dereferencing type-punned pointer
will break strict-aliasing rules
commands/terminal.c: In function 'grub_cmd_terminal_output':
commands/terminal.c:219: warning: dereferencing type-punned pointer
will break strict-aliasing rules
commands/terminal.c:220: warning: dereferencing type-punned pointer
will break strict-aliasing rules
gmake: *** [terminal_mod-commands_terminal.o] Error 1

Maybe because FreeBSD's system gcc is older?

$ gcc --version
gcc (GCC) 4.2.1 20070719  [FreeBSD]
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I can try to compile it with a newer gcc, but it'll take some time
to compile gcc first...

Thanks,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[C. P. Ghost]

2010/5/19 C. P. Ghost <cpghost@cordula.ws>:
> 2010/5/19 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> Mailer. Now I attach it
>
> Ah, thanks. Patches fine now. I get a compile error:
>
> gcc  -nostdlib -static-libgcc  -m32 -Wl,-r,-d -o pre-regexp.o
> regexp_mod-gnulib_regex.o regexp_mod-commands_regexp.o
> nm -g --defined-only -P -p pre-regexp.o | sed 's/^\([^ ]*\).*/\1
> regexp/' > def-regexp.lst
> gcc -Icommands -I./commands -I./include -I. -I./include -Wall -W
> -ffreestanding  -Os -DGRUB_MACHINE_PCBIOS=1 -DMACHINE=I386_PC -Wall -W
> -Wshadow -Wpointer-arith -Wmissing-prototypes                -Wundef
> -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1
> -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -m32
> -fno-stack-protector -mno-stack-arg-probe -Werror -mrtd -mregparm=3
> -DGRUB_FILE=\"commands/terminal.c\" -MD -c -o
> terminal_mod-commands_terminal.o commands/terminal.c
> cc1: warnings being treated as errors
> commands/terminal.c: In function 'grub_cmd_terminal_input':
> commands/terminal.c:204: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> commands/terminal.c:205: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> commands/terminal.c: In function 'grub_cmd_terminal_output':
> commands/terminal.c:219: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> commands/terminal.c:220: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> gmake: *** [terminal_mod-commands_terminal.o] Error 1
>
> Maybe because FreeBSD's system gcc is older?
>
> $ gcc --version
> gcc (GCC) 4.2.1 20070719  [FreeBSD]
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> I can try to compile it with a newer gcc, but it'll take some time
> to compile gcc first...

Silly me, I had a gcc44 here already:

phenom# /usr/local/bin/gcc44 --version
gcc44 (GCC) 4.4.4 20100427 (prerelease)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Using that, I get this:

/usr/local/bin/gcc44 -o kernel.img kernel_img-kern_i386_pc_startup.o
kernel_img-kern_i386_misc.o kernel_img-kern_main.o
kernel_img-kern_device.o kernel_img-kern_disk.o kernel_img-kern_dl.o
kernel_img-kern_file.o kernel_img-kern_fs.o kernel_img-kern_err.o
kernel_img-kern_misc.o kernel_img-kern_mm.o kernel_img-kern_term.o
kernel_img-kern_rescue_parser.o kernel_img-kern_rescue_reader.o
kernel_img-kern_time.o kernel_img-kern_list.o
kernel_img-kern_handler.o kernel_img-kern_command.o
kernel_img-kern_corecmd.o kernel_img-kern___target_cpu__dl.o
kernel_img-kern_i386_pc_init.o kernel_img-kern_i386_pc_mmap.o
kernel_img-kern_parser.o kernel_img-kern_partition.o
kernel_img-kern_i386_tsc.o kernel_img-kern_i386_pit.o
kernel_img-kern_generic_rtc_get_time_ms.o
kernel_img-kern_generic_millisleep.o kernel_img-kern_env.o
kernel_img-term_i386_pc_console.o kernel_img-term_i386_vga_common.o
kernel_img-symlist.o -nostdlib -static-libgcc  -m32
-Wl,--build-id=none -lgcc  -nostdlib -Wl,-N  -Wl,-Ttext,0x8200 -mrtd
-mregparm=3
/usr/local/bin/ld: skipping incompatible
/usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd8.0/4.4.4/libgcc.a when
searching for -lgcc
/usr/local/bin/ld: skipping incompatible /usr/lib/libgcc.a when
searching for -lgcc
/usr/local/bin/ld: cannot find -lgcc
collect2: ld returned 1 exit status
gmake: *** [kernel.img] Error 1

This is with binutils-2.20.1_1 in /usr/local:

$ /usr/local/bin/ld --version
GNU ld (GNU Binutils) 2.20.1.20100303
Copyright 2009 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

> Thanks,
> -cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

C. P. Ghost wrote:
> 2010/5/19 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>   
>> Mailer. Now I attach it
>>     
>
> Ah, thanks. Patches fine now. I get a compile error:
>
> gcc  -nostdlib -static-libgcc  -m32 -Wl,-r,-d -o pre-regexp.o
> regexp_mod-gnulib_regex.o regexp_mod-commands_regexp.o
> nm -g --defined-only -P -p pre-regexp.o | sed 's/^\([^ ]*\).*/\1
> regexp/' > def-regexp.lst
> gcc -Icommands -I./commands -I./include -I. -I./include -Wall -W
> -ffreestanding  -Os -DGRUB_MACHINE_PCBIOS=1 -DMACHINE=I386_PC -Wall -W
> -Wshadow -Wpointer-arith -Wmissing-prototypes                -Wundef
> -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1
> -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -m32
> -fno-stack-protector -mno-stack-arg-probe -Werror -mrtd -mregparm=3
> -DGRUB_FILE=\"commands/terminal.c\" -MD -c -o
> terminal_mod-commands_terminal.o commands/terminal.c
> cc1: warnings being treated as errors
> commands/terminal.c: In function 'grub_cmd_terminal_input':
> commands/terminal.c:204: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> commands/terminal.c:205: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> commands/terminal.c: In function 'grub_cmd_terminal_output':
> commands/terminal.c:219: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> commands/terminal.c:220: warning: dereferencing type-punned pointer
> will break strict-aliasing rules
> gmake: *** [terminal_mod-commands_terminal.o] Error 1
>
> Maybe because FreeBSD's system gcc is older?
>
>   
You can just disable -Werror with --disable-werror configure option
> $ gcc --version
> gcc (GCC) 4.2.1 20070719  [FreeBSD]
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> I can try to compile it with a newer gcc, but it'll take some time
> to compile gcc first...
>
> Thanks,
> -cpghost.
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Are BSD partitions not supported?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 4503 bytes --]

C. P. Ghost wrote:
> 2010/5/19 C. P. Ghost <cpghost@cordula.ws>:
>   
>> 2010/5/19 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>     
>>> Mailer. Now I attach it
>>>       
>> Ah, thanks. Patches fine now. I get a compile error:
>>
>> gcc  -nostdlib -static-libgcc  -m32 -Wl,-r,-d -o pre-regexp.o
>> regexp_mod-gnulib_regex.o regexp_mod-commands_regexp.o
>> nm -g --defined-only -P -p pre-regexp.o | sed 's/^\([^ ]*\).*/\1
>> regexp/' > def-regexp.lst
>> gcc -Icommands -I./commands -I./include -I. -I./include -Wall -W
>> -ffreestanding  -Os -DGRUB_MACHINE_PCBIOS=1 -DMACHINE=I386_PC -Wall -W
>> -Wshadow -Wpointer-arith -Wmissing-prototypes                -Wundef
>> -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1
>> -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -m32
>> -fno-stack-protector -mno-stack-arg-probe -Werror -mrtd -mregparm=3
>> -DGRUB_FILE=\"commands/terminal.c\" -MD -c -o
>> terminal_mod-commands_terminal.o commands/terminal.c
>> cc1: warnings being treated as errors
>> commands/terminal.c: In function 'grub_cmd_terminal_input':
>> commands/terminal.c:204: warning: dereferencing type-punned pointer
>> will break strict-aliasing rules
>> commands/terminal.c:205: warning: dereferencing type-punned pointer
>> will break strict-aliasing rules
>> commands/terminal.c: In function 'grub_cmd_terminal_output':
>> commands/terminal.c:219: warning: dereferencing type-punned pointer
>> will break strict-aliasing rules
>> commands/terminal.c:220: warning: dereferencing type-punned pointer
>> will break strict-aliasing rules
>> gmake: *** [terminal_mod-commands_terminal.o] Error 1
>>
>> Maybe because FreeBSD's system gcc is older?
>>
>> $ gcc --version
>> gcc (GCC) 4.2.1 20070719  [FreeBSD]
>> Copyright (C) 2007 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> I can try to compile it with a newer gcc, but it'll take some time
>> to compile gcc first...
>>     
>
> Silly me, I had a gcc44 here already:
>
> phenom# /usr/local/bin/gcc44 --version
> gcc44 (GCC) 4.4.4 20100427 (prerelease)
> Copyright (C) 2010 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Using that, I get this:
>
> /usr/local/bin/gcc44 -o kernel.img kernel_img-kern_i386_pc_startup.o
> kernel_img-kern_i386_misc.o kernel_img-kern_main.o
> kernel_img-kern_device.o kernel_img-kern_disk.o kernel_img-kern_dl.o
> kernel_img-kern_file.o kernel_img-kern_fs.o kernel_img-kern_err.o
> kernel_img-kern_misc.o kernel_img-kern_mm.o kernel_img-kern_term.o
> kernel_img-kern_rescue_parser.o kernel_img-kern_rescue_reader.o
> kernel_img-kern_time.o kernel_img-kern_list.o
> kernel_img-kern_handler.o kernel_img-kern_command.o
> kernel_img-kern_corecmd.o kernel_img-kern___target_cpu__dl.o
> kernel_img-kern_i386_pc_init.o kernel_img-kern_i386_pc_mmap.o
> kernel_img-kern_parser.o kernel_img-kern_partition.o
> kernel_img-kern_i386_tsc.o kernel_img-kern_i386_pit.o
> kernel_img-kern_generic_rtc_get_time_ms.o
> kernel_img-kern_generic_millisleep.o kernel_img-kern_env.o
> kernel_img-term_i386_pc_console.o kernel_img-term_i386_vga_common.o
> kernel_img-symlist.o -nostdlib -static-libgcc  -m32
> -Wl,--build-id=none -lgcc  -nostdlib -Wl,-N  -Wl,-Ttext,0x8200 -mrtd
> -mregparm=3
> /usr/local/bin/ld: skipping incompatible
> /usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd8.0/4.4.4/libgcc.a when
> searching for -lgcc
> /usr/local/bin/ld: skipping incompatible /usr/lib/libgcc.a when
> searching for -lgcc
> /usr/local/bin/ld: cannot find -lgcc
> collect2: ld returned 1 exit status
> gmake: *** [kernel.img] Error 1
>   
Normally you need 32-bit libgcc. As a test build you can just remove
-lgcc but this isn't supported.
> This is with binutils-2.20.1_1 in /usr/local:
>
> $ /usr/local/bin/ld --version
> GNU ld (GNU Binutils) 2.20.1.20100303
> Copyright 2009 Free Software Foundation, Inc.
> This program is free software; you may redistribute it under the terms of
> the GNU General Public License version 3 or (at your option) a later version.
> This program has absolutely no warranty.
>
>   
>> Thanks,
>> -cpghost.
>>     
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Are BSD partitions not supported?

[Navdeep Parhar]

2010/5/19 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> C. P. Ghost wrote:
>> 2010/5/19 C. P. Ghost <cpghost@cordula.ws>:
>>
>>> 2010/5/19 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>>>
>>>> Mailer. Now I attach it
>>>>
>>> Ah, thanks. Patches fine now. I get a compile error:
>>>
>>> gcc  -nostdlib -static-libgcc  -m32 -Wl,-r,-d -o pre-regexp.o
>>> regexp_mod-gnulib_regex.o regexp_mod-commands_regexp.o
>>> nm -g --defined-only -P -p pre-regexp.o | sed 's/^\([^ ]*\).*/\1
>>> regexp/' > def-regexp.lst
>>> gcc -Icommands -I./commands -I./include -I. -I./include -Wall -W
>>> -ffreestanding  -Os -DGRUB_MACHINE_PCBIOS=1 -DMACHINE=I386_PC -Wall -W
>>> -Wshadow -Wpointer-arith -Wmissing-prototypes                -Wundef
>>> -Wstrict-prototypes -g -falign-jumps=1 -falign-loops=1
>>> -falign-functions=1 -mno-mmx -mno-sse -mno-sse2 -mno-3dnow -m32
>>> -fno-stack-protector -mno-stack-arg-probe -Werror -mrtd -mregparm=3
>>> -DGRUB_FILE=\"commands/terminal.c\" -MD -c -o
>>> terminal_mod-commands_terminal.o commands/terminal.c
>>> cc1: warnings being treated as errors
>>> commands/terminal.c: In function 'grub_cmd_terminal_input':
>>> commands/terminal.c:204: warning: dereferencing type-punned pointer
>>> will break strict-aliasing rules
>>> commands/terminal.c:205: warning: dereferencing type-punned pointer
>>> will break strict-aliasing rules
>>> commands/terminal.c: In function 'grub_cmd_terminal_output':
>>> commands/terminal.c:219: warning: dereferencing type-punned pointer
>>> will break strict-aliasing rules
>>> commands/terminal.c:220: warning: dereferencing type-punned pointer
>>> will break strict-aliasing rules
>>> gmake: *** [terminal_mod-commands_terminal.o] Error 1
>>>
>>> Maybe because FreeBSD's system gcc is older?
>>>
>>> $ gcc --version
>>> gcc (GCC) 4.2.1 20070719  [FreeBSD]
>>> Copyright (C) 2007 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>
>>> I can try to compile it with a newer gcc, but it'll take some time
>>> to compile gcc first...
>>>
>>
>> Silly me, I had a gcc44 here already:
>>
>> phenom# /usr/local/bin/gcc44 --version
>> gcc44 (GCC) 4.4.4 20100427 (prerelease)
>> Copyright (C) 2010 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>
>> Using that, I get this:
>>
>> /usr/local/bin/gcc44 -o kernel.img kernel_img-kern_i386_pc_startup.o
>> kernel_img-kern_i386_misc.o kernel_img-kern_main.o
>> kernel_img-kern_device.o kernel_img-kern_disk.o kernel_img-kern_dl.o
>> kernel_img-kern_file.o kernel_img-kern_fs.o kernel_img-kern_err.o
>> kernel_img-kern_misc.o kernel_img-kern_mm.o kernel_img-kern_term.o
>> kernel_img-kern_rescue_parser.o kernel_img-kern_rescue_reader.o
>> kernel_img-kern_time.o kernel_img-kern_list.o
>> kernel_img-kern_handler.o kernel_img-kern_command.o
>> kernel_img-kern_corecmd.o kernel_img-kern___target_cpu__dl.o
>> kernel_img-kern_i386_pc_init.o kernel_img-kern_i386_pc_mmap.o
>> kernel_img-kern_parser.o kernel_img-kern_partition.o
>> kernel_img-kern_i386_tsc.o kernel_img-kern_i386_pit.o
>> kernel_img-kern_generic_rtc_get_time_ms.o
>> kernel_img-kern_generic_millisleep.o kernel_img-kern_env.o
>> kernel_img-term_i386_pc_console.o kernel_img-term_i386_vga_common.o
>> kernel_img-symlist.o -nostdlib -static-libgcc  -m32
>> -Wl,--build-id=none -lgcc  -nostdlib -Wl,-N  -Wl,-Ttext,0x8200 -mrtd
>> -mregparm=3
>> /usr/local/bin/ld: skipping incompatible
>> /usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd8.0/4.4.4/libgcc.a when
>> searching for -lgcc
>> /usr/local/bin/ld: skipping incompatible /usr/lib/libgcc.a when
>> searching for -lgcc
>> /usr/local/bin/ld: cannot find -lgcc
>> collect2: ld returned 1 exit status
>> gmake: *** [kernel.img] Error 1
>>
> Normally you need 32-bit libgcc. As a test build you can just remove
> -lgcc but this isn't supported.

Or try adding -L/usr/lib32 to your gcc command.

Navdeep

Re: Are BSD partitions not supported?

[C. P. Ghost]

2010/5/19 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>> /usr/local/bin/gcc44 -o kernel.img kernel_img-kern_i386_pc_startup.o
>> kernel_img-kern_i386_misc.o kernel_img-kern_main.o
>> kernel_img-kern_device.o kernel_img-kern_disk.o kernel_img-kern_dl.o
>> kernel_img-kern_file.o kernel_img-kern_fs.o kernel_img-kern_err.o
>> kernel_img-kern_misc.o kernel_img-kern_mm.o kernel_img-kern_term.o
>> kernel_img-kern_rescue_parser.o kernel_img-kern_rescue_reader.o
>> kernel_img-kern_time.o kernel_img-kern_list.o
>> kernel_img-kern_handler.o kernel_img-kern_command.o
>> kernel_img-kern_corecmd.o kernel_img-kern___target_cpu__dl.o
>> kernel_img-kern_i386_pc_init.o kernel_img-kern_i386_pc_mmap.o
>> kernel_img-kern_parser.o kernel_img-kern_partition.o
>> kernel_img-kern_i386_tsc.o kernel_img-kern_i386_pit.o
>> kernel_img-kern_generic_rtc_get_time_ms.o
>> kernel_img-kern_generic_millisleep.o kernel_img-kern_env.o
>> kernel_img-term_i386_pc_console.o kernel_img-term_i386_vga_common.o
>> kernel_img-symlist.o -nostdlib -static-libgcc  -m32
>> -Wl,--build-id=none -lgcc  -nostdlib -Wl,-N  -Wl,-Ttext,0x8200 -mrtd
>> -mregparm=3
>> /usr/local/bin/ld: skipping incompatible
>> /usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd8.0/4.4.4/libgcc.a when
>> searching for -lgcc
>> /usr/local/bin/ld: skipping incompatible /usr/lib/libgcc.a when
>> searching for -lgcc
>> /usr/local/bin/ld: cannot find -lgcc
>> collect2: ld returned 1 exit status
>> gmake: *** [kernel.img] Error 1
>>
> Normally you need 32-bit libgcc. As a test build you can just remove
> -lgcc but this isn't supported.

Ah, okay. If I remove -lgcc manually, everything compiles.

This is what I get now (after reformatting the partition with newfs):

phenom# grub-install --root-directory=/mnt --modules=ufs2 /dev/md5555
/usr/local/sbin/grub-setup: warn: Your embedding area is unusually
small.  core.img won't fit in it..
/usr/local/sbin/grub-setup: warn: Embedding is not possible.  GRUB can
only be installed in this setup by using blocklists.  However,
blocklists are UNRELIABLE and their use is discouraged..
/usr/local/sbin/grub-setup: error: if you really want blocklists, use --force.

Using --force:

phenom# grub-install --force --root-directory=/mnt --modules=ufs2 /dev/md5555
/usr/local/sbin/grub-setup: warn: Your embedding area is unusually
small.  core.img won't fit in it..
/usr/local/sbin/grub-setup: warn: Embedding is not possible.  GRUB can
only be installed in this setup by using blocklists.  However,
blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.

If I boot now with qemu:

% qemu -hda bsddisk.img
GRUB loading...
Welcome to GRUB!

error: no such partition.
Entering rescue mode...
grub rescue> _

I compressed the image again: here it is now:

http://www.cordula.ws/tempdir/bsddisk_2.7z

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[C. P. Ghost]

2010/5/19 Navdeep Parhar <nparhar@gmail.com>:
>>> /usr/local/bin/gcc44 -o kernel.img kernel_img-kern_i386_pc_startup.o
>>> kernel_img-kern_i386_misc.o kernel_img-kern_main.o
>>> kernel_img-kern_device.o kernel_img-kern_disk.o kernel_img-kern_dl.o
>>> kernel_img-kern_file.o kernel_img-kern_fs.o kernel_img-kern_err.o
>>> kernel_img-kern_misc.o kernel_img-kern_mm.o kernel_img-kern_term.o
>>> kernel_img-kern_rescue_parser.o kernel_img-kern_rescue_reader.o
>>> kernel_img-kern_time.o kernel_img-kern_list.o
>>> kernel_img-kern_handler.o kernel_img-kern_command.o
>>> kernel_img-kern_corecmd.o kernel_img-kern___target_cpu__dl.o
>>> kernel_img-kern_i386_pc_init.o kernel_img-kern_i386_pc_mmap.o
>>> kernel_img-kern_parser.o kernel_img-kern_partition.o
>>> kernel_img-kern_i386_tsc.o kernel_img-kern_i386_pit.o
>>> kernel_img-kern_generic_rtc_get_time_ms.o
>>> kernel_img-kern_generic_millisleep.o kernel_img-kern_env.o
>>> kernel_img-term_i386_pc_console.o kernel_img-term_i386_vga_common.o
>>> kernel_img-symlist.o -nostdlib -static-libgcc  -m32
>>> -Wl,--build-id=none -lgcc  -nostdlib -Wl,-N  -Wl,-Ttext,0x8200 -mrtd
>>> -mregparm=3
>>> /usr/local/bin/ld: skipping incompatible
>>> /usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd8.0/4.4.4/libgcc.a when
>>> searching for -lgcc
>>> /usr/local/bin/ld: skipping incompatible /usr/lib/libgcc.a when
>>> searching for -lgcc
>>> /usr/local/bin/ld: cannot find -lgcc
>>> collect2: ld returned 1 exit status
>>> gmake: *** [kernel.img] Error 1
>>>
>> Normally you need 32-bit libgcc. As a test build you can just remove
>> -lgcc but this isn't supported.
>
> Or try adding -L/usr/lib32 to your gcc command.

That's a good hint! Thank you.

> Navdeep

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1.1: Type: text/plain, Size: 3129 bytes --]

C. P. Ghost wrote:
> 2010/5/19 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>   
>>> /usr/local/bin/gcc44 -o kernel.img kernel_img-kern_i386_pc_startup.o
>>> kernel_img-kern_i386_misc.o kernel_img-kern_main.o
>>> kernel_img-kern_device.o kernel_img-kern_disk.o kernel_img-kern_dl.o
>>> kernel_img-kern_file.o kernel_img-kern_fs.o kernel_img-kern_err.o
>>> kernel_img-kern_misc.o kernel_img-kern_mm.o kernel_img-kern_term.o
>>> kernel_img-kern_rescue_parser.o kernel_img-kern_rescue_reader.o
>>> kernel_img-kern_time.o kernel_img-kern_list.o
>>> kernel_img-kern_handler.o kernel_img-kern_command.o
>>> kernel_img-kern_corecmd.o kernel_img-kern___target_cpu__dl.o
>>> kernel_img-kern_i386_pc_init.o kernel_img-kern_i386_pc_mmap.o
>>> kernel_img-kern_parser.o kernel_img-kern_partition.o
>>> kernel_img-kern_i386_tsc.o kernel_img-kern_i386_pit.o
>>> kernel_img-kern_generic_rtc_get_time_ms.o
>>> kernel_img-kern_generic_millisleep.o kernel_img-kern_env.o
>>> kernel_img-term_i386_pc_console.o kernel_img-term_i386_vga_common.o
>>> kernel_img-symlist.o -nostdlib -static-libgcc  -m32
>>> -Wl,--build-id=none -lgcc  -nostdlib -Wl,-N  -Wl,-Ttext,0x8200 -mrtd
>>> -mregparm=3
>>> /usr/local/bin/ld: skipping incompatible
>>> /usr/local/lib/gcc44/gcc/x86_64-portbld-freebsd8.0/4.4.4/libgcc.a when
>>> searching for -lgcc
>>> /usr/local/bin/ld: skipping incompatible /usr/lib/libgcc.a when
>>> searching for -lgcc
>>> /usr/local/bin/ld: cannot find -lgcc
>>> collect2: ld returned 1 exit status
>>> gmake: *** [kernel.img] Error 1
>>>
>>>       
>> Normally you need 32-bit libgcc. As a test build you can just remove
>> -lgcc but this isn't supported.
>>     
>
> Ah, okay. If I remove -lgcc manually, everything compiles.
>
> This is what I get now (after reformatting the partition with newfs):
>
> phenom# grub-install --root-directory=/mnt --modules=ufs2 /dev/md5555
> /usr/local/sbin/grub-setup: warn: Your embedding area is unusually
> small.  core.img won't fit in it..
> /usr/local/sbin/grub-setup: warn: Embedding is not possible.  GRUB can
> only be installed in this setup by using blocklists.  However,
> blocklists are UNRELIABLE and their use is discouraged..
> /usr/local/sbin/grub-setup: error: if you really want blocklists, use --force.
>
> Using --force:
>
> phenom# grub-install --force --root-directory=/mnt --modules=ufs2 /dev/md5555
> /usr/local/sbin/grub-setup: warn: Your embedding area is unusually
> small.  core.img won't fit in it..
> /usr/local/sbin/grub-setup: warn: Embedding is not possible.  GRUB can
> only be installed in this setup by using blocklists.  However,
> blocklists are UNRELIABLE and their use is discouraged..
> Installation finished. No error reported.
>
> If I boot now with qemu:
>
> % qemu -hda bsddisk.img
> GRUB loading...
> Welcome to GRUB!
>
> error: no such partition.
> Entering rescue mode...
> grub rescue> _
>
> I compressed the image again: here it is now:
>
> http://www.cordula.ws/tempdir/bsddisk_2.7z
>
> -cpghost.
>
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: bsdlabel.diff --]
[-- Type: text/x-diff; name="bsdlabel.diff", Size: 3064 bytes --]

=== modified file 'include/grub/bsdlabel.h'
--- include/grub/bsdlabel.h	2010-02-06 17:43:37 +0000
+++ include/grub/bsdlabel.h	2010-05-18 22:05:09 +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 'kern/i386/pc/init.c'
--- kern/i386/pc/init.c	2010-02-06 23:52:31 +0000
+++ kern/i386/pc/init.c	2010-05-19 19:19:18 +0000
@@ -75,8 +75,8 @@
 	  ptr += grub_strlen (ptr);
 
 	  if (grub_install_bsd_part >= 0)
-	    grub_snprintf (ptr, sizeof (dev) - (ptr - dev), ",%c",
-			   grub_install_bsd_part + 'a');
+	    grub_snprintf (ptr, sizeof (dev) - (ptr - dev), ",%u",
+			   grub_install_bsd_part + 1);
 	  ptr += grub_strlen (ptr);
 	}
 

=== modified file 'partmap/bsdlabel.c'
--- partmap/bsdlabel.c	2010-03-26 14:44:13 +0000
+++ partmap/bsdlabel.c	2010-05-18 22:13:37 +0000
@@ -37,9 +37,6 @@
   grub_disk_addr_t delta = 0;
   unsigned pos;
 
-  /* BSDLabel offsets are absolute even when it's embed inside partition.  */
-  delta = grub_partition_get_start (disk->partition);
-
   /* Read the BSD label.  */
   if (grub_disk_read (disk, GRUB_PC_PARTITION_BSD_LABEL_SECTOR,
 		      0, sizeof (label), &label))
@@ -49,15 +46,36 @@
   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 to determine a base of be.offset.  */
+  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;
+
+      delta = grub_le_to_cpu32 (whole_disk_be.offset);
+    }
+
   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 +86,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;


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Are BSD partitions not supported?

[C. P. Ghost]

2010/5/19 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
> Regards
> Vladimir 'φ-coder/phcoder' Serbinenko

Trying the *second* patch (now with -L/usr/lib32 instead of removing
-lgcc):

phenom# grub-install --root-directory=/mnt --modules=ufs2 /dev/md5555
/usr/local/sbin/grub-setup: warn: Your embedding area is unusually
small.  core.img won't fit in it..
/usr/local/sbin/grub-setup: warn: Embedding is not possible.  GRUB can
only be installed in this setup by using blocklists.  However,
blocklists are UNRELIABLE and their use is discouraged..
/usr/local/sbin/grub-setup: error: if you really want blocklists, use --force.

phenom# grub-install --force --root-directory=/mnt --modules=ufs2 /dev/md5555
/usr/local/sbin/grub-setup: warn: Your embedding area is unusually
small.  core.img won't fit in it..
/usr/local/sbin/grub-setup: warn: Embedding is not possible.  GRUB can
only be installed in this setup by using blocklists.  However,
blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.

With the new patch, grub boots successfully:

grub> root (hd0,<TAB>
Possible partitions are:

Partition hd0,msdos1: Unknown filesystem
Partition hd0,msdos1,bsd1: Filesystem type ufs2 - Last
modification time 2010-05-19 19:30:34 Wednesday,
UUID 4bf43c35b902989d

grub> root (hd0,msdos1,a)
error: no such partition.

grub> root (hd0,msdos1,bsd1)
(hd0,msdos1,bsd1): Filesystem is ufs2.

grub> ls /
boot/

grub> ls /boot
grub/

grub> halt

That's great! :-)

Here's the updated image:

http://www.cordula.ws/tempdir/bsddisk_3.7z

The next test would be to create two slices on an image,
and redo the tests on the second slice (which won't start
at offset 0 of the disk, so we can be sure the logic is
correct). Will do this tomorrow with the patched grub,
and report back.

Thanks again for the great help. :-)
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[C. P. Ghost]

On Wed, May 19, 2010 at 9:41 PM, C. P. Ghost <cpghost@cordula.ws> wrote:
> The next test would be to create two slices on an image,
> and redo the tests on the second slice (which won't start
> at offset 0 of the disk, so we can be sure the logic is
> correct). Will do this tomorrow with the patched grub,
> and report back.

Just a quick followup. I've had success with the patch on
a bigger multislice image too. The BSD slice is located
*after* a DOS slice for good measure:

phenom# fdisk /dev/md5555
******* Working on device /dev/md5555 *******
parameters extracted from in-core disklabel are:
cylinders=63 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=63 heads=255 sectors/track=63 (16065 blks/cyl)

Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 6 (0x06),(Primary DOS, 16 bit FAT (>= 32MB))
    start 63, size 497952 (243 Meg), flag 0
        beg: cyl 0/ head 1/ sector 1;
        end: cyl 30/ head 254/ sector 63
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 498078, size 497952 (243 Meg), flag 80 (active)
        beg: cyl 31/ head 1/ sector 1;
        end: cyl 61/ head 254/ sector 63
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

phenom# bsdlabel /dev/md5555s2
# /dev/md5555s2:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:   497936       16    4.2BSD        0     0     0
  c:   497952        0    unused        0     0         # "raw" part, don't edit

phenom# ls -l /dev/md5555*
crw-r-----  1 root  operator    0, 150 May 20 17:59 /dev/md5555
crw-r-----  1 root  operator    0, 153 May 20 17:57 /dev/md5555s1
crw-r-----  1 root  operator    0, 154 May 20 17:55 /dev/md5555s2
crw-r-----  1 root  operator    0, 156 May 20 17:56 /dev/md5555s2a

phenom# grub-install --root-directory=/mnt --modules=ufs2 /dev/md5555
/usr/local/sbin/grub-setup: warn: Your embedding area is unusually
small.  core.img won't fit in it..
/usr/local/sbin/grub-setup: warn: Embedding is not possible.  GRUB can
only be installed in this setup by using blocklists.  However,
blocklists are UNRELIABLE and their use is discouraged..
/usr/local/sbin/grub-setup: error: if you really want blocklists, use --force.

(----> No idea what's going on here... using --force. <----)

phenom# grub-install --force --root-directory=/mnt --modules=ufs2 /dev/md5555
/usr/local/sbin/grub-setup: warn: Your embedding area is unusually
small.  core.img won't fit in it..
/usr/local/sbin/grub-setup: warn: Embedding is not possible.  GRUB can
only be installed in this setup by using blocklists.  However,
blocklists are UNRELIABLE and their use is discouraged..
Installation finished. No error reported.

Now, testing the image:

% qemu -hda bsddisk.img
grub> root (hd0,<TAB>
Possible partitions are:

  Partition hd0,msdos1: Filesystem type fat, UUID 44b3-1913
  Partition hd0,msdos2: Unknown filesystem
  Partition hd0,msdos2,bsd1: Filesystem type ufs2 - Last modification
     time 2010-05-20 15:59:46 Thursday, UUID 4bf55bb9a21a9565

grub> root (hd0,msdos1)
(hd0,msdos1): Filesystem is fat.
grub> ls /
readme
grub> cat /README
This file is on a FAT16 filesystem.

grub> root (hd0,msdos2,bsd1)
(hd0,msdos2,bsd1): Filesystem is ufs2.
grub> ls /
README boot/
grub> cat /README
This file is on a UFS2 filesystem.

grub> halt

So I guess, this second patch solves the problem adequately.
All that remains is the question why --force is needed in grub-install.

Here's the new image, just in case you want to try it. I'll remove
it from that server in a couple of weeks.

http://www.cordula.ws/tempdir/bsddisk_4.7z

Again, thanks for the help. I hope you'll commit that patch soon. ;-)

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[Grégoire Sutre]

[-- Attachment #1: Type: text/plain, Size: 2029 bytes --]

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
.
.
.

[-- Attachment #2: bsdlabel_v3.diff --]
[-- Type: text/x-patch, Size: 2196 bytes --]

=== 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;

Re: Are BSD partitions not supported?

[C. P. Ghost]

2010/5/23 Grégoire Sutre <gregoire.sutre@gmail.com>:
> 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.

(...)

> 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.

With bsdlabel_v3.diff, and the image I've posted here, I get dropped
into grub_rescue. This breaks Vladimir's second patch on FreeBSD. :-(

-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[Grégoire Sutre]

On 05/23/2010 05:44 PM, C. P. Ghost wrote:

> With bsdlabel_v3.diff, and the image I've posted here, I get dropped
> into grub_rescue. This breaks Vladimir's second patch on FreeBSD.
> :-(

Thanks for testing the patch.  But I honestly don't understand why it
does not work on your system.

I could reproduce the problem with trunk on your image by installing
grub (trunk) on a USB key and by running:

qemu -hda /dev/sdf -hdb /mnt/exchange/bsddisk.img
grub> insmod part_bsd
grub> ls (hd1,msdos2,bsd1)
         Partition hd1,msdos2,bsd1: Unknown filesystem


However, if I build the patched version (with bsdlabel_v3.diff) and
re-install grub on the USB key, I get:

qemu -hda /dev/sdf -hdb /mnt/exchange/bsddisk.img
grub> insmod part_bsd
grub> ls (hd1,msdos2,bsd1)
         Partition hd1,msdos2,bsd1: Filesystem type ufs2 - Last
modification time
  2010-05-20 16:11:12 Thursday, UUID 4bf55bb9a21a9565
grub> ls (hd1,msdos2,bsd1)/
README boot/
grub> cat (hd1,msdos2,bsd1)/README
This file is on a UFS2 filesystem.


Grégoire

Re: Are BSD partitions not supported?

[C. P. Ghost]

2010/5/24 Grégoire Sutre <gregoire.sutre@gmail.com>:
> On 05/23/2010 05:44 PM, C. P. Ghost wrote:
>
>> With bsdlabel_v3.diff, and the image I've posted here, I get dropped
>> into grub_rescue. This breaks Vladimir's second patch on FreeBSD.
>> :-(
>
> Thanks for testing the patch.  But I honestly don't understand why it
> does not work on your system.
>
> I could reproduce the problem with trunk on your image by installing
> grub (trunk) on a USB key and by running:
>
> qemu -hda /dev/sdf -hdb /mnt/exchange/bsddisk.img
> grub> insmod part_bsd
> grub> ls (hd1,msdos2,bsd1)
>        Partition hd1,msdos2,bsd1: Unknown filesystem
>
>
> However, if I build the patched version (with bsdlabel_v3.diff) and
> re-install grub on the USB key, I get:
>
> qemu -hda /dev/sdf -hdb /mnt/exchange/bsddisk.img
> grub> insmod part_bsd
> grub> ls (hd1,msdos2,bsd1)
>        Partition hd1,msdos2,bsd1: Filesystem type ufs2 - Last
> modification time
>  2010-05-20 16:11:12 Thursday, UUID 4bf55bb9a21a9565
> grub> ls (hd1,msdos2,bsd1)/
> README boot/
> grub> cat (hd1,msdos2,bsd1)/README
> This file is on a UFS2 filesystem.

That's very strange...

I'm away from my test machine right now, but I'll provide
a diskimage with the v3 patch later, as soon as I can.

I don't think it's related to me using md(4) devices instead
of USB keys, but there's the slight possibility that it may
be the cause (?). I'll also test both v2 and v3 images on a
USB key as well with real hardware to see if it matters.

Thanks,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/

Re: Are BSD partitions not supported?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]

Grégoire Sutre wrote:
> 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.
>
Looks like we have to have different behaviour for different BSDs. Since
it looks like generic code would fail for ThisBSD or ThatBSD, I propose
to go by as-needed basis. So I think we should:
-restrict bsdlabel to being embed into msdos partitions of types a5, a6
or a9.
-conditionalise the behaviour and use my patch for a5 (FreeBSD) and
current behaviour for a6 (OpenBSD) and a9 (NetBSD).
I recognise that it's ugly.
Another possibility is to have both (hdX,msdosY,freebsdZ) and
(hdX,msdosY,netbsdZ) syntax but it would result in many confusing ghost
partitions. But since bsdlabel is so disorganised and ugly I prefer to
limit its support to minimum.
> 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
> .
> .
> .
> ------------------------------------------------------------------------
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Re: Are BSD partitions not supported?

[Grégoire Sutre]

On 05/31/2010 11:16 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> Looks like we have to have different behaviour for different BSDs.
> Since it looks like generic code would fail for ThisBSD or ThatBSD,
> I propose to go by as-needed basis. So I think we should: -restrict
> bsdlabel to being embed into msdos partitions of types a5, a6 or a9.
>  -conditionalise the behaviour and use my patch for a5 (FreeBSD) and
>  current behaviour for a6 (OpenBSD) and a9 (NetBSD).

We could be a bit more general and assume that BSD label offsets are
always relative except for NetBSD and OpenBSD msdos-embedded partitions.
In particular, we should support BSD labels that are not embedded in an
msdos partition.

So bsdlabel_partition_map_iterate would do (in pseudo code):

if   disk->partition is not NULL                /* embedded partition */
      and
      disk->partition's partmap is msdos
      and
      disk->partition's msdos partition type is NetBSD or OpenBSD
then
      interpret BSD label offsets as absolute    /* (a) */
else
      interpret BSD label offsets as relative    /* (b) */
fi

In short, the normal interpretation of BSD label offsets would be the
relative one (b), and we would make an exception to handle NetBSD and
OpenBSD (a).

Now, when BSD label offsets are detected absolute (a), should we
consider them as absolute:
- w.r.t. to the start of the disk (as is done in the code right now),
   or
- w.r.t to the location of the msdos partmap?
I prefer the second option since it is compatible with dd-ing an entire
disk into an msdos partition.  Maybe the loopback feature also requires
the second option (I don't know the internals).

Grégoire

Re: Are BSD partitions not supported?

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 1603 bytes --]

On 06/01/2010 12:34 PM, Grégoire Sutre wrote:
>
> if   disk->partition is not NULL                /* embedded partition */
>      and
>      disk->partition's partmap is msdos
>      and
>      disk->partition's msdos partition type is NetBSD or OpenBSD
> then
>      interpret BSD label offsets as absolute    /* (a) */
> else
>      interpret BSD label offsets as relative    /* (b) */
For FreeBSD we have to investigate 'c' partition to determine delta.
> fi
>
> In short, the normal interpretation of BSD label offsets would be the
> relative one (b), and we would make an exception to handle NetBSD and
> OpenBSD (a).
The bottom line is: bsdlabel is broken concept. Unless support of
$config is required I would omit it to disencourage further propagation
of broken concepts.
>
> Now, when BSD label offsets are detected absolute (a), should we
> consider them as absolute:
> - w.r.t. to the start of the disk (as is done in the code right now),
>   or
> - w.r.t to the location of the msdos partmap?
> I prefer the second option since it is compatible with dd-ing an entire
> disk into an msdos partition.  Maybe the loopback feature also requires
> the second option (I don't know the internals).
>
Second one is cleaner. But perhaps it's pointless to support such config
since no BSD will be able to bootstrap from such a config
> Grégoire
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Are BSD partitions not supported?

[Grégoire Sutre]

On 06/01/2010 01:21 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

> For FreeBSD we have to investigate 'c' partition to determine delta.

Right.

>> In short, the normal interpretation of BSD label offsets would be the
>> relative one (b), and we would make an exception to handle NetBSD and
>> OpenBSD (a).
> The bottom line is: bsdlabel is broken concept. Unless support of
> $config is required I would omit it to disencourage further propagation
> of broken concepts.

I am not sure I understand what you mean here.

Regarding bsdlabel: it is not broken by itself.  The problem comes from
the fact that several OSes use it as (native) disklabel, but do not
interpret the fields in the same way.

I guess it's easier to maintain coherence when the disklabel is used
(natively) by a single OS.

>> Now, when BSD label offsets are detected absolute (a), should we
>> consider them as absolute:
>> - w.r.t. to the start of the disk (as is done in the code right now),
>>    or
>> - w.r.t to the location of the msdos partmap?
>> I prefer the second option since it is compatible with dd-ing an entire
>> disk into an msdos partition.  Maybe the loopback feature also requires
>> the second option (I don't know the internals).
>>
> Second one is cleaner. But perhaps it's pointless to support such config
> since no BSD will be able to bootstrap from such a config

You could at least boot the kernel from such a config. And, for NetBSD,
I believe that the use of wedges should allow the kernel to mount the
root file system (but I'm not an expert on wedges), provided that grub
gives the wedge information in the bootinfo structure.

Grégoire