Description of problem: Kickstart installation F18 i686, all installation repos are on NFS, crashes at package 2539 of 3612 with message: "There was an error installing the wesnoth-data package. This is a fatal error and installation will be aborted". tail of '/tmp/tmpyito8m' file is: Installing rubygem-goocanvas-1.2.0-1.fc18.i686 (2538/3612) Installing wesnoth-data-1.10.5-3.fc18.noarch (2539/3612) error: unpacking of archive failed on file /usr/share/man/en_GB/wesnoth.6.gz;511da63c: cpio: open failed - No such file or directory Version-Release number of selected component (if applicable): anaconda 18.37.11 How reproducible: I tested it on Toshiba NTB wiht 2GB RAM and desktop PC with 1.25 GB RAM with same result - installer crashed at same package Additional info: - 'wesnoth-data' package is present and right, checksums OK - at several previous Fedora distros (surely on F13,F14,F16,F17) it was working fine - trying install it by hand with rpm from installer console at tty2, immediately after crash, with command: rpm -Uv --nodeps --root /mnt/sysimage /run/install/myupdates.nfs/wesnoth-data-1.10.5-3.fc18.noarch works fine, package is installed. - as this package is perhaps biggest from all I want to install (~ 318 MB RPM file size), I suspect there may be some insufficient memory or disk problems. - IMO error in this kind of (for system run) insignificant packages should not be fatal. Every a bit experienced user can easily correct them after install (when they will be logged somewhere - and it seems they are already). Possibility to continue with installation may be better than repeat several tens of minutes or hours new installation.
sorry, I originally report it as 'amora' bug. This has be against anaconda installer.
Please attach /tmp/syslog and /tmp/packaging.log from when the error happens to this bug report as individual, uncompressed files. Thanks.
Created attachment 698849 [details] /tmp/packaging.log
Created attachment 698851 [details] /tmp/syslog
(In reply to Frantisek Hanzlik from comment #0) ... > tail of '/tmp/tmpyito8m' file is: > Installing rubygem-goocanvas-1.2.0-1.fc18.i686 (2538/3612) > Installing wesnoth-data-1.10.5-3.fc18.noarch (2539/3612) > error: unpacking of archive failed on file > /usr/share/man/en_GB/wesnoth.6.gz;511da63c: cpio: open failed - No such file > or directory ... This is the same error message as reported in Bug 984709, Comment 13: Bug 984709 - Anaconda kickstart install fails on package dosfstools Have you tried installing with F19?
(In reply to Frantisek Hanzlik from comment #0) ... > tail of '/tmp/tmpyito8m' file is: > Installing rubygem-goocanvas-1.2.0-1.fc18.i686 (2538/3612) > Installing wesnoth-data-1.10.5-3.fc18.noarch (2539/3612) > error: unpacking of archive failed on file > /usr/share/man/en_GB/wesnoth.6.gz;511da63c: cpio: open failed - No such file > or directory ... This is a wesnoth-data packaging bug. The wesnoth-data package and the filesystem package both own /usr/share/man/en_GB/: $ rpm -qf /usr/share/man/en_GB/ filesystem-3.1-2.fc18.x86_64 wesnoth-data-1.10.5-3.fc18.noarch See: Bug 987735 - error: unpacking of archive failed on file /usr/share/man/de/man8/fatlabel.8.gz;51e5abf4: cpio: open failed - No such file or directory See also this wesnoth bug, which is CLOSED/CURRENTRELEASE: Bug 905379 - Man-pages of wesnoth are in wrong directories and not gzipped
New bug for this problem: Bug 988456 - wesnoth-data owns some man page directories
Frantisek: wesnoth-1.10.6-7.fc18 should fix this problem. Could you retest when the package becomes available in updates-testing and post karma? https://admin.fedoraproject.org/updates/wesnoth-1.10.6-7.fc18 $ sudo repoquery wesnoth-data --enablerepo=updates-testing Bug 905379 - Man-pages of wesnoth are in wrong directories and not gzipped Bug 988456 - wesnoth-data owns some man page directories
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.