Created attachment 470103 [details] strace -o /tmp/firefox-strace.txt -f /usr/lib64/firefox-4/firefox -app /usr/lib64/firefox-4/application.ini Description of problem: Still even when completely removing xulrunner* and firefox* and reinstalling from koji builds of firefox-4.0-0.7b8.fc15.x86_64 and xulrunner-2.0-0.11b8.fc15.x86_64 firefox still doesn't start with error message "Cannot read application.ini" Steps to Reproduce: 1. firefox 2. in the profile window select any profile (or even create a new one) 3. Actual results: that's it ... the main window doesn't show up and only on the stderr there is a message "Cannot read application.ini". Expected results: Running firefox; upstream binary from ftp://ftp.mozilla.org/pub/firefox/nightly/4.0b8-candidates/build1/linux-x86_64/en-US/firefox-4.0b8.tar.bz2 works as expected. Additional info: Attached is output of strace -o /tmp/firefox-strace.txt -f /usr/lib64/firefox-4/firefox -app /usr/lib64/firefox-4/application.ini
Hm, unable to reproduce. The message "Cannot read application.ini" is apparently wrong, the strace shows it's opened and loaded: 2843 open("/usr/lib64/firefox-4/application.ini", O_RDONLY) = 3 2843 fstat(3, {st_mode=S_IFREG|0644, st_size=2064, ...}) = 0 2843 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f4c49750000 2843 fstat(3, {st_mode=S_IFREG|0644, st_size=2064, ...}) = 0 2843 lseek(3, 0, SEEK_SET) = 0 2843 read(3, "; ***** BEGIN LICENSE BLOCK ****"..., 2064) = 2064 2843 lseek(3, 2064, SEEK_SET) = 2064 2843 close(3) = 0
*** Bug 664884 has been marked as a duplicate of this bug. ***
I've just updated my probuction box to rawhide and firefox b8 i686 works as expected. Could it be x86_64 related?
I have this on an x86_64 Rawhide KVM guest. Nightly XFCE liveCD install. tried sudo yum erase --remove-leaves firefox yum install firefox 4.0-0.7b8.fc15 (koji) same result
(In reply to comment #3) > I've just updated my probuction box to rawhide and firefox b8 i686 works as > expected. Could it be x86_64 related? Yes I can reproduce it on x86_64 here too (have not tried i686), it seems to look for the application.ini in the wrong place a cp /usr/lib64/firefox-4/application.ini /usr/lib64/xulrunner-2/ fixes it.
Hm, it looks like the 64-bit xulrunner-stub ignores the firefox application.ini but 32-bit version works...
I just installed firefox-4.0-0.7b8.fc15.x86_64 to my 64 bit rawhide system and it works fine. Try to clear all your previous firefox/xulrunner installation and install the latest package again.
(In reply to comment #7) > I just installed firefox-4.0-0.7b8.fc15.x86_64 to my 64 bit rawhide system and > it works fine. Try to clear all your previous firefox/xulrunner installation > and install the latest package again. Did you remove ~/.mozilla ? (The error occurs after removing it for the first time).
I have now managed to get this problem on 32 bit after installing desktop-i386-20101226.16.iso As I needed XFCE, yum grouperase GNOME, yum groupinstall XFCE. I have rn -rf all .mozilla files /home and /root /usr/lib. On reinstall firefox xulrunner problem still there. firefox-4.0-0.7b8.fc15.i686 xulrunner-2.0-0.13b8.fc15.i686
I can reproduce this bug, my packages are: [filiper@rosset-laptop ~]$ rpm -q firefox firefox-4.0-0.7b8.fc15.x86_64 [filiper@rosset-laptop ~]$ rpm -q xulrunner xulrunner-2.0-0.13b8.fc15.x86_64 It's happened after deleting ~/.mozilla
Same issue. Did nothing to my .mozilla or other dirs, just a normal "yum upgrade" of my rawhide-laptop. Downgrading to xulrunner-2.0-0.7b7.fc15.i686 and firefox-4.0-0.6b7.fc15.i686 fixed the problem.
Has now happened with a nightly LiveCD (Not installed) http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/xfce-x86_64-20101229.18.iso http://alt.fedoraproject.org/pub/alt/nightly-composes/xfce/logs/20101229.18-x86_64.log
Yeah, removing the profile in .mozilla does the trick. I can reproduce it now.
Should be fixed by firefox-4.0-0.8b8.fc15.
I got this on fedora-14-x86_64 using the firefox4.repo (http://repos.fedorapeople.org/repos/spot/firefox4/). The fix mentioned in Comment 5 fixes it.
I also got this on fedora-14-x86_64 using the firefox4.repo (http://repos.fedorapeople.org/repos/spot/firefox4/). The tweak in Comment 5 fixes it, but kicks me straight to a new error (which I'll be searching for next). On first run of a profile, I get a little xul window that says: XML Parsing Error: undefined entity Location: chrome://mozapps/content/extensions/update.xul Line Number 14, Column 1:<wizard id="updateWizard" ^ After closing that, it exits, and on previous runs with that profile, it terminates right after the profile window. Running FF4 from root (via a SU'ed console) it runs fine. I have both FF and FF4 on this machine. They seem to share a profile (though I've never run them at the same time). I'm wondering if that might have mucked them up, somehow. I've never removed the .mozilla directory, but possibly they are fighting over it?
I discovered that starting firefox (3.6.13 default in fedora 14) before firefox4 per user also fixes any errors..
In my case, starting regular firefox has had no effect. I have been alternating between them, regularly--using ff3 to look online attempting to fix ff4--and runs between ff3 have made no difference. I *have*, however, created a new machine account, and launched ff4 under it. It works fine. In fact, if I remove the copied file from comment 5, the new account continues to work fine, but my main account goes back to broken. On another note, I got an ff4 update, today. it seems to have updated the versions in the original application.ini, but continues to look for the copied file... giving it a GRE error. Recopying it works around that, but: ln -s /usr/lib64/firefox-4/application.ini /usr/lib64/xulrunner-2/ seems to be a much better choice, and seems to work fine. None of these things seem to have an affect on ff4 under the new user account. It just runs along, dumb and happy. With the ini, or without. I'm not sure why one account would look for the ini in one location, and another would appear to look elsewhere... but there you have it.
Why is this closed? It's still a problem in firefox4-4.0-0.13.b11.fc14.x86_64
(In reply to comment #19) > Why is this closed? It's still a problem in firefox4-4.0-0.13.b11.fc14.x86_64 Can anyone else confirm it?
(In reply to comment #20) > (In reply to comment #19) > > Why is this closed? It's still a problem in firefox4-4.0-0.13.b11.fc14.x86_64 > > Can anyone else confirm it? Note that the "firefox4" package is from spots repo, not sure whether he applied the same fixes or not.