Bug 107213

Summary: 6.1-release restore(8) can't read some 6-stable dumps (regression)
Product: Base System Reporter: Rob Austein <sra>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 6.2-PRERELEASE   
Hardware: Any   
OS: Any   

Description Rob Austein 2006-12-26 20:40:17 UTC
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.

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.
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.
Comment 1 dfilter service freebsd_committer freebsd_triage 2008-04-14 21:16:13 UTC
mckusick    2008-04-14 20:15:53 UTC

  FreeBSD src repository

  Modified files:
    sbin/restore         dirs.c 
  Log:
  restore(8) does not check for write failure while building two temp
  files containing directory and ownership data. If /tmp fills, the
  console is blasted with zillions of "file system full" errors, and
  restore continues on, even though directory and/or ownership data
  has been lost. This is particularly likely to happen when running
  from the live CD, which has little /tmp space.
  
  PR:         bin/93603, also probably bin/107213
  Fix from:   Ken Lalonde
  
  Revision  Changes    Path
  1.34      +68 -24    src/sbin/restore/dirs.c
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
Comment 2 Kirk McKusick freebsd_committer freebsd_triage 2008-04-14 21:23:10 UTC
State Changed
From-To: open->closed

The fix applied for PR bin/93603 most likely was what was 
causing this problem.