Subject: Re: Install Problems
To: Simon Burge <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 08/05/1999 16:51:50
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?