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