File handling in Linux VMs partly broken on qa-set

RESOLVED WONTFIX

Status

Mozilla QA
Infrastructure
--
critical
RESOLVED WONTFIX
7 years ago
6 years ago

People

(Reporter: whimboo, Assigned: abillings)

Tracking

Details

(Reporter)

Description

7 years ago
It happens sometimes and goes away with a reboot. But a couple of days it reappeared on qa-set's Linux VMs. Right now it is clearly visible on the Ubuntu 64bit machine. 

Steps:
1. Change into the VM
2. Goto /mnt/hgfs/data/testing
3. Run ls -l

You will see a broken folder entry for 7.0 tests:

> d????????? ? ?   ?          ?                ? 7.0

Due to this problem our release testing scripts are failing. Not sure yet, why that is a problem. Al, would be great if you could look into it.
(Reporter)

Comment 1

7 years ago
Raising severity since it is still an issue. Geo, please comment on the bug as what you have already written via email. Thanks.
Severity: normal → critical
Yeah, bit me again on Friday while running tests. This time it was one of the generated staging folders that did it. 

I tried several other fixes, including moving the folder, restaging, etc, and everything I did ended up with something that had corrupted permissions.

Flipping Shared Folders off and on on that VM restored permissions, including for things that were previously "broken."

There's something about Fusion's mounting that's hosing us. My recommendation is we move off of their mounting system onto something more robust.
(Reporter)

Comment 3

7 years ago
Al, can you please have a look into that?
Assignee: nobody → abillings
(Assignee)

Comment 4

7 years ago
I'm completely baffled by this since it is only happening in one place.

That said, with the new VMware Fusion 4.0 and the new instance of tools, let's see if adding those late this week changes this situation.
(Reporter)

Comment 5

7 years ago
Al, do you have any update for us? Nearly 2 months have been passed by meanwhile. Any conclusion you got while working with VMware Fusion 4?
(Reporter)

Updated

7 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 6

7 years ago
I haven't seen this problem, personally. I'm not sure how often it occurs. Can anyone tell me whether it has occurred since we upgrade to VMware 4? 4.1 is out (as of Friday) as well and I'll be wanting to upgrade the boxes soon.
(Reporter)

Comment 7

7 years ago
AFAIR you have hit this issue once while you have tested the 3.6.24 release candidate builds. A restart of the box solved it for you.

I have seen something similar locally when I have created a new folder on the host system and tried to change into on Linux. The new folder hasn't been shown up as folder and I was not able to change into it. So it should probably be a wide-spread issue and doesn't only affect our testing machines.
(Reporter)

Comment 8

7 years ago
Al, so we wanna call this a wontfix?
(Assignee)

Comment 9

7 years ago
I think we do. With the rollout to the new infrastructure in the next month or so (I hope), we can work around this as a problem.
(Reporter)

Comment 10

7 years ago
An open question would still be how we handle the daily and l10n test-runs. For those the problem could still persist, except we also have a cluster or integrate it into the one for release testing. So probably we have to keep the bug open for now.
(Reporter)

Comment 11

6 years ago
Haven't heard about this problem for a while. Also I think it's not worth fixing given the goal to move to individual boxes and away from VMWare Fusion.

Most likely a wontfix. Closing as such.
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.