C. Kukulies wrote: > /rescue is always causing trouble with me here. make world falls over > with: > > ===> rescue/rescue > install -s -o root -g wheel -m 555 rescue /rescue > install -o root -g wheel -m 555 nextboot_FIXED /rescue/nextboot.sh > install: /rescue/nextboot.sh: Not a directory > *** Error code 71 > > Stop in /u/src/rescue/rescue. > *** Error code 1 > > Looking into / I see that /rescue is a file. > > Why is this /rescue being created in /? It used to blow up and > overflow the / filesystem (there were times when a 40 MB root FS was > sufficient). > > What is the safe method to put /rescue elsewhere (in an area with enough > space). It also seems that it is being deleted by make world, at least I > seem to remember that putting a soft link into /rescue into / didn't > help either. Symlinking /rescue -> / will cause exactly the problem you're seeing. (Because there is a file called /rescue/rescue, which will then get installed on top of the symlink. Boom!) Don't do that. You could probably symlink /rescue -> /usr/rescue, but that sort of defeats the purpose. /rescue is part of a plan to reduce the size of the / partition, though it's a somewhat involved process. There are two key pieces: 1) Building /bin and /sbin dynamically. This is a big space savings, but comes at a cost. Namely, it's a lot easier to trash a dynamic /bin than the old static one. 2) /rescue contains a compact set of statically-linked executables (about 3MB total) that are provided to help in system recovery if /bin or /sbin gets damaged. The catch, of course, is that step #2 needs to be finished first, temporarily increasing the / partition size until #1 is done. You have several options: * Disable /rescue. Define NO_RESCUE to suppress it from being built and installed, e.g., make -DNO_RESCUE buildworld make -DNO_RESCUE installworld Or add it to /etc/make.conf * Take the plunge and compile /bin dynamically. Define WITH_DYNAMICROOT in /etc/make.conf. * Get a bigger hard disk. ;-) Hope this helps, Tim KientzleReceived on Mon Oct 20 2003 - 09:20:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:26 UTC