mozinstall should not magically try to find the mount point of the DMG

NEW
Unassigned

Status

Testing
Mozbase
--
major
4 years ago
3 years ago

People

(Reporter: Andrei Eftimie, Unassigned, Mentored)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [lang=py], URL)

(Reporter)

Description

4 years ago
We've occasionally seen a problem on some OSX nodes that our automation scripts were unable to unmount the Firefox DMG volume after an install. This would block all further unmount operations and we would end up with dozens of mounted firefox dmg's.

See the following github issue for more information: https://github.com/mozilla/mozmill-automation/issues/90

While we were not using mozinstall and handled this from within mozmill-automation we used the argument -force

We should add this in mozinstall, and it should prevent further occurrence of remaining with unmounted DMG's.
I will take this. Lets see if I can even figure out a working test.
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Hardware: x86 → All
Actually it's not only the -force option which is missing here. The problem is even larger. As of now we are trying to magically detect the mount point for the DMG file. This can totally fail if there are already mounted DMGs of the same application present. In those cases we even copy the wrong application to the install location!! We have seen this recently on bug 967655.

The end result is that if the application at the detected mount point is running, we cannot unmount it. So over time more and more mounted DMGs will be added but never unmounted.
Blocks: 967655
Severity: normal → major
Summary: Add -force argument to mozinstall when unmounting DMG's on OSX → mozinstall should not magically try to find the mount point of the DMG
If a DMG with the same name has already been mounted, the following exception is thrown:

/dev/disk3
/Volumes/Stub
Traceback (most recent call last):
  File "/Volumes/data/envs/mozbase/bin/mozinstall", line 9, in <module>
    load_entry_point('mozInstall==0.10', 'console_scripts', 'mozinstall')()
  File "/Volumes/data/code/mozbase/mozinstall/mozinstall/mozinstall.py", line 326, in install_cli
    install_path = install(src, options.dest)
  File "/Volumes/data/code/mozbase/mozinstall/mozinstall/mozinstall.py", line 121, in install
    install_dir = _install_dmg(src, dest)
  File "/Volumes/data/code/mozbase/mozinstall/mozinstall/mozinstall.py", line 257, in _install_dmg
    for appFile in os.listdir(appDir):
mozinstall.mozinstall.InstallError: Failed to install "/Volumes/data/code/mozbase/mozinstall/tests/installer_stubs/firefox.dmg"

I will change the install method to use the code we have in mozmill-automation and which has been proven to work over the last three years.
Blocks: 958812
Sorry for the delay here. I will continue as soon as possible. Most likely on Monday.
Blocks: 980801

Updated

4 years ago
Duplicate of this bug: 1015983

Comment 6

4 years ago
(In reply to Henrik Skupin (:whimboo) [away 07/19 - 08/01] from comment #4)
> Sorry for the delay here. I will continue as soon as possible. Most likely
> on Monday.
It's Thursday now.
Flags: needinfo?(hskupin)
Blocks: 970594
No longer blocks: 980801
Flags: needinfo?(hskupin)
I don't have time at the moment. So I would put this bug back into the bucket. I'm happy to mentor this bug.  So if anyone wants to have a look at it before I can have, please go ahead.
Assignee: hskupin → nobody
Mentor: hskupin@gmail.com
Whiteboard: [lang=py]
Status: ASSIGNED → NEW
FWIW, this is what we use in buildbot-land:
  http://hg.mozilla.org/build/tools/file/8a7c4b4d9536/release/common/unpack-diskimage.sh
You need to log in before you can comment on or make changes to this bug.