Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 28 Jun 2011 01:52:16 +0200
From:      Gyrd Thane Lange <>
Subject:   Re: Dual Boot 8.2 and Windows 7
Message-ID:  <>
In-Reply-To: <>
References:  <> <> <4D7F86D5012E084A@> <> <> <> <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Mon, 27 Jun 2011 09:56:51 -0700 wrote:

> Gyrd Thane Lange <> wrote:
> > On Fri, 24 Jun 2011 16:47:26 -0700
> > wrote:
> >
> > > ... The code in i386/boot2 and
> > > lib/libstand is written to find the / (or /boot) FS on a
> > > BSD partition of an fdisk "primary partition" (aka slice),
> > > or in a GPT partition, and would need additions to handle
> > > fdisk "extended partitions".
> >
> > Some years ago I ran into a similar problem. I ran out of primary
> > partitions (using MBR-speak) and had to move FreeBSD into an
> > extended partition.
> >
> > Here the simple patch I wrote for the FreeBSD boot loader:
> > <>;
> > <>;
> Any thought of submitting that as a PR?

I've always meant to submit it as a PR, but found the send-pr(1) too
daunting. (It is impossible/undesirable for me to have a working mail
sender on my system and I have not yet found a way for send-pr(1) to
work in offline mode for delayed sending by a different machine.) I
suppose I could give the HTML version a try...

> > The next challenge is to find a boot manager that will pick up
> > FreeBSD in an extended partition. For myself I use a self patched
> > GRUB. (GRUB also nearly worked out of the box, but had a different
> > problem.)
> It makes sense that GRUB would understand "extended partitions"
> since its roots are in Linux which is often installed in extended
> partitions.  Ideally FreeBSD should have a native solution, i.e.
> a version of boot2 that would understand extended partitions.
> Dunno without trying it if the capability could be added to the
> existing boot2 without exceeding available space, or if it would
> need a new variant.

I agree that would have been more convenient, but since MBR is going
the way of the dodo I haven't looked that closely into it.

> > You're welcome to have those patches as well if you need them.
> It would be good to get them posted somewhere.  GRUB is not in the
> FreeBSD tree AFAIK, so send-pr is likely not all that good a method,
> but perhaps they could be pushed upstream to the GRUB maintainers?

The problem with GRUB was computing the correct absolute start sector
of FreeBSD partitions, as in bsdlabel(8), when they resided in
"extended partitions". More details are available as comments in the

All that's required is to drop the file into:


and then build the port, install grub, e.t.c.

I can make a PR for it against the sysutils/grub port. I'll also look
into how to push it upstream.

> > Lastly I have the following in my kernel configuration file:
> >
> > include GENERIC
> > ...
> > nooptions         GEOM_PART_BSD
> > nooptions         GEOM_PART_MBR
> > options           GEOM_BSD
> > options           GEOM_MBR
> >
> > That is because I am not fond of the new mangled device names,
> > but prefer the old ones.
> What differences?  AFAIK a disk sliced with fdisk and partitioned
> with bsdlabel will have partition names like ad0s1a regardless of
> which GEOM modules are used to process the MBR and partitions.
> It's only if one uses the GPT partitioning scheme instead of
> fdisk/bsdlabel that the disk will have partition names like ad0a.

Sorry, I didn't explain that very well. Yes, I agree that there
probably aren't any differences for primary slices, but I had some
trouble with slice names for slices in "extended partitions".

For instance, my root volume is on /dev/ad8s11a. I don't remember what
the new GEOM_PART_* suggested to call it, but it was very different.
Also I wanted to avoid using the hard-to-read names like


I suppose I could always get around that problem by using 

  tunefs -L myroot

and putting 


in /boot/loader.conf. Similar change to /etc/fstab.

Gyrd ^_^

Want to link to this message? Use this URL: <>