Re: DragonFly 3.4 release planning

[Dan Cross <crossd@xxxxxxxxx>]

--e0cb4efe3444f12ff604d93d7a7f
Content-Type: text/plain; charset=UTF-8

On Sun, Mar 31, 2013 at 2:26 PM, Matthew Dillon <dillon@apollo.backplane.com>
wrote:
>     I'll add one more thing re: use of /boot.  We could also clean up
>     the crypto bootstrapping to just use the /boot/rescue root instead of
>     bootstrap image.  That is, an unencrypted /boot (doesn't need to be
>     encrypted anyway) and an encrypted normal root could be driven
entirely
>     from the /boot/rescue environment.
>
>     (If I understand the current crypto bootstrapping correctly).

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.

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.

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.

--e0cb4efe3444f12ff604d93d7a7f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Mar 31, 2013 at 2:26 PM, Matthew Dillon &lt;<a hre=
f=3D"mailto:dillon@apollo.backplane.com";>dillon@apollo.backplane.com</a>&gt=
; wrote:<br>&gt; =C2=A0 =C2=A0 I&#39;ll add one more thing re: use of /boot=
. =C2=A0We could also clean up<br>

&gt; =C2=A0 =C2=A0 the crypto bootstrapping to just use the /boot/rescue ro=
ot instead of<br>&gt; =C2=A0 =C2=A0 bootstrap image. =C2=A0That is, an unen=
crypted /boot (doesn&#39;t need to be<br>&gt; =C2=A0 =C2=A0 encrypted anywa=
y) and an encrypted normal root could be driven entirely<br>

&gt; =C2=A0 =C2=A0 from the /boot/rescue environment.<br>&gt;<br>&gt; =C2=
=A0 =C2=A0 (If I understand the current crypto bootstrapping correctly).<di=
v><br></div><div style>If one takes that route, then /boot/rescue isn&#39;t=
 (solely) about rescuing things anymore, so perhaps consider calling it som=
ething else (possibly revive the 4.4BSD /stand convention?). =C2=A0Or, just=
 do away with the subdirectory entirely and have these things in /boot/bin =
and /boot/sbin; that seems simpler and more straight forward.</div>

<div style><br></div><div style>It strikes me that if one is booting into s=
ingle user mode, one is most often doing that to repair something; if that =
is true, then I would imagine that chroot&#39;ing into a /boot/rescue envir=
onment isn&#39;t all that useful. =C2=A0Either 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 righ=
t locations.</div>

<div style><br></div><div style>You had said before that you didn&#39;t car=
e for the idea of a /rescue (if I understood you correctly), and I asked wh=
y; I&#39;m still very curious about that?</div><div style><br></div><div st=
yle>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Dan C.</div><div style><br></div><div style><=
br></div></div>

--e0cb4efe3444f12ff604d93d7a7f--