55754 - Installer crashes if higher dirs are not writeable

Status: VERIFIED WORKSFORME

(SeaMonkey :: Installer, defect, P3)

Description

[Ben Bucksch (:BenB)]

Assuming N6PR3's installer is open source (I install Mozilla Linux nighlies from
tarballs).

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 libplc4.so 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

[Sean Su]

reassigning to Samir.

Comment 2

[Samir Gehani]

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

[Ben Bucksch (:BenB)]

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

Comment 4

[Samir Gehani]

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

Grace,
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.

Ben,
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.

Comment 5

[Ben Bucksch (:BenB)]

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.

Samir,
the installer didn't dump a core, and I don't have a debug build (unless
mozilla.org distributes DEBUG binaries - my own build is non-debug).

Comment 6

[Samir Gehani]

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

[Samir Gehani]

Grace,
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

[Grace Bush]

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

[Ben Bucksch (:BenB)]

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.

Comment 10

[Daniel Veditz [:dveditz]]

Moz 0.9 tasks

Comment 11

[Samir Gehani]

Using the initially posted setup I could not reproduce this bug.  

Comment 12

[Ben Bucksch (:BenB)]

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

[Samir Gehani]

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:
<ftp://ftp.mozilla.org/pub/mozilla/nightly/2001-03-14-08-Mtrunk/mozilla-i686-pc-linux-gnu-sea.tar.gz>

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

Grace,
Please verify when you have time.  Thanks.

Comment 14

[Ben Bucksch (:BenB)]

Yes, it works now. VRFY.