Things to remove from /rescue
David O'Brien
obrien at freebsd.org
Thu Jul 17 01:08:09 PDT 2003
This is a list of binaries that I don't feel should be part of /resuce as
it's mission is to recover/rebuild a "broken" / [due to all the binaries
being dynamic]. Is there justification for keeping them?
- domainname, one does not need YP in the circumstances /rescue is meant
to address.
- date, one can use a watch if they really want to know it is 5am and
their system is down.
- sleep, this is what the admin wishes he was doing at 5am rather than
trying to recover a borked system. The admin doesn't need the OS
sleeping and delaying the repair.
- adjkerntz, who cares if the date is wrong if you right to the FS (and
you are on a PC and have Winloose on it also). At the least this
should only be installed on i386.
- comcontrol, I can't begin to imagine why one would need this to fix
a borked /.
- conscontrol, I can't begin to imagine why one would need this to fix
a borked /.
- growfs, how would growing / fix a borked /lib??
- ipfw & natd & ipf & ipfs & ipfstat & ipmon & ipnan, why would one needs
these? /rescue is to fix a borked /, not replace PicoBSD.
- nfsiod, to quote "It improves performance but is not required for
correct operation." Recovering a borked / doesn't need to be high
performance.
- quotacheck, does one really want to enforce quota's on root, while he
is trying direly to fix a borked /??
- shutdown, 'reboot' is sufficient when single user -- there are no other
users on the system inform of the impending shutdown.
- swapon, this is not needed to fix a whacked out /lib.... unless we add
Emacs to /resuce.
- wall, when single user (as one needs to be to fix a broked /) who is
one going to communicate with??
- tar, pax (w/{bz,g}zip) can do everything GNU tar can.
More information about the freebsd-arch
mailing list