Bug 5267

Summary: after default install the user cannot start firefox
Product: Mageia Reporter: AL13N <alien>
Component: RPM PackagesAssignee: Mageia Bug Squad <bugsquad>
Status: RESOLVED WORKSFORME QA Contact:
Severity: normal    
Priority: Normal CC: eeeemail, mageia, mageia
Version: Cauldron   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Source RPM: firefox CVE:
Status comment:

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