Installer crashes if higher dirs are not writeable



17 years ago
13 years ago


(Reporter: BenB, Assigned: Samir Gehani)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [xpibug])



17 years ago
Assuming N6PR3's installer is open source (I install Mozilla Linux nighlies from

If I ran the graphical installer as user, and told it to install in
/usr/local/packages/netscape-n6pr3, it died shortly after unpacking the xpis
(IIRC, after or somthing). /usr/local is drwxr-xr-x 0:0, but
/usr/local/packages is 0:0 and symlink to /mnt/packages, which is drwxr-xr-x and
owned by the installing user. netscape-n6pr3 has the same permissions.

Dunno, if it's the smylink or the permissions causing the trouble. If the
former, please removing it from meta bug 42184.

Comment 1

17 years ago
reassigning to Samir.
Assignee: ssu → sgehani


17 years ago
QA Contact: gemal → gbush

Comment 2

17 years ago
How rampant would this be if the symlink was the issue?  Trying to guage whther
we should invesitigate this now or work on it for the next release.

Comment 3

17 years ago
sgehani, symlinks in the install path are *very* common.

Comment 4

17 years ago
OK, I'll take your word on this.  This warrants expedient investigation.

Can you help by isolating whether the issue is higher dirs not being writable (I
highly doubt) or whether having a symlink in the path is the issue?  If both
work exclusively then try the combination to see if that is the unique situation
in which this crash occurs.  Thanks.

Would it be possible for you to attach a stack trace of the crash if the
installer dumped a core.  If it didn't and if you have a debug build swap in the
debug mozilla-installer-bin in your optimized installer folder with the one from
your mozilla/xpinstall/wizard/unix/src2 directory and run in gdb.  Thanks for
any help.
Priority: P3 → P1
Target Milestone: --- → M19

Comment 5

17 years ago
I forgot to notice:
Installing in /tmp/inst/ worked fine.
/tmp is a smylink, owned by 0:0. The target, /mnt/tmp/tmp/, was drwxrwxrwt,
owned by myuser. /mnt/tmp/ is drwxr-xr-x, owned by 0:0. /tmp/inst/ was
drwxr-xr-x, owned by myuser.

So, it is *not* just the symlink. Adjusting SUMMARY.

the installer didn't dump a core, and I don't have a debug build (unless distributes DEBUG binaries - my own build is non-debug).
Summary: Installer crashes if higher dirs are not writeable / a symlink → Installer crashes if higher dirs are not writeable

Comment 6

17 years ago
CC'ing David since I vaguely recollect him mentioning some such behavior.  Since
it's not the symlink problem I'm not too worried.

Comment 7

17 years ago
Can you try and reproduce the higer dirs not having write perms problem?  Since
I seem to be hearing that the symlink factor is not what is causing this bug we
need not investigate/try to reproduce that aspect.  Thanks.

Comment 8

17 years ago
I cannot reproduce this using directory structure similar to one noted (no 
symlink) t1/t2/t3 with t1 and t3 having 755 permissions and t2 having 555. I 
successfully install into t3.
I am not familiar with the 0:0 notation- so I maybe missing something. 

Is this the same as bug 46558? 

Comment 9

17 years ago
gbush, 0:0 is short for root:root, i.e. owned by root, group root.

IIRC, I've seen bug 46558 before, but it mentions no crash.
Keywords: crash
Keywords: nsbeta1
Whiteboard: [xpibug]
Moz 0.9 tasks
Target Milestone: --- → mozilla0.9


17 years ago
Priority: P1 → P3


17 years ago
Keywords: crash, nsbeta1 → nsbeta1+

Comment 11

17 years ago
Using the initially posted setup I could not reproduce this bug.  
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 12

17 years ago
I saw pretty wierd crashes GTK and stuff when I ran the Mozilla Linux stub
installer recently. Maybe I used mozilla-installer-bin, not mozilla-installer?

I fail with a download error, when using the latter. When setting ftp_proxy and
FTP_PROXY, it just exists before downloading. Different bug? Guess so.

Anyway, cannot verify or reject closure.

Comment 13

17 years ago
We don't support proxies yet in the linux installer.  Once we do we'll expose
the settings in the UI.  Very soon.

Could you try verifying using the "blob" instead of the "stub" installer?  The
blob is the one that has the "sea" suffix in place of the "installer" suffix in
the name.  For example:

The blob contains all the zippies (.xpis) already so it doesn't try to download.
 Thanks for your time.

Please verify when you have time.  Thanks.

Comment 14

17 years ago
Yes, it works now. VRFY.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.