Created attachment 649304 [details] journalctl output Description of problem: I tired to do a install with Beta RC1 but the installation got aborted while installing "man-pages-de". See: http://94.247.144.115/fail.png Nothing really helpful in the log.
Some notes: 1) netinstall 2) i386 3) selected gnome + "software development on the right pane" 4) language = german
We were talking about this in IRC, but to keep the info in BZ I'm repeating here. There is no traceback after the error message (or at least no libreport window).Can you attach the anaconda logs (in /tmp/) to this bug (separately with text/plain as MIME) Does this fail in the same way when doing an install without the software development group?
(In reply to comment #1) > Some notes: > > 1) netinstall > 2) i386 > 3) selected gnome + "software development on the right pane" > 4) language = german Just selecting GNOME (i.e leave the default) is enough for it to fail.
Confirmed that I can reproduce this. There's a file named /tmp/tmp4uO9US which appears to contain the backing error - it's a yum transaction log with this on the last line: "error: unpacking of archive failed on file /usr/share/man/de/man2/_exit.2.gz;50ad0e03: cpio: open failed - Datei oder Verzeichnis nicht gefunden" translates to "File or directory not found". The man-pages build is not new at all - it's from July: http://koji.fedoraproject.org/koji/buildinfo?buildID=336586 so either the copy on mirrors got messed up somehow, or something weirder is going on. /mnt/sysimage/usr/share/man/de/ appears to contain man1, man3, man5 and man8 subdirs, but no man2.
sorry, better extract is: Installation wird ausgeführt man-pages-de-0.5-7.fc18.noarch (1120/1177) error: unpacking of archive failed on file /usr/share/man/de/man2/_exit.2.gz;50ad0e03: cpio: open failed - Datei oder Verzeichnis nicht gefunden just to show the error is from man-pages-de. 'yum install man-pages-de' on a running f18 system seems to work fine.
I tried DVD installation and it worked without a glitch, but I found out that man-pages-de were not installed at all. That might be a different bug that makes DVD installation not explode as a consequence.
Created attachment 649336 [details] packaging.log (requested by dlehman)
The package itself is not corrupted. I found it in a cache dir and checked; its sha256sum - 3028e760f5bd544b7ae5d27e7dd0637deb82760f2703e30da2ee6de6dd36d1ee - matches that of the same package downloaded directly from any mirror.
man-pages-de-0.5-8.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/man-pages-de-0.5-8.fc18
I'm pretty sure I understand what's going on here now. I don't think install of man-pages-de would ever have worked from anaconda - at least recently. The reason we're only seeing this bug now is that it never used to get installed, and only sometimes does now. Prior to Beta TC8, we had https://bugzilla.redhat.com/show_bug.cgi?id=868869 - anaconda was not using the yum 'langpacks' feature to install all the packages specific to the language you're installing in, which includes man-pages-(language). So any install prior to TC8 - netinst or otherwise - would never have hit this. From TC8 onwards, langpacks install should be working. However, I'm now 99.9% confident thanks to notting's help that there's a further bug which breaks langpacks install for any install being sourced from a pungi-generated repository - so DVD installs and also netinst using a repo built by pungi (which is how we attempted to test the fix for this bug). pungi strips out the <langpacks> section from comps. As notting says: <notting> pungi assembles the comps files from all the repos it uses for the compose, and uses yum.comps.xml() to write out a merged version. unfortunately, that means every section that yum.comps doesn't specifically know about falls out So when you're doing a DVD install, or a netinst install from pungi-created repo, this bug is hidden because langpacks doesn't work and so man-pages-de does not get installed. So what I think this means is that the basic bug here is simply that man-pages-de owns some directories also owned by filesystem - that's https://bugzilla.redhat.com/show_bug.cgi?id=569392 - and this breaks installation of it via anaconda. The update from comment #9 ought to fix this, without any need for a re-spin. That's the good news. Once that update is pushed, network installs of Beta should work completely correctly - langpacks will be installed. DVD installs, however, will work, but won't be installing langpacks at all, unless we fix that with an RC2. We marked the langpack bug - 868869 - as NTH not blocker, so if we stick with that decision, we can still ship RC1 and note the langpack problem as a commonbug. I'll mark this bug as depending on 569392 and file a new bug against pungi for the langpacks borkage. Based on all the above, I'm -1 blocker for this, as currently understood.
OK, further verification for the above, I created a kickstart which does a minimal install with man-pages-de added: http://www.happyassassin.net/extras/ks-de.ks if you do an install with that kickstart against the repo at https://dl.fedoraproject.org/pub/alt/qa/18/20121121_f18b-smoke24/os/ (which is the default), which contains the fixed man-pages-de, the install completes successfully. If you do an install with that kickstart but change to 'closest mirror' for your repo, the install fails on man-pages-de. So I think we know exactly what's going on here. No respin is needed, just pushing the fixed man-pages-de to mirrors. It may be worth making this NTH and pushing the fix stable, just to make sure it gets into all network installs. Proposing as NTH. I am still -1 blocker, it seems clear no respin is needed to fix this. Oh, I filed https://bugzilla.redhat.com/show_bug.cgi?id=879030 for the pungi problem.
updated man-pages-de is currently being pushed stable, closing.
man-pages-de-0.5-8.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.