bin/107213: 6.1-release restore can't read some 6-stable dumps

[Rob Austein]

>Number:         107213
>Category:       bin
>Synopsis:       6.1-release restore can't read some 6-stable dumps
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Dec 26 20:40:17 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Rob Austein
>Release:        FreeBSD 6.2-PRERELEASE i386
>Organization:
>Environment:
FreeBSD thrintun.hactrn.net 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #17: Thu Dec  7 16:13:01 EST 2006     sra at thrintun.hactrn.net:/usr/obj/usr/src/sys/THRINTUN  i386

>Description:
Bought a faster machine, wanted to transfer entire personality
of old machine to new, so built new machine as minimal
6.1-RELEASE machine then attempted to dump on old 6-STABLE
machine and restore on new 6.1-RELEASE machine while running
from 6.1-RELEASE Fixit live filesystem CD-ROM.

This worked ok for the two small filesystems (/ and /var) but
started spewing "expected next file <inumber>, got <inumber>"
errors with the two larger filesystems (/usr and /u).  restore
of /usr ran to completion but was missing many files (eg,
/usr/bin/login); restore of /u failed completely, restore
eventually decided it was so confused it had to abort.

I was eventually able to complete the transfer by using the
6-STABLE restore binary to read the dumps for everything but
the root partition; I had to trust the 6.1-RELEASE restore to
read the root partition but was able to confirm afterwards
(using diff, etc) that it had been restored without damage.

System that generated dumps as shown above: 6.2-PRERELEASE
cvsuped from 6-STABLE branch on 7 December 2006.

I've confirmed that the dumps were created with the -L switch,
so at least in theory they should have been pristine dumps of
snapshots.  More to the point, they restored properly with the
newer version of restore, so I don't think this was pilot error.

I'm reporting this as a software bug because inability to
restore from dumps strikes me as a fairly serious issue.  That
said, it's obviously too late to fix the 6.1-RELEASE version
of restore, so if this isn't just a new bug in dump, I'm at a
loss to suggest a fix.

>How-To-Repeat:
Dump large filesystems on a 6-STABLE machine circa 7 December
2006, attempt to restore using 6.1-RELEASE live filesystem
CD-ROM version of restore.

In case this is not sufficient to reproduce the problem: I do
still have the old 6-STALE machine that generated the
problematic dumps, and can leave it intact for a month or two
if somebody intends to pursue this and wants me to test a new
version of dump with the same data.  Old machine's eventual
destiny is to be reused as lab equipment, so don't wait too
long if you want me to test anything against the particular
filesystem content that was in place when problem occurred.

>Fix:
No fix known.  Workaround would be to use a more recent
version of dump, eg, build a bootable floppy or CD-ROM
containing just a 6-STABLE kernel and the /rescue binary.

>Release-Note:
>Audit-Trail:
>Unformatted: