Closed Bug 1018439 Opened 10 years ago Closed 10 years ago

Mn tests on Windows 8 fail with: WindowsError: [Error 740] The requested operation requires elevation


(Release Engineering :: General, defect)

Windows 8
Not set


(Not tracked)



(Reporter: jgriffin, Assigned: jgriffin)




(2 files)

We've enabled Mn tests on Windows on cedar; the Windows 8 runs are failing with:

11:10:21     INFO - Detecting whether we're running mozinstall >=1.0...
11:10:21     INFO - Getting output from command: ['c:\\talos-slave\\test\\build\\venv\\Scripts\\mozinstall', '-h']
11:10:21     INFO - Copy/paste: c:\talos-slave\test\build\venv\Scripts\mozinstall -h
11:10:21     INFO - Running post-action listener: _resource_record_post_action
11:10:21    FATAL - Uncaught exception: Traceback (most recent call last):
11:10:21    FATAL -   File "C:\slave\test\scripts\mozharness\base\", line 1217, in run
11:10:21    FATAL -     self.run_action(action)
11:10:21    FATAL -   File "C:\slave\test\scripts\mozharness\base\", line 1159, in run_action
11:10:21    FATAL -     self._possibly_run_method(method_name, error_if_missing=True)
11:10:21    FATAL -   File "C:\slave\test\scripts\mozharness\base\", line 1100, in _possibly_run_method
11:10:21    FATAL -     return getattr(self, method_name)()
11:10:21    FATAL -   File "scripts/scripts/", line 353, in install
11:10:21    FATAL -     super(MarionetteTest, self).install()
11:10:21    FATAL -   File "C:\slave\test\scripts\mozharness\mozilla\testing\", line 340, in install
11:10:21    FATAL -     output = self.get_output_from_command(cmd + ['-h'])
11:10:21    FATAL -   File "C:\slave\test\scripts\mozharness\base\", line 790, in get_output_from_command
11:10:21    FATAL -     cwd=cwd, stderr=tmp_stderr, env=env)
11:10:21    FATAL -   File "c:\mozilla-build\python27\lib\", line 679, in __init__
11:10:21    FATAL -     errread, errwrite)
11:10:21    FATAL -   File "c:\mozilla-build\python27\lib\", line 896, in _execute_child
11:10:21    FATAL -     startupinfo)
11:10:21    FATAL - WindowsError: [Error 740] The requested operation requires elevation
11:10:21    FATAL - Running post_fatal callback...
11:10:21    FATAL - Exiting -1

This seems to be a problem with the mozharness script; I can look at the other scripts running on Windows 8 to see if I can figure out what the solution is.
This is how we handle mozinstall on Windows, apparently, looking at the desktop configs.
Attachment #8431962 - Flags: review?(jlund)
Assignee: nobody → jgriffin
Comment on attachment 8431962 [details] [diff] [review]
Use Windows-specific mozinstall wrapper on Windows,

lgtm based on the same logic you found: i.e. what talos/ and unittests/ do.

I am not certain on where mozinstall-script comes from but it looks like both the pre virtualenv actions use mozbase_requirements.txt for modules needed

so I would imagine that these virtualenvs should both have the same
Attachment #8431962 - Flags: review?(jlund) → review+
Comment on attachment 8431962 [details] [diff] [review]
Use Windows-specific mozinstall wrapper on Windows,
Attachment #8431962 - Flags: checked-in+
In production with reconfig on 2014-06-04 02:19 PT
My last attempt at cargo-culting didn't quite work, because mozinstall was being extracted to c:/talos-slave due to the virtualenv_path setting in the config file, but mozinstall path in the config was pointing to c:/slave.  I think the best solution, from the unittest win config file, is to use a relative virtualenv_path.
Attachment #8434971 - Flags: review?(jlund)
Comment on attachment 8434971 [details] [diff] [review]
Fix virtualenv path on Windows,

huh, didn't realize that query_virtualenv_path() will set the path in the 'build' dir (abs_work_dir) if virtualenv_path was not absolute. Your patch and the unittest win config way makes it seem like it will be relative to where the script was called (base_work_dir)

Looking at Talos I guess we give abs paths in the config directly

This approach feels more explicit but I suppose it binds us to having the abs_work_dir be in {base_work_dir}/build.

Tangent aside, both ways make sense; it's just too bad we are not more consistent across our configs :)
Attachment #8434971 - Flags: review?(jlund) → review+
Yes, I agree it would be nice if there were a canonical way to handle these.
Closed: 10 years ago
Resolution: --- → FIXED
In production.
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.