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?)

>> At this
>> point, installing the 1.4.1 snapshot is the best thing anyway.  If you
>> don't want to do that, workarounds are to unpack the sets by hand now
>> that you've labelled and newfs'ed the target disk;
>
>I'd guess that installing by hand is probably easiest at this stage...

Or netboot again, but use the target disk (which now has a copy of the
ramdisk-install image) as root, rather than NFS.  sysinst should just
run, and it wont try the copy because its already running with the
target as its root.

>> 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?