Machine: Операция создания с драйвером vmwarefusion не завершена

/ cc @frapposelli

это очень странно, очевидно, ваша машина была создана правильно (она выполнила runScriptInGuest правильно, что требует, чтобы машина была в слиянии с правильно запущенными инструментами vmware), но каким-то образом не удалось войти в процесс подготовки.

@ehazlett - это двоичные файлы, созданные из master ?

Дайте мне знать, если вам нужно, чтобы я запустил какую-нибудь помощь / скрипт отладки. Счастливый
помогать.

13 августа 2015 г. в 07:26, Фабио Раппоселли [email protected]
написал:

это _очень_ странно, видимо ваша машина была создана правильно (это
правильно выполнил runScriptInGuest, что требует, чтобы компьютер был включен
в слиянии с инструментами vmware правильно работает) но почему-то не удалось войти
процесс подготовки.

@ehazlett https://github.com/ehazlett - это те двоичные файлы, созданные из
мастер ?

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/machine/issues/1671#issuecomment -130605035.

Робин Бейт Буроп

Я наблюдаю такое же поведение. runScriptInGuest и компания. работают нормально, но vmrun list не перечисляет виртуальную машину докер-машины.

Попытка запустить виртуальную машину вручную через /Applications/VMware\ Fusion.app/Contents/Library/vmrun start ~/.docker/machine/machines/dev/dev.vmx приводит к:

Error: Unknown error

Я знаю, это не так полезно.

Я могу подтвердить эту проблему на Docker 1.8.1, Machine 0.4.1 и Mac OS X 10.10.4.

@mikew, не могли бы вы опубликовать файл vmware.log который находится в ~/.docker/machine/machines/dev ? это поможет устранить проблему.

Попытка ... не может даже добраться туда, где раньше не давала
Вот журнал этого прогона

Игнорируйте предыдущий комментарий, я забыл флаг -D . Вот еще одна попытка с журналами:

https://gist.github.com/mikew/9a20b864156f610923de#docker -output

https://gist.github.com/mikew/9a20b864156f610923de#vmware -fusion-logs

Здесь та же проблема. Мои данные на случай, если это поможет ...

Детали системы:

❯ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.5
BuildVersion:   14F27

❯ docker -v
Docker version 1.8.1, build d12ea79

❯ docker-machine -v
docker-machine version 0.4.1 (e2c88d6)

❯ /Applications/VMware\ Fusion.app/Contents/Library/vmrun
vmrun version 1.14.2 build-2779224

Лог-файлы:

docker-machine -D create --driver vmwarefusion fusion

~ / .docker / машина / машины / фьюжн / vmware.log

Хорошо, это странно, я очень старался, но не могу воспроизвести это вообще, это моя конфигурация системы:

~ ⟩ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.5
BuildVersion:   14F27
~ ⟩ docker -v
Docker version 1.8.1, build d12ea79
~ ⟩ docker-machine -v
docker-machine version 0.5.0-dev (49cbc6b)
~ ⟩ "/Applications/VMware Fusion.app/Contents/Library/vmware-vmx" -v

VMware Fusion Information:
VMware Fusion 8.0.0 build-2985594 Release

и docker-machine просто работает:

~ ⟩ docker-machine create -d vmwarefusion test-GH1671
Creating SSH key...
Creating VM...
Starting test-GH1671...
Waiting for VM to come online...
To see how to connect Docker to this machine, run: docker-machine env test-GH1671
~ ⟩ eval (docker-machine env test-GH1671)
~ ⟩ docker version
Client:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 19:47:52 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.8.1
 API version:  1.20
 Go version:   go1.4.2
 Git commit:   d12ea79
 Built:        Thu Aug 13 02:49:29 UTC 2015
 OS/Arch:      linux/amd64
~ ⟩ docker run busybox date
Unable to find image 'busybox:latest' locally
latest: Pulling from library/busybox
cf2616975b4a: Pull complete
6ce2e90b0bc7: Pull complete
8c2e06607696: Already exists
library/busybox:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:38a203e1986cf79639cfb9b2e1d6e773de84002feea2d4eb006b52004ee8502d
Status: Downloaded newer image for busybox:latest
Thu Aug 27 15:53:17 UTC 2015

Я настоятельно рекомендую вам, ребята, открыть вопрос технической поддержки по проблеме [msg.vnet.padrConflict] вы столкнулись, которая, скорее всего, является виновником вашей проблемы с Fusion.

[msg.vnet.padrConflict] MAC address 00:0C:29:3E:BF:B2 of adapter Ethernet0 is within the reserved address range or is in use by another virtual adapter on your system. Adapter Ethernet0 may not have network connectivity.

Круто, я разберусь. Виртуальная машина, созданная докер-машиной, не запускается, и при попытке ее запуска Fusion начинает вести себя очень странно. Он жалуется, что другая виртуальная машина уже запущена, при попытке запустить другую.

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.5
BuildVersion:   14F27

$ docker -v
Docker version 1.8.1, build d12ea79

$ docker-machine -v
docker-machine version 0.4.1 (e2c88d6)

$ "/Applications/VMware Fusion.app/Contents/Library/vmware-vmx" -v

VMware Fusion Information:
VMware Fusion 8.0.0 build-2985594 Release

Неудачно:

$ docker-machine create -d vmwarefusion test-GH1671
Creating SSH key...
Creating VM...
Starting test-GH1671...
Waiting for VM to come online...
Error creating machine: Maximum number of retries (60) exceeded
You will want to check the provider to make sure the machine and associated resources were properly removed.

Спасибо @frapposelli , тоже получил ошибку MAC-адреса. Рассмотрим открытие тикета с VMware.

@frapposelli Я обновил программное обеспечение на своей машине, и теперь оно соответствует версиям, опубликованным вами выше. Проблема сохраняется. В моем файле vmware.log я вижу ту же строку, которую вы упомянули ("msg.vnet.padrConflict"). Я бы открыл проблему с VMware, но если бы я сделал это, я не смог бы объяснить, откуда взялся выбранный MAC-адрес, как он был выбран и почему я ожидал, что он сработает. Мне просто нужно было бы отослать VMware к коду докер-машины. Не могли бы вы пролить свет на то, как докер-машина выбирает MAC-адрес?

@robinbb @ johnallen3d драйвер docker-machine использует шаблон vmx, встроенный в драйвер (см. здесь ), этот шаблон содержит директиву ethernet0.addressType = "generated" которая заставляет гипервизор автоматически создавать новый MAC при первой загрузке .

Для тех, кто открывает билеты в службу поддержки VMware, не стесняйтесь упоминать мое имя напрямую (чтобы они могли зацикливать меня внутри) и, пожалуйста, отправьте свой номер SR, как только вы его получите, чтобы я мог отслеживать их.

Еще раз спасибо

Я провел некоторую отладку и могу подтвердить, что "запуск vmrun", который запускается в Create () (https://github.com/docker/machine/blob/93366f22be4200bffb8b547a8a1f1052f3fb63e5/drivers/vmwarefusion/fusion_darwin7.go#L20 преуспеть. Vmware.log (~ / .docker / machine / machines / spinzo-vm / vmware.log) содержит следующие интересные строки:

2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: Msg_Post: Warning
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: [msg.vnet.padrConflict] MAC address 00:0C:29:87:83:87 of adapter 'Ethernet0' is within the reserved address range or is in use by another virtual adapter on your system. Adapter 'Ethernet0' may not have network connectivity.
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: ----------------------------------------
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: MsgIsAnswered: Using builtin default 'OK' as the answer for 'msg.vnet.padrConflict'
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VMXNET3 user: Ethernet0 Driver Info: version = 16974848 gosBits = 2 gosType = 1, gosVer = 0, gosMisc = 0
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:49.120-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:50.369-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)
2015-08-28T18:57:50.369-04:00| vcpu-0| I125: VNET: MACVNetPort_SetPADR: Ethernet0: can't set PADR (Resource busy)

Я могу подтвердить, что в моей системе нет других виртуальных машин с точно таким MAC-адресом.

Может это быть связано с № 1434? У меня была именно эта проблема с Fusion, установленным через homebrew-cask , и после того, как я установил вручную с помощью установщика для настольного компьютера, все работало правильно. (Если это так, я надеюсь, что это можно решить, поскольку я бы очень предпочел не устанавливать Fusion за пределами brewcask.)

Я использую VMWare Fusion 8.0 с MacOSX 10.10.5.

@mroth Может быть, но я действительно установил Fusion традиционным ручным способом.

Я не полагался на пиво для фьюжн или докер-машину. Я установил машину с помощью docker toolbox.

Я также использовал метод установки, поставляемый VMware.

Я переустановил vmware и установил 0 машин. Затем я сделал machine-create и при запуске имел ту же ошибку.

Однако мне удалось открыть файл vmx с помощью fusion и запустить его, это дало мне возможность обновить его, и я это сделал. Он запускается и отображается как работающий в docker-machine ls .

$ docker-machine ls
NAME    ACTIVE   DRIVER         STATE     URL                         SWARM
test2            vmwarefusion   Running   tcp://192.168.40.251:2376

Однако, если я попытаюсь использовать ssh, это даст мне

$ docker-machine ssh test2
exit status 255

$ docker-machine ip test2
192.168.40.251

$ docker-machine url test2
tcp://192.168.40.251:2376

$ docker-machine env test2
open /Users/***/.docker/machine/machines/test2/ca.pem: no such file or directory

$ docker-machine regenerate-certs test2
Regenerate TLS machine certs?  Warning: this is irreversible. (y/n): y
Regenerating TLS certificates
Error getting SSH command: exit status 255

У меня есть ошибка padrConflict в vmware.log. Однако, если я регенерирую MAC-адрес в слиянии, я получаю ошибку при выполнении docker-machine ls :

$ docker-machine ls
error getting URL for host test2: couldn't find MAC address in VMX file /Users/**/.docker/machine/machines/test2/test2.vmx
error getting URL for host test2: couldn't find MAC address in VMX file /Users/**/.docker/machine/machines/test2/test2.vmx
error determining if host is active for host test2: couldn't find MAC address in VMX file /Users/**/.docker/machine/machines/test2/test2.vmx

Хорошо, давайте удалим эту неудачную попытку: docker-machine rm test2

Теперь попробуем создать с помощью sudo:

$ sudo docker-machine create -d vmwarefusion test3 -D

Это успешно: /

Затем я chown -R эту машинную директорию с моим локальным пользователем.

$ sudo chown -R *** test3

где *** мой локальный пользователь

Теперь я удаляю файлы / каталоги lck и vmem . Откройте файл vmx в Fusion и запустите его, снова выполняя обновление, когда он дает мне возможность. Я могу запустить docker-machine ls и посмотреть, как он работает:

 docker-machine ls
NAME    ACTIVE   DRIVER         STATE     URL                         SWARM
test3            vmwarefusion   Running   tcp://192.168.40.128:2376

Теперь я могу установить свои локальные переменные env:

$ docker-machine env test3
export DOCKER_TLS_VERIFY="1"
export DOCKER_HOST="tcp://192.168.40.128:2376"
export DOCKER_CERT_PATH="/Users/***/.docker/machine/machines/test3"
export DOCKER_MACHINE_NAME="test3"
# Run this command to configure your shell:
# eval "$(docker-machine env test3)"

$ eval "$(docker-machine env test3)"

После этого docker-machine ssh работает!

$ docker-machine ssh test3
                        ##         .
                  ## ## ##        ==
               ## ## ## ## ##    ===
           /"""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ /  ===- ~~~
           \______ o           __/
             \    \         __/
              \____\_______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.8.1, build master : 7f12e95 - Thu Aug 13 03:24:56 UTC 2015
Docker version 1.8.1, build d12ea79

Надеюсь, это поможет служить временным решением и пролить свет на проблему.

Исходя из этого, я использую это:

https://gist.github.com/mikew/66e15a8be8eaf7d6043c

В результате docker-machine ls отображается как работающий и активный, однако ssh по-прежнему не работает с exit status 255 здесь.

Просмотр работающей виртуальной машины в Fusion показывает [guestinfo] Failed to get vmstats. что не может быть хорошим.

@mikew выглядит хорошо, но pkill не нужен. По какой-то причине это ломает вещи. Вот обновленный скрипт:

#!/bin/bash

name="${1:-test}"
dir="${HOME}/.docker/machine/machines/${name}"
vmx="${dir}/${name}.vmx"

echo "Running docker-machine create, will need sudo for vmwarefusion"
sudo docker-machine -D create -d vmwarefusion "${name}"

echo "Changing owner of ${dir} to ${USER}"
sudo chown -R "${USER}" "${dir}"

echo "Cleaning vmem/lck files"
rm -r \
  "${dir}"/*.vmem \
  "${dir}"/*.lck

echo "Opening in Fusion to upgrade"
open "${vmx}"

echo "You should be able to run 'eval \"\$(docker-machine env ${name})\"'"

FYI - это сработало для меня после обновления VMware Fusion до v8. Спасибо за устранение неполадок @geek и скрипт @mikew!

Что ж, похоже, что машина, созданная с помощью приведенного выше сценария, больше не будет доступна, если я приостановлю графический интерфейс Fusion или выполню docker-machine stop/start . Во всяком случае, это был мой недавний опыт.

то же самое здесь, к сожалению

• Майк Вятт

В понедельник, 31 августа 2015 г., в 23:44, Джон Аллен [email protected]
написал:

Что ж, похоже, что машина, созданная с помощью вышеуказанного
скрипт больше не доступен, если я приостанавливаю интерфейс Fusion или выполняю докер-машину
стоп / старт. Во всяком случае, это был мой недавний опыт.

-
Ответьте на это письмо напрямую или просмотрите его на GitHub
https://github.com/docker/machine/issues/1671#issuecomment -136557908.

@frapposelli , а вам удалось

Я обновил сценарий, в то время как pkill усугубил ситуацию, выполнение vmrun stop означает, что вам не нужно удалять файлы блокировки или что-то еще.

После того, как виртуальная машина завершит работу, просто измените разрешения, и все будет работать должным образом. Вам понадобится sudo только для первых нескольких команд.

https://gist.github.com/mikew/66e15a8be8eaf7d6043c

Спасибо за обновление @mikew , я планирую в ближайшее время попробовать. Однако возникает вопрос: нужна ли команда upgradevm ? Я заметил, что вы закомментировали суть.

Не на самом деле нет. Просто удаляет приглашение, если вы когда-нибудь захотите запустить виртуальную машину в самом Fusion.

@mikew спасибо за обновленный скрипт :)

После того, как вы запустите сценарий, сможете ли вы запустить docker-machine start и он работает, или есть другие шаги, которые вы выполняете вручную после запуска сценария?

Я мог делать все неоднократно, без необходимости использования sudo после начальной настройки.

Единственная проблема, которая возникла, заключалась в том, что при "запуске докер-машины", когда виртуальная машина была приостановлена, после этого у ssh были ошибки. Но после остановки и запуска виртуальной машины через докер-машину все заработало отлично.

Сценарий из @mikew 's gist у меня сработал, хотя мне пришлось запустить sudo docker-machine start xyz после его завершения и 'eval "$ (sudo docker-machine env xyz)"', чтобы все заработало.

@robinbb Если вам удобно использовать sudo docker-machine ... , сценарий вам вообще не нужен.

Странно, что sudo по-прежнему нужен. У вас установлена ​​копия Fusion в /Applications ?

@mikew 'sudo' требуется, потому что без него docker-machine имеет поведение, для которого я изначально открыл эту проблему, и, чтобы было ясно, виртуальная машина не будет запускаться с "docker-machine start xyz" после создания терпит неудачу.

Скрипт не требуется, но это удобный способ не забыть изменить разрешения для ~ / .docker / machine / machines / xyz. В противном случае даже выдача «докера» приведет к сбою разрешений.

@frapposelli Может ли тот факт, что моя umask установлен на 0077, вызвать проблемы с разрешениями, которые можно решить, выполнив docker-machine как root?

@frapposelli есть обновления?

@vmware ^^^?

@geek пока ничего, я дам вам знать, как только получу сообщение от

Пытался воспроизвести еще раз на днях, но не смог.

Моя проблема исчезла после обновления до El Capitan GM Candidate (15A282b)

У меня была эта проблема на El Capitan GM Candidate после обновления с VMware Fusion 6 до 8, а затем установки докер-машины.

Для меня перезагрузка решила проблему.

Я почти уверен, что это какая-то форма повреждения установки / проблемы с правами доступа / проблемы с конфигурацией с Fusion.

Тем, кто все еще сталкивается с этой проблемой, не могли бы вы попробовать полностью удалить Fusion (следуйте этой статье KB http://kb.vmware.com/kb/1017838) и переустановите? это должно устранить все существующие условия.

@frapposelli Я попробовал переустановить, не повезло :(

@frapposelli Я полностью удалил VMware Fusion в соответствии с указанными инструкциями и переустановил Fusion 8. Проблема осталась с теми же симптомами.

Связанный vmware.log находится здесь: https://dl.dropboxusercontent.com/u/31368575/vmware.log , больше сообщений «padrConflict» больше нет.

Я могу обойти проблему, введя команды docker-machine с помощью sudo.

Пробовал это несколько недель назад, попробовал сегодня снова. Кажется, я не могу заставить докер-машину со слиянием для создания и запуска, даже после обновления различных вещей / переустановки.

Название продукта: Mac OS X
Версия продукта: 10.10.5
Версия: 14F27
Докер версии 1.8.2, сборка 0a8c2e3
docker-machine версия 0.4.1 (HEAD)
vmrun версия 1.15.0 build-3094680

Я пробовал установку homebrew и загрузку в старом стиле VMWare Fusion .dmg.

Я столкнулся с этой проблемой : сценарии @geek у меня вообще не работают.

Получение этой ошибки даже при наличии ethernet0.address в dev.vmx .

Not there yet 1/60, error: couldn't find MAC address in VMX file /Users/msch/.docker/machine/machines/dev/dev.vmx

У меня все еще не получается с docker 1.9 и vmware fusion 8.0.2

Я получаю ту же ошибку, что и @MSch

- (~) $ -> sw_vers && docker -v && docker-machine -v && "/ Applications / VMware Fusion.app/Contents/Library/vmware-vmx" -v
Название продукта: Mac OS X
Версия продукта: 10.11.1
Версия: 15B42
Докер версии 1.9.0, сборка 76d6bc9
docker-machine версия 0.5.0 (HEAD)

Информация о VMware Fusion:
Выпуск VMware Fusion 8.0.2 build-3164312

Всем, у кого все еще есть проблема, не могли бы вы отправить запрос на обслуживание в службу поддержки VMware и опубликовать номер SR, чтобы я мог отслеживать? Я хочу закрепить это, но пока мне не удалось это воспроизвести.

@frapposelli есть ссылка и кого мы должны

@geek используйте эту ссылку в качестве отправной точки: https://www.vmware.com/support/file-sr/ и не стесняйтесь упоминать меня прямо в SR.

@frapposelli, не могли бы вы помочь мне направить меня к номеру которому я могу позвонить? Кажется, я нигде не могу попасть на сайт.

На данный момент я просто хочу вернуть деньги. Я не фанат Oracle, поэтому я выбрал VMWare, чтобы не использовать виртуальный бокс. VMWare заявила, что работает с докером. Сайт докеров даже делает это заявление и ссылается на ваш драйвер @frapposelli. Определенно не работает, как рекламируется, и на данный момент он сломался в течение нескольких месяцев.

Я ценю твою попытку помочь, @frapposelli.

Номера @geek перечислены здесь https://www.vmware.com/support/file-sr/file-sr-phone.html :

США и Канада: 1-877-4-VMWARE (1-877-486-9273) или 1-650-475-5345.

для международных номеров: https://www.vmware.com/support/contacts/us_support.html

Я создал SR по запросу: 15802564411.

Хорошо, теперь, когда я открыл, я понял это (по крайней мере, в моем случае). Я пользователь boxen и изначально установил vmware fusion 7 с помощью boxen (что означает использование homebrew / cask). Когда это было настроено, он создал символическую ссылку на файлы из приложения fusion7 в мой каталог bin homebrew. Когда я обновился до 8, он не был удален, поэтому докер-машина все еще использовала его для вызова vmrun. И я обнаружил, что бочонок тоже не смог удалить его обычными способами. Как-то казалось, что его больше не устанавливают, но все же он был там.

Чтобы исправить это, я выполнил следующие шаги:

• sudo rm -rf / opt / homebrew-cask / Caskroom / vmware-fusion
• sudo rm -f / opt / boxen / homebrew / bin / vm * (Отметьте этот, он соответствует всем тем, которые я хотел удалить)
• sudo rm -rf /Users/myusername/.docker /var/root/.docker (на всякий случай)

Затем я удалил приложение Fusion из папки Application и установил его заново из dmg, который я загрузил для обновления. После этого, когда я запустил докер-машину, все было чисто от начала до конца, без проблем.

Вот что мне нужно было сделать, чтобы это заработало:

• Полностью удалить VMWare Fusion
• Полностью удалить докер и докер-машину
• Установите VMWare Fusion, используя .dmg из VMWare. _Не_ используйте для этого бочку с пивом!
• заварить бочку установить докер докер-машину

Возникла проблема с разрешениями на vmrun. Если я устанавливаю Fusion с помощью brew-cask, vmrun не имеет необходимых разрешений, и установка setuid root по-прежнему не работает. Однако установка из .dmg прошла успешно.

Также кажется, что драйвер ищет vmrun при его установке и никогда не обновляет путь, даже если вы удалите Fusion через brew cask и установите его через .dmg.

У меня тоже были подобные проблемы, и, как предположил @robinbb , в моем случае это было вызвано

Любопытно, что сегодня утром я заметил, что стандартная версия docker-machine 0.5.1, похоже, нормально работает на El Capitan (который я обновил до вчера), так что это может быть меньшей проблемой в El Capitan. Однако я еще не полностью уверен.

Я столкнулся с той же проблемой с docker-toolbox 1.12-rc3, vmware fusion 8.1.
Вышеупомянутые сценарии не работали, но перезагрузка моего ноутбука сработала.

С VMWare Fusion версии 8.1.1 (3771013), macOS Sierra 10.12 и Docker версии 8.1.1 (3771013) эта проблема больше не возникает у меня. Закрытие.