Date: Tue, 26 Dec 2006 20:30:38 GMT From: Rob Austein<sra@hactrn.net> To: freebsd-gnats-submit@FreeBSD.org Subject: bin/107213: 6.1-release restore can't read some 6-stable dumps Message-ID: <200612262030.kBQKUcTq089576@www.freebsd.org> Resent-Message-ID: <200612262040.kBQKeI67042223@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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@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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612262030.kBQKUcTq089576>