Open
Bug 969334
Opened 9 years ago
Updated 6 months ago
mozinstall should not magically try to find the mount point of the DMG
Categories
(Testing :: Mozbase, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: andrei, Unassigned, Mentored)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [lang=py])
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.
Comment 1•9 years ago
|
||
I will take this. Lets see if I can even figure out a working test.
Assignee: nobody → hskupin
Status: NEW → ASSIGNED
Hardware: x86 → All
Comment 2•9 years ago
|
||
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
Comment 3•9 years ago
|
||
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.
Comment 4•9 years ago
|
||
Sorry for the delay here. I will continue as soon as possible. Most likely on Monday.
Blocks: 980801
![]() |
||
Comment 6•9 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)
Updated•9 years ago
|
Comment 7•9 years ago
|
||
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
Whiteboard: [lang=py]
Updated•9 years ago
|
Status: ASSIGNED → NEW
Comment 8•9 years ago
|
||
FWIW, this is what we use in buildbot-land: http://hg.mozilla.org/build/tools/file/8a7c4b4d9536/release/common/unpack-diskimage.sh
Comment 9•5 years ago
|
||
Is this bug still relevant now? Or can this be closed?
Comment 10•5 years ago
|
||
This problem should still be present, yes.
Updated•6 months ago
|
Severity: major → S2
You need to log in
before you can comment on or make changes to this bug.
Description
•