David,

I have upgraded the system kernel to 1.4.2 and tried the restore which
failed perviously. It did not produce an error this time.

At this point, we could just shrug our shoulders and carry-on with
business (i.e. not pursue it any further). Since I work with MS products
a lot, this is now a reflex response to mysterious problems. It this
worth pursuing?

Thanks.

On Thu, 27 Apr 2000, David Brownlee wrote:
> 	Don't know if I can be any help here, but just a couple of random
> 	ideas:
> 	   - do you get the panic from 'dump -0f - /dev/wd0e > /mnt/dump.fs'
> 	   - have you tried ti with a 1.4.2 kernel (should not need to
> 	     change anything else for the test)
> 
> 		David/absolute
> 
> On Thu, 27 Apr 2000, Marinier, M. Claude, G. wrote:
> > Hi, I am running NetBSD 1.4.1 on i386 (Intel PD440FX, Pentium II).
> > 
> > Problem:
> > 
> > I was copying a file system with a dump/restore pipe as follows.
> > 
> > 	newfs /dev/wd1e
> > 	mount /dev/wd1e /mnt
> > 	cd /mnt
> > 	dump -0f - /dev/wd0e | restore -rf
> > 
> > When the system hung, I went to the console and found that fsck had failed
> > on reboot after a panic.
> > 
> > 	Apr 27 12:56:14 behemoth savecore:
> > 		reboot after panic: lockmgr: locking against myself
> > 
> > I assumed that I had messed-up the file system before copying. I tried
> > again and got a different panic.
> > 
> > 	Apr 27 13:08:41 behemoth savecore:
> > 		reboot after panic: ffs_alloccg: map corrupted
> > 
> > This may be because I was copying from a live system. I then did a dump to
> > disk followed by a restore from disk. I got the same panic again.
> > 
> > 	Apr 27 14:09:14 behemoth savecore:
> > 		reboot after panic: ffs_alloccg: map corrupted
> > 
> > The last time the system died, there was an error message about an
> > interrupt but I cannot find it in the log files.
> > 
> > Question:
> > 
> > I have done this sort of operation many times. I moved the same system to
> > a new disk earlier this week without a problem. I do not know what is
> > going on here.
> > 
> > At this point, I could speculate wildly but it would not be very useful.
> > One of you can probably help me.

-- 
Claude Marinier, Information Technology Group    claude.marinier@dreo.dnd.ca 
Defence Research Establishment Ottawa (DREO)    (613) 998-4901  FAX 998-2675
3701 Carling Avenue, Ottawa, Ontario  K1A 0Z4         http://www.dreo.dnd.ca