Re: Trimming a diskless distribution

[Brett Lymn <blymn%internode.on.net@localhost>]

On Wed, Oct 10, 2018 at 07:13:41PM -0700, Don NetBSD wrote:
> On 10/8/2018 2:10 PM, Brett Lymn wrote:
> >
> >For your purposes surely either just testing on loopback or on the local
> >interface from the machine would be sufficient?  You just wanted to make
> >sure things start.
> 
> Yes, but you have to arrange for all of those "things" to actually GET
> started.  And, the bigger problem, if they <gag> when invoked, there's
> very little to help you figure out what they might be missing.
> 

Well, that is what atf would be for.  Do you know about anita?  This is
what the project uses to test the installer.  If you automate the
running ot the tests then  it makes the "run, fail, fix, rins, repeat"
process a lot easier.

> You can look at the .so's that are linked to a (non-static) binary
> and arrange for them to be present.  But, if they exec something else,
> in turn, then you have to arrange for those binaries (and their
> dependencies) to be present.
> 

Right, a shell script and ldd will help you pull ann the shared library
dependencies.

> Ideally, I'd like something like the "required to run" explicit dependency
> specification in pkgsrc.
> 
> [Yes, I realize this is asking a lot.  So, I'm looking for a reliable way
> of MANUALLY ascertaining these dependencies without having to rely on an
> intimate knowledge of "how things work"]
> 

Yes, it is asking a lot.  I don't think you will find what you are
looking for.  Maintaing that sort of dependency list is a lot of work
(as you have found) and there really is little gain for the NetBSD
project as a whole to do this.

> >
> >If you want to really test externally then you could use qemu to build a
> >test virtual machine and use the host at the "external" machine.
> 
> I'm only looking to "test" to the extent that nothing SIGSEGV's or
> otherwise crashes because I failed to include something that it needed
> in the target filesystem.  I assume that if I've got everything in
> place, it "will work".
> 

Yep, just opening the port of a network facing service will do that.

> >>I've been "manually" invoking everything that I want/need to run and
> >>capturing any errors logged to sort out what might be missing.
> >
> >Right - atf can automate this bit for you.  If you are doing a
> >customised build then you will want to do this agin if/when you update
> >to make sure things are not broken afterwards.  It means you can
> >validate things in a consistent and repeatable manner.
> 
> I think that's more than I need.  I'm going to pick *a* release
> and stick with it (for a very long time -- updates will be difficult).
> The bigger concern is deciding that I need to add some particular
> binary to this "distribution".  Adding shouldn't break anything
> that already works but could require additional dependencies that
> haven't been present, prior to that point.
> 

OK, if you say so but manually bashing through all the tests time after
time just to track down some obscure crash is pretty tedious in my mind.

You probably should think seriously about maintaining the image even if
it is for back-porting security updates.

> To repeat/summarize, my approach, thus far, has been to PXE boot a kernel
> and let it NFS mount a remote filesystem that is initially empty.  Then,
> examine the errors that are generated and start adding stuff to that
> file system to eliminate each error -- which inevitably exposes another
> error, etc.
> 
> Once the system made it to single user, I continued the process after 
> telling
> it to go multiuser.
> 
> Once it could correctly get to multiuser, THEN I started looking at the
> additional programs that I wanted present -- adding each, individually;
> invoking them, manually; then pacifying the errors that were thrown.
> 

all of which atf can do for you... look for "netbsd anita"

-- 
Brett Lymn
Let go, or be dragged - Zen proverb.