Hi, When there is both a MBR partition table and a (primary) BSD disklabel, grub-setup returns an error: No DOS-style partitions found. Yet, the partition containing the GRUB images is in the MBR. But we are actually lucky, since it could be worse. Below is a detailed example on NetBSD/i386 starting with an empty disk (actually, a virtual disk vnd(4)).
First disklabel the disk for NetBSD use, say we get: # size offset fstype a: 4000 100 4.2BSD d: 16384 0 unused The disklabel is stored in the second sector of the disk (at offset 1). Now, assume that we also want to use the disk with another OS. We create an MBR partition for it, and add the partition to the NetBSD disklabel. We initialize its filesystem. We get: Partition table: 0: Linux native (sysid 131) start 8064, size 8064 (4 MB, Cyls 3/60/1-7/55/32) PBR is not bootable: All bytes are identical (0x00) 1: <UNUSED> 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 <snip> 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. </snip> AFAICS, grub-setup sees e: as (vnd0d,bsd5) and therefore complains that the (primary) partmap is not msdos. This is actually not so bad. Indeed, e: could have been detected as (vnd0d,msdos1), in which case grub-setup would have destroyed the NetBSD disklabel (stored at offset 1). AFAICS, the only reason why e: is detected as (vnd0d,bsd5) is the order of the partmap_modules in the file grub_setup_init.lst generated by the build. This order depends on the order of the .c files obtained by the make command $(filter %.c,$^). For instance, if all occurences of $(filter %.c,...) are replaced by $(sort $(filter %.c,...)) in conf/common.rmk, then e: is detected as (vnd0d,msdos1), grub-setup succeeds and the NetBSD disklabel is effectively destroyed (but grub successfully boots -- tested in qemu). IMHO, implicitly relying on the order of $(filter %.c,...) is not robust. I thought of several options to solve this issue: (a) declare that the order in which the partmap modules are loaded is critical, and make sure that we get the right order. (b) check that each sector to be written by grub-setup does not contain a disklabel, and abort if any is found (unless e.g. --force was specified). We have at most 62 sectors to check, and there is room for optimization (by taking into account the size of core.img). (c) as (b), but do not abort if there is a sufficiently large contiguous embedding area. I would prefer (c) as it would allow the installation of grub when a BSD disklabel is at offset 1 (we would only lose one sector as embedding space). That is, if grub-setup searches a DOS-style partmap in all primary partmaps instead of stoping at the first one. Thanks for reading all of this :-) Comments welcome, Grégoire _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel