From owner-freebsd-questions@FreeBSD.ORG Thu Nov 15 05:53:52 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D613BCAB for ; Thu, 15 Nov 2012 05:53:52 +0000 (UTC) (envelope-from ah@dreamchaser.org) Received: from nightmare.dreamchaser.org (nightmare.dreamchaser.org [12.32.44.142]) by mx1.freebsd.org (Postfix) with ESMTP id 75ED28FC08 for ; Thu, 15 Nov 2012 05:53:52 +0000 (UTC) Received: from breakaway.dreamchaser.org (breakaway.dreamchaser.org. [12.32.36.73]) by nightmare.dreamchaser.org (8.13.6/8.13.6) with ESMTP id qAF5rp2G033805 for ; Wed, 14 Nov 2012 22:53:51 -0700 (MST) (envelope-from ah@dreamchaser.org) Message-ID: <50A4836F.7000702@dreamchaser.org> Date: Wed, 14 Nov 2012 22:53:51 -0700 From: Gary Aitken User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120609 Thunderbird/13.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org Subject: Re: ugh. dump / restore problem(s) "Cannot find file dump list" References: <50A3543E.9000406@dreamchaser.org> In-Reply-To: <50A3543E.9000406@dreamchaser.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (nightmare.dreamchaser.org [12.32.36.65]); Wed, 14 Nov 2012 22:53:51 -0700 (MST) X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 05:53:52 -0000 > did the following: > booted to backup disk > dump -0aR -h 0 -f /usr/backup/dump_var_0_20121113_1920 /dev/ada0p4 > (repeat for /tmp, /usr, / partitions to be safe) > repartitioned the main disk using gpart > newfs the modified partitions (var, tmp, usr) > rewrote the boot block and boot partition (#1) > mount /dev/ada0p4 /mnt/ssd/var > cd /mnt/ssd/var > restore -r /usr/backup/dump_var_0_20121113_1920 > Cannot find file dump list ok, after digging around in my notes and memory I have a better understanding of what actually happened: I went through several reboot sequences, between the backup disk and the main disk. After generating the /var dump file on the backup disk while booted from the backup disk, I did a shutdown -r to reboot the main disk; can't remember why. What I do remember is that the dump itself, running as root from ttyv5, appeared to terminate normally, with no error message; I got the # prompt. However, as the shutdown was happening, I saw the message: Dump failed, partition too small on ttyv1 -- despite the fact that the command completed without any message on the controlling terminal, ttyv5. The destination file-system was nowhere near full, and the source was read-only, so I stupidly assumed the output was ok and the message was the result of some other niggly thing. Obviously dump ran out of space (the file is exactly a multiple of the block size and apparently truncated), and the dump directory can't be found. But where it ran out of space is unclear to me, as the destination file system was nowhere near full before or after the event, and contains two much larger intact dump sets (for / and /usr) and one of those was written after the truncated ones. The question I have is: Why didn't the dump failure message show up on the controlling terminal? It's not clear which partition ran out of space. Does dump use /tmp or /var? /tmp and /var on the running backup os are relative small (512MB), and the filesystem being dumped was the same size and ~70% full. If dump uses /tmp and tmp runs out of space and the tty output of dump is depending on a socket in /tmp, that might cause a problem. But once the process terminates, if it cleans up after itself there's no trace of the overflow. crazy? it was kinda late at night...