You can subscribe to this list here.
| 2000 |
Jan
(2) |
Feb
(24) |
Mar
(4) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(5) |
Oct
(4) |
Nov
|
Dec
(26) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
|
| 2003 |
Jan
(10) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2004 |
Jan
(9) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2005 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
(3) |
Jul
(4) |
Aug
(2) |
Sep
(6) |
Oct
(6) |
Nov
(17) |
Dec
(28) |
| 2006 |
Jan
(9) |
Feb
(6) |
Mar
(4) |
Apr
(2) |
May
(11) |
Jun
(22) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(6) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(6) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andreas Dilger <adilger@ho...> - 2000-02-24 21:57:04
|
Hello,
I've been using ext2 dump since way back, and I have to say it's great that
someone is maintaining it again (I had previously sent bug reports to the
Debian maintainer).
There are a couple minor things I noticed when building dump on my system:
1) even though I've done it properly before, it is not obvious when installing
e2fsprogs that you need to run "make install-libs" and not just "make
install", so it would be nice to have a note to that effect in the
configure error message for ext2fs_lib.
2) It's nice to get "PWD" when using restore in interactive mode. I have it
tied to verbose mode, but it could also just be the default mode, or have
its own "prompt" mode or something.
3) The default tape device for dump and mt are not the same.
4) I removed a bit of unused cruft.
I've included a patch which will do these things below. As I don't know
anything about autoconf, I haven't added a check for <sys/mtio.h>, which
might be a better solution than my code.
Cheers, Andreas
--- cut here ---
diff -ru dump-0.4b14/configure dump-0.4b14a/configure
--- dump-0.4b14/configure Sun Nov 21 08:39:46 1999
+++ dump-0.4b14a/configure Thu Feb 24 13:04:32 2000
@@ -1632,7 +1632,7 @@
fi
if test "$ext2fs_h" = no -o "$ext2fs_lib" = no; then
- { echo "configure: error: You need to install the Ext2fs libraries from the E2fsprogs distribution first" 1>&2; exit 1; }
+ { echo "configure: error: You need to install the Ext2fs libraries from the E2fsprogs distribution first - hint: make install-libs" 1>&2; exit 1; }
fi
for ac_func in err errx verr verrx vwarn vwarnx warn warnx realpath lchown
diff -ru dump-0.4b14/configure.in dump-0.4b14a/configure.in
--- dump-0.4b14/configure.in Sun Nov 21 08:39:46 1999
+++ dump-0.4b14a/configure.in Thu Feb 24 13:03:57 2000
@@ -226,7 +226,7 @@
AC_CHECK_HEADER(ext2fs/ext2fs.h, [ext2fs_h=yes], [ext2fs_h=no])
AC_CHECK_LIB(ext2fs, ext2fs_open, [ext2fs_lib=yes], [ext2fs_lib=no], [-lcom_err])
if test "$ext2fs_h" = no -o "$ext2fs_lib" = no; then
- AC_MSG_ERROR(You need to install the Ext2fs libraries from the E2fsprogs distribution first)
+ AC_MSG_ERROR(You need to install the Ext2fs libraries from the E2fsprogs distribution first - hint: make install-libs)
fi
dnl
diff -ru dump-0.4b14/dump/dump.h dump-0.4b14a/dump/dump.h
--- dump-0.4b14/dump/dump.h Thu Feb 24 12:45:56 2000
+++ dump-0.4b14a/dump/dump.h Thu Feb 24 12:21:15 2000
@@ -71,7 +71,6 @@
char tape[NAME_MAX]; /* name of the tape file */
char *tapeprefix; /* prefix of the tape file */
char *dumpdates; /* name of the file containing dump date information*/
-char *temp; /* name of the file for doing rewrite of dumpdates */
char lastlevel; /* dump level of previous dump */
char level; /* dump level of this dump */
int uflag; /* update flag */
diff -ru dump-0.4b14/dump/main.c dump-0.4b14a/dump/main.c
--- dump-0.4b14/dump/main.c Thu Feb 24 12:45:56 2000
+++ dump-0.4b14a/dump/main.c Thu Feb 24 12:59:41 2000
@@ -144,7 +144,6 @@
if ((tapeprefix = getenv("TAPE")) == NULL)
tapeprefix = _PATH_DEFTAPE;
dumpdates = _PATH_DUMPDATES;
- temp = _PATH_DTMP;
strcpy(labelstr, "none"); /* XXX safe strcpy. */
if (TP_BSIZE / DEV_BSIZE == 0 || TP_BSIZE % DEV_BSIZE != 0)
quit("TP_BSIZE must be a multiple of DEV_BSIZE\n");
diff -ru dump-0.4b14/dump/tape.c dump-0.4b14a/dump/tape.c
--- dump-0.4b14/dump/tape.c Thu Feb 24 12:45:56 2000
+++ dump-0.4b14a/dump/tape.c Thu Feb 24 13:00:49 2000
@@ -732,10 +732,11 @@
msg("Dumping volume %d on %s\n", tapeno, tape);
}
#ifdef RDUMP
- while ((tapefd = (host ? rmtopen(tape, 2) :
- pipeout ? 1 : open(tape, O_WRONLY|O_CREAT, 0666))) < 0)
+ while ((tapefd = (host ? rmtopen(tape, 2) : pipeout ?
+ fileno(stdout) :
+ open(tape, O_WRONLY|O_CREAT, 0666))) < 0)
#else
- while ((tapefd = (pipeout ? 1 :
+ while ((tapefd = (pipeout ? fileno(stdout) :
open(tape, O_WRONLY|O_CREAT, 0666))) < 0)
#endif
{
diff -ru dump-0.4b14/restore/interactive.c dump-0.4b14a/restore/interactive.c
--- dump-0.4b14/restore/interactive.c Fri Jan 21 03:17:41 2000
+++ dump-0.4b14a/restore/interactive.c Thu Feb 24 12:50:05 2000
@@ -337,7 +337,11 @@
* Read a command line and trim off trailing white space.
*/
do {
- fprintf(stderr, "%s > ", __progname);
+ if (vflag)
+ fprintf(stderr, "%s:%s:%s > ", __progname,
+ spcl.c_filesys, curdir[1] ? &curdir[1] : "/");
+ else
+ fprintf(stderr, "%s > ", __progname);
(void) fflush(stderr);
(void) fgets(input, BUFSIZ, terminal);
} while (!feof(terminal) && input[0] == '\n');
diff -ru dump-0.4b14/compat/include/pathnames.h dump-0.4b14a/compat/include/pathnames.h
--- dump-0.4b14/compat/include/pathnames.h Fri Jan 21 03:17:41 2000
+++ dump-0.4b14a/compat/include/pathnames.h Thu Feb 24 14:25:23 2000
@@ -42,7 +42,10 @@
#include <paths.h>
+#ifdef __linux__
+#include <sys/mtio.h>
+#define _PATH_DEFTAPE DEFTAPE
+#else
#define _PATH_DEFTAPE "/dev/st0"
-#define _PATH_DTMP "/etc/dtmp"
-#define _PATH_LOCK "/tmp/dumplockXXXXXX"
+#endif /* __linux__ */
#define _PATH_RMT "/etc/rmt" /* path on remote host */
--- cut here ---
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
|
|
From: Stelian Pop <pop@cy...> - 2000-02-18 22:35:12
|
On Fri, 11 Feb 2000, Frank Koormann wrote:
> Performing remote dumps I use ssh instead of rsh.
> However due to changes in common/dumprmt.c (1.11)
> the password is no langer transfered to the ssh
> but can be seen in plain text on the console.
>
> I don't think this is really a bug but only a
> smaller problem. Hence I am refering to this list.
Yes, I am aware of this issue, but it's not that simple
to deal with it...
The old way to handle RSH caused the rsh process (ssh in
your case) to be killed when the user pressed ^C. Dump
itself catches the signal and asks if you really want to
abort the dump. If you respond with 'no', you're out
of luck because ssh itself catched the signal and died.
So the backup will fail. This is what the patch solved.
The only way to make ssh not interpret the ^C was to
put it into a new process group, detached from the
terminal. The ^C works this way, but ssh, since it has
no more a terminal to read from, cannot ask anymore
for a password... The solution would be to make ssh
not ask for a password, using one of its RSAHosts or
RSA methods of authentificate.
Both two ways are not satisfying me, but I don't see
any either solution...
Stelian.
--
/\
/ \ Stelian Pop
/ DS \ Email: pop@...
\____/
|
|
From: Frank Koormann <archiver@db...> - 2000-02-11 15:40:57
|
This message was sent from Geocrawler.com by "Frank Koormann" <frank.koormann@...> Be sure to reply to that address. Hi Folks, I have just updated from 0.4b12 to 0.4b14. Performing remote dumps I use ssh instead of rsh. However due to changes in common/dumprmt.c (1.11) the password is no langer transfered to the ssh but can be seen in plain text on the console. I don't think this is really a bug but only a smaller problem. Hence I am refering to this list. Is there already a patch to solve this. A work around for me was to replace the file by the former version (1.08) from the 0.4b12 package. Regards, Frank Geocrawler.com - The Knowledge Archive |
|
From: Stelian Pop <stelian@ca...> - 2000-02-10 15:35:36
|
On Thu, 10 Feb 2000, Denis Gerasimov wrote:
> On Thu, 10 Feb 2000, Stelian Pop wrote:
>
> > Stelian Pop wrote:
> > Do the latest release (0.4b14) still give the same error?
>
> Stelian and others,
> I apologize for this. It was all my fault. I was playing with drive
> firmware before the failures and forgot to restore the original (working)
> firmware. dump is working fine.
You mean playing with the tape drive firmware (not the hard drive). Another user
reported a problem similar to yours, maybe it's the same cause (the bug is filled
in the sourceforge bug section).
Anyway, happy to hear it was not a dump problem..
> It does sometimes miscalculate size of the
> volume (and ends up with messages like:
Miscalculation is normal (I mean it's not perfect, it's only an approximation).
But reporting negative time counts or more than 100% it is a bug, which was fixed in
0.4b14.
Stelian.
--
Stelian Pop <spop@...>| Too many things happened today
Captimark | Too many words I don't wanna say
Paris, France | I wanna be cool but the heat's coming up
| I'm ready to kill 'cause enough is enough
PGP key available on request | (Accept - "Up To The Limit")
|
|
From: Denis Gerasimov <denis@da...> - 2000-02-10 15:26:00
|
On Thu, 10 Feb 2000, Stelian Pop wrote: > Stelian Pop wrote: > Do the latest release (0.4b14) still give the same error? Stelian and others, I apologize for this. It was all my fault. I was playing with drive firmware before the failures and forgot to restore the original (working) firmware. dump is working fine. It does sometimes miscalculate size of the volume (and ends up with messages like: DUMP: estimated 1126323 tape blocks. .... DUMP: 93.08% done, finished in 0:02 DUMP: 109.01% done, finished in 0:-3 DUMP: DUMP: 1230156 tape blocks on 1 volumes(s) but this is minor.) Dennis Gerasimov |
|
From: Stelian Pop <stelian@ca...> - 2000-02-10 13:50:27
|
On Thu, 10 Feb 2000, Rob Cermak wrote:
> Just making sure that it was native or the new ones :)
I meant native BSD dump (in order to have a dump file which has the
'reference' format...).
> I think /etc on most systems these days have all file types.
There are no devices on /etc, and maybe no hard links either... And
BSD have something that linux ext2 doesn't support: file with holes. I
don't know how to find if a file has holes in it, but it would be
interesting to see how we can deal (I mean linux restore) with such
a file ...
Stelian.
--
Stelian Pop <spop@...>| Too many things happened today
Captimark | Too many words I don't wanna say
Paris, France | I wanna be cool but the heat's coming up
| I'm ready to kill 'cause enough is enough
PGP key available on request | (Accept - "Up To The Limit")
|
|
From: Rob Cermak <cermak@IMCS.Rutgers.EDU> - 2000-02-10 13:11:28
|
Just making sure that it was native or the new ones :) I'll try and figure out the md5 checksum things. I've used them before... I think /etc on most systems these days have all file types. More later... Rob |
|
From: Stelian Pop <pop@cy...> - 2000-02-10 12:00:34
|
Stelian Pop wrote:
>
> Denis Gerasimov wrote:
> >
> > Folks,
> > I have upgraded from 0.4b4 to 0.4b13 and now I have a weird write error. I
> > use exabyte 8505XL drives (tried with two of them). The error:
> > DUMP: write error 2620 blocks into volume 1
> > DUMP: Do you want to restart?: ("yes" or "no")
>
Do the latest release (0.4b14) still give the same error?
Stelian.
--
Stelian Pop <spop@...>| Too many things happened today
Captimark | Too many words I don't wanna say
Paris, France | I wanna be cool but the heat's coming up
| I'm ready to kill 'cause enough is enough
PGP key available on request | (Accept - "Up To The Limit")
|
|
From: Stelian Pop <pop@cy...> - 2000-02-10 09:41:44
|
Stelian Pop wrote:
> Anyway, tomorrow at work I'll try more in detail the HP/UX dump,
> which seemed to me to be compatible with the Linux version (but I
> didn't check the integrity of the binary data).
I've checked it and:
- linux restore is able to read a HP/UX dump (including binary files -
although HP/UX dumps seems to be of an old dump tape format).
- the HP/UX restore coredumps when trying to read a linux dump...
I'd say that the HP/UX restore is buggy, and that linux dump/restore
is correct.
Stelian.
--
Stelian Pop <spop@...>| Too many things happened today
Captimark | Too many words I don't wanna say
Paris, France | I wanna be cool but the heat's coming up
| I'm ready to kill 'cause enough is enough
PGP key available on request | (Accept - "Up To The Limit")
|
|
From: Stelian Pop <stelian@ca...> - 2000-02-10 09:14:42
|
On Wed, 9 Feb 2000, Rob Cermak wrote:
> I'm reluctant to say my wife has a FreeBSD laptop (IBM thinkpad).
Well well well..
>
> You need some tests on that system? That is my weakest platform
> with SGI. All I can do is compile and try :)
>
> The filesystem is different, but the dump/restore code should work
> on it?
>
I don't think that the linux dump/restore code will compile any more
on FreeBSD... but this is not the point actually:
All that I would like you to do is make a dump of one of BSD's filesystems
, using the native dump, and send it to me (along with a, say md5sum of all
files, so I can test the integrity after restoring). The dump needs to be big
enough and needs to contains hard links, symlinks, devices, text files,
binary files, maybe some files with special BSD attributes (append-only,
secure deletion etc, do not know if this exists on BSD).
And second, using the native BSD restore, could you verify that you can
read a linux dump?
This is however a low priority thing... do this when you'll have some time
to spare.
Thanks.
Stelian.
--
Stelian Pop <spop@...>| Too many things happened today
Captimark | Too many words I don't wanna say
Paris, France | I wanna be cool but the heat's coming up
| I'm ready to kill 'cause enough is enough
PGP key available on request | (Accept - "Up To The Limit")
|
|
From: Rob Cermak <cermak@IMCS.Rutgers.EDU> - 2000-02-09 22:12:37
|
I'm reluctant to say my wife has a FreeBSD laptop (IBM thinkpad). You need some tests on that system? That is my weakest platform with SGI. All I can do is compile and try :) The filesystem is different, but the dump/restore code should work on it? Rob |
|
From: Stelian Pop <pop@cy...> - 2000-02-09 21:50:33
|
On Wed, 9 Feb 2000, Rob Cermak wrote:
> Patch applied : success
> Compiled on RH 6.1 (sparc)/e2fsprogs-devel-1.17-1 : success
>
> Linux to Linux:
> Dumped from sparc to tape, restore using sparc : ok
> Restored sparc dump to x86 : ok!
> Dumped from x86 to tape, restore using x86 : ok
> Restored x86 dump to sparc : ok!
>
Ok, so this is ready for the release! Thanks again for all those testings.
(but, if I believe what I read, you do like testing :) ).
> Based on the above and what I did below it looks like the Solaris
> ufsdump and ufsrestore are suspect. You can move text around, but
> heaven hold your binaries :)
Well, my problem is that I have no "reference" BSD test dumps (and
I don't have a *BSD system, unless I decinde to install one to play
with...).
So I can make no guarantee if linux dump format is really 100% compatible
with the BSD one... Some users did use that feature, and they were
reporting success, so I guess I'll have to trust them.
As for the Solaris ufsdump, I don't even know if it's the same as
FreeBSD one (although it should be...). So I don't see how we can
tell if the Solaris dump is buggy (or behaving differently), or if
the Linux dump is not correct. Both seems to do almost the same thing,
but in order to find which one is the bad guy, we will need to test
both of them with a reference FreeBSD dump.
Anyone in the audience have a Free/Net/OpenBSD machine ?
Anyway, tomorrow at work I'll try more in detail the HP/UX dump,
which seemed to me to be compatible with the Linux version (but I
didn't check the integrity of the binary data).
In an optimal world, all dumps and restores would be compatible,
but maybe this is too utopic after all.
> But the SparcLinux works like a champ -- glad to be of some help in my
> limited capacity. I'll await a new release and whip up the Sparc rpms.
Please do.
> The executable was not in the same state... Gotta watch how your
> molecules get scattered using the Enterprise transporters!
>
> I thought it was kinda cute in that I've never seen that message before.
To boldly go when no one has gone before... Maybe the restore process was
disrupted by a tachyon beam or something. O'Brian should be more careful
in the future :)
> Doing a binary compare (cmp), it dies on byte 12289.
> [root@... pkgs]# cmp ls /bin/ls
> ls /bin/ls differ: char 12289, line 25
What is amazing is that text files works, and a binary file get corrupted
only after 12000 bytes! If it had not worked at all, it would be
much simpler :)
> The Solaris box almost ran the SparcLinux dump executable (just testing
> out of curiousity) -- it ended up looking for the linux loader...
You really like to do strange things... :)
> NOTE: I don't expect x86 or sparc linux executables to run on Solaris.
I was wondering... :)
--
/\
/ \ Stelian Pop
/ DS \ Email: pop@...
\____/
|
|
From: Rob Cermak <cermak@IMCS.Rutgers.EDU> - 2000-02-09 21:10:38
|
Patch applied : success
Compiled on RH 6.1 (sparc)/e2fsprogs-devel-1.17-1 : success
Linux to Linux:
Dumped from sparc to tape, restore using sparc : ok
Restored sparc dump to x86 : ok!
Dumped from x86 to tape, restore using x86 : ok
Restored x86 dump to sparc : ok!
One more test -- as a result of the dump/restore/dump dilemma seen
using Solaris.
Acid testing:
1. Dump using x86
2. Restore using sparc
3. Dump same stuff using sparc
4. Restore using x86
5. Check executable to see if its ok to use
Acid test result: ok!
Ok, last one, reverse of last to see if x86 mangles sparc executables,
result: passed! Rock on...
Based on the above and what I did below it looks like the Solaris
ufsdump and ufsrestore are suspect. You can move text around, but
heaven hold your binaries :)
IGNORE the rest if you'd like --- the SparcLinux items work now.
Don't know if it'd be too much of a chore to figure out what is
going on to enable Solaris compatilibity with Linux. I haven't
given the Solaris/Linux emulator a try. Low priority hacking...
But the SparcLinux works like a champ -- glad to be of some help in my
limited capacity. I'll await a new release and whip up the Sparc rpms.
Rob Cermak
----------------------------------------------------------------------
Misc compatibility tests with Solaris 2.6 (ufsdump/ufsrestore):
Restored x86 linux dump to sparc Solaris 2.6 (ufsrestore) : ok
Restored sparc linux dump to sparc Solaris 2.6 (ufsrestore) : ok
Dumped from Solaris 2.6 using ufsdump --
Read using sparc linux: works? (*)
Read using x86 linux: works? (*)
(*) Looks like text files are ok, but there is some mangling of
the executable. The x86 ls that I dumped on the Solaris side
was put to tape using ufsdump and on the x86 side was restored.
The executable was not in the same state... Gotta watch how your
molecules get scattered using the Enterprise transporters!
Don't know if you want to go here or not. The results you get when
you run the restored ls is:
x86->Solaris->x86:
[root@... pkgs]# ./ls
BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 57: elf_get_dynamic_info: Assertion `! "bad dynamic
tag"' failed!
I thought it was kinda cute in that I've never seen that message before.
Doing a binary compare (cmp), it dies on byte 12289.
[root@... pkgs]# cmp ls /bin/ls
ls /bin/ls differ: char 12289, line 25
Solaris 2.6:
The Solaris box almost ran the SparcLinux dump executable (just testing
out of curiousity) -- it ended up looking for the linux loader...
magellan1{root}139: file dump
dump: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, stripped
magellan1{root}140: ./dump
dump: Cannot find /lib/ld-linux.so.2
Killed
NOTE: I don't expect x86 or sparc linux executables to run on Solaris.
|
|
From: Stelian Pop <stelian@ca...> - 2000-02-09 13:43:25
|
On Tue, 8 Feb 2000, Stelian Pop wrote:
> On Tue, 8 Feb 2000, Rob Cermak wrote:
>
> > Dumps from dumpe2fs, the file systems are the same type and block size,
> > groupings are a bit different. See information below.
>
> Ok, I'll try to debug this tomorrow...
Ok, here it is (see the attached patch, to be applied to 0.4b13).
Please test if this works, in all four directions (sparc-sparc,
x86-sparc, sparc-x86, x86-x86), and report me the results. I would
like to include this patch in the next release (which I would like to
make at the end of this week).
> > Right from the get-go the simple command dump 0S sparc on both
> > systems produce differnet results:
>
> Strange... maybe normal but worth a look at the code...
After having looked at the code this is normal, because, when dumping a
subset of a filesystem, all the entries of each directory on the path from
the root to the directory to be dumped are dumped (the contents of the entry
is not dumped, only the inode). And you had more entries like these on
the sparc filesystem that on the intel one.
Stelian.
--
Stelian Pop <spop@...>| Too many things happened today
Captimark | Too many words I don't wanna say
Paris, France | I wanna be cool but the heat's coming up
| I'm ready to kill 'cause enough is enough
PGP key available on request | (Accept - "Up To The Limit")
|
|
From: Stelian Pop <pop@cy...> - 2000-02-08 21:20:16
|
On Tue, 8 Feb 2000, Rob Cermak wrote:
> Dumps from dumpe2fs, the file systems are the same type and block size,
> groupings are a bit different. See information below.
Ok, I'll try to debug this tomorrow...
> Right from the get-go the simple command dump 0S sparc on both
> systems produce differnet results:
Strange... maybe normal but worth a look at the code...
> [Do you have the Commercial version of secureshell installed 2.0.13?
> If so, I can give you access to a 'SparcLinux' box...just send me a
> public key and we can go from there.
I still use ssh-1.2.27, for license reasons...
Ok, expect to here from me tomorrow, if all goes right. :)
Stelian.
--
/\
/ \ Stelian Pop
/ DS \ Email: pop@...
\____/
|
|
From: Rob Cermak <cermak@Rutgers.EDU> - 2000-02-08 21:03:18
|
Dumps from dumpe2fs, the file systems are the same type and block size,
groupings are a bit different. See information below.
I created a directory with a file in it...
x86:
[root@... /root]# ls -l sparc
total 4
-rw-r--r-- 1 root root 3782 Feb 8 15:38 rpm.list
sparc:
[root@... /root]# ls -l sparc
total 4
-rw-r--r-- 1 root root 3782 Feb 8 14:46 rpm.list
Right from the get-go the simple command dump 0S sparc on both
systems produce differnet results:
x86:
[root@... /root]# dump 0S sparc
49152
sparc:
[root@... /root]# dump 0S sparc
70656
I'll put the two tapedumps on the website with the sparc RPMs.
tapefile.sparc [dump 0f tapefile.sparc sparc]
tapefile.x86 [dump 0f tapefile.x86 sparc]
[Do you have the Commercial version of secureshell installed 2.0.13?
If so, I can give you access to a 'SparcLinux' box...just send me a
public key and we can go from there.
http://www.rge.com/pub/security/ssh/ssh-2.0.13.tar.gz ]
NOTES:
x86:
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 0a009856-4b1e-11d3-9035-0080c85aff68
Filesystem magic number: 0xEF53
Filesystem revision #: 0 (original)
Filesystem features: (none)
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 64512
Block count: 258016
Reserved block count: 12900
Free blocks: 89275
Free inodes: 43410
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2016
Inode blocks per group: 252
Last mount time: Mon Feb 7 13:59:58 2000
Last write time: Tue Feb 8 15:41:19 2000
Mount count: 17
Maximum mount count: 20
Last checked: Wed Oct 13 05:55:38 1999
Check interval: 15552000 (6 months)
Next check after: Mon Apr 10 05:55:38 2000
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
sparc:
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 2f24d4a0-da2d-11d3-8a8e-08002004d239
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: filetype sparse_super
Filesystem state: not clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 117856
Block count: 471200
Reserved block count: 23560
Free blocks: 86564
Free inodes: 85360
First block: 1
Block size: 1024
Fragment size: 1024
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2032
Inode blocks per group: 254
Last mount time: Mon Feb 7 13:30:04 2000
Last write time: Tue Feb 8 16:39:10 2000
Mount count: 3
Maximum mount count: 20
Last checked: Thu Feb 3 06:29:32 2000
Check interval: 15552000 (6 months)
Next check after: Tue Aug 1 07:29:32 2000
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
x86:
[root@... /root]# dump 0f tapefile.x86 sparc
DUMP: Date of this level 0 dump: Tue Feb 8 15:53:06 2000
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/hda1 (/) to tapefile.x86
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 49 tape blocks on 0.00 tape(s).
DUMP: Volume 1 started at: Tue Feb 8 15:53:06 2000
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: DUMP: 40 tape blocks on 1 volumes(s)
DUMP: finished in less than a second
DUMP: Volume 1 completed at: Tue Feb 8 15:53:06 2000
DUMP: DUMP: Date of this level 0 dump: Tue Feb 8 15:53:06 2000
DUMP: DUMP: Date this dump completed: Tue Feb 8 15:53:06 2000
DUMP: DUMP: Average transfer rate: 0 KB/s
DUMP: Closing tapefile.x86
DUMP: DUMP IS DONE
sparc:
[root@... /root]# dump 0f tapefile.sparc sparc
DUMP: Date of this level 0 dump: Tue Feb 8 16:52:55 2000
DUMP: Date of last level 0 dump: the epoch
DUMP: Dumping /dev/sda1 (/) to tapefile.sparc
DUMP: Label: none
DUMP: mapping (Pass I) [regular files]
DUMP: mapping (Pass II) [directories]
DUMP: estimated 70 tape blocks on 0.00 tape(s).
DUMP: Volume 1 started at: Tue Feb 8 16:52:55 2000
DUMP: dumping (Pass III) [directories]
DUMP: dumping (Pass IV) [regular files]
DUMP: DUMP: 54 tape blocks on 1 volumes(s)
DUMP: finished in less than a second
DUMP: Volume 1 completed at: Tue Feb 8 16:52:56 2000
DUMP: Volume 1 took 0:00:01
DUMP: Volume 1 transfer rate: 54 KB/s
DUMP: DUMP: Date of this level 0 dump: Tue Feb 8 16:52:55 2000
DUMP: DUMP: Date this dump completed: Tue Feb 8 16:52:56 2000
DUMP: DUMP: Average transfer rate: 54 KB/s
DUMP: Closing tapefile.sparc
DUMP: DUMP IS DONE
|
|
From: Stelian Pop <stelian@ca...> - 2000-02-08 12:29:07
|
On Mon, 7 Feb 2000, Ambrose Li [EDP] wrote:
> I noticed some files missing from a restore, then I noticed the
> comment about the schg flag in the linkit() code. After some
> digging around, I came up with the attached patch that at least
> allows me to do a full restore.
You're right, I included your patch in the CVS. Thanks.
As for the secure deletion flag, it is safe to zero the attributes
(as long as we are restoring them after doing the link). The link
function does not modify (or overwrite, or delete) the original,
so it should be just fine.
Stelian.
--
Stelian Pop <spop@...>| Too many things happened today
Captimark | Too many words I don't wanna say
Paris, France | I wanna be cool but the heat's coming up
| I'm ready to kill 'cause enough is enough
PGP key available on request | (Accept - "Up To The Limit")
|
|
From: Ambrose Li [EDP] <acli@mi...> - 2000-02-08 00:43:50
|
I noticed some files missing from a restore, then I noticed the
comment about the schg flag in the linkit() code. After some
digging around, I came up with the attached patch that at least
allows me to do a full restore.
Perhaps someone more familiar with the ext2 routines should take
a look at the patch and see if there is anything wrong with it.
--
Ambrose Li / +1 416 321 0088 x272 / Ming Pao Newspapers (Canada) Ltd.
/ EDP Department @ Toronto
PGP fingerprint = 945C 2CF7 001D 5F03 B026 375F C5CF A55C 9F10 8B0E
|
|
From: Stelian Pop <pop@cy...> - 2000-02-07 10:05:25
|
Denis Gerasimov wrote:
>
> Folks,
> I have upgraded from 0.4b4 to 0.4b13 and now I have a weird write error. I
> use exabyte 8505XL drives (tried with two of them). The error:
> DUMP: write error 2620 blocks into volume 1
> DUMP: Do you want to restart?: ("yes" or "no")
I never seen this kind of error before (at least nobody reported it), so I'll
go towards a hardware problem (or a software one, concerning the driver for
your tape drive).
Just a few thoughts:
- what are you using as dump's command line?
- do you have the same problem when dumping into /dev/null or a /tmp file?
- the exabyte is this a SCSI tape drive, and do you modprobe the driver
before starting to dump (or you have the module inserted automatically
when accessing to the tape).
- any driver messages in /var/log/messages ?
- is this a SMP system?
- does a tar into that tape drive works?
I made a list of questions on the web page
(http://dump.sourceforge.net/REPORTING-BUGS),
could you please report the versions of your software as indicated on that
page.
Maybe that will give me some supplementar clues...
Stelian.
--
Stelian Pop <spop@...>| Too many things happened today
Captimark | Too many words I don't wanna say
Paris, France | I wanna be cool but the heat's coming up
| I'm ready to kill 'cause enough is enough
PGP key available on request | (Accept - "Up To The Limit")
|
|
From: Denis Gerasimov <denis@da...> - 2000-02-07 06:08:43
|
Folks,
I have upgraded from 0.4b4 to 0.4b13 and now I have a weird write error. I
use exabyte 8505XL drives (tried with two of them). The error:
DUMP: write error 2620 blocks into volume 1
DUMP: Do you want to restart?: ("yes" or "no")
It repeats on different drives (all the same model), different tapes,
local (redhat 6.0 kernel 2.2.6) or remote (from mandrake 6.0 kernel 2.2.14
to redhat 6.0 kernel 2.2.6). The block number is always the same - 2620.
So I dug into the code and found out that a slave is getting a write
error. So I compiled dump with -DWRITEDEBUG, and added errno output to the
relevant printf, and I got:
.... (a lot of output snipped)
slave 2 wrote 10240
slave 0 wrote 10240
slave 1 wrote 10240
DUMP: write: Input/output error
slave 2 wrote -1
slave 2 only wrote 0 out of 10240 bytes and gave up. errno=5, Input/output
error
DUMP: write error 2620 blocks into volume 1, signal=10
DUMP: Do you want to restart?: ("yes" or "no") no
At this point I am stuck (or too tired to think about this anymore).
Any suggestions?
-- Dennis Gerasimov
|
|
From: Rob Cermak <cermak@ah...> - 2000-02-02 23:39:09
|
> > The rpms are built. The sparc dumps them fine (via tape on i386), but the > > i386 can't read them. The sparc restore reads the tape dump fine. > > I suppose that the sparc machine can read its own dumps at least, no? :) The tape drive is on a x86. Remote dump/restore works on the Sparc works. Pretty odd, but this might be good to know that it can read its incorrectly written data? I'll bet the sparc can't read a x86 dump... Its when the x86 tries to read the sparc dump. > Good. I should add a pointer on the web page to this... By the way, > on your page it should be 'rmt' instead of 'rpm' :) Got it. > Looks to me like some kind of byte swapping bug. This should be fixed, > but unfortunatelly I don't have access to a sparc... > > If you have some time, you can try to debug this. I'll start by making > two (small) file dumps, a x86 one and a Sparc one (of an empty directory, > for example), then try to figure out the differences and track down up > to the incriminated portion of code. > > Send me the two dump, and I'll also try myself to see what's happening. I'll see what I can do about getting two dumps to you; as well as a test on if the sparc can read a x86 dump. Rob |
|
From: Stelian Pop <pop@cy...> - 2000-02-02 22:04:39
|
On Wed, 2 Feb 2000, Rob Cermak wrote: > The rpms are built. The sparc dumps them fine (via tape on i386), but the > i386 can't read them. The sparc restore reads the tape dump fine. > I suppose that the sparc machine can read its own dumps at least, no? :) > Website link to sparc rpms: > http://njlug.rutgers.edu/projects/dump/index.html Good. I should add a pointer on the web page to this... By the way, on your page it should be 'rmt' instead of 'rpm' :) > Just some notes: It looks like the x86 machine tries to do the right > thing, but doesn't :) Something to add to the TODO list? I should be able > to restore to both platforms (including alpha?) seamlessly -- at least Yes, it works on alpha. It seems that the sparc doesn't write correctly the dump. > text documents. I don't expect sparc executables to run on the x86 :) > > On the i386, this is what restore shows: > > [root@... /root]# restore ivf /dev/nst0 > Verify tape and initialize maps > Tape block size is 32 > Note: Doing Byte swapping > Dump date: Tue Feb 1 20:35:07 2000 > Dumped from: the epoch > Level 0 dump of / on anole.sjrcd.org:/dev/sda1 > Label: none > Note: Doing Quad swapping > Extract directories from tape > . is not on the tape > Root directory is not on tape > abort? [yn] n > Initialize symbol table. > restore > ls Looks to me like some kind of byte swapping bug. This should be fixed, but unfortunatelly I don't have access to a sparc... If you have some time, you can try to debug this. I'll start by making two (small) file dumps, a x86 one and a Sparc one (of an empty directory, for example), then try to figure out the differences and track down up to the incriminated portion of code. Send me the two dump, and I'll also try myself to see what's happening. Thanks. Stelian. -- /\ / \ Stelian Pop / DS \ Email: pop@... \____/ |
|
From: Rob Cermak <cermak@ah...> - 2000-02-02 21:52:47
|
Hiya, The rpms are built. The sparc dumps them fine (via tape on i386), but the i386 can't read them. The sparc restore reads the tape dump fine. Website link to sparc rpms: http://njlug.rutgers.edu/projects/dump/index.html Just some notes: It looks like the x86 machine tries to do the right thing, but doesn't :) Something to add to the TODO list? I should be able to restore to both platforms (including alpha?) seamlessly -- at least text documents. I don't expect sparc executables to run on the x86 :) On the i386, this is what restore shows: [root@... /root]# restore ivf /dev/nst0 Verify tape and initialize maps Tape block size is 32 Note: Doing Byte swapping Dump date: Tue Feb 1 20:35:07 2000 Dumped from: the epoch Level 0 dump of / on anole.sjrcd.org:/dev/sda1 Label: none Note: Doing Quad swapping Extract directories from tape . is not on the tape Root directory is not on tape abort? [yn] n Initialize symbol table. restore > ls Rob Cermak -:- cermak@... -:- W: 732-932-3704 I.M.C.S. -:- Rutgers University -:- F: 732-932-3036 71 Dudley Road -:- Cook College -:- WWW: njlug. New Brunswick, NJ 08901 -:- Old Blake Hall, Rm 203 -:- .rutgers.edu |
|
From: Stelian Pop <pop@cy...> - 2000-01-29 08:18:20
|
On Fri, 28 Jan 2000, Rob Cermak wrote:
> Hi. Its me. I'm the one with the thesis to write. Just handed in a
> partial draft and taking a little break. I'd like to offer up a .rpm
> build on a SparcLinux box. If I grab the source, is there a particular
> command other than make, to build the rpm for the release? say maybe?
>
> make rpm
I have not made this automatic :)
The source includes a dump.spec file (which needs to go into the SPECS
directory). This, along with dump tarball (to be placed into the SOURCES
directory) is all you need in order to construct a source rpm, using, for
example:
rpm -ba SPECS/dump.spec
Stelian.
--
/\
/ \ Stelian Pop
/ DS \ Email: pop@...
\____/
|
|
From: Rob Cermak <cermak@ah...> - 2000-01-28 19:11:30
|
Hi. Its me. I'm the one with the thesis to write. Just handed in a partial draft and taking a little break. I'd like to offer up a .rpm build on a SparcLinux box. If I grab the source, is there a particular command other than make, to build the rpm for the release? say maybe? make rpm Needless to say, I've never created a rpm before, so any pointers would help too... I also saw and agree that the size estimate should have been bytes, but being unfamiliar with the code didn't want to change too much :) At any rate, I have used a prior version of dump/restore on a SparcLinux box to a remote i386 box with the tape drive and all was well :) Being the sparcLinux box was using an ext2 filesystem as well, it should have worked. If there are any bugs in the Sparc port, I guess I'll be glad to take a crack at the 32 bit side. I don't have a 64 bit machine to look at -- I didn't win an alpha leftover from TheLinuxStore either :( Good choice to move to dump.sourceforge.com. Rob Cermak -:- cermak@... -:- W: 732-932-3704 I.M.C.S. -:- Rutgers University -:- F: 732-932-3036 71 Dudley Road -:- Cook College -:- WWW: njlug. New Brunswick, NJ 08901 -:- Old Blake Hall, Rm 203 -:- .rutgers.edu |