dump-users

[Dump-users] exabyte 8500 parameters

[Greg T. <eve...@us...>]

what are reasonable values for blocksize, density, and feet for one of
these?  i have a legacy dumping script that uses 126, 54000, and 13000,
respectively, but none of those numbers make sense to me.  are density and
feet only used by dump to calculate how much data it can shove on a tape?
should i just use "-a" rather than try to figure them out?

blocksize: what value should i be using?  does it matter?  will i get better
throughput to the tapes if i pick some magic blocksize that's just right for
this drive?

density: i'm using mt to set the density code for the drive to 21 (0x15),
but i can't find anyplace that'll tell me what that corresponds to in bpi.

length: even though exabyte recommends against it, i'm using 160m XL tapes.
if m stands for meters, then that works out to just shy of 525 feet, which
is nowhere near the 13000 that someone put in this old script i'm using.
what's up with that?

any help would be appreciated.
--
		-greg

[Dump-users] [Fwd: Linux dump strikes again]

[Bernhard E. <be...@be...>]

-------- Original Message --------
Subject: Linux dump strikes again
Date: Tue, 29 Feb 2000 16:19:15 -0800 (PST)
From: ve...@pi...
To: ama...@am...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

For all you using linux dump, you may wish to examine this advisory.

Ian Turner

- ---------- Forwarded message ----------
Date: Mon, 28 Feb 2000 15:17:33 +0900
From: "±è¿ëÁØ KimYongJun (99Á¹¾÷)" <s9...@CE...>
To: BU...@SE...
Subject: [ Hackerslab bug_paper ] Linux dump buffer overflow

[ Hackerslab bug_paper ] Linux dump buffer overflow


File   :   /sbin/dump

SYSTEM :   Linux


INFO :


The problem occurs when it gets the argument.
It accepts the argument without checking out its length, and this causes
the problem.

It seems that this vulnerability also applies to RedHat Linux 6.2beta,
the latest version.


[loveyou@loveyou SOURCES]$ dump  -f a `perl -e 'print "x" x 556'`
  DUMP: Date of this level 0 dump: Mon Feb 28 14:45:01 2000
  DUMP: Date of last level  dump: the epoch
  DUMP: Dumping
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
to a
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx:
ÆÄÀÏ À̸§ÀÌ ³Ê¹« ±é´Ï´Ù while opening filesystem
  DUMP: SIGSEGV: ABORTING!
Segmentation fault

[loveyou@loveyou SOURCES]$ dump  -f a `perl -e 'print "loveyou" x 556'`
  DUMP: SIGSEGV: ABORTING!
Segmentation fault    <=  occur ctime4()


How to fix
- ----------

patch :

[root@loveyou SOURCES]# diff -ru dump-0.4b13/dump/main_orig.c
dump-0.4b13/dump/main.c
- --- dump-0.4b13/dump/main_orig.c        Mon Feb 28 14:40:01 2000
+++ dump-0.4b13/dump/main.c     Mon Feb 28 14:40:57 2000
@@ -273,6 +273,9 @@
                exit(X_STARTUP);
        }
        disk = *argv++;
+        if ( strlen(disk) > 255 )
+           exit(X_STARTUP);
+
        argc--;
        if (argc >= 1) {
                (void)fprintf(stderr, "Unknown arguments to dump:");



hot fix :
it  is recommended that  the suid bit is
removed from dump using command :

    chmod a-s /sbin/dump




- - Yong-jun, Kim -
e - mail : lo...@ha...       s9...@ce...
homepage : http://www.hackerslab.org    http://ce.hannam.ac.kr/~s96192
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4vGIGfn9ub9ZE1xoRAoA/AJ9cF2bJ/54bE8DIKxohksb490gW9wCgl8n/
WALe173AdzxWlZlOqaOG4zY=
=Uj8c
-----END PGP SIGNATURE-----

Re: [Dump-users] Cannot open output<?>

[Stelian P. <po...@cy...>]

On Mon, 28 Feb 2000 cco...@sw... wrote:

> I'm curious to know what the "Cannot open output..." line means, as well as why dumps would run sporadically.

This message occures when dump was not able to open(2) the
device. This could mean that you had no tape in drive, your
tape driver was not ready (not loaded if it's a kernel module),
maybe device permissions etc.

As for the 'sporadic' dumps, I don't understand what you mean...

> Also, can anyone point me to the algorithm for determining the magic incantations for blocksize, length and data density?

The blocksize, density etc are related to device capabilities. 
Old tape devices worked in fixed block and gap size, and you 
had to choose those values really well in order to really use
the capacity of the tape.

This is no longer true, so you are probably safe with -B if you
want to specify your tape size or -a if you want dump to 
automatically guess it.

Stelian.
-- 
    /\ 
   /  \     Stelian Pop
  / DS \                        Email: po...@cy...
  \____/ 

[Dump-users] Cannot open output<?>

[<cco...@sw...>]

When running a dump:

# /sbin/dump 0bdsf 64 61000 12676 /dev/nst0 /
  DUMP: Date of this level 0 dump: Mon Feb 28 09:38:51 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/sda1 (/) to /dev/nst0
  DUMP: Label: none
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 64368 tape blocks on 0.01 tape(s).
  DUMP: Cannot open output "/dev/nst0".
  DUMP: Do you want to retry the open?: ("yes" or "no") no
  DUMP: The ENTIRE dump is aborted.

I'm curious to know what the "Cannot open output..." line means, as well as why dumps would run sporadically.

Tapes which have been successfully dumped in the past are restore-able, but when I try to run a dump, dump fails as above.

Also, can anyone point me to the algorithm for determining the magic incantations for blocksize, length and data density?

Thanks in advance,

chris couples

Re: [Dump-users] Multi volume dump problems

[Mark D. <dru...@rm...>]

On Wed, Feb 23, 2000 at 12:42:49PM +0100, Stelian Pop wrote:
> 
> The problem seems to be that the first tape was done 
> at a moment when your computer was running at a greater
> speed that at the moment when you did the second tape (the
> day after). Why, I don't know, but maybe you were doing 
> something which slowed down your computer (or your disk) - 
> a cron or something - on that particular morning. 

I was actually testing my backup script, and doing a full,
level 0 dump of my filesystems. The first tape was not yet complete
when I left for home. The next morning I can in and changed tapes.
That's when this started happening. There is not really much in my
crontab, just updatedb at 0:23, makewhatis at 0:03, updaterootns
(updates my list of root nameservers) and 0:33, uprecord (logs my
machines uptime "record" at 7:00.

I will try doing another level 0 dump right now, hopefully it will
complete before my workday is out.

-- 
______________________________________________________
Mark Drummond|ICQ#19153754|mailto:mar...@rm...
         Gang Warily|http://signals.rmc.ca/
Kingston Linux Users Group|http://signals.rmc.ca/klug/

Re: [Dump-users] Multi volume dump problems

[Stelian P. <st...@ca...>]

On Tue, 22 Feb 2000, Mark E. Drummond wrote:

> I am in the process of doing a multi volume level 0 dump of my Linux box
> (Slack 7, kernel 2.2.14). The first tape went just fine, But the second
> tape "finished in" time is actually _increasing_!! Here is the dump
> output:
> 

Well, I made some tests just to be sure and I don't think this 
is actually a bug in dump...

The problem seems to be that the first tape was done 
at a moment when your computer was running at a greater
speed that at the moment when you did the second tape (the
day after). Why, I don't know, but maybe you were doing 
something which slowed down your computer (or your disk) - 
a cron or something - on that particular morning. 

The estimation is done (as all estimations) considering that
the speed would remain constant. In your case, this doesn't
seem to be the case.

This could be confirmed if I knew the end of your dump. If
it really made 4 hours or more to complete the dump, than
I'm right. On the contrary, if it made only 1h45 to complete
the dump, than someting is wrong in the estimation code.

If you really thinks that you encountered a bug, I could
use some more information about your system (see 
REPORTING-BUGS).

Stelian.

> DUMPING /dev/hda6 ...
>   DUMP: Date of this level 0 dump: Mon Feb 21 17:50:50 2000
>   DUMP: Date of last level 0 dump: the epoch
>   DUMP: Dumping /dev/hda6 (/home/ftp) to /dev/nst0
>   DUMP: Label: none
>   DUMP: mapping (Pass I) [regular files]
>   DUMP: mapping (Pass II) [directories]
>   DUMP: estimated 1543170 tape blocks.
>   DUMP: Volume 1 started at: Mon Feb 21 17:50:59 2000
>   DUMP: dumping (Pass III) [directories]
>   DUMP: dumping (Pass IV) [regular files]
>   DUMP: 3.30% done, finished in 2:26
>   DUMP: 6.56% done, finished in 2:22
>   DUMP: 9.48% done, finished in 2:23
>   DUMP: 12.39% done, finished in 2:21
>   DUMP: 15.32% done, finished in 2:18
>   DUMP: 18.23% done, finished in 2:14
>   DUMP: 21.15% done, finished in 2:10
>   DUMP: 24.08% done, finished in 2:06
>   DUMP: 27.11% done, finished in 2:00
>   DUMP: 30.30% done, finished in 1:55
>   DUMP: 33.28% done, finished in 1:50
>   DUMP: 36.19% done, finished in 1:45
>   DUMP: End of tape detected
>   DUMP: Closing /dev/nst0
>   DUMP: Volume 1 completed at: Mon Feb 21 18:51:27 2000
>   DUMP: Volume 1 took 1:00:28
>   DUMP: Volume 1 transfer rate: 155 KB/s
>   DUMP: Change Volumes: Mount volume #2
>   DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes
>   DUMP: Volume 2 started at: Tue Feb 22 08:46:47 2000
>   DUMP: Volume 2 begins with blocks from inode 8197
>   DUMP: 36.45% done, finished in 1:45
>   DUMP: 36.47% done, finished in 1:54
>   DUMP: 36.53% done, finished in 2:03
>   DUMP: 36.58% done, finished in 2:13
>   DUMP: 36.63% done, finished in 2:22
>   DUMP: 36.68% done, finished in 2:31
>   DUMP: 36.73% done, finished in 2:40
>   DUMP: 36.79% done, finished in 2:50
>   DUMP: 36.84% done, finished in 2:59
>   DUMP: 36.89% done, finished in 3:08
>   DUMP: 36.94% done, finished in 3:17
>   DUMP: 37.00% done, finished in 3:26
>   DUMP: 37.05% done, finished in 3:35
>   DUMP: 37.10% done, finished in 3:44
>   DUMP: 37.15% done, finished in 3:53
>   DUMP: 37.20% done, finished in 4:02
>   DUMP: 37.26% done, finished in 4:11
>   DUMP: 37.31% done, finished in 4:20
> 
> Is this a known bug?
> 
> -- 
> ______________________________________________________
> Mark Drummond|ICQ#19153754|mailto:mar...@rm...
>          Gang Warily|http://signals.rmc.ca/
> Kingston Linux Users Group|http://signals.rmc.ca/klug/
> 
> _______________________________________________
> Dump-users mailing list
> Dum...@li...
> http://lists.sourceforge.net/mailman/listinfo/dump-users
> 

-- 
Stelian Pop <sp...@ca...>| 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")

Re: [Dump-users] File permissions for dump

[Stelian P. <st...@ca...>]

On Wed, 23 Feb 2000, Bernhard Erdmann wrote:

> $ ll /sbin/dump
> -rwsr-sr-x   1 root     tty         42052 Feb 13 12:35 /sbin/dump
> 
> Isn't this a major security hole if anyone can run dump?
> It is currently done by the RPM's Spec-File.
> Why group tty? What is the reason for it?

Dump drops the root priviledges as soon as it has 
successfully called rcmd (for dumping to a remote tape). See
man rcmd(3) for what this is necessary.

As told in the dump man page, if you are doing only local backups,
or if you use RSH environment variable to specify the external
remote shell program, you don't need to suid the executable.

Of course, you need also read permission on the disk to
backup, and this is why dump has the sgid bit set. It 
shoud be in the same group as the disk devices (group 'disk'
on RedHat Linux, maybe on others too?). 

Stelian.

-- 
Stelian Pop <sp...@ca...>| 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")

[Dump-users] File permissions for dump

[Bernhard E. <be...@be...>]

$ ll /sbin/dump
-rwsr-sr-x   1 root     tty         42052 Feb 13 12:35 /sbin/dump

Isn't this a major security hole if anyone can run dump?
It is currently done by the RPM's Spec-File.
Why group tty? What is the reason for it?

[Dump-users] Multi volume dump problems

[Mark E. D. <dru...@rm...>]

I am in the process of doing a multi volume level 0 dump of my Linux box
(Slack 7, kernel 2.2.14). The first tape went just fine, But the second
tape "finished in" time is actually _increasing_!! Here is the dump
output:

DUMPING /dev/hda6 ...
  DUMP: Date of this level 0 dump: Mon Feb 21 17:50:50 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/hda6 (/home/ftp) to /dev/nst0
  DUMP: Label: none
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 1543170 tape blocks.
  DUMP: Volume 1 started at: Mon Feb 21 17:50:59 2000
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 3.30% done, finished in 2:26
  DUMP: 6.56% done, finished in 2:22
  DUMP: 9.48% done, finished in 2:23
  DUMP: 12.39% done, finished in 2:21
  DUMP: 15.32% done, finished in 2:18
  DUMP: 18.23% done, finished in 2:14
  DUMP: 21.15% done, finished in 2:10
  DUMP: 24.08% done, finished in 2:06
  DUMP: 27.11% done, finished in 2:00
  DUMP: 30.30% done, finished in 1:55
  DUMP: 33.28% done, finished in 1:50
  DUMP: 36.19% done, finished in 1:45
  DUMP: End of tape detected
  DUMP: Closing /dev/nst0
  DUMP: Volume 1 completed at: Mon Feb 21 18:51:27 2000
  DUMP: Volume 1 took 1:00:28
  DUMP: Volume 1 transfer rate: 155 KB/s
  DUMP: Change Volumes: Mount volume #2
  DUMP: Is the new volume mounted and ready to go?: ("yes" or "no") yes
  DUMP: Volume 2 started at: Tue Feb 22 08:46:47 2000
  DUMP: Volume 2 begins with blocks from inode 8197
  DUMP: 36.45% done, finished in 1:45
  DUMP: 36.47% done, finished in 1:54
  DUMP: 36.53% done, finished in 2:03
  DUMP: 36.58% done, finished in 2:13
  DUMP: 36.63% done, finished in 2:22
  DUMP: 36.68% done, finished in 2:31
  DUMP: 36.73% done, finished in 2:40
  DUMP: 36.79% done, finished in 2:50
  DUMP: 36.84% done, finished in 2:59
  DUMP: 36.89% done, finished in 3:08
  DUMP: 36.94% done, finished in 3:17
  DUMP: 37.00% done, finished in 3:26
  DUMP: 37.05% done, finished in 3:35
  DUMP: 37.10% done, finished in 3:44
  DUMP: 37.15% done, finished in 3:53
  DUMP: 37.20% done, finished in 4:02
  DUMP: 37.26% done, finished in 4:11
  DUMP: 37.31% done, finished in 4:20

Is this a known bug?

-- 
______________________________________________________
Mark Drummond|ICQ#19153754|mailto:mar...@rm...
         Gang Warily|http://signals.rmc.ca/
Kingston Linux Users Group|http://signals.rmc.ca/klug/

Re: [Dump-users] Dump for ext3

[Stelian P. <po...@cy...>]

On Thu, 17 Feb 2000, Bernhard Erdmann wrote:

> Does anyone know anything about dump for ext3?
> 

As ext3 is the same filesystem as ext2, dump can
also dump ext3 filesystems (although you may need 
to declare a #define ...EXT3... something in
dump/traverse.c manually, if I remember well).

Stelian.
-- 
    /\ 
   /  \     Stelian Pop
  / DS \                        Email: po...@cy...
  \____/ 

[Dump-users] Re: dump performance

[Bernhard E. <be...@be...>]

Here some of my results... (System is an AMD K6-233, harddisk
IBM-DJNA-372200, Red Hat Linux 6.1, dump 0.4b14-1)

To another partition on the same physical drive:

# /sbin/dump 0sf 100000 home-200002171500.dump /home/
  DUMP: Date of this level 0 dump: Thu Feb 17 15:01:41 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/hdc14 (/home) to home-200002171500.dump
  DUMP: Label: none
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 847938 tape blocks on 0.50 tape(s).
  DUMP: Volume 1 started at: Thu Feb 17 15:01:44 2000
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 89.80% done, finished in 0:00
  DUMP: DUMP: 860256 tape blocks on 1 volumes(s)
  DUMP: finished in 333 seconds, throughput 2583 KBytes/sec
  DUMP: Volume 1 completed at: Thu Feb 17 15:07:17 2000
  DUMP: Volume 1 took 0:05:33
  DUMP: Volume 1 transfer rate: 2583 KB/s
  DUMP: DUMP: Date of this level 0 dump: Thu Feb 17 15:01:41 2000
  DUMP: DUMP: Date this dump completed:  Thu Feb 17 15:07:17 2000
  DUMP: DUMP: Average transfer rate: 2583 KB/s
  DUMP: Closing home-200002171500.dump
  DUMP: DUMP IS DONE

To /dev/null:

# /sbin/dump 0sf 100000 /dev/null /home 
  DUMP: Date of this level 0 dump: Thu Feb 17 15:44:53 2000
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/hdc14 (/home) to /dev/null
  DUMP: Label: none
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 848032 tape blocks on 0.50 tape(s).
  DUMP: Volume 1 started at: Thu Feb 17 15:44:57 2000
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: DUMP: 860411 tape blocks on 1 volumes(s)
  DUMP: finished in 127 seconds, throughput 6774 KBytes/sec
  DUMP: Volume 1 completed at: Thu Feb 17 15:47:04 2000
  DUMP: Volume 1 took 0:02:07
  DUMP: Volume 1 transfer rate: 6774 KB/s
  DUMP: DUMP: Date of this level 0 dump: Thu Feb 17 15:44:53 2000
  DUMP: DUMP: Date this dump completed:  Thu Feb 17 15:47:04 2000
  DUMP: DUMP: Average transfer rate: 6774 KB/s
  DUMP: Closing /dev/null
  DUMP: DUMP IS DONE

[Dump-users] Dump for ext3

[Bernhard E. <be...@be...>]

Does anyone know anything about dump for ext3?

Re: [Dump-users] dump performance

[Eros A. <er...@la...>]

Stelian Pop wrote:
> 
> Playing with the blocksize parameter (-b) can dramatically improve
> the transfer rate (since dump always writes data - to the remote or

I am wondering if there is something wrong with my systems (either local or
remote, although when I do a dump on the system that has the tape  and when a
dump to /dev/null I obtain the same figures as when I write through the net). 
I have:

dump  (-b default)
  DUMP: DUMP: 2569003 tape blocks on 1 volumes(s)
  DUMP: finished in 3595 seconds, throughput 714 KBytes/sec
  DUMP: Volume 1 completed at: Sun Feb 13 00:43:07 2000
  DUMP: Volume 1 took 1:00:00
  DUMP: Volume 1 transfer rate: 713 KB/s

dump  -b 32
  DUMP: DUMP: 2565411 tape blocks on 1 volumes(s)
  DUMP: finished in 5388 seconds, throughput 476 KBytes/sec
  DUMP: Volume 1 completed at: Sun Feb 13 18:22:40 2000
  DUMP: Volume 1 took 1:29:54
  DUMP: Volume 1 transfer rate: 475 KB/s
  DUMP: DUMP: Date of this level 0 dump: Sun Feb 13 16:52:17 2000
  DUMP: DUMP: Date this dump completed:  Sun Feb 13 18:22:40 2000
  DUMP: DUMP: Average transfer rate: 475 KB/s

dump  -b 64
  DUMP: DUMP: 2565670 tape blocks on 1 volumes(s)
  DUMP: finished in 5212 seconds, throughput 492 KBytes/sec
  DUMP: Volume 1 completed at: Sun Feb 13 19:50:42 2000
  DUMP: Volume 1 took 1:26:52
  DUMP: Volume 1 transfer rate: 492 KB/s

dump  -b 2
  DUMP: DUMP: 2565542 tape blocks on 1 volumes(s)
  DUMP: finished in 3064 seconds, throughput 837 KBytes/sec
  DUMP: Volume 1 completed at: Mon Feb 14 10:01:29 2000
  DUMP: Volume 1 took 0:51:04
  DUMP: Volume 1 transfer rate: 837 KB/s
-- 
Eros Albertazzi
CNR-LAMEL, Via P.Gobetti 101, 40129 Bologna, Italy  
Tel: (+39)-051-639 9179
Fax: (+39)-051-639 9216
E-mail: er...@la...

Re: [Dump-users] dump performance

[Stelian P. <po...@cy...>]

On Sun, 13 Feb 2000, Eros Albertazzi wrote:

> I am using dump to write to a remote tape and I am surprise of the low transfer
> rate I have.
> I am wondering if I am right and if this is cause by the program itself.
> What, if any, steps can be taken to improve?  

Playing with the blocksize parameter (-b) can dramatically improve
the transfer rate (since dump always writes data - to the remote or
local tape - in chunks of size equals to the blocksize parameter). 
I use myself -b 32 (instead of the default, which is 10).

Of course, this can also slow down a bit the traffic on your local
net, but you are the one who decide what you want...

Stelian.

-- 
    /\ 
   /  \     Stelian Pop
  / DS \                        Email: po...@cy...
  \____/ 

[Dump-users] dump performance

[Eros A. <er...@la...>]

I am using dump to write to a remote tape and I am surprise of the low transfer
rate I have.
I am wondering if I am right and if this is cause by the program itself.
What, if any, steps can be taken to improve?  

I have dump-0.4b14-1 on a RH 6.1 x86 w/ide disks.
The remore tape is a SCSI-2 UltraWide Sony SDT-10000 ( transfer rate
non-compressed 2.4 MB/s) attached to a Alpha XP1000 workstation.
Both machine have fast ethernet connected to a 3Com switch.

Here is what I got:
  DUMP: DUMP: 2569003 tape blocks on 1 volumes(s)
  DUMP: finished in 3595 seconds, throughput 714 KBytes/sec
  DUMP: Volume 1 completed at: Sun Feb 13 00:43:07 2000
  DUMP: Volume 1 took 1:00:00
  DUMP: Volume 1 transfer rate: 713 KB/s

Yhanks for any hints.
-- 
Eros Albertazzi
CNR-LAMEL, Via P.Gobetti 101, 40129 Bologna, Italy  
Tel: (+39)-051-639 9179
Fax: (+39)-051-639 9216
E-mail: er...@la...

Re: [Dump-users] dump 0.4b13 and $(DESTDIR)

[Stelian P. <po...@cy...>]

On Mon, 7 Feb 2000, Ambrose Li [EDP] wrote:

> What is the supposed semantics of $(DESTDIR) in the dump Makefiles?

Good question :)

To be honest, when I started maintaining dump, I found the dump makefiles 
very confusing so I didn't change anything inside (as long as it worked)...

> I tried to use $(DESTDIR) but found that what it does is very strange.
> Can someone more knowledgeable look at the attached patch and see if
> this is more like what is intended?

Looking at the makefiles I found that all the configure standard paths
seems to be ignored (such as --sbindir or --mandir).

Maybe the right way to do that is to review all the configure/MCONFIG/Makefile
stuff and make something that really works...

If you're interested, I'd be happy to get your contribution. Or maybe
someone else wants to have a sleepless night? :)

Stelian.

-- 
    /\ 
   /  \     Stelian Pop
  / DS \                        Email: po...@cy...
  \____/ 

[Dump-users] dump 0.4b13 and $(DESTDIR)

[Ambrose Li [EDP] <ac...@mi...>]

What is the supposed semantics of $(DESTDIR) in the dump Makefiles?
I tried to use $(DESTDIR) but found that what it does is very strange.
Can someone more knowledgeable look at the attached patch and see if
this is more like what is intended?

(In particular, I notice the following "problems", or perhaps it's
something wrong with my understanding of how $(DESTDIR) means:

- $(DESTDIR) is only used for links (ln -s), but the way it is used
  results in absolute links to places that may not ultimately exist
  (assuming my understanding of what $(DESTDIR) is for is correct)
  In particular, the interpretation of $(MLINKS) in the install
  target results in unsatisfied symlinks if $(DESTDIR) is nonempty

- In other places $(DESTDIR) seems to be completely ignored)


Thanks,
-- 
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

Re: [Dump-users] dump and restore mini HOWTO (in Japanese)

[Stelian P. <po...@cy...>]

On Sun, 23 Jan 2000, FUKUSHIMA Osamu wrote:

> I wrote and exhibit a document called "Linux: dump and restore mini HOWTO".
> 
>   http://www.linux.or.jp/JF/JFdocs/dump-restore-mini-HOWTO.html
>   (Japanese version)

I looked at it, and although I didn't understand the text :), I found that
the graphics and links you propose very interesting. 

This must be a high quality document, the kind of document that dump
is really missing (several users asked for more documentation about dump,
especially concerning the tape size/density tuning parameters).

> Although it is very regrettable, that which translated this document
> into English does not exist.

I entirely agree!

> I am looking for the man who has writing work of the document of the
> English version, the French version, and the Spanish version carried 
> out together with me.

I could do the French translation, but since I don't understand Japanese,
this can be a tough job :)

> Since Japanese and a man detailed to Linux come to your acquaintance,
> supposing you carry out, please introduce surely.

Well, for instance this list is rather unpopulated (since I created it
one week ago), but I'm sure that sooner or later, someone will read this
message and decide to do a good job for the dump community.

Thanks to you and thanks to him.

Stelian.
-- 
    /\ 
   /  \     Stelian Pop
  / DS \                        Email: po...@cy...
  \____/ 

[Dump-users] dump and restore mini HOWTO (in Japanese)

[FUKUSHIMA O. <fu...@am...>]

Hi all,

I'm FUKUSHIMA Osamu. dump/restore is a very important tool for me.
It considers very joyfully that development work of dump/restore was
succeeded to by Stelian Pop.

I wrote and exhibit a document called "Linux: dump and restore mini HOWTO".

  http://www.linux.or.jp/JF/JFdocs/dump-restore-mini-HOWTO.html
  (Japanese version)

Although it is very regrettable, that which translated this document
into English does not exist.

As for English composition, I myself do not have the schedule which
is not not much its favorite and to which it carries out and 
translation in other languages is performed, either.

I am looking for the man who has writing work of the document of the
English version, the French version, and the Spanish version carried 
out together with me.

Since Japanese and a man detailed to Linux come to your acquaintance,
supposing you carry out, please introduce surely.

Regards,

-- 
FUKUSHIMA, Osamu.  from Tokyo, Japan.