Bug 5267 - after default install the user cannot start firefox
Summary: after default install the user cannot start firefox
Status: RESOLVED WORKSFORME
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-04-07 13:15 CEST by AL13N
Modified: 2013-05-11 16:22 CEST (History)
3 users (show)

See Also:
Source RPM: firefox
CVE:
Status comment:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description AL13N 2012-04-07 13:15:27 CEST 
it appears the ~/.mozilla/{extensions|firefox} directory is owned by root.

this happened after a default network installation from the boot.iso media in x86_64 3 days ago.

it seems that they even already contained a session for it to start.

i suppose during installation, they are being created, and since it's normally the current user, but during install it's run as root, they are created as root?

after chowning them, all works well...
AL13N 2012-04-07 13:15:49 CEST

Priority: Normal => High

Comment 1 Marja Van Waes 2012-05-26 13:02:41 CEST 
Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Comment 2 AL13N 2012-06-14 21:40:59 CEST 
resolving old... after i'll reinstall my server, i can reinstall my PXE+NFS network install and then i can see if it's still there, if it is, i'll reopen.

Status: NEW => RESOLVED
Resolution: (none) => OLD

Comment 3 AL13N 2013-05-05 15:08:36 CEST 
confirmed on Mga3 RC LiveCD

Keywords: NEEDINFO => (none)
Priority: High => release_blocker
Status: RESOLVED => REOPENED
Resolution: OLD => (none)

Comment 4 Manuel Hiebel 2013-05-05 19:18:35 CEST 
which one ?
strange nobody noticed it..
Comment 5 AL13N 2013-05-05 19:26:32 CEST 
x86_64 (the tmb one from 2013-05-04)

it gives a mention about "session not accessible" or similar
claire robinson 2013-05-05 20:49:36 CEST

CC: (none) => eeeemail

Comment 6 Nicolas Lécureuil 2013-05-09 00:03:18 CEST 
you only see this on live ?

CC: (none) => nicolas.lecureuil

Comment 7 AL13N 2013-05-09 00:04:36 CEST 
i have not tested otherwise on mga3, besides using live (not installing)
Comment 8 Sander Lepik 2013-05-09 09:07:34 CEST 
Can someone else confirm that bug? I have tested multiple live isos and I haven't noticed such problem :/

CC: (none) => sander.lepik

Comment 9 AL13N 2013-05-09 09:14:45 CEST 
i must admit i seen this only once, but when i live tested, i didn't use FF except that one time.

the only thing i can think of is that i booted fast, and immediately clicked on FF. perhaps too fast?
Comment 10 AL13N 2013-05-09 09:15:26 CEST 
used the KDE 64bit one for this, btw
Comment 11 Sander Lepik 2013-05-09 22:58:36 CEST 
Tested with LiveDVD x86_64 KDE version and with LiveCD x86_64 KDE version from wl-test folder.

I can't reproduce this. There are no .mozilla folder before firefox is started and when it's started those folders are created as live user. So I'm decreasing priority. You can set it back to release critical if you figure out how to reproduce it and what is the exact error.

Priority: release_blocker => Normal
Severity: critical => normal

Comment 12 AL13N 2013-05-11 16:22:03 CEST 
couldn't reproduce either

Status: REOPENED => RESOLVED
Resolution: (none) => WORKSFORME
Note You need to log in before you can comment on or make changes to this bug.