Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1373206 - dump/restore No longer work
Summary: dump/restore No longer work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: dump
Version: 24
Hardware: x86_64
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: Josef Ridky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-05 13:35 UTC by Ray Holme
Modified: 2016-10-28 19:51 UTC (History)
2 users (show)

Fixed In Version: dump-0.4-0.30.b46.fc25 dump-0.4-0.30.b46.fc23 dump-0.4-0.30.b46.fc24
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-28 00:40:10 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Ray Holme 2016-09-05 13:35:51 UTC
Description of problem: I installed dump (was standard with Fedora 22, now an addition in Fedora 24) and dumped my new system after upgrading to Fedora 24, I tried to recover a file from the dump image today. Huge amounts of "Incorrect block for <file removal list> at NNNN blocks" appear. The dump file is not usable.

Version-Release number of selected component (if applicable): 
Installed Packages
Name        : dump
Arch        : x86_64
Epoch       : 1
Version     : 0.4
Release     : 0.29.b45.fc24


How reproducible: 100% - I tried to see if restore worked on any of the file systems (root, boot, home) - same problems with each. Prior dumps made with Fedora 22 dump work fine using newer restore. Dumps from both of my 64 bit Fedora boxes made with Fedora 24 and the added dump FAIL - all 6 file systems.


Steps to Reproduce:
1. put in a mountable disk, change directory to somewhere on it
2. e.g. - boot is small so only one volume
dump -u0 -f - -A boot.toc -L boot -z2 /boot | split -b 2GB -d - boot.dmp
3. restore if boot.dmp00
other file systems require a line like the below
  cat root.dmp* | restore if -

Actual results:
Dump tape is compressed.
Incorrect block for <file removal list> at 19 blocks
Incorrect block for <file removal list> at 20 blocks
..... two thousand times
Incorrect block for <file removal list> at 2057 blocks
Incorrect block for <file removal list> at 2058 blocks
decompression error, block 2059: data error
File decompression error while restoring <file removal list>
continue? [yn] 


Expected results:
Dump tape is compressed.
restore >

Additional info: This means going back to Fedora 22 if I cannot have backups or using TAR instead of Dump (a poor choice IMHO).

Comment 1 Josef Ridky 2016-09-06 07:39:31 UTC
Thank you for reporting this bug.

This issue has been reported to upstream.

Comment 2 Ray Holme 2016-09-06 11:55:55 UTC
So for a while, I must find another way to backup systems (tar I guess) until this is fixed. boo hoo hoo

One other point, I believe I had to install a "development" version of dump a month ago due to some problem encountered at the very startup. I cannot find it in my history or I would say more.

Hope you can fix it soon. A lot of people use dump. Most of my ex-clients (retired) use scripts I wrote that depend on it.

Comment 3 Ray Holme 2016-09-07 13:48:10 UTC
Hope this helps. First I removed the pipe to split - that did nothing.
Then I remove all options EXCEPT compressing - that did nothing.
Then I removed compresssion (-z2) and the restore worked fine.

I guess I could remove this option in my scripts and get a lot more files written to the backup device. I have room for right now.

Comment 4 Josef Ridky 2016-09-08 05:07:33 UTC
(In reply to Ray Holme from comment #3)

> Then I removed compression (-z2) and the restore worked fine.

Thank you for this suggestion. It should be easier to find the issue in source code right now.

Comment 5 Ray Holme 2016-09-08 12:07:53 UTC
And I now have a work-around. :=]

dump -u0 -f - -A root.toc -L root / | gzip | split -b 2GB -d - root.dmp

 followed by

zcat root.dmp* | restore if -

WORKS!!!!!!

And by the way the "-A" option does nothing - the file generated is 0 bytes.

[ray@rainbow tmp]$ !!
ls -l /home/root*
-rw-r--r--. 1 root root 2000000000 Sep  8 08:00 /home/root.dmp00
-rw-r--r--. 1 root root 2000000000 Sep  8 08:04 /home/root.dmp01
-rw-r--r--. 1 root root  304644335 Sep  8 08:05 /home/root.dmp02
-rw-r--r--. 1 root root          0 Sep  8 07:55 /home/root.toc

:=]

Comment 6 Josef Ridky 2016-09-19 13:11:27 UTC
New update of dump is available (dump-1:0.4-0.30.b46).
You can upgrade it by following command:

sudo dnf --enablerepo=updates-testing upgrade dump

This update has expected results as mentioned in comment #1.
Please check, if is this update satisfying.

Comment 7 Josef Ridky 2016-09-19 13:13:09 UTC
I am apologize, correct is comment #0 (Expected results)

Comment 8 Ray Holme 2016-09-19 14:22:14 UTC
Interesting timing. :=]]]
I was busy copying my dump files to my son's external disk drive for an
 offsite copy and vice versa for him
So I used a local file system not the normal external one.

Anyway, I did the following test:

  cd /home; mkdir dump_test; cd dump_test
  dump -u0 -f - -A root.toc -L root -z2 / | split -b 2GB -d - root.dmp

Got:

  DUMP: Date of this level 0 dump: Mon Sep 19 10:09:35 2016
  DUMP: Dumping /dev/mapper/fedora_rainbow-root (/) to standard output
...
  DUMP: Archiving dump to (null)
  DUMP: DUMP IS DONE

[root@rainbow dump_test]# ls -l
total 5156356
-rw-r--r--. 1 root root 2000000000 Sep 19 10:12 root.dmp00
-rw-r--r--. 1 root root 2000000000 Sep 19 10:13 root.dmp01
-rw-r--r--. 1 root root 1216246296 Sep 19 10:14 root.dmp02
-rw-r--r--. 1 root root   63840256 Sep 19 10:14 root.toc

OK, you fixed the Table of Contents. Great!
[root@rainbow dump_test]# cat root.dmp* | restore if -
Dump tape is compressed.
restore > 


Looks good! This is not a very extensive test, but I could look at "/etc"
and that looks decent. I did NOT try restoring anything, but I think you got it.

Thanks and great job!!!

Ray

Comment 9 Fedora Update System 2016-09-20 05:37:17 UTC
dump-0.4-0.30.b46.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-df773b62ca

Comment 10 Fedora Update System 2016-09-20 05:38:13 UTC
dump-0.4-0.30.b46.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-efe4ccf884

Comment 11 Fedora Update System 2016-09-20 05:38:40 UTC
dump-0.4-0.30.b46.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-28c594c4a9

Comment 12 Fedora Update System 2016-10-28 00:40:10 UTC
dump-0.4-0.30.b46.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 13 Fedora Update System 2016-10-28 18:49:38 UTC
dump-0.4-0.30.b46.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 14 Fedora Update System 2016-10-28 19:51:04 UTC
dump-0.4-0.30.b46.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.


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