Okay, I tried mounting /dev/sd0a on /targetroot and cp -R -p, but that  
started a timeout cycle. Copying by hand, the .profile file went okay  
without the -p option, but INSTALL.more and sysinstall with the -p  
option start timeout cycles. Could it be the -p option? I should check  
that.

Sizes reported by list:
     INSTALL.more      151863
     sysinst                  1359848
Are those reasonable?

The timeout cycles look something look this (copied by hand):

     sd0(esp0:0:0:0) esp0: timed out [ecb 0x104b000 (flags 0x1, dleft  
10000, stat 0)] <state 5, nexus 0x104b000, phase (l 3, c 0, p 0), resid  
10000, msg (q 0, o 0) DMA active> AGAIN
     sd0(esp0:0:0:0) esp0: timed out [ecb 0x104b000 (flags 0x41, dleft  
10000, stat 0)] <state 5, nexus 0x104b000, phase (l 3, c 0, p 0), resid  
10000, msg (q 20, o 0) DMA active> AGAIN
     cd0: async, 8-bit transfers
     sd0: waiting for pack to spin up ...

On copying INSTALL.more, the above was repeated eight times total,  
except the cd message was only there the first time. Then it completed,  
and it looked like the file made it alright, but I couldn't find a diff  
to check. So I tried copying sysinstall, and the machine's been doing  
the timeout cycles for over an hour.

Anyway, I know I get the timeout cycles with the SBC kernel, as well.

Oh. The controller is NCR 53C96. The machine is a Performa 630 with 36M  
RAM. That's probably as far as I'm going to get tonight.

On 2004.5.26, at 07:11 PM, Joel Rees wrote:

> Just tried with the sbc kernel. My memory is that the scsi controller  
> is not the one the sbc kernel is supposed to be for, but I thought I'd  
> give it a shot. Get the same
>
>     openpty() failed
>     cp /etc/disklabel.preinstall /etc/disklabel
>
> error when trying to write the disklabel, but this time it drops out  
> to the shell instead of trying to proceed. Otherwise the same.
>
> Maybe I should try mounting the partitions before I run sysinstall.  
> But how does the script access the ram volume if I have the hard disk  
> mounted on /?
>
> On 2004.5.26, at 06:20 PM, Joel Rees wrote:
>
>>
>>> The 23 May mac68k softfloat build lives at:
>>>
>>> ftp://lain.ziaspace.com/pub/NetBSD/m68k/NetBSD-release-2.0-mac- 
>>> softfloat
>>> /
>>
>> Okay, I gave this one a shot. Tried the install kernel, it got along  
>> to the point where it was supposed to partition the disks, and it saw  
>> the map left over from when I partitioned with the Mac HD Setup  
>> utility. It let me set the mount points, then complained that it  
>> couldn't open something (which I forgot to write down, silly me). So,  
>> when it checked to see if it could install, it said the file system  
>> did not look like a netbsd file system.
>>
>> So, I specifically changed each volume to what it was, in an attempt  
>> to get disklabel to write the label, but it still failed to open  
>> whatever it was.
>>
>> So, I dropped out to the shell, newfs-ed each partition by hand  
>> (defaults, no errors reported), then ran sysinst again. This time it  
>> allowed me to proceed to attempt to load from ftp. But about half way  
>> through the first tarball, kern-GENERIC.tgz, it choked, complaining  
>> there is no space left on the device. (70 M on root should be enough,  
>> right?)
>>
>> This is the same machine that reported flaky disk usage numbers on  
>> netbsd 1.6, allowed me to load the base set into a single root  
>> partition from the Macside tools, but kept hanging when I tried to  
>> move things where they belong.
>>
>> I guess maybe what I need to do is put together some test machine  
>> code that would tell me if this LC040 is one of that batch that was  
>> really botched. If that's not the case, I'm thinking I should suspect  
>> that my SCSI circuitry is broken. The machine's stability under Mac  
>> OS was never great and has been declining noticeably in the last year  
>> or so.
>>
>> Which means I doubt the above information will be anything but noise,  
>> but I thought I'd post my results anyway.
>>
>