ugh. dump / restore problem(s) "Cannot find file dump list"
Gary Aitken
ah at dreamchaser.org
Thu Nov 15 05:53:52 UTC 2012
> 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...
More information about the freebsd-questions
mailing list