Oaky, I'm late for work. However, Martin and Julian have solved the 
problem. There was a kernel issue that made dump/restore not work properly.

I have now gotten a newer kernel, tested a dump, and booted the machine. 
Woo Hoo! I'll go fix my script this evening and try to automate everything.

ciao!

leam


leam wrote:
> Many alphabetically ordered thanks to Andrey, Manuel, and Richard!
> 
> Although I do *not* yet have the solution to the dump/restore issue, as 
> suggested I tried:
> 
>     umask 0000
>     tar -clf - -C / . | tar xPf - -C /mnt
> 
> After editing the fstab I am able to boot into the second disk. This 
> suggests either I'm not using dump/restore correctly or there is a 
> problem with them. As the first is more likely, that's the next stage of 
> the investigation.
> 
> Key to this was Andrey's suggestion to diff -r "/" and "/mnt". Many 
> critical files showed up as different that should not have been so.
> 
> So I can close this thread with a "Thanks!" and if needed I'll start one 
> on dump/restore later. Once that is done and things are automated we can 
> go to -current.
> 
> ciao!
> 
> leam
> 
> 
> Andrey Petrov wrote:
> 
>> On Tue, Feb 11, 2003 at 05:13:25PM -0500, leam wrote:
>>
>>> The reason for the "dump/restore" vice the other options is that I'm 
>>> trying to port a script from Solaris to NetBSD. The original script 
>>> does an fsck of the to-be-dumped-to partition, mounts it on /mnt, 
>>> dumps the twin partition from the live disk, and then umounts it.
>>>
>>
>>
>> Yeah, that seems easier with dump/restore. I'd suggest to verify 
>> copied partition by comparing it with original one,
>> if it fails i'd try -current.
>>
>> And netbsd's dmesg or solaris's prtconf -pv would be helpful.
>>
>>     Andrey
>>
>>
>>
> 
> 
> 
>