New BSD Installer

Dewayne Geraghty dewayne.geraghty at
Fri Feb 17 06:37:38 UTC 2012

To answer an earlier question by Bruce... 

> -----Original Message-----
> From: owner-freebsd-stable at 
> [mailto:owner-freebsd-stable at] On Behalf Of Ian Smith
> Sent: Wednesday, 15 February 2012 4:15 AM
> To: Bruce Cran
> Cc: FreeBSD Stable Mailing List; Joe Holden; Alex Samorukov
> Subject: Re: New BSD Installer
> On Sun, 12 Feb 2012 15:32:51 +0000, Bruce Cran wrote:
>  > On 2/10/2012 7:47 PM, Alex Samorukov wrote:
>  > > I am highly against reverting. Old installer is not GPT 
> aware and in fact  > > is unmaintained for a very long time.
>  >
>  > That's not really correct: quite a lot of work was done on 
> it last year.
> Indeed.  Was it you working on the updated sade(8) adding GPT and ZFS?
> <rant>
> I don't see it in terms of reverting.  Much other useful 
> functionality of sysinstall has yet to be reimplemented.  
> Sure, I know, send code .. 
> but it's not only the functionality lost, but the ability for 
> new users to accomplish a good deal of initial server setup 
> before they're skilled enough to do it all from the command 
> line, which is where I was in '98.
> I also think much of the sometimes gratuitous deprecation of 
> sysinstall is unwarranted.  I've used sysinstall 
> post-installation regularly since
> '98 on 2.2.6 through 3.3, 4.4-10, 5.-5, 6.1, 7.0-4 and 8.0-2. 
>  Since one small disaster on 3.3 about 12 years ago 
> (installing to the wrong slice) I've had no major issues with 
> it, mostly partitioning all sorts of disks but also browsing 
> and adding useful packages at installation.
> Strangely, the big push to GPT partitions was oft said to be 
> because MBR slices provided too few partitions.  I never 
> found 4 * 6 much of a limit myself, and now the default 
> install makes a Linux-like single partition, rendering dump & 
> restore more or less unusable or at least impractical, while 
> booting multiple systems on GPT also seems to require Linux tools.
> I don't know whether this move away from BSD traditional 
> filesystem partitioning (/, /var, /usr etc) to Linux-style 
> came down from Core On High or is just the prerogative of 
> installer-writers?  Jordan was both the latter and a big part 
> of the former for many years, but I guess that's something 
> that can be reverted if people feel to do so.
> I expect most developers run mostly the latest gear, and 
> nowadays tend to use vbox images a good deal, but there will 
> be many laptops and other systems using MBR slices and 
> bsdlabel partitions for years to come, and I'd hate to see 
> FreeBSD's longterm support for _slightly_ older hardware 
> disappear, just because of having added better support for latest kit.
> I for one will be screwed if sade, fdisk and bsdlabel 
> disappear, as the release notes for 9 seem to indicate may be 
> imminently on the cards.
> </rant>
> cheers, Ian
> _______________________________________________
> freebsd-stable at mailing list
> To unsubscribe, send any mail to 
> "freebsd-stable-unsubscribe at"

I've included the gpart commands that should allay your concerns about fdisk and bsdlabel. Like you I use MBR for exactly the
reasons that Freddie has articulated, and share Jeremy's concerns.  GPT doesn't yet suit my operations model for bootable media;

The following will prepare the partitions/slices for a conventional device, for example a small usb drive

 D=da1 SIZE=1G
 gpart create -s MBR $D  

 gpart add -b63 -s $SIZE -t freebsd $D    # to insert s1
 gpart create -s bsd ${D}s1               # create s1 as BSD
 gpart add -s 300M -t freebsd-ufs ${D}s1  # create partition s1a
 gpart add -s 16M  -t freebsd-swap ${D}s1 # create swap
 gpart add         -t freebsd-ufs ${D}s1  # rest to s1d

 gpart add -s $SIZE -t freebsd $D # to insert s2
 gpart create -s bsd ${D}s2 # create s2
 gpart add -s 256M -t freebsd-ufs ${D}s2  # should be s2a
 gpart add -s 16M  -t freebsd-ufs ${D}s2  # should be s2d
 gpart add -s 32M  -t freebsd-ufs ${D}s2  # should be s2e
 gpart add -s 48M  -t freebsd-ufs ${D}s2  # should be s2f
 gpart add -s 64M  -t freebsd-ufs ${D}s2  # should be s2e
 gpart add         -t freebsd-ufs ${D}s2  # should be s2h

 gpart bootcode -b /boot/boot0 ${D}
 gpart bootcode -b /boot/boot ${D}s1
 gpart set -a active -i 1 ${D}  # This is redundent, but emphasises the point :)

I like the convenience of this approach as it eliminates the fiddly fdisk and bsdlabel work. Enjoy.

Regards, Dewayne.

More information about the freebsd-stable mailing list