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 746844
Summary: | files in gdk-pixbuf2 are corrupted when installing from F16 Final TC1 x86_64 desktop live image, any app that uses gtk segfaults on run, system boots to black screen | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Williamson <awilliam> |
Component: | anaconda | Assignee: | Brian Lane <bcl> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 16 | CC: | anaconda-maint-list, bcl, dmalcolm, flokip, gholms, ivazqueznet, jonathan, jonathansteffan, mgracik, os, rhughes, robatino, vanmeeuwen+fedora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Unspecified | ||
Whiteboard: | abrt_hash:ea9b1386b1f5a63406257436231978e7ca58a966 | ||
Fixed In Version: | anaconda-16.22-1.fc16 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2011-10-20 04:03:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 713568 | ||
Attachments: |
Description
Adam Williamson
2011-10-17 22:57:25 UTC
Created attachment 528667 [details]
File: coredump
Created attachment 528668 [details]
File: maps
Created attachment 528669 [details]
File: backtrace
This is the 'F16 Final TC1 x86_64 hangs at a black screen after install from live image' bug. It's not in firstboot as lots of stuff crashes with a traceback in ld-2.14.90.so - firstboot, im-settings-daemon, gnome-session, whatever. just after the first boot you have crashes in firstboot, gtk-update-icon-cache, and fprintd. Taking a shot at glibc, but not really sure what's going wrong. Doesn't seem to affect i686, that works okay. *** Bug 746509 has been marked as a duplicate of this bug. *** Proposing as final blocker: this renders x86_64 live installs useless. Current nightly has the same problem, so this isn't some one-off problem in the TC1 compose. x86_64 DVD install works fine. Just tested TC1 x86_64 LXDE live and it worked. *** Bug 746529 has been marked as a duplicate of this bug. *** Just noting that bug 746529 affected both i686 and x86_64, so if it's the same bug, then this affects both arches. I'm not entirely convinced about that. It's clearly the same bug - check the abrt reports in /var/log/messages - but it definitely doesn't hit i686 for me. May have been human error somewhere in that test. Just a "me too" on a clean Lenovo T510. Blocker with flashing lights IMO. Looking at attachment 528669 [details], I see /usr/bin/firstboot (implemented in Python) is attempting to "import gtk". In frames 12 and below it is importing gtk._gtk i.e. dynamically loading this shared library:
/usr/lib64/python2.7/site-packages/gtk-2.0/gtk/_gtk.so
From frame 7 and below, we're inside __dlopen(), and something is going badly wrong. Am attempting to reproduce.
according to rpm -Va, some files in gdk-pixbuf2 have an md5sum mismatch, and indeed, 'yum reinstall gdk-pixbuf2' seems to fix the bug. 2011-10-18 nightly - http://koji.fedoraproject.org/koji/taskinfo?taskID=3440929 - is not affected by the bug. (remember, 2011-10-16 nightly *was* affected by the bug). Okay, it seems like the files get corrupted *before* you ever boot the installed system - so during the installation process, somehow. The correct sha256sum for /usr/lib64/libgdk_pixbuf_xlib-2.0.so.0.2400.0 is 65975d97a3f17b63137454086750665fb6d2f5195059466540ef4df819a4d0ba . This is what you get when booted live, and post-install on any working image. The incorrect sha256sum that you get on a 'broken' install is 8060fd8e9a5f34d3772428d9af0b1bb33e312d2f4b4e517569bebbdef45958e6 . This seems to be consistent, at least, it's been the same across two tries for me. So it's not _random_ corruption of the file. If I do an installation, then reboot back to the live image - i.e. the installed system has never been booted - mount the installed root partition to /mnt/temp and do sha256sum /mnt/temp/usr/lib64/libgdk_pixbuf_xlib-2.0.so.0.2400.0 , I get the 'bad' sha256sum. So the file is 'bad' before the installed system has ever been booted. prelink --undo refuses to run on the file, claiming it's not an ELF file, so it seems extremely unlikely prelink is involved in this. It's something happening during install. I see the same behavior: I downloaded: http://dl.fedoraproject.org/pub/alt/stage/16.TC1/Live/x86_64/Fedora-16-TC1-x86_64-Live-Desktop.iso and ran it. I verified that "import gtk" worked successfully. I then tried to install it to the disk, and ran into these issues. On this box, the broken library has the same incorrect sha256sum as reported in comment #17: [root@F16-TC1-From-LiveDVD ~]# sha256sum /usr/lib64/libgdk_pixbuf_xlib-2.0.so.0.2400.0 8060fd8e9a5f34d3772428d9af0b1bb33e312d2f4b4e517569bebbdef45958e6 /usr/lib64/libgdk_pixbuf_xlib-2.0.so.0.2400.0 Created attachment 528858 [details]
Output from running eu-readelf -a /usr/lib64/libgdk_pixbuf-2.0.so.0.2400.0
eu-readelf -a on the library shows corruption
Created attachment 528859 [details]
The library itself: /usr/lib64/libgdk_pixbuf-2.0.so.0.2400.0
both gdk_pixbuf libraries are corrupted, just to be clear on that. seems like lots of files in the package are screwed. as you'd expect, on the unaffected 2011-10-18 nightly image, the files have correct sha256sums post-install. trying to figure what's the difference between affected and unaffected images. hexdump -C /usr/lib64/libgdk_pixbuf-2.0.so.0.2400.0 |less shows a long run of zeroes at the end of the file (about 7KB): ------------------------------------------------------------------------------- 00020000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00021e00 00 00 00 00 00 00 00 00 |........| 00021e08 ------------------------------------------------------------------------------- Also, # # rpm -Va gdk-pixbuf2 shows various other files with issues: 5........ /usr/lib64/libgdk_pixbuf-2.0.so.0.2400.0 5........ /usr/lib64/libgdk_pixbuf_xlib-2.0.so.0.2400.0 5........ /usr/share/locale/af/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/ar/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/as/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/ast/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/az/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/be/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/be@latin/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/bg/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/bn/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/bn_IN/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/bs/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/ca/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/ca@valencia/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/crh/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/cs/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/cy/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/da/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/de/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/dz/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/el/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/en@shaw/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/en_CA/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/io/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/mi/LC_MESSAGES/gdk-pixbuf.mo 5........ /usr/share/locale/ps/LC_MESSAGES/gdk-pixbuf.mo 5........ d /usr/share/man/man1/gdk-pixbuf-query-loaders.1.gz All of the .mo files listed above appear to be all zero-filled, with no non-zero bytes. For example: # hexdump -C /usr/share/locale/de/LC_MESSAGES/gdk-pixbuf.mo 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00005770 00 00 00 00 00 00 00 00 00 00 00 00 00 |.............| 0000577d Similarly for the manpage: # hexdump -C /usr/share/man/man1/gdk-pixbuf-query-loaders.1.gz 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000003f0 00 00 00 |...| 000003f3 # rpm -qf /usr/lib64/libgdk_pixbuf-2.0.so.0.2400.0 gdk-pixbuf2-2.24.0-1.fc16.x86_64 This file appears in Koji as: http://koji.fedoraproject.org/koji/fileinfo?rpmID=2679902&filename=/usr/lib64/libgdk_pixbuf-2.0.so.0.2400.0 which says that it has a size of 138760 bytes Comparing with the corrupt library: # ll /usr/lib64/libgdk_pixbuf-2.0.so.0.2400.0 -rwxr-xr-x. 1 root root 138760 Aug 30 18:24 /usr/lib64/libgdk_pixbuf-2.0.so.0.2400.0 shows that it does have an on-disk size of 138760 Manually downloading the rpm from Koji: $ wget http://kojipkgs.fedoraproject.org/packages/gdk-pixbuf2/2.24.0/1.fc16/x86_64/gdk-pixbuf2-2.24.0-1.fc16.x86_64.rpm $ rpmdev-extract gdk-pixbuf2-2.24.0-1.fc16.x86_64.rpm $ hexdump -C gdk-pixbuf2-2.24.0-1.fc16.x86_64/usr/lib64/libgdk_pixbuf-2.0.so.0.2400.0 > /tmp/hexdump-from-koji.txt Comparing with the corrupt library: $ hexdump -C /tmp/libgdk_pixbuf-2.0.so.0.2400.0 > /tmp/hexdump-corrupt.txt $ diff -up /tmp/hexdump-from-koji.txt /tmp/hexdump-corrupt.txt > /tmp/diff-from-koji-to-corrupt.txt Am attaching the textual diff Created attachment 528869 [details]
diff -up /tmp/hexdump-from-koji.txt /tmp/hexdump-corrupt.txt
Textual difference between hexdump of the library taken from Koji, vs the hexdump of the library on disk after install from live DVD.
This shows that the first 128KB of the file is correct, but every subsequent byte was zeroed.
gave the bug a better summary. # rpm -qf /usr/bin/liveinst anaconda-16.21-1.fc16.x86_64 Reassigning to "anaconda" in lieu of knowing exactly what's introducing the corruption. so we think liveinst is truncating files for some reason, and we think it happens even in the 'working' cases - it just happens to truncate files that aren't so obviously important. in the 'working' 2011-10-18 nightly image I see md5sum errors from rpm -Va for /usr/share/misc/magic and /usr/share/misc/magic.mgc , and they do appear to be cut off like the gdk-pixbuf2 files in the 'broken' case. bcl thinks he's nailed the bug: <bcl> adamw: truncated copy <bcl> A quick kludge is to add 1 to self.anaconda.storage.liveImage.format.currentSize <bcl> yeah, it depends on the size of the image and how close to the 1MB roundoff it falls. the core problem may be in wherever currentSize comes from, which should be fixed too, but I think it safer to just read the livefs until the end instead of depending on an exact < match. Here's an update image for this, it also includes a couple other patches since the last build of anaconda. ok, so it would be helpful to paste the url, wouldn't it? http://bcl.fedorapeople.org/updates/746844.img update looks good at a first test with the tc1 image: the installed system boots, nothing crashes, and rpm -Va shows no 'valid' md5sum errors (only files that are legitimately changed post-install). Will check with a few other images too. Looks good testing the 11-18 nightly as well: those /usr/share/misc/magic files are not truncated. so the fix is looking nice. *** Bug 746827 has been marked as a duplicate of this bug. *** anaconda-16.22-1.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/anaconda-16.22-1.fc16 16.22 looks good: installed it after booting TC1 live desktop x86_64, did an installation, installed system boots fine, nothing is corrupted. Package anaconda-16.22-1.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing anaconda-16.22-1.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-14624 then log in and leave karma (feedback). anaconda-16.22-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report. |