Subject: Re: Install Problems
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Simon Burge <firstname.lastname@example.org>
Date: 08/06/1999 09:59:51
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.