Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 8036 - dump -0ufB /dev/ftape 1638000 /mnt2 fails to use /mnt2 as the bkup target
dump -0ufB /dev/ftape 1638000 /mnt2 fails to use /mnt2 as the bkup target
Product: Red Hat Linux
Classification: Retired
Component: dump (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Nalin Dahyabhai
Depends On:
  Show dependency treegraph
Reported: 1999-12-28 21:34 EST by ajvincens
Modified: 2008-05-01 11:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-03-08 15:09:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description ajvincens 1999-12-28 21:34:34 EST
I have been using dump on previous Linux releases w/o a problem 2.0.32
Pentium 2 200mhz MMX, TR-3 tape drive

1.  /sbin/insmod   <path>zftape.o                 OK
2.  mt -f /dev/ftape rewind or fsf or retension   OK
3.  tar -cvf /dev/ftape /mnt2                     OK
4.  dump -0ufB /dev/ftape 1638000 /mnt2

At this point I have 2 mounted partitions:  /  = /dev/hda3    3 gig
                                            /mnt2 = /dev/hdb2 1 gig

/mnt2 contains my 2.0.32 OS. ext2 file system

dump says it's backing up /dev/hdb3 to /dev/ftape and is finished w/
nothing dump'd to tape. (about 1 minute) At first I thought it was an
ftape problem but I have no problem w/ mt and tar.  I'm not sure why it's
saying it is dumping the /dev/hda3 file system unless it isn't seeing
the /mnt2 parm and is somehow defaulting to the root file system.  I've
tried different variations of the command dump -0 -u -f /dev/ftape etc.
I've also tried loading ftape.o, but I couldn't get tar or mt to work.
Let me know if you need more info, I'd be glad to provide any info you

Comment 1 Jeff Johnson 1999-12-29 13:53:59 EST
What version of dump "rpm -q dump"? You might try the latest dump-0.4b11
from Raw Hide, as mamy bugs in dump have been fixed there.
Comment 2 ajvincens 1999-12-29 23:36:59 EST
I'm using dump 0.4b4-11.  I'll check for the new version.


Comment 3 ajvincens 1999-12-30 00:17:59 EST
I just tried dump 0.4b11-2 w/ the same results.  Seems like dump is ignoring
the last parm which is the file system to be backed up. It is trying to dump my
root file system, not /mnt2 With this version I get a write error 20 block also
that I didn't get in version 0.4b4-11.
Comment 4 Stelian Pop 1999-12-30 05:07:59 EST
Is /mnt2 is your fstab?

Does it work if you dump directly the device (dump 0f /dev/nftape /dev/hdb2)?

What tells the 'file' command applied to your (empty) dump?

Comment 5 Stelian Pop 2000-02-10 07:25:59 EST
I have reasons to believe this was fixed in the latest release of dump, 0.4b14

Could you try that one, available from http://dump.sourceforge.net and see if
your problem persists?

Comment 6 Jeff Johnson 2000-02-10 10:21:59 EST
I've built dump-0.4b14 for Red Hat 6.2. Bug should be closed as soon as it's
verified that the package fixes the bug.
Comment 7 Jeff Johnson 2000-03-08 15:09:59 EST
Did dump-0.4b1[45] from RawHide/SourceForgefix your problem?
Comment 8 Preston Brown 2000-06-27 12:12:33 EDT
closed due to lack of additional feedback.
Comment 9 David Lawrence 2000-07-03 11:55:19 EDT
email received from user by bugzilla@redhat.com

I never received the email "Did dump-0.4b1[45] from RawHide/SourceForgefix 
your problem?".   Sorry I wasn't sure how to close out the bug report. 
  Yes, it did work.  I believe I responded directly with Stelian.

Sorry for the misunderstanding.  I am very thankful for the assistance.


Note You need to log in before you can comment on or make changes to this bug.