Re: 5.3: /stand/ versus /rescue/ ?

From: Brooks Davis <brooks_at_one-eyed-alien.net>
Date: Wed, 6 Oct 2004 14:56:00 -0700
On Wed, Oct 06, 2004 at 03:53:35PM -0600, Ryan Sommers wrote:
> Jose M Rodriguez said:
> > On Wednesday 06 October 2004 20:13, John Baldwin wrote:
> >> On Wednesday 06 October 2004 01:48 pm, Ryan Sommers wrote:
> >> > Is there any reason why we need /stand after the install process?
> >> > As part of the post-install configuration would it be possible to
> >> > have /stand removed?
> >>
> >> Prior to /rescue it was (ab)used as a sort of /rescue type of thing.
> >> Now that we have /rescue, it probably can be removed after the
> >> installation is complete.
> >
> > Take care of:
> >  - it only takes ~2 MB of your rootfs.
> 
> About a year ago a lot of people didn't want /rescue because of a lack of
> space in some of the older root slices. This would free up a little bit of
> room from a lot of programs that are likely duplicated in /rescue. Getting
> rid of /stand might make a little difference.
> 
> >  - I'm not sure that /rescue/tar can work without a tmp dir
> 
> I'll look into that.

If this is a problem, you might see if it's a problem with bsdtar since
/rescue/tar is currently gnutar.  We're going to want to do that anyway
if we're going to remove gnutar from the tree anyway.

> >    and this is really needed for initdiskless oper (/stand/cpio).
> 
> >From looking at the initdiskless script, is there any reason we couldn't
> add cpio to /rescue and use it from there? From what I saw the only
> references to /stand were /stand/cpio and /stand/gzip, and gzip is already
> in /rescue.

If you add bsdtar, you get cpio support.

> >  - can sysinstall unlink his own binary before restart?
> 
> Couldn't we restart the post-install from /usr/sbin/sysinstall? I'm not
> too familiar with the installation code.

It's always safe to delete an open file so long as you don't need to
reopen it.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4

Received on Wed Oct 06 2004 - 19:50:50 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:16 UTC