xulrunner never fully installs
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
xulrunner-1.9.1 (Ubuntu) |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: xulrunner-1.9.1, xulrunner-1.9.2
xulrunner never finishes installing... it gives a configuration message and stops there forever.
If I killall xulrunner-bin, the rest of the installation process goes on, but it breaks xulrunner, firefox, yelp, desktopcouch, and several other packages depending on what's installed at the time.
apport claims (at the end of dist-upgrade, after killing xulrunner-bin) that it will NOT log anything as this is the result of a "previous failure" of which I also find no logging.... this is interesting for me because I've never actually seen a message from apport appear while not using apport...
I have attempted to compensate by forced purge of xulrunner and all dependent packages, but that doesn't seem like a decent solution to me.
Which reminds me: xulrunner cannot be removed either, except by dpkg with --force-all. Otherwise it tries to configure itself to infinity again.
description: | updated |
Am I totally alone with this problem?
I have a little more information. xulrunner-1.9.1 is a dependency of firefox 3.5.x, so it is possible to avoid the problem by simply never upgrading past firefox 3.0.x
Finally I've gone back to Jaunty (there are just too many issues with my setup and karmic to even consider an upgrade again) and I have avoided firefox 3.5 since reinstallation. During a previous reinstallation however, I noticed exactly the same problem as I had in Karmic: xulrunner-1.9.1 will never finish installing (it left it running all day...)
Furthermore, the process is always in sleep or wait status, giving me the impression that it's hoping for some kind of trigger to go off but it never comes.
I still have no log information regarding the issue, but I found an interesting tidbit on phoronix just now:
http:// www.phoronix. com/scan. php?page= article& item=ext4_ btrfs_nilfs2& num=2
It seems ext4 is quite slow with sql databases. My system is installed on an ext4 formatted RAID:0.
Could this be the route of the problem?