New BSD Installer
Dewayne Geraghty
dewayne.geraghty at heuristicsystems.com.au
Fri Feb 17 06:37:38 UTC 2012
To answer an earlier question by Bruce...
> -----Original Message-----
> From: owner-freebsd-stable at freebsd.org
> [mailto:owner-freebsd-stable at freebsd.org] 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 freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"
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;
so
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