Bugzilla – Bug 121979
I did a yast update (you) today and it broke both firefox and mozilla
Last modified: 2005-11-24 11:09:49 UTC
andrea@opteron:~> firefox /usr/bin/firefox: line 259: 16545 Segmentation fault $MOZ_PROGRAM $MOZ_LANG andrea@opteron:~> mozilla /usr/bin/mozilla: line 259: 16558 Segmentation fault $MOZ_PROGRAM $MOZ_LANG I'll attach an strace.
Created attachment 52091 [details] strace -f mozilla
well this is worse than what I though, I tried to reboot just in case and then X didn't startup anymore and I couldn't even login on the console ("module error of some sort"). That would have been a dead box to replace as far as desktop user would been concerned. I fixed up by passing "emergency" to grub, and then luckily the login program that asks the password isn't bloated like the getty one, so I could login successfully there. Then I mounted all fs rw (including /proc) by hand and I run rpm like "rpm -Uhv xorg-x11-Xvnc dia resmgr" to downgrade to the previous versions of those three packages (the one in the master, however surprisingly rpm didn't complain about the fact I was doing a downgrade, I didn't need to run --force or similar), and that fixed it. So the bug must be in the update of one of the above three packages. I guess it's resmgr. The working versions is: xorg-x11-Xvnc-6.8.2-100.x86_64.rpm the ones that fails and that YOU installed is: resmgr-0.9.8-65_65.2.x86_64.delta.rpm It's certainly a resmgr bug because now mozilla works but firefox still segfaults, and infact firefox is 32bit and I forgot to downgrade the resmgr-32bit: opteron:/var/lib/YaST2/you/mnt/x86_64/update/9.3 # rpm -Uhv ~andrea/tmp/SUSE-x86_64/suse/x86_64/resmgr-32bit-0.9.8_SVNr57-2.x86_64.rpm Preparing... ########################################### [100%] package resmgr-32bit-9.3-7.1 (which is newer than resmgr-32bit-0.9.8_SVNr57-2) is already installed opteron:/var/lib/YaST2/you/mnt/x86_64/update/9.3 # rpm -Uhv --force ~andrea/tmp/SUSE-x86_64/suse/x86_64/resmgr-32bit-0.9.8_SVNr57-2.x86_64.rpm Preparing... ########################################### [100%] 1:resmgr-32bit ########################################### [100%] opteron:/var/lib/YaST2/you/mnt/x86_64/update/9.3 # Interestingly the above one required --force, I don't seem to recall to need --force when I did the same thing for the 64bit package when in emergency mode, but I may be remembering wrong and I may have added --force there too, dunno. Now firefox is back alive. So it's a bug in resmgr.
Adding resmgr maintainer and tutor in cc. I've no idea myself what resmgr is about and why mozilla/firefox/getty needs to link against it.
in the comment #2 I quoted the Xvnc version instead of the resmgr working version. The resmgr working version is the same of the of the one of the 32bit package: resmgr-0.9.8_SVNr57-2.x86_64.rpm
mozilla/firefox doesn't have anything to do with resmgr. But X seems to have a problem which causes the applications to fail.
This looks like a problem with the recent x11-org update to me. Unlikely that resmgr is involved.
The problem is Xvnc, correct?
mozilla opens libresmgr: 20539 open("/opt/mozilla/lib64/plugins/libresmgr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) 20539 open("/opt/mozilla/lib64/libresmgr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) 20539 open("/home/andrea/bin/x86_64/python/lib/libresmgr.so.1", O_RDONLY) = -1 ENOENT (No such file or directory) 20539 open("/lib64/libresmgr.so.1", O_RDONLY) = 21 20539 read(21, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000\24\0"..., 640) = 640 I can't see how this can be a problem in Xvnc, because firefox (32bit) kept segfaulting even after downgrading Xvnc, then I downgraded the 32bit package of resmsg and that finally fixed firefox. I think the problem is really resmgr, what has changed in resmsg between resmgr-0.9.8_SVNr57-2.x86_64.rpm and resmgr-0.9.8-65_65.2.x86_64.delta.rpm? Can somebody try to apply the latest x86-64 resmgr update and see if they can still login after reboot?
strange. I cannot reproduce this with my 9.3 machine. rpm -q --changelog resmgr|head * Di Sep 27 2005 - lnussel@suse.de - read usb class from interface definition if descriptor says zero (#112719) - always fetch all device attributes from /proc/bus/usb to be able to match for class etc (#112719) But I do not have libresmgr.so.1, i have only 0.9.8... $ ls /lib64/libresmgr.so.0.9.8 /lib64/libresmgr.so.0.9.8 I am confused. which distribution is it exaclty?
andrea@opteron:~> cat /etc/SuSE-release SUSE LINUX 10.0 (X86-64) VERSION = 10.0 andrea@opteron:~> andrea@opteron:~> ls -l /lib64/libresmgr.so* lrwxrwxrwx 1 root root 18 2005-10-10 19:21 /lib64/libresmgr.so -> libresmgr.so.1.0.0 lrwxrwxrwx 1 root root 14 2005-10-10 19:21 /lib64/libresmgr.so.0.9.8 -> libresmgr.so.1 lrwxrwxrwx 1 root root 18 2005-10-10 19:21 /lib64/libresmgr.so.1 -> libresmgr.so.1.0.0 -rwxr-xr-x 1 root root 15488 2005-09-09 19:59 /lib64/libresmgr.so.1.0.0 andrea@opteron:~> This was a SL10 RC4 IIRC, the updated rpm come from yast uptdate. Currently: andrea@opteron:~> rpm -q --changelog resmgr|head * Wed Aug 24 2005 - lnussel@suse.de - always fetch all device attributes from /proc/bus/usb to be able to match for class etc (#112719, bug1) - append new devices again to get the exclude/add order right * Tue Aug 23 2005 - lnussel@suse.de - fix access flags on devices without explicit family (#106735) andrea@opteron:~> I should have run a rpm --changelog before downgrading resmgr but I hope the yast-uptodate version mentioned in the previous comments is accurate.
I tried to search in the ftp site for the resmgr package but I couldn't find it in the 10.0 directory. the logs in my system are like this: opteron:/var # find -name \*resmgr\* ./adm/fillup-templates/rc.config.resmgr.del ./lib/YaST2/you/mnt/x86_64/update/9.3/patches/resmgr-52492 ./lib/YaST2/you/installed/resmgr-52492 ./run/.resmgr_socket ./run/resmgr.pid ./run/resmgr opteron:/var # Note the 9.3 directory. My system was upgraded from 9.3 to 10.0-RC4 or similar. I assume the problem is that I installed a 9.3 package on 10.0 distro that didn't need the update. So the culprit of this bug seems that the yast update still points to 9.3 (or at least that's certainly a misconfiguration of my system). How can I tell yast update to use the 10.0 directory instead of 9.3? everything else knows it's 10.0, only yast update is still stuck in 9.3. Thanks.
check /var/adm/YaST/ProdDB/ it should have 1 file, and it should mention 10.0 if it has more than , delete the rest except the 10.0 file i will attach my ProdDB file (you will have to change the install source perhaps, mine points to dist.suse.de directly).
Created attachment 54359 [details] prod_00000001 my proddb file for 10.0-x86_64
y2pmsh source -P <numberof10.0instsourcehere>
My brother just had the very same problem I had. We both have 9.3 in you after an update from the RC4 suse tree I donwloaded from machcd some week ago. He's also x86-64. A different system where I did a real install of 10.0 works fine but that was not an update and it was an i686 system (not x86-64). I've no idea what <numberof10.0instsourcehere> means, so I can't fixup with y2pmsh sorry. I think it's absolutely wrong that with a /etc/SUSE-release like this: andrea@opteron:~> cat /etc/SuSE-release SUSE LINUX 10.0 (X86-64) VERSION = 10.0 andrea@opteron:~> YOU fails to notice he's pointing to the wrong place and screwup the update. That prod_00000001 thing is not being updated. Perhaps I downloaded a wrong copy of 10.0 from machcd, I don't know. Feel free to close if you think it's irrelevant, I can't help you much more than this, I'll just try to fixup stuff by hand.
Ok fixing up by hand using Marcus's file worked fine. Thanks a lot! Bottom line is that if this is not a bug for sure it's not a feature either ;)
that productdb stuff is fragile and not exactly fool proof. Thats part of the reason why the official procedure for distro upgrades is to boot from the new installation medium and have yast handle it. /etc/SUSE-release is just a text file. It does have nothing to do with YOU whatsoever. y2pmsh source -s shows you the number of your installation sources, y2pmsh source -P NUMBER installs an installation source as product.
my point is that exactly because that stuff is fragile, there could be a warning if /etc/SUSE-release doesn't match the productdb. My system stopped booting because it didn't notice it was the wrong distro update. Yet another warning could be spawn in the yast update procedure, suggesting to boot from CD. I had no idea that doing the update from CD was better. A long time ago when I was using debian I never booted from CD except for the very first time, I always updated through dselect (apt-get wasn't there yet), so I thought it was the same with SUSE too (i.e. no need of boot from CD for updates).
I had the problem once that updating to a 'wrong' product worked (system even booted) but any further update failed. I had to edit files in the productdb by hand. This was so fragile that when leaving the old files around for reference in the same directory but with a different name strange things happened. I was beaten up badly when I reported this as a bug.