DragonFly kernel List (threaded) for 2013-03
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
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
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]