Description of problem: Restore of dump level 0 succesful. Restore of level 1 causes this error: rename ./var/spool/postfix/lib/i386-linux-gnu/RSTTMP01047047 to ./var/spool/postfix/lib/x86_64-linux-gnu/libnss_dns-2.17.so rename ./var/lib/dpkg/alternatives/RSTTMP01047086 to ./var/spool/postfix/lib/x86_64-linux-gnu/libnss_files-2.17.so rename ./var/lib/logrotate/RSTTMP01047107 to ./var/spool/postfix/lib/x86_64-linux-gnu/libnss_hesiod-2.17.so rename ./var/cache/apt/archives/libjson0_0.10-1.2ubuntu2_amd64.deb to ./var/spool/postfix/lib/x86_64-linux-gnu/libnss_nisplus-2.17.so Find unreferenced names. deleteino: out of range 0 abort? [yn] n deleteino: 0 not found abort? [yn] n deleteino: out of range 0 abort? [yn] n deleteino: 0 not found abort? [yn] n deleteino: out of range 0 abort? [yn] n deleteino: 0 not found abort? [yn] n deleteino: out of range 0 abort? [yn] n deleteino: 0 not found abort? [yn] n deleteino: out of range 0 abort? [yn] n deleteino: 0 not found abort? [yn] n n ^Crestore interrupted, continue? [yn] n After the last "abort? [yn]" was answered "no", like all others, restore hangs, and CPU gets stuck at 100% load. After a dozen minutes, restore is cancelled with a SIGINT (Ctrl+C). Version-Release number of selected component (if applicable): dump i686 1:0.4-0.14.b44.fc18 How reproducible: Always (happened on two separate restores of dumps from different systems, different disks) Steps to Reproduce: 1. Create a filesystem's dump level 0 2. Modify the filesystem 3. Create the filesystem's dump level 1 4. Remake filesystem (mkfs.ext4) 5. Restore level 0 dump 6. Restore level 1 dump Actual results: Find unreferenced names. deleteino: out of range 0 abort? [yn] Expected results: No error messages; successful restore. Additional info: A bug with same symptoms was debated on http://sourceforge.net/p/dump/bugs/157/ (created on 2012-06-21) The same way to solve it (using b42 instead of later versions b43 and b44) was successfully followed: 1. dump version 1:0.4-0.14.b44.fc18 was removed; 2. dump version 1:0.4-0.6.b42.fc13 was installed; 3. restore of same dump files completed successfully.
(In reply to Alessandro Selli from comment #0) > Description of problem: > Restore of dump level 0 succesful. Restore of level 1 causes this error: > rename ./var/spool/postfix/lib/i386-linux-gnu/RSTTMP01047047 to > ./var/spool/postfix/lib/x86_64-linux-gnu/libnss_dns-2.17.so > rename ./var/lib/dpkg/alternatives/RSTTMP01047086 to > ./var/spool/postfix/lib/x86_64-linux-gnu/libnss_files-2.17.so > rename ./var/lib/logrotate/RSTTMP01047107 to > ./var/spool/postfix/lib/x86_64-linux-gnu/libnss_hesiod-2.17.so > rename ./var/cache/apt/archives/libjson0_0.10-1.2ubuntu2_amd64.deb to > ./var/spool/postfix/lib/x86_64-linux-gnu/libnss_nisplus-2.17.so > Find unreferenced names. > deleteino: out of range 0 > abort? [yn] n > deleteino: 0 not found > abort? [yn] n > deleteino: out of range 0 > abort? [yn] n > deleteino: 0 not found > abort? [yn] n > deleteino: out of range 0 > abort? [yn] n > deleteino: 0 not found > abort? [yn] n > deleteino: out of range 0 > abort? [yn] n > deleteino: 0 not found > abort? [yn] n > deleteino: out of range 0 > abort? [yn] n > deleteino: 0 not found > abort? [yn] n > n > ^Crestore interrupted, continue? [yn] n > > After the last "abort? [yn]" was answered "no", like all others, restore > hangs, and CPU gets stuck at 100% load. After a dozen minutes, restore is > cancelled with a SIGINT (Ctrl+C). > > Version-Release number of selected component (if applicable): > dump i686 1:0.4-0.14.b44.fc18 > > How reproducible: > Always (happened on two separate restores of dumps from different systems, > different disks) > > Steps to Reproduce: > 1. Create a filesystem's dump level 0 > 2. Modify the filesystem > 3. Create the filesystem's dump level 1 > 4. Remake filesystem (mkfs.ext4) > 5. Restore level 0 dump > 6. Restore level 1 dump > > Actual results: > Find unreferenced names. > deleteino: out of range 0 > abort? [yn] > > Expected results: > No error messages; successful restore. > > Additional info: > A bug with same symptoms was debated on > http://sourceforge.net/p/dump/bugs/157/ (created on 2012-06-21) > The same way to solve it (using b42 instead of later versions b43 and b44) > was successfully followed: > 1. dump version 1:0.4-0.14.b44.fc18 was removed; > 2. dump version 1:0.4-0.6.b42.fc13 was installed; > 3. restore of same dump files completed successfully. Same bug affects Debian Wheezy 7.1 as well: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714234 Same solution applies there as well: 1) remove package dump-0.4b44-1; 2) install dump-0.4b42-1 downloaded from http://it.archive.ubuntu.com/ubuntu/pool/universe/d/dump/dump_0.4b42-1_amd64.deb. Any chance this bug will get anyone's attention?
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Hi, I think this bug should be reopened. The dump package in Fedora 22, 23 and rawhide are still affected by this bug.
Damien, as I cannot verify it on my own today, I ask you to please confirm that the symptoms and workaround (installation of a b42 version package) are the same as of this bug. Thank you.
Hi. On a fresh up to date Fedora 22 installation, I download the test case found on this page : http://sourceforge.net/p/dump/bugs/157/ [root@localhost mnt]# dump dump 0.4b44 (using libext2fs 1.42.12 of 29-Aug-2014) Then run, you get an error : [root@localhost mnt]# restore -r -f /root/level0.dump [root@localhost mnt]# restore -r -f /root/level1.dump deleteino: out of range 0 abort? [yn] Downgrade to b42 version : [root@localhost mnt]# dnf install https://kojipkgs.fedoraproject.org//packages/dump/0.4/0.6.b42.fc14/x86_64/dump-0.4-0.6.b42.fc14.x86_64.rpm [root@localhost mnt]# dump dump 0.4b42 (using libext2fs 1.42.12 of 29-Aug-2014) [root@localhost mnt]# restore -r -f /root/level0.dump [root@localhost mnt]# restore -r -f /root/level1.dump No error.
Not sure why this was even closed, bit I'll go ahead and reopen it. Patch exists upstream: http://sourceforge.net/p/dump/bugs/157/ And in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714234 Will work up a patch for rawhide in a bit.
Created attachment 1076796 [details] Patch to the current rawhide package This applies the patch from http://sourceforge.net/p/dump/bugs/157/ to the current rawhide package. Petr, I would be happy to push this out to any branches you wish if that would save you time. Other folks, if you'd like a scratch build to test, just let me know.
dump-0.4-0.26.b44.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-2af91726f1
scm-commit for rawhide http://pkgs.fedoraproject.org/cgit/dump.git/commit/?id=f8c4b30243b922ed8890122188ea5edd67156019 scm-commit for F23 http://pkgs.fedoraproject.org/cgit/dump.git/commit/?h=f23&id=f8c4b30243b922ed8890122188ea5edd67156019 scm-commit for F22 http://pkgs.fedoraproject.org/cgit/dump.git/commit/?h=f22&id=f8c4b30243b922ed8890122188ea5edd67156019
dump-0.4-0.26.b44.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-f4124bf060
dump-0.4-0.26.b44.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update dump' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-f4124bf060
dump-0.4-0.26.b44.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update dump' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-2af91726f1
Cool, thanks!
Thank you for the update :)
Don't forget to test those updates and give karma. Were I the maintainer, I wouldn't push this for F22 unless at least a couple of people tested it.
dump-0.4-0.26.b44.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
dump-0.4-0.26.b44.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.