Installer changes on master (does not effect release)

[Matthew Dillon]

The installer is meant to be simple.  Trying to edit slice or partition
tables setup by other operating systems opens a big can of worms.  We don't
really have the developer time available to do something as complex as what
linux has.  So generally speaking users are on their own when it comes
multi-OS installs.  For single-OS installs, DragonFly's installer works
well.  At best we will be able to bang UEFI booting into shape at some
point, but that's the only new boot-loader work really contemplated.

The DOS slice table vs gpt isn't a big deal, but we'd need updated gpt
tools from FreeBSD and developer time to make it an installer option.  It
should be noted that the DOS slice table is just a degenerate form... for
example, if the drive is larger than 2TB fdisk can't configure a slice to
be larger, but the kernel recognizes that a slice ending in 0xffffffff
should literally mean 'the whole rest of the disk' regardless of other
considerations.  So it is simple and it just works.  Complex
slice/partition setups are usually a lose.

We put a disklabel64 on top of whatever low-level scheme is used and that
will not change.  The disklabel mechanic gives us significantly better
control over the disk layout than a slice or gpt mechanic.  We will
generally always want to have a disklabel.

-Matt

On Tue, Dec 15, 2015 at 6:51 AM, PeerCorps Trust Fund <
ipc at peercorpstrust.org> wrote:

> Since the topic is at hand.
>
> Was there a technical reason why a disk partition tool isn't built into
> the installer?
>
> As of 4.4.1 when configuring disks for installation, the installer still
> recommends using DOS, another *BSD or Linux to partition disks.
>
> On 12/14/2015 09:53 PM, Matthew Dillon wrote:
> >     Master has gotten an installer revamp w/regards to the partition
> >     setup.
> >
> >     Previously the installer used radically different arrangements for
> UFS
> >     vs HAMMER.  UFS put an integrated boot+root on partition 'a', swap
> on 'b',
> >     and HAMMER put boot on 'a', swap on 'b', and root on 'd'.  HAMMER
> installs
> >     also created a whole bunch of PFS's for various major directories
> such
> >     as /home.
> >
> >     The new setup is more uniform.  An 'a' boot, 'b' swap, 'd' root, and
> >     'e' /build is created whether UFS or HAMMER is chosen.  PFS's are no
> >     longer used.  Instead, major directories which generally do not have
> >     to be backed up (such as /usr/obj) are put on /build and null-mounted
> >     to their appropriate places via the fstab.  Major directories which
> >     typically do need to be backed up, such as (most of /var), /home,
> /usr,
> >     and /usr/local remain on the root filesystem.
> >
> >     The new setup handles small drives (typically < 40GB) by not creating
> >     a separate /build partition.  It still creates the /build directory
> >     infrastructure on the root filesystem and still creates the
> null-mounts,
> >     making it relatively easy for the user to manage later on if/when
> moving
> >     to a setup with more storage.
> >
> >     --
> >
> >     I've been using this scheme very successfully at home and on servers
> >     for more than a year now and really like the flexibility and ease of
> >     management.  The null mounts are a lot easier for users to manage
> than
> >     the hammer PFS's, and the separation reduces the chances of the root
> >     filesystem becoming corrupt during a crash.
> >
> >     These changes also allow UFS installs to use encrypted roots which
> they
> >     could not before.  While we recommend HAMMER over UFS generally,
> there
> >     are still a few cases where UFS is more convenient, such as on small
> >     storage media / USB flash drives.
> >
> >                                       -Matt
> >                                       Matthew Dillon
> >                                       <dillon at backplane.com>
> >
>
> --
> Mike
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20151215/1a3621fc/attachment-0002.html>