Re: [issue1407] disklabel64 boot problem

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    Another interesting issue here which I really think puts the nail in
    coffin is that we really want to be able to use more complex access
    schemes, such as vinum, for these large filesystems.  I don't want to
    have to depend on something like the BIOS fake-raid, its just too severely
    limiting.

    With a small UFS /boot we can make the primary root filesystem whatever
    we want... from multi-volume mounts to vinum or any other scheme we
    choose, including eventually mounts named by serial number.

    The more I think about it, the more I really want us to default to
    a small UFS /boot.  Here's another example... lets say we wanted to
    support encrypted disks.  The information on the UFS /boot would not
    have to be encrypted per-say, since it's just a tiny boot-only partition
    containing no production data.  It could, however, contain sufficient
    information to allow the system to auto-boot the encrypted root disk.

    For example, the /boot booted kernel could query the local environment,
    such as the network, and acquire sufficient information to mount its
    encrypted root.

    --

    If we reserved space for a /boot by default on every disk we disklabel,
    it could lead to some fairly impressive booting and recovery options.
    I'd like it to be the new concept for the 'a' partition.  Make 'a'
    *always* be a small /boot partition.

						-Matt