[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

grub-setup failure with (primary) BSD disklabel

From: Grégoire Sutre
Subject: grub-setup failure with (primary) BSD disklabel
Date: Tue, 25 May 2010 17:00:41 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100411 Icedove/3.0.4


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

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)

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,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]