Re: DragonFly 3.4 release planning

:If one takes that route, then /boot/rescue isn't (solely) about rescuing
:things anymore, so perhaps consider calling it something else (possibly
:revive the 4.4BSD /stand convention?).  Or, just do away with the
:subdirectory entirely and have these things in /boot/bin and /boot/sbin;
:that seems simpler and more straight forward.

    Yes.  I was concerned I'd be breaking convention since the boot
    files and directories are then in the stand-alone /, but after thinking
    about it a bit more I think you are right.  A boot with root == /boot
    should be a single-user boot.

:It strikes me that if one is booting into single user mode, one is most
:often doing that to repair something; if that is true, then I would imagine
:that chroot'ing into a /boot/rescue environment isn't all that useful.
: Either mount /boot on root and have /boot/bin, /boot/sbin show up as /bin
:and /sbin, or mount it over a pseudo-root as /boot and set $PATH for the
:single user shell to refer to the right locations.

    We want to be able to boot without the multi-user root at all, since
    that might be what is broken.  In this case the multi-user root could
    be mounted under /boot by the sysop while doing the repair.

:You had said before that you didn't care for the idea of a /rescue (if I
:understood you correctly), and I asked why; I'm still very curious about
:that?
:
:        - Dan C.

    Basically the problem is that it's a lot of mess *just* to implement
    a single function.

    If having something like that gave us multiple functions, such as
    proposed (also modified by not having /boot/rescue at all but just
    using /boot straight-out for the single-user root), then I would be
    happier with adding the mess because the same infrastructure could
    then be used to implement other features such as the crypto boot.

    We would have a minimally working /boot-as-root for single user,
    /boot-crypto-bootstrap, a method to get a safe non-lib root shell on a
    live system that only needs to chroot to /boot.

    I'm sure we could come up with other uses as well.  For example,
    pxeboot could be reworked such that servers only needed to export
    a '/boot' worth of data rather than a full blown system as the basis
    for an auto-configuration or a mixed pxeboot/NFS/local-disk
    environment.

					-Matt