From ag@hamming.space.net  Tue Jun  8 20:22:35 2004
Return-Path: <ag@hamming.space.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0E3C916A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  8 Jun 2004 20:22:35 +0000 (GMT)
Received: from hamming.space.net (hamming.Space.Net [195.30.0.52])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7371D43D2F
	for <FreeBSD-gnats-submit@freebsd.org>; Tue,  8 Jun 2004 20:22:34 +0000 (GMT)
	(envelope-from ag@hamming.space.net)
Received: from hamming.space.net (localhost [127.0.0.1])
	by hamming.space.net (8.12.10/8.12.10) with ESMTP id i58KMXX3059180;
	Tue, 8 Jun 2004 22:22:33 +0200 (CEST)
	(envelope-from ag@hamming.space.net)
Received: (from ag@localhost)
	by hamming.space.net (8.12.10/8.12.10/Submit) id i58KMWM7059179;
	Tue, 8 Jun 2004 22:22:32 +0200 (CEST)
	(envelope-from ag)
Message-Id: <200406082022.i58KMWM7059179@hamming.space.net>
Date: Tue, 8 Jun 2004 22:22:32 +0200 (CEST)
From: Armin Gruner <ag-freebsd@space.net>
Reply-To: Armin Gruner <ag-freebsd@space.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc: ag-freebsd@space.net
Subject: FreeBSD 5.x restore cannot handle other platforms/Linux(extfs)-dumps anymore
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         67723
>Category:       bin
>Synopsis:       restore(8) FreeBSD 5.x restore cannot handle other platforms/Linux(extfs)-dumps anymore
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Jun 08 20:30:23 GMT 2004
>Closed-Date:    
>Last-Modified:  Sat May 24 19:36:11 UTC 2008
>Originator:     Armin Gruner
>Release:        FreeBSD 5.2.1-RELEASE-p6 i386
>Organization:
SpaceNet AG
>Environment:
System: FreeBSD hamming 5.2.1-RELEASE-p6 FreeBSD 5.2.1-RELEASE-p6 #1: Fri May 7 22:13:46 CEST 2004 ag@hamming:/usr/obj/usr/src/sys/SPACE i386

>Description:
	At some point between FreeBSD 4 and FreeBSD 5 versions of the "restore" utility,
	"restore" ceased to support reading dumps of other platforms, namely Linux-ext2fs-dumps.
	This makes using a FreeBSD 5.x system as a backup server system very unfriendly
	in a mixed environment.
	This was probably introduced when incorporating changes for UFS2 support.

>How-To-Repeat:
	Get a Linux-extfs filesystem dump, and try to restore it on a FreeBSD system:

	On a FreeBSD 4.9-RELEASE, restore works fine:

	[ag@moebius2 1054]$ uname -a
	FreeBSD moebius2 4.9-RELEASE-p4 FreeBSD 4.9-RELEASE-p4 #1: Wed Mar 24 23:44:34 CET 2004 
	   ag@dhcp-147.office:/usr/obj/usr/src/sys/SPACE_SMP  i386

	[ag@moebius2 1053]$ file linux.dump
	linux.dump: new-fs dump file (little endian), This dump Wed Jun  2 01:02:08 2004,
	Previous dump Sun May 30 00:52:59 2004, Volume 1, Level 1, type: tape header,
	Label /var, Filesystem /var, Device /dev/sda3, Host Swain, Flags 1

	[ag@moebius2 1055]$ restore ivbf 2 linux.dump
	Verify tape and initialize maps
	Dump   date: Wed Jun  2 01:02:08 2004
	Dumped from: Sun May 30 00:52:59 2004
	Level 1 dump of /var on Swain:/dev/sda3
	Label: /var
	Extract directories from tape
	Initialize symbol table.
	restore > ls
	.:
	     2 ./     125953 cache/ 220417 lock/  299137 run/
	     2 ../     31489 lib/    94465 log/   314881 spool/

	restore > quit


	Whereas on a FreeBSD-5.2.1-RELEASE, it fails:

	[ag@hamming 1073]$ uname -a
	FreeBSD hamming 5.2.1-RELEASE-p6 FreeBSD 5.2.1-RELEASE-p6 #1: Fri May  7 22:13:46 CEST 2004
	    ag@hamming:/usr/obj/usr/src/sys/SPACE  i386

	[ag@hamming 1074]$ file linux.dump
	linux.dump: new-fs dump file (little endian), This dump Wed Jun  2 01:02:08 2004,
	Previous dump Sun May 30 00:52:59 2004, Volume 1, Level 1, type: tape header,
	Label /var, Filesystem /var, Device /dev/sda3, Host Swain, Flags 1

	[ag@hamming 1075]$ restore ivbf 2 linux.dump
	Verify tape and initialize maps
	Dump   date: Thu Jan  1 01:00:10 1970
	Dumped from: the epoch
	Level 1 dump of /var on Swain:/dev/sda3
	Label: /var
	Extract directories from tape
	. is not on the tape
	Root directory is not on tape
	abort? [yn] y
	dump core? [yn] n
>Fix:
>Release-Note:
>Audit-Trail:

From: Paul Frommeyer <paul@palas.com>
To: <freebsd-gnats-submit@freebsd.org>, <ag-freebsd@space.net>
Cc:  
Subject: Re: bin/67723: FreeBSD 5.x restore cannot handle other
	platforms/Linux(extfs)-dumps anymore
Date: Fri, 09 Jul 2004 12:06:36 -0400

 Hello,
 I wanted to offer some supplemental information that I suspect is wider
 behavior for this same bug. On 5.2.1-RC, recognition of legacy filesystems
 appears to be broken, up to and including refusal of restore to recognize
 the -c switch:
 
 milo2.palas.com:/local/dump#uname -v
 FreeBSD 5.2.1-RC #0: Sat Jan 31 05:36:22 GMT 2004
 root@cypress.btc.adpatec.com:/usr/obj/usr/src/sys/GENERIC
 milo2.palas.com:/local/dump#file sunosdump
 sunosdump: dump format, 4.2 or 4.3 BSD without IDC
 milo2.palas.com:/local/dump#restore -rf sunosdump
 Tape is not a dump tape
 milo2.palas.com:/local/dump#restore -c -r -f sunosdump
 restore: illegal option -- c
 usage:  restore -i [-cdhmNuvy] [-b blocksize] [-f file] [-s fileno]
       restore -r [-cdNuvy] [-b blocksize] [-f file] [-s fileno]
       restore -R [-cdNuvy] [-b blocksize] [-f file] [-s fileno]
       restore -x [-cdhmNuvy] [-b blocksize] [-f file] [-s fileno] [file ...]
       restore -t [-cdhNuvy] [-b blocksize] [-f file] [-s fileno] [file ...]
 milo2.palas.com:/local/dump#restore -c
 restore: illegal option -- c
 usage:  restore -i [-cdhmNuvy] [-b blocksize] [-f file] [-s fileno]
       restore -r [-cdNuvy] [-b blocksize] [-f file] [-s fileno]
       restore -R [-cdNuvy] [-b blocksize] [-f file] [-s fileno]
       restore -x [-cdhmNuvy] [-b blocksize] [-f file] [-s fileno] [file ...]
       restore -t [-cdhNuvy] [-b blocksize] [-f file] [-s fileno] [file ...]
 milo2.palas.com:/local/dump#
 
 I found that an eminently effective workaround was to just use the 4.10
 restore binary. I'm in the process of upgrading to 5.2.1-RELEASE, I'll post
 another update if I notice different behavior with it.
 
 I hope this information is helpful.
 --Paul
 
 Paul's Fone Company           http://www.palas.com         corwin@palas.com
  Terabit routing, Peering, Metro Ethernet, Content Networking, CCIE
 
 
>Unformatted:
