From owner-freebsd-questions@FreeBSD.ORG Mon Jun 27 23:52:18 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ACFD9106566B for ; Mon, 27 Jun 2011 23:52:18 +0000 (UTC) (envelope-from gyrd-se@thanelange.no) Received: from sakura.nani.no (sakura.nani.no [195.204.164.110]) by mx1.freebsd.org (Postfix) with SMTP id 11D258FC18 for ; Mon, 27 Jun 2011 23:52:17 +0000 (UTC) Received: (qmail 90348 invoked by uid 89); 28 Jun 2011 01:52:16 +0200 Received: from cm-84.208.141.195.getinternet.no (HELO parvati.thanelange.no) (gyrd-se@thanelange.no@84.208.141.195) by sakura.nani.no with SMTP; 28 Jun 2011 01:52:16 +0200 Date: Tue, 28 Jun 2011 01:52:16 +0200 From: Gyrd Thane Lange To: perryh@pluto.rain.com Message-ID: <20110628015216.386bf8c6@parvati.thanelange.no> In-Reply-To: <4e08b653.f21Zod5W+PPBQkwI%perryh@pluto.rain.com> References: <4D7F86D5012E084A@> <4e05220e.GBAaOafCcTgMjymv%perryh@pluto.rain.com> <20110626202852.6765f935@parvati.thanelange.no> <4e08b653.f21Zod5W+PPBQkwI%perryh@pluto.rain.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: doug@safeport.com, freebsd-questions@freebsd.org Subject: Re: Dual Boot 8.2 and Windows 7 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 23:52:18 -0000 On Mon, 27 Jun 2011 09:56:51 -0700 perryh@pluto.rain.com wrote: > Gyrd Thane Lange wrote: > > > On Fri, 24 Jun 2011 16:47:26 -0700 > > perryh@pluto.rain.com 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 patch. All that's required is to drop the file into: /usr/ports/sysutils/grub/files/ 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 /dev/ufsid/442602f4ad1b67d2 I suppose I could always get around that problem by using tunefs -L myroot and putting vfs.root.mountfrom="ufs:/dev/ufs/myroot" in /boot/loader.conf. Similar change to /etc/fstab. Gyrd ^_^