On 2/21/2012 3:24 AM, Yasha Karant wrote:
> On 02/20/2012 04:07 PM, Mark Stodola wrote:
>> On 2/20/2012 5:37 PM, Yasha Karant wrote:
>>> On 02/20/2012 02:32 PM, Chris Pemberton wrote:
>>>> On 02/20/12 13:29, Yasha Karant wrote:
>>>>> Before someone states that this is not a Scientific Linux issue, as it
>>>>> seems to be restricted to this distribution (perhaps other EL
>>>>> distributions as well), this issue would seem to qualify.
>>>>>
>>>>> Rather than using the Mozilla packages that exist within the
>>>>> distribution repository, I use the production (not testing or beta)
>>>>> installations from Mozilla: firefox, thunderbird/lightning, and
>>>>> seamonkey, currently 10.0.2 except SeaMonkey 2.7.2.
>>>>>
>>>>> My laptop and workstation are operating environment identical except
>>>>> that my laptop is IA-32 SL6x and my workstation is X86-64 SL6x (and
>>>>> there are some hardware differences reflected in driver differences).
>>>>> On my workstation, as root, I can update any of the Mozilla
>>>>> applications I have mentioned within a major release (e.g., 10.0.1 to
>>>>> 10.0.2) from within the application. However, on my laptop, this
>>>>> generally fails and I must download a new tar.bz2 file that I must
>>>>> unpack into the appropriate directory. Does anyone have an idea on
>>>>> what is the reason? Note that my mozilla configuration files between
>>>>> the two platforms are the same in so far as I have any control over
>>>>> these (e.g., visitation to different URLs from firefox or seamonkey
>>>>> might have different cookies, etc., loaded -- but all URLs are either
>>>>> mandated by my university or from "clean" sites).
>>>>>
>>>>> I have done a cursory check of the mozilla public lists but have found
>>>>> nothing of relevance.
>>>>>
>>>>> Thanks for any insight.
>>>>>
>>>>> Yasha Karant
>>>> Could you start firefox from a terminal, try the internal update
>>>> process, and see if any usefull information is given in the terminal?
>>>> Sure sounds like a permission problem; but you said you are using root?
>>>> You should be able to destroy anything as root:)
>>>>
>>>> Chris
>>>
>>> There is no problem in downloading from Mozilla the entire update as a
>>> tar.bz2 package followed by the manual installation ( tar -vxjf ) as
>>> root into the appropriate directory.
>>>
>>> However, there is a mechanism, for minor release updates (e.g., 10.0.1
>>> to 10.0.2) within firefox, thunderbird/lightning, and seamonkey
>>> without the manual unpacking -- the files are updated within the
>>> running application and the updated instance is invoked at the next
>>> initiation (restart) of the application. This mechanism needs to be as
>>> root if the files are installed in a systems, as contrasted with an
>>> ordinary end-user, directory. However, the mechanism fails on one SL6x
>>> box but succeeds on another; when the mechanism fails, then I must
>>> used the manual installation method from the tar.bz2 file as explained
>>> above.
>>>
>>> Yasha Karant
>>
>> I believe Chris is well aware of that. He instructed you to start
>> firefox from a terminal and attempt the update process from within
>> firefox (meaning _not_ the tar.bz2) and see if it has any errors written
>> to stdout or stderr in the terminal. It helps if you read the email you
>> are replying to.
>>
>> -Mark
> 
> I missed that -- sorry.  But in fact, that is what I do.  E.g., I start
> a terminal as an end-user, su, and then /usr/lib/firefox/firefox .  The
> diagnostics I get are not related to the update process.  Here is an
> example:
> 
> [root@localhost ykarant]# /usr/lib/firefox/firefox
> failed to create drawable
> 
> (firefox:3299): GnomeUI-WARNING **: While connecting to session manager:
> None of the authentication protocols specified are supported.
> 
> Nonetheless, despite these diagnostics, on one machine there is success
> and another not.  However, the next time I go to do this, I shall record
> the specific diagnostics, but having read these in the past, there has
> never been an obvious significant difference.  Note that firefox invoked
> as above appears to be fully functional as a web browser.
> 
> Yasha Karant

Just a guess:

Do you have DISPLAY environment variable exported?

$ export DISPLAY=":0"

Zoran Ovcin