[arch-general] ld-2.11.1.so and segfaults
Hi all, I installed arch 64-bit on my t61 this weekend, and when I try to run midori or epiphany, and some other apps as well, I get midori[16445]: segfault at 8 ip 00007f0d1093d963 sp 00007fffb6e8a1e0 error 4 in ld-2.11.1.so[7f0d10933000+1e000] and epiphany[16664]: segfault at 8 ip 00007fbe5670e963 sp 00007fffff76fc10 error 4 in ld-2.11.1.so[7fbe56704000+1e000] By doing pacman -Qo /lib/ld-2.11.1.so, I get glibc, which is at version 2.11.1-1. I've tried doing pacman -Syu, but that hasn't resolved anything. I some how think this isn't a bug, but something I'm doing wrong on my end. Any pointers on how to trouble shoot this? As a final note, heres uname -a: Linux turnstile 2.6.32-ARCH #1 SMP PREEMPT Tue Feb 9 15:12:10 CET 2010 x86_64 Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz GenuineIntel GNU/Linux Of course, any other info is also available, just let me know what might be needed. Thanks in advance -- Chris
On 02/25/2010 01:40 PM, christopher floess wrote:
By doing pacman -Qo /lib/ld-2.11.1.so, I get glibc, which is at version 2.11.1-1.
I've tried doing pacman -Syu, but that hasn't resolved anything. I some how think this isn't a bug, but something I'm doing wrong on my end.
Any pointers on how to trouble shoot this?
Tried reinstalling glibc? I've lost power a few times and had to resync the base group just to get a sane system again. Anyway, try (as root) pacman -S glibc pacman -Syu by itself will only update the package list, and update out of date packages.
On 02/25/2010 09:46 PM, Gary Wright wrote:
On 02/25/2010 01:40 PM, christopher floess wrote:
By doing pacman -Qo /lib/ld-2.11.1.so, I get glibc, which is at version 2.11.1-1.
I've tried doing pacman -Syu, but that hasn't resolved anything. I some how think this isn't a bug, but something I'm doing wrong on my end.
Any pointers on how to trouble shoot this?
Tried reinstalling glibc? I've lost power a few times and had to resync the base group just to get a sane system again.
Anyway, try (as root) pacman -S glibc
pacman -Syu by itself will only update the package list, and update out of date packages.
Yeah, just tried it. No luck. I'm trying to figure out if it has something to do with the fact that I copied files over from my 32-bit install. I had 32-bit arch installed and then I realized that I have a 64-bit system, so I installed 64-bit arch on an extra partition. I'm pretty sure I only copied over rc.conf rc.local and xorg.conf. hmmm
On 02/25/2010 03:02 PM, christopher floess wrote:
Yeah, just tried it. No luck.
I'm trying to figure out if it has something to do with the fact that I copied files over from my 32-bit install.
I had 32-bit arch installed and then I realized that I have a 64-bit system, so I installed 64-bit arch on an extra partition. I'm pretty sure I only copied over rc.conf rc.local and xorg.conf.
hmmm
Hmm, those three shouldn't be the guilty party. Here's a bug report from the redhat bugtracker that details what kind of goofiness you can expect from corrupt hdd sectors/hard powerdowns: https://bugzilla.redhat.com/show_bug.cgi?id=488449#c11 I'd check your logs to see if there is anything about "cleaning up orphan inodes" or such, meaning that it lost part of or a whole file. First, clean your pacman cache, just in case one of the cached packages got corrupted. pacman -Scc To get you back running, first try reinstalling libwebkit, desktop-file-utils, and libnotify. Those are the three depends in common between midori and epiphany. Then try to resync the base group: (I do this every time I have a sudden poweroff and orphaned inodes) pacman -Scc pacman -Syy base base-devel (base-devel if you compile stuff regularly or use the AUR/ABS) If that doesn't work, try reinstalling midori and epiphany. If that fails, try reinstalling all the deps of midori, epiphany, and any other program that throws a segfault in ld And if that fails? Well, I'm out of ideas then. Keep us posted. Gary
Hmm, those three shouldn't be the guilty party.
Here's a bug report from the redhat bugtracker that details what kind of goofiness you can expect from corrupt hdd sectors/hard powerdowns:
https://bugzilla.redhat.com/show_bug.cgi?id=488449#c11
I'd check your logs to see if there is anything about "cleaning up orphan inodes" or such, meaning that it lost part of or a whole file. nothing
First, clean your pacman cache, just in case one of the cached packages got corrupted. pacman -Scc
Done
To get you back running, first try reinstalling libwebkit, desktop-file-utils, and libnotify. Those are the three depends in common between midori and epiphany.
So I think we can rule out desktop-file-utils. Brasero, Gimp, and Firefox depend on this and they work. I'm not sure if libnotify and libwebkit should be suspect either at this point because I've discovered that soffice and gnome-settings-daemon do this as well now.
Then try to resync the base group: (I do this every time I have a sudden poweroff and orphaned inodes) pacman -Scc pacman -Syy base base-devel (base-devel if you compile stuff regularly or use the AUR/ABS)
Did that.
If that doesn't work, try reinstalling midori and epiphany.
Did that.
If that fails, try reinstalling all the deps of midori, epiphany, and any other program that throws a segfault in ld
And if that fails? Well, I'm out of ideas then. Keep us posted.
I'm out of ideas too, because they still segfault. Crap. I guess I could reinstall the system, but doesn't seem like the way to go here. I have X working with wmii. I just have nasty looking window decorations and random productivity Applications that don't work. Is there a way to de-install everything that's NOT in base? I looked around for this, and will I could certainly create a command line chain for it something like "pacman -R --all !base" would be nice -- Chris
I'm out of ideas too, because they still segfault. Crap.
I guess I could reinstall the system, but doesn't seem like the way to go here. I have X working with wmii. I just have nasty looking window decorations and random productivity Applications that don't work.
Is there a way to de-install everything that's NOT in base? I looked around for this, and will I could certainly create a command line chain for it something like "pacman -R --all !base" would be nice
the "file" command will tell you if a binary is 32bit or 64bit, so go in /lib/ /usr/lib/ /usr/bin etc and do a file * | grep '32-bit' or a bit more robust find /usr/lib/ -print0 | xargs -0 file | grep '32-bit' -- damjan
On 02/26/2010 01:00 PM, Damjan Georgievski wrote:
I'm out of ideas too, because they still segfault. Crap.
I guess I could reinstall the system, but doesn't seem like the way to go here. I have X working with wmii. I just have nasty looking window decorations and random productivity Applications that don't work.
Is there a way to de-install everything that's NOT in base? I looked around for this, and will I could certainly create a command line chain for it something like "pacman -R --all !base" would be nice
the "file" command will tell you if a binary is 32bit or 64bit, so go in /lib/ /usr/lib/ /usr/bin etc and do a
file * | grep '32-bit'
or a bit more robust
find /usr/lib/ -print0 | xargs -0 file | grep '32-bit'
Since it's a pretty short list, here's the output /usr/lib/syslinux/vpdtest.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/elf.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/kbdmap.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/rosh.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/ethersel.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/config.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/ifcpu.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/cpuidtest.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/gpxecmd.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/chain.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/mboot.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/linux.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/reboot.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/sdi.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/hdt.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/vesainfo.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/disk.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/dmitest.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/pmload.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/cmd.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/gfxboot.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/ifcpu64.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/vesamenu.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/menu.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/sanboot.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/meminfo.c32: COM executable (32-bit COMBOOT) /usr/lib/syslinux/pcitest.c32: COM executable (32-bit COMBOOT) /usr/lib/mono/gac/avahi-sharp/1.0.0.0__4d116c78973743f5/avahi-sharp.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit Mono/.Net assembly /usr/lib/mono/gac/avahi-ui-sharp/0.0.0.0__4d116c78973743f5/avahi-ui-sharp.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit Mono/.Net assembly /usr/lib/mono/gac/gmime-sharp/2.4.0.0__2b75c2ad004c52e4/gmime-sharp.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit Mono/.Net assembly /usr/lib/opera/10.10/operapluginwrapper-ia32-linux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped /usr/lib/python2.6/site-packages/setuptools/gui.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit /usr/lib/python2.6/site-packages/setuptools/cli.exe: PE32 executable for MS Windows (console) Intel 80386 32-bit /usr/lib/python2.6/distutils/command/wininst-7.1.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit /usr/lib/python2.6/distutils/command/wininst-8.0.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit /usr/lib/python2.6/distutils/command/wininst-9.0.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit /usr/lib/python2.6/distutils/command/wininst-6.0.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit Maybe it's just my untrained eye, but things don't seem to be out of the ordinary here. /lib didn't show anything 32-bit. At this point, if I could be fairly certain that a reinstall would work, I'd try that. I'm just afraid that it won't produce anything. It couldn't possibly have to do with the fact that my boot loader is the grub from the 32-bit install, could it? -- Chris
On 02/26/2010 12:43 PM, christopher floess wrote:
Maybe it's just my untrained eye, but things don't seem to be out of the ordinary here. /lib didn't show anything 32-bit.
At this point, if I could be fairly certain that a reinstall would work, I'd try that. I'm just afraid that it won't produce anything. It couldn't possibly have to do with the fact that my boot loader is the grub from the 32-bit install, could it?
-- Chris
It shouldn't. At one point I had a 32 bit Ubuntu, 64bit Arch, and WinXP 32, all booting from the same bootloader (Ubuntu's grub) and they all worked fine. Whenever I bork something beyond repair, I just chalk it up to the price of cutting edge software. That, and I can be back up in an identical system after a reinstall in two or three hours, thanks to a seperate /home and keeping a list of installed packages. Truth be told, I think the longest I've ever kept an arch install was about 6 months before I found a way to break it. Gary
It shouldn't. At one point I had a 32 bit Ubuntu, 64bit Arch, and WinXP 32, all booting from the same bootloader (Ubuntu's grub) and they all worked fine.
Whenever I bork something beyond repair, I just chalk it up to the price of cutting edge software. That, and I can be back up in an identical system after a reinstall in two or three hours, thanks to a seperate /home and keeping a list of installed packages. Truth be told, I think the longest I've ever kept an arch install was about 6 months before I found a way to break it. Okay, so I've reinstalled, and everything seems to be in order. That was some pretty strange stuff though. I kind of wish that we could have put our fingers on exactly what it was.
Right now I'm just getting the little things squared away. If all goes well, at the end of this weekend I'll have migrated completely. The only concern at the moment is that I seem to notice that the system is a bit sluggish from time to time. ATM I seem to think that it happens when there is a lot of disk IO. I'm copying my old pretty large chunks of data from the old partition to the new one, but still I don't remember that sort of thing slowing down my 32-bit install this much. I'll keep watch. Thanks for all of your help everyone. -- Chris
Is there a way to de-install everything that's NOT in base? I looked around for this, and will I could certainly create a command line chain for it something like "pacman -R --all !base" would be nice
-- Chris
pacman -R $(pacman -Qq | grep -v "$(pacman -Qqg base)") Though I havn't tested that, it should work :) -- Laurie
On 02/26/2010 08:41 AM, Laurie Clark-Michalek wrote:
Is there a way to de-install everything that's NOT in base? I looked around for this, and will I could certainly create a command line chain for it something like "pacman -R --all !base" would be nice
-- Chris
pacman -R $(pacman -Qq | grep -v "$(pacman -Qqg base)")
Though I havn't tested that, it should work :)
I was pondering that one last night before bed. Good thing I gave up. :P . I did test it, except for replacing the pacman -R bit with echo $(... and it works. Added to the wiki: http://wiki.archlinux.org/index.php/Pacman_Tips#Removing_everything_but_base...
On 02/26/2010 09:18 PM, Gary Wright wrote:
On 02/26/2010 08:41 AM, Laurie Clark-Michalek wrote:
Is there a way to de-install everything that's NOT in base? I looked around for this, and will I could certainly create a command line chain for it something like "pacman -R --all !base" would be nice
-- Chris
pacman -R $(pacman -Qq | grep -v "$(pacman -Qqg base)")
Though I havn't tested that, it should work :)
I was pondering that one last night before bed. Good thing I gave up. :P . I did test it, except for replacing the pacman -R bit with echo $(... and it works. Cool. I haven't run it because it seemed to want to remove pacman, but maybe I did something wrong. At this point it looks like I'll be reinstalling any way, so if it wrecks my system, it's not a big deal.
I'll report back. -- Chris
On 02/26/2010 01:29 PM, christopher floess wrote:
On 02/26/2010 09:18 PM, Gary Wright wrote:
On 02/26/2010 08:41 AM, Laurie Clark-Michalek wrote:
Is there a way to de-install everything that's NOT in base? I looked around for this, and will I could certainly create a command line chain for it something like "pacman -R --all !base" would be nice
-- Chris
pacman -R $(pacman -Qq | grep -v "$(pacman -Qqg base)")
Though I havn't tested that, it should work :)
I was pondering that one last night before bed. Good thing I gave up. :P . I did test it, except for replacing the pacman -R bit with echo $(... and it works. Cool. I haven't run it because it seemed to want to remove pacman, but maybe I did something wrong. At this point it looks like I'll be reinstalling any way, so if it wrecks my system, it's not a big deal.
I'll report back.
-- Chris
Hmm, well I did try it with just the pacman -R at the start and it refused, saying there were unsatisfied dependencies. With the -Rc opt, it tries to remove kernel26... hmm. pacman -Rd .... would create all hell, but it wouldn't complain... maybe an reinstall would be for the best.
participants (4)
-
christopher floess
-
Damjan Georgievski
-
Gary Wright
-
Laurie Clark-Michalek