From owner-freebsd-stable@FreeBSD.ORG Thu Aug 19 05:46:19 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BFAC16A4CE for ; Thu, 19 Aug 2004 05:46:19 +0000 (GMT) Received: from smtp.dkm.cz (smtp.dkm.cz [62.24.64.34]) by mx1.FreeBSD.org (Postfix) with SMTP id ED6A943D2F for ; Thu, 19 Aug 2004 05:46:17 +0000 (GMT) (envelope-from neuhauser@chello.cz) Received: (qmail 11225 invoked by uid 0); 19 Aug 2004 05:46:16 -0000 Received: from r2g224.chello.upc.cz (HELO isis.wad.cz) (62.245.70.224) by smtp.dkm.cz with SMTP; 19 Aug 2004 05:46:16 -0000 Received: by isis.wad.cz (Postfix, from userid 1001) id 893C21F87BED; Thu, 19 Aug 2004 07:46:16 +0200 (CEST) Date: Thu, 19 Aug 2004 07:46:16 +0200 From: Roman Neuhauser To: freebsd-stable Message-ID: <20040819054616.GB8507@isis.wad.cz> References: <20040818055250.GA545@isis.wad.cz> <20040818185105.GA86583@doom.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040818185105.GA86583@doom.homeunix.org> User-Agent: Mutt/1.5.6i Subject: Re: restore: "no memory to extend symbol table" abort X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2004 05:46:19 -0000 # ip@doom.homeunix.org / 2004-08-18 22:51:05 +0400: > On Wed, Aug 18, 2004 at 07:52:50AM +0200, Roman Neuhauser wrote: > > I have problems dump|restoring to a new disk. > > > > Procedure: > > > > shutdown now > > /sbin/fdisk -Iv ad1 > > /sbin/disklabel -r ad1s1 > > /sbin/disklabel -re ad1s1 > > /sbin/newfs /dev/ad1s1e > > /sbin/swapon -a # 1GB ad0s1b > > /sbin/mount /dev/ad1s1a /mnt > > cd /mnt > > /sbin/dump -0af- /usr | restore -xf- > > <-- restore reports insufficient memory, asks for permission to abort > > and dump core (backtrace below) > > I expirienced something like this (I don't remember exactly) > when I had not enough space in /tmp. You're not the first person to suggest this might be the culprit. But, /tmp remains the same both in single- and multiuser modes; notice that I was dumping /usr, and this output: roman@isis ~ 1003:2 > ls -l / | grep -Fe '->' lrwxr-xr-x 1 root wheel 10 Mar 18 02:08 compat -> usr/compat lrwxr-xr-x 1 root wheel 8 Mar 18 02:08 home -> usr/home lrwxr-xr-x 1 root wheel 7 Mar 18 02:08 opt -> usr/opt lrwxr-xr-x 1 root wheel 11 Jun 27 14:27 sys -> usr/src/sys lrwxr-xr-x 1 root wheel 7 Mar 18 02:08 tmp -> usr/tmp lrwxr-xr-x 1 root wheel 7 Mar 18 02:08 var -> usr/var IOW, if /tmp has enough space in multiuser, what would it cause to shrink in singleuser? (I tried the dump|restore multiple times in both modes, with consistent results.) -- FreeBSD 4.10-STABLE 7:27AM up 23:37, 4 users, load averages: 0.06, 0.05, 0.01