Jonathan Stone wrote:

> 
> In message <199908052330.JAA11527@balrog.supp.cpr.itg.telecom.com.au>,
> Simon Burge writes:
> 
> >Jonathan Stone wrote:
> >
> >> This one is our fault, not yours.  pax is opening a temporary file to
> >> keep track of state whilst it does its thing, but the attempt to copy
> >> everything to your local disk clobbers it.
> >> 
> >> I thought Simon had fixed it for 1.4, but maybe it's 1.4.1.
> >
> >Umm, drat.  This hasn't been fixed...
> 
> Uh, oh. We really should fix that in the prebuilt install kits, even
> if it doesnt get into the source. But cgd has removed the `copy
> ramdisk to target disk' in 1.4.1, so maybe it's not a problem?  (the
> problem was, iirc, that pax/tar was creating a temporary file in /tmp
> where it wrote last-change info about the files it was moving, and
> restored it when it was done; and it noticed that file changed size
> during the `copy'. So if we don't copy the ramdisk to the target, it
> should all work. Right?)

I think cgd only did that on the ports he could test, and I think there
was a corner case on the pmax where it still could be useful.  I've
spent bugger-all time on sysinst since Chris cleaned things up...

I'll at least try to get the install kernel built with a fix, and send a
pull-up for the 1.4 branch.  If I can find what the corner case was, and
it looks nukeable, then I'll just to that.

> >> or (alternatively)
> >> try mounting an mfs /tmp. (I think the small kernel for machines with
> >> buggy TFTP proms doesn't have mfs, though, so that may not work for you).
> >
> >That's correct - no mfs.
> 
> Um. Can we fix that for 1.4.1, or does it bloat the kernel too much?

That was the concern.  Since mfs already uses ffs I guess it couldn't
add _that_ much to the kernel.  Time for a test.  Then again, fixing
sysinst is the Right Thing.

Simon.