Created attachment 773873 [details] Used Kickstart File Description of problem: When doing an automated kickstart install the installer quits with a fatal error while installing the dosfstools package. Error Message Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/pyanaconda/packaging/yumpayload.py", line 1647, in callback pyanaconda.packaging.PayloadInstallError: cpio, unpack, or fatal script error FATAL ERROR: python callback <bound method RPMCallback.callback of <pyanaconda.p ackaging.yumpayload.RPMCallback object at 0x44cbf10>> failed, aborting! If I try to exclude dosfstools in the packages section of the kickstart the installer seems to ignore that line and try to install it anyway. It looks extremely similar to this closed bug: https://bugzilla.redhat.com/show_bug.cgi?id=865291 Version-Release number of selected component (if applicable): anaconda 18.37.11 How reproducible: Always reproducible Steps to Reproduce: 1. Start kickstart install with the attached file 2. 3. Actual results: Aborted installation Expected results: Successful installation Additional info:
Developers are probably going to want to look at the installer log files. Are you getting an exception dialog with a "Report Bug" button?
(In reply to Logan Gunnell from comment #0) ... > Version-Release number of selected component (if applicable): > anaconda 18.37.11 ... Have you tried F19?
Created attachment 774406 [details] anaconda.log
Created attachment 774407 [details] The rest of the logs in /tmp
If at all possible we would like to avoid using F19 for now. This kickstart is used for student computer labs that we maintain and it takes us some time to make sure updates don't break anything that the students need for their classes. This installation problem only started happening within the last couple of weeks or so. Before a couple of weeks ago this kickstart was working fine. The anaconda install is running in command line mode and we are not getting an option to report a bug. It just yells at me with the above python exception message and then says Pane is dead.
Created attachment 774432 [details] packaging.log
Created attachment 774433 [details] program.log
Created attachment 774434 [details] storage.log
Created attachment 774435 [details] syslog
Thanks for the logs. FYI, if you get an exception, there may be a file /tmp/anaconda-tb-* that has all the logs together. It also has the complete Python traceback. Could you attach that, if possible? (I apologize for not telling you about it earlier.) BTW, BZ usually gets the mime type wrong, so you can explicitly set it to text/plain from the Create New Attachment page. The logs can then be opened in a web browser.
Created attachment 774440 [details] Directory listing of /tmp after install fails Thanks for the tip about the mimetype. I'm unable to find any anaconda-tb* files so I've attache a directory listing of /tmp in case there are any other log files that may be helpful in there.
Created attachment 774482 [details] Screenshot showing PayloadInstallError exception I reproduced the exception in a VM using your kickstart file. Procedure: Initialize a disc image: $ qemu-img create f18-test-2.img 32G Boot the F18 installer DVD: $ qemu-kvm -m 4096 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga std -boot menu=on Append options to the kernel command line: Command line from dmesg in installer console: [ 0.000000] Command line: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2018\x20x86_64 inst.cmdline inst.loglevel=debug inst.debug=1 ks=http://mirrors.cs.byu.edu/kickstart/fedora18.ks BOOT_IMAGE=vmlinuz Wait. NB: The kernel command line options are derived from the attached syslog. I typed them in manually after removing the "quiet" option.
Created attachment 774505 [details] /tmp/tmpI6xVtP after exception This file was in /tmp after the exception: $ tail -4 tmpI6xVtP Installing libkate-0.3.8-6.fc18.x86_64 (577/3432) Installing sg3_utils-libs-1.34-1.fc18.x86_64 (578/3432) Installing dosfstools-3.0.20-2.fc18.x86_64 (579/3432) error: unpacking of archive failed on file /usr/share/man/de/man8/fatlabel.8.gz;51e5abf4: cpio: open failed - No such file or directory
Logan: Serving your kickstart file on an unencrypted connection could be a security risk, because it could be modified by a man-in-the-middle attack. It also exposes your encrypted password. $ curl -s http://mirrors.cs.byu.edu/kickstart/fedora18.ks | grep rootpw rootpw --iscrypted $6$TSLT$tyD01g5Q3Tj5i9xPC6MclQX9x1fL92VjkmW1.0rjguId8Ti9/a.AlrhwXaO.6Xry.J3ukbuOJamtSxODH0LQZ1 $ curl https://mirrors.cs.byu.edu/kickstart/fedora18.ks curl: (7) Failed connect to mirrors.cs.byu.edu:443; Connection refused Disclaimer: I am not a computer security specialist.
Steve: Thanks for the heads up. We didn't consider that. FYI, the hash above is not our really root password, just a dummy one for the bug report. Thanks for the help.
(In reply to Logan Gunnell from comment #0) ... > If I try to exclude dosfstools in the packages section of the kickstart the > installer seems to ignore that line and try to install it anyway. ... Several packages require dosfstools. Trying to remove dosfstools with "yum erase dosfstools" in an F18 VM shows there are 29 dependent packages, so that doesn't seem like a practical workaround ... $ rpm -q --whatrequires dosfstools lorax-18.31-1.fc18.x86_64 udisks-1.0.4-8.fc18.x86_64 udisks2-2.0.1-2.fc18.x86_64 python-imgcreate-18.15-1.fc18.x86_64 livecd-tools-18.15-1.fc18.x86_64
FWIW, I completed an install using the F19 installer in a VM and the unmodified kickstart file. The resulting system would boot, but hang while going multi-user. NB: For this test, the kickstart file was served over NFS. With the F18 installer, the install still failed at dosfstools. VM command-line: $ qemu-img create f19-test-3.img 32G $ qemu-kvm -m 4096 -hda f19-test-3.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on Kernel command-line: 05:53:08,853 INFO kernel:[ 0.000000] Command line: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 cmdline ks=nfs:walnut.lan:/var/tmp/kickstart/ks.cfg BOOT_IMAGE=vmlinuz
I don't know if this matters, but your URLs are missing slashes at the end, so they return a redirect. $ curl -s http://mirrors.cs.byu.edu/fedora/releases/18/Everything/x86_64/os <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://mirrors.cs.byu.edu/fedora/releases/18/Everything/x86_64/os/">here</a>.</p> <hr> <address>Apache/2.2.15 (Red Hat) Server at mirrors.cs.byu.edu Port 80</address> </body></html> $ curl -s http://mirrors.cs.byu.edu/fedora/updates/18/x86_64 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>301 Moved Permanently</title> </head><body> <h1>Moved Permanently</h1> <p>The document has moved <a href="http://mirrors.cs.byu.edu/fedora/updates/18/x86_64/">here</a>.</p> <hr> <address>Apache/2.2.15 (Red Hat) Server at mirrors.cs.byu.edu Port 80</address> </body></html>
FYI, chrony replaced ntp in F16, and it works fine: 3.8.2. Chrony Fedora 16 uses Chrony as the default Network Time Protocol (NTP) client. http://docs.fedoraproject.org/en-US/Fedora/16/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html Snippet from ks.cfg: ... ntp ntpdate ...
@printing is listed twice: $ grep printing fedora18.ks @printing @printing Fedora doesn't test with rpmfusion packages, so it might be a good idea to list non-Fedora packages in a separate section, so they can be commented out for testing purposes. I guess you are getting a kickstart code review ... :-)
Created attachment 775907 [details] ks-3.cfg installs dosfstools only (NOT A BUG -- for reference only) Installing with this kickstart file succeeds: 1. The only package explicitly installed is dosfstools. 2. The rpmfusion repos are removed. The resulting system boots to a console. Snippet from ks-3.cfg: ... %packages dosfstools %end
There is a space after the groups "@" sign for the authoring-and-publishing group: $ curl -s http://mirrors.cs.byu.edu/kickstart/fedora18.ks | grep '@ ' # a component, put them after the component (i.e. a line after "@ component") @ authoring-and-publishing
Created attachment 776115 [details] ks-reproducer-2.cfg reproduces exception with Fedora-only repos This kickstart file reproduces the exception with Fedora-only repos from kernel.org. The package list is identical to the list in the original report. If you install in graphical mode (no "cmdline" option), the installer will prompt you to continue or not for each package it cannot find. There are only 5 such packages. non-Fedora packages 5 Fedora packages 3352 dosfstools exception 539 VM command-line: $ qemu-img create f18-test-3.img 32G $ qemu-kvm -m 4096 -hda f18-test-3.img -cdrom ~/xfr/fedora/F18/Fedora-18-x86_64-DVD.iso -vga std -boot menu=on Kernel option to specify kickstart file on NFS server (the VM host): ks=nfs:walnut.lan:/var/tmp/kickstart/ks-reproducer-2.cfg
After replacing 18 with 19 in ks-reproducer-2.cfg and booting with the F19 installer DVD, the install succeeds, and, after initial setup, a desktop can be started. kdm is running, and several desktop environments can be selected. Nine non-Fedora packages were skipped, and dosfstools installed successfully. With F19: non-Fedora packages 9 Fedora packages 3276 dosfstools installed 375 (per anaconda.packaging.log) VM command-line: $ qemu-img create f19-test-3.img 32G $ qemu-kvm -m 4096 -hda f19-test-3.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on Kernel command-line from /var/log/anaconda/syslog: 08:12:24,772 INFO kernel:[ 0.000000] Command line: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20x86_64 ks=nfs:walnut.lan:/var/tmp/kickstart/ks.cfg BOOT_IMAGE=vmlinuz
Created attachment 776144 [details] [F19] /root/anaconda-ks.cfg (NOT A BUG) NB: There are no kickstart "repo" directives in this file.
Created attachment 776145 [details] [F19] /root/initial-setup-ks.cfg (NOT A BUG)
(In reply to Logan Gunnell from comment #0) ... > It looks extremely similar to this closed bug: > https://bugzilla.redhat.com/show_bug.cgi?id=865291 ... The fix for that installed an exception handler only, and, in graphical kickstart install mode with F18, a fatal error message is indeed displayed for the dosfstools exception: Bug 865291, Comment 9.
(In reply to Steve Tyler from comment #13) > Created attachment 774505 [details] > /tmp/tmpI6xVtP after exception > > This file was in /tmp after the exception: > > $ tail -4 tmpI6xVtP > Installing libkate-0.3.8-6.fc18.x86_64 (577/3432) > Installing sg3_utils-libs-1.34-1.fc18.x86_64 (578/3432) > Installing dosfstools-3.0.20-2.fc18.x86_64 (579/3432) > error: unpacking of archive failed on file > /usr/share/man/de/man8/fatlabel.8.gz;51e5abf4: cpio: open failed - No such > file or directory This bug appears to have been reported before: Bug 911877 - f18 installer isn't able install bigger packages?
Is there any sort of work around besides installing F19?
Good question. Since this can be reproduced with kernel.org alone, it does not seem to be a mirror/repo issue (Comment 23). And since dosfstools can be successfully installed in a minimal install, dosfstools does not seem to be the actual problem (Comment 21). Presumably, there is a mid-point between those two cases. The only thing I can think of is trimming the package list. Can you prioritize your packages?
One other idea would be to install one desktop with default packages and then after the install, run yum to install everything else. What post-install configuration do you currently do?
Bug 878967 is supposedly fixed with man-pages-de-0.5-8.fc18, but it does shed some light on the problem: Bug 878967 - Installation fails when selecting german language This error message (Comment 13) is unclear about which file or directory is missing, but after the failure, it can be seen that /mnt/sysimage/usr/share/man/de/ does not exist: error: unpacking of archive failed on file /usr/share/man/de/man8/fatlabel.8.gz;51e5abf4: cpio: open failed - No such file or directory Any of these variants in the kickstart file had no effect on the failure: man-pages-de -man-pages-de @german-support
(In reply to Steve Tyler from comment #30) > ... dosfstools does not seem to be the actual > problem (Comment 21). ... Maybe dosfstools is part of the problem after all: $ rpm -qf /usr/share/man/de dosfstools-3.0.20-3.fc19.x86_64 filesystem-3.2-13.fc19.x86_64 $ rpm -qf /usr/share/man/de/man8 dosfstools-3.0.20-3.fc19.x86_64 filesystem-3.2-13.fc19.x86_64 $ rpm -qf /usr/share/man/man8 dosfstools-3.0.20-3.fc19.x86_64 filesystem-3.2-13.fc19.x86_64 $ rpm -qf /usr/share/man/ filesystem-3.2-13.fc19.x86_64 $ rpm -qf /usr/share/man/it filesystem-3.2-13.fc19.x86_64 $ rpm -qf /usr/share/man/fr filesystem-3.2-13.fc19.x86_64
The dosfstools German man pages were added in F18: Packaged DE man pages committer Jaroslav Škarvada <jskarvad> 2013-06-12 08:44:21 (GMT) http://pkgs.fedoraproject.org/cgit/dosfstools.git/commit/?h=f18&id=ca784a08f2f73c1d91dc6df48001f4262cb5f19b
Bug 987735 opened against dosfstools.
(In reply to Steve Tyler from comment #35) > Bug 987735 opened against dosfstools. A fix has been submitted (Bug 987735, Comment 3): https://admin.fedoraproject.org/updates/dosfstools-3.0.22-2.fc18 This may take a few days to get through the testing process. Once it gets to updates-testing, you can test manually with: $ sudo yum update --enablerepo=updates-testing dosfstools
The dosfstools update is in updates-testing: $ sudo repoquery dosfstools --enablerepo=updates-testing dosfstools-0:3.0.22-2.fc19.x86_64 https://admin.fedoraproject.org/updates/FEDORA-2013-13562/dosfstools-3.0.22-2.fc18
I successfully completed an F18 kickstart install using the full package list[1] from this report and kernel.org for everything except the updated dosfstools[2], which I put into a local repo. kickstart repo config used for testing: repo --name=everything --baseurl=http://mirrors.kernel.org/fedora/releases/18/Everything/x86_64/os/ repo --name=cs-updates --baseurl=http://mirrors.kernel.org/fedora/updates/18/x86_64/ repo --name=repo-1 --baseurl=nfs:walnut.lan:/var/tmp/kickstart/repo-1/ [1] Excluding five non-Fedora packages. [2] dosfstools-3.0.22-2.fc18.x86_64.rpm
Logan: You could help move dosfstools into updates by testing it and then posting "karma" here (Click "Add a comment" -- you may need to register): https://admin.fedoraproject.org/updates/FEDORA-2013-13562/dosfstools-3.0.22-2.fc18
The updated dosfstools works great with our kickstart and I've submitted karma for that update. Thank you very much for all the help!
Thanks for testing and posting karma. That's very good to hear.
Since the problem was the dosfstools package, I'm marking this bug as a duplicate of the bug where the package was fixed *** This bug has been marked as a duplicate of bug 987735 ***