Bug 14803

(In reply to Vitaly Lipatov from comment #0)
> Заметил, что wine vanilla 5.22 при создании префикса

При создании префикса да, такое есть.

> (да и дальше при каждом
> запуске любой программы) выдаёт
> 0050:err:ole:start_rpcss Failed to open RpcSs service

Однако при дальнейших запусках 'wine winver' не могу подтвердить ни с winehq
5.22, ни с wine-staging 5.22.

Замечу, что я выполняю wine из дерева сборки и не устанавливаю в систему.
Может в этом источник разницы в поведении?

Собственно все сообщения при запуске очень неприятные, и, похоже, это всё ещё и запуск тормозит:

0050:err:service:validate_context_handle Handle is of an invalid type (1, 2)
0060:err:ole:start_rpcss Failed to open RpcSs service
0060:err:ole:start_rpcss Failed to open RpcSs service
003c:fixme:service:scmdatabase_autostart_services Auto-start service L"wineusb" failed to start: 1053
0080:err:service:validate_context_handle Handle is of an invalid type (1, 2)

(Ответ Dmitry Timoshkov на комментарий #2)
> Замечу, что я выполняю wine из дерева сборки и не устанавливаю в систему.
> Может в этом источник разницы в поведении?
Я надеюсь, что источник разницы в том, что у вас wineserver не успел завершиться.

(In reply to Vitaly Lipatov from comment #4)
> (Ответ Dmitry Timoshkov на комментарий #2)
> > Замечу, что я выполняю wine из дерева сборки и не устанавливаю в систему.
> > Может в этом источник разницы в поведении?
> Я надеюсь, что источник разницы в том, что у вас wineserver не успел
> завершиться.

Нет, winserver завершен, я это проверяю обязательно.

Похоже, что это новая регрессия: https://bugs.winehq.org/show_bug.cgi?id=50168

(In reply to Dmitry Timoshkov from comment #6)
> Похоже, что это новая регрессия:
> https://bugs.winehq.org/show_bug.cgi?id=50168

Я не могу воспроизвести локально после:

1. ./configure --prefix=/home/dmitry/test --disable-tests
2. make
3. make install
4. rm -rf ~/.wine
5. /home/dmitry/test/bin/wine winver
Ожидаемо получаю
0050:err:ole:start_rpcss Failed to open RpcSs service
6. /home/dmitry/test/bin/wineserver -k
'ps ax | grep wine' кроме себя ничего не находит
7. /home/dmitry/test/bin/wine winver
Ошибки как после шага 5 нет.

Виталий, можете повторить мои шаги и сообщить результат?

Повторил следующие действия:

1. ./configure --prefix=/srv/mais/Projects/test --disable-tests
2. make
3. make install
4. rm -rf ~/.wine
5.  /srv/mais/Projects/wine-vanilla/wine winver
Присутствует ошибка 0050:err:ole:start_rpcss Failed to open RpcSs service
6. /srv/mais/Projects/test/bin/wineserver -k
'ps ax | grep wine' -  нашел только '107724 pts/0    S+     0:00 grep wine'
7. /srv/mais/Projects/wine-vanilla/wine winwer 
Как ни странно, но ошибка пропала

В 5.20 при каждом запуске также
0060:err:ole:start_rpcss Failed to open RpcSs service

(In reply to Vitaly Lipatov from comment #9)
> В 5.20 при каждом запуске также
> 0060:err:ole:start_rpcss Failed to open RpcSs service

Изменилась ли ситуация с wine-6.0-rc1?

Я сейчас зашел на builder32 и там не наблюдаю проблему:

[dtimoshkov@builder32 ~]$ wine --version
wine-6.0 (Staging)
[dtimoshkov@builder32 ~]$ wine cmd
002c:fixme:winediag:LdrInitializeThunk wine-staging 6.0 is a testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org.
0060:err:explorer:initialize_display_settings Failed to query current display settings for L"\\\\.\\DISPLAY1".
Microsoft Windows 6.1.7601

Z:\home\dtimoshkov>exit
[dtimoshkov@builder32 ~]$

*** Bug 14961 has been marked as a duplicate of this bug. ***

Нужно провести bisect согласно
https://wiki.winehq.org/Regression_Testing
и найти коммит, ломающий работу.

Вводные данные:
1. Ошибка проявляется в появлении при повторном запуске wine сообщения 0060:err:ole:start_rpcss Failed to open RpcSs service
2. В wine-5.20 ошибки нет. В wine-6.2 ошибка есть.
3. Сборку и тестирование проводим на builder-p8
4. Для сборки используем jmake вместо make
5. Репозиторий wine: git://source.winehq.org/git/wine.git
6. Для проверки: WINEPREFIX=~/.wine-test-p8 wine notepad

Предположительно причина заключается в старом ядре ovz 2.6.32, но работа сломалась в каком-то коммите.

написал скрипт для автоматического bisect

#!/bin/bash
fatal()
{
    echo fatal
    exit 1
}
git bisect start
git bisect good wine-5.20
git bisect bad wine-6.2
export WINEPREFIX=~/.wine-test-p8
for number in 1 2 3 4 5 6 7 8 9 10
do
var1=0
rm -rf $WINEPREFIX
./configure --verbose >> $0.log 2>&1 && jmake >> $0.log 2>&1 || fatal
wine regsvr32 >> $0.log 2>&1 
wineserver -k
wine regsvr32 2>&1 | grep "RpcSs service" && var1=1 #to start and to open
if [ $var1 = 1 ] ; then
    git bisect bad
    echo bad
else 
    git bisect good
    echo good
fi 
done

(In reply to Павел Солдатов from comment #14)
> написал скрипт для автоматического bisect
> 
> #!/bin/bash
> fatal()
> {
>     echo fatal
>     exit 1
> }
> git bisect start
> git bisect good wine-5.20
> git bisect bad wine-6.2
> export WINEPREFIX=~/.wine-test-p8
> for number in 1 2 3 4 5 6 7 8 9 10
> do
> var1=0
> rm -rf $WINEPREFIX
> ./configure --verbose >> $0.log 2>&1 && jmake >> $0.log 2>&1 || fatal

'./configure --disable-tests' значительно ускорит сборку, так как отключит
компиляцию тестов.

> wine regsvr32 >> $0.log 2>&1 
> wineserver -k
> wine regsvr32 2>&1 | grep "RpcSs service" && var1=1 #to start and to open
> if [ $var1 = 1 ] ; then
>     git bisect bad
>     echo bad
> else 
>     git bisect good
>     echo good
> fi 
> done

(Ответ Павел Солдатов на комментарий #14)
> написал скрипт для автоматического bisect
> 
> #!/bin/bash
> fatal()
> {
>     echo fatal
>     exit 1
> }
> git bisect start
> git bisect good wine-5.20
> git bisect bad wine-6.2
Начальные утверждения о good и bad нужно проверить путём вызова функций сборки и проверки на этих тегах.

> export WINEPREFIX=~/.wine-test-p8
> for number in 1 2 3 4 5 6 7 8 9 10
> do
> var1=0
> rm -rf $WINEPREFIX
> ./configure --verbose >> $0.log 2>&1 && jmake >> $0.log 2>&1 || fatal
сборку нужно вынести в отдельную функцию

> wine regsvr32 >> $0.log 2>&1 
> wineserver -k
> wine regsvr32 2>&1 | grep "RpcSs service" && var1=1 #to start and to open
Тестирование нужно вынести в отдельную функцию

Переписал скрипт gitlab.eterfund.ru/wine/wine-rebased-utils/blob/master/bisect/slice.sh
Проблема появляется при использовании swine. Если использовать wine-5.20 или wine-6.2 сообщение  RpcSs service возникает только при первом запуске.

(In reply to Павел Солдатов from comment #17)
> Переписал скрипт
> gitlab.eterfund.ru/wine/wine-rebased-utils/blob/master/bisect/slice.sh
> Проблема появляется при использовании swine. Если использовать wine-5.20 или
> wine-6.2 сообщение  RpcSs service возникает только при первом запуске.

Видимо следующим шагом нужно выяснить, что именно не так с swine, что
ведет к такой проблеме. Насколько я понимаю, проблема воспроизводится
так же только с определенной версией ядра. Поэтому закрывать задачу рано.

(Ответ Dmitry Timoshkov на комментарий #18)
> (In reply to Павел Солдатов from comment #17)
> > Переписал скрипт
> > gitlab.eterfund.ru/wine/wine-rebased-utils/blob/master/bisect/slice.sh
> > Проблема появляется при использовании swine. Если использовать wine-5.20 или
> > wine-6.2 сообщение  RpcSs service возникает только при первом запуске.
> 
> Видимо следующим шагом нужно выяснить, что именно не так с swine, что
> ведет к такой проблеме. Насколько я понимаю, проблема воспроизводится
> так же только с определенной версией ядра. Поэтому закрывать задачу рано.
Да, выяснилось, что проблема только на Сизифе (новый glibc?) и старом ядре (2.6.32).
Кроме как отлаживать на конкретной машине, я пока не вижу вариантов.

Дополнительное тестирование с помощью копирования имеющихся у меня готовых
сборок Wine (wine-4.0.x, wine-5.0.x, wine-6.x) и уточнения нужного окна с
помощью сборки wine-5.10 для проведенения теста на регресиию показало, что
регрессия появилась между wine-5.10 и wine-5.20.

Павел, можете выполнить тест на регрессию своим скриптом между этими версиями?

Павел, можете выполнить тест на регрессию своим скриптом между указанными
версиями wine?

 git bisect good
e9090e1c903578b30118ce9559c1824361abc6da is the first bad commit
commit e9090e1c903578b30118ce9559c1824361abc6da
Author: Hans Leidekker <hans@codeweavers.com>
Date:   Mon Sep 7 14:10:13 2020 +0200

    advapi32: Reimplement SystemFunction036 using system interrupt information.
    
    Signed-off-by: Hans Leidekker <hans@codeweavers.com>
    Signed-off-by: Alexandre Julliard <julliard@winehq.org>

 dlls/advapi32/crypt.c | 62 +++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 48 insertions(+), 14 deletions(-)

Реверт этого коммита в новейшем wine-6.4 с помощью

$ git show e9090e1c903578b30118ce9559c1824361abc6da | patch -p1 -R
patching file dlls/advapi32/crypt.c
Hunk #1 succeeded at 2381 (offset -41 lines).
Hunk #2 succeeded at 2395 (offset -41 lines).

и исправление сборки с помощью замен open/read/close на _lopen/_lread/_lclose,
замена O_RDONLY на OF_READ и проверка работы собранного после этого wine-6.4
на сервере показали, что такая сборка успешно работает.

(In reply to Dmitry Timoshkov from comment #22)
>  git bisect good
> e9090e1c903578b30118ce9559c1824361abc6da is the first bad commit
> commit e9090e1c903578b30118ce9559c1824361abc6da
> Author: Hans Leidekker <hans@codeweavers.com>
> Date:   Mon Sep 7 14:10:13 2020 +0200
> 
>     advapi32: Reimplement SystemFunction036 using system interrupt
> information.
>     
>     Signed-off-by: Hans Leidekker <hans@codeweavers.com>
>     Signed-off-by: Alexandre Julliard <julliard@winehq.org>
> 
>  dlls/advapi32/crypt.c | 62
> +++++++++++++++++++++++++++++++++++++++------------
>  1 file changed, 48 insertions(+), 14 deletions(-)
> 
> Реверт этого коммита в новейшем wine-6.4 с помощью
> 
> $ git show e9090e1c903578b30118ce9559c1824361abc6da | patch -p1 -R
> patching file dlls/advapi32/crypt.c
> Hunk #1 succeeded at 2381 (offset -41 lines).
> Hunk #2 succeeded at 2395 (offset -41 lines).
> 
> и исправление сборки с помощью замен open/read/close на
> _lopen/_lread/_lclose,
> замена O_RDONLY на OF_READ и проверка работы собранного после этого wine-6.4
> на сервере показали, что такая сборка успешно работает.

Добавил комментарий в официальный баг репорт.

Created attachment 4221 [details]
revert

Прикладываю патч с ревертом и необходимыми после этого исправлениями
сборки для wine-6.4.

Ханс ответил, что скорее всего это одна из разновидностей проблемы, описанной
в https://bugs.winehq.org/show_bug.cgi?id=49938, где glibc возвращает ENOSYS
из реализации getrandom(): https://bugs.winehq.org/show_bug.cgi?id=49938#c9

Т.е. сборка Wine производится на системе с новым glibc, в котором определен
#ifdef __NR_getrandom (ядро 3.17, glibc 2.25), а выполнение - на старом.

(In reply to Dmitry Timoshkov from comment #25)
> Ханс ответил, что скорее всего это одна из разновидностей проблемы, описанной
> в https://bugs.winehq.org/show_bug.cgi?id=49938, где glibc возвращает ENOSYS
> из реализации getrandom(): https://bugs.winehq.org/show_bug.cgi?id=49938#c9
> 
> Т.е. сборка Wine производится на системе с новым glibc, в котором определен
> #ifdef __NR_getrandom (ядро 3.17, glibc 2.25), а выполнение - на старом.

Я спросил Ханса, можно ли добавить детектирование работоспособности getrandom(),
и он приложил патч для тестирования. С предложенным патчом проблема решилась:
https://bugs.winehq.org/attachment.cgi?id=69618

(In reply to Dmitry Timoshkov from comment #26)
> > Ханс ответил, что скорее всего это одна из разновидностей проблемы, описанной
> > в https://bugs.winehq.org/show_bug.cgi?id=49938, где glibc возвращает ENOSYS
> > из реализации getrandom(): https://bugs.winehq.org/show_bug.cgi?id=49938#c9
> > 
> > Т.е. сборка Wine производится на системе с новым glibc, в котором определен
> > #ifdef __NR_getrandom (ядро 3.17, glibc 2.25), а выполнение - на старом.
> 
> Я спросил Ханса, можно ли добавить детектирование работоспособности
> getrandom(),
> и он приложил патч для тестирования. С предложенным патчом проблема решилась:
> https://bugs.winehq.org/attachment.cgi?id=69618

Ханс отправил патч для принятия в winehq:
https://source.winehq.org/patches/data/201784

(In reply to Dmitry Timoshkov from comment #27)
> > > Ханс ответил, что скорее всего это одна из разновидностей проблемы, описанной
> > > в https://bugs.winehq.org/show_bug.cgi?id=49938, где glibc возвращает ENOSYS
> > > из реализации getrandom(): https://bugs.winehq.org/show_bug.cgi?id=49938#c9
> > > 
> > > Т.е. сборка Wine производится на системе с новым glibc, в котором определен
> > > #ifdef __NR_getrandom (ядро 3.17, glibc 2.25), а выполнение - на старом.
> > 
> > Я спросил Ханса, можно ли добавить детектирование работоспособности
> > getrandom(),
> > и он приложил патч для тестирования. С предложенным патчом проблема решилась:
> > https://bugs.winehq.org/attachment.cgi?id=69618
> 
> Ханс отправил патч для принятия в winehq:
> https://source.winehq.org/patches/data/201784

Патч принят:
https://source.winehq.org/git/wine.git/?a=commit;h=e6407c39bab62838081f30868cb2ac1362029bdf

Я еще раз проверил свою сборку через swine и она работает.

Отмечаю эту задачу как решенную.

P.S.
Виталий, пожалуйста поручите тестировщикам проверить исправление, например
как описано в https://bugs.etersoft.ru/show_bug.cgi?id=14961 с помощью
установки vcrun2010 и dotnet35sp1.

(In reply to Dmitry Timoshkov from comment #28)
> (In reply to Dmitry Timoshkov from comment #27)
> > > > Ханс ответил, что скорее всего это одна из разновидностей проблемы, описанной
> > > > в https://bugs.winehq.org/show_bug.cgi?id=49938, где glibc возвращает ENOSYS
> > > > из реализации getrandom(): https://bugs.winehq.org/show_bug.cgi?id=49938#c9
> > > > 
> > > > Т.е. сборка Wine производится на системе с новым glibc, в котором определен
> > > > #ifdef __NR_getrandom (ядро 3.17, glibc 2.25), а выполнение - на старом.
> > > 
> > > Я спросил Ханса, можно ли добавить детектирование работоспособности
> > > getrandom(),
> > > и он приложил патч для тестирования. С предложенным патчом проблема решилась:
> > > https://bugs.winehq.org/attachment.cgi?id=69618
> > 
> > Ханс отправил патч для принятия в winehq:
> > https://source.winehq.org/patches/data/201784
> 
> Патч принят:
> https://source.winehq.org/git/wine.git/?a=commit;
> h=e6407c39bab62838081f30868cb2ac1362029bdf

При необходимости этот коммит можно прикладывать к предыдущим версиям Wine.

> Я еще раз проверил свою сборку через swine и она работает.
> 
> Отмечаю эту задачу как решенную.
> 
> P.S.
> Виталий, пожалуйста поручите тестировщикам проверить исправление, например
> как описано в https://bugs.etersoft.ru/show_bug.cgi?id=14961 с помощью
> установки vcrun2010 и dotnet35sp1.

(Ответ Dmitry Timoshkov на комментарий #25)
> Ханс ответил, что скорее всего это одна из разновидностей проблемы, описанной
> в https://bugs.winehq.org/show_bug.cgi?id=49938, где glibc возвращает ENOSYS
> из реализации getrandom(): https://bugs.winehq.org/show_bug.cgi?id=49938#c9
> 
> Т.е. сборка Wine производится на системе с новым glibc, в котором определен
> #ifdef __NR_getrandom (ядро 3.17, glibc 2.25), а выполнение - на старом.
Ох, что же я не сказал раньше про getrandom... Это единственная и основная проблема с новым glibc...



(Ответ Dmitry Timoshkov на комментарий #26)
> (In reply to Dmitry Timoshkov from comment #25)
> > Ханс ответил, что скорее всего это одна из разновидностей проблемы, описанной
> > в https://bugs.winehq.org/show_bug.cgi?id=49938, где glibc возвращает ENOSYS
> > из реализации getrandom(): https://bugs.winehq.org/show_bug.cgi?id=49938#c9
> > 
> > Т.е. сборка Wine производится на системе с новым glibc, в котором определен
> > #ifdef __NR_getrandom (ядро 3.17, glibc 2.25), а выполнение - на старом.
> 
> Я спросил Ханса, можно ли добавить детектирование работоспособности
> getrandom(),
> и он приложил патч для тестирования. С предложенным патчом проблема решилась:
> https://bugs.winehq.org/attachment.cgi?id=69618
Спасибо большое!
Сделал с ним сборку, всё работает.

Наблюдаю ошибку
start_rpcss Failed to open RpcSs service
на первоначальной создании бутылки в нормальной системе (проверял и на 32 битах и на 64 битах) с нестарым ядром 5.10.52-std-def-alt1

[wine@winestaging64:peoples/lav/test2 .wine-test2]$wine64 notepad
002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
002c:fixme:winediag:LdrInitializeThunk wine-staging 6.14 is a testing version containing experimental patches.
002c:fixme:winediag:LdrInitializeThunk Please mention your exact version when filing bug reports on winehq.org.
0048:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0050:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0)
0050:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0050:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0050:err:ole:apartment_get_local_server_stream Failed: 0x80004002
0048:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002
0048:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
0048:err:ole:apartment_get_local_server_stream Failed: 0x80004002
0048:err:ole:start_rpcss Failed to open RpcSs service

(In reply to Vitaly Lipatov from comment #31)
> Наблюдаю ошибку
> start_rpcss Failed to open RpcSs service
> на первоначальной создании бутылки в нормальной системе (проверял и на 32
> битах и на 64 битах) с нестарым ядром 5.10.52-std-def-alt1
> 
> [wine@winestaging64:peoples/lav/test2 .wine-test2]$wine64 notepad
> 002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly
> L"Microsoft.Windows.Common-Controls" (6.0.0.0)
> 002c:fixme:winediag:LdrInitializeThunk wine-staging 6.14 is a testing
> version containing experimental patches.
> 002c:fixme:winediag:LdrInitializeThunk Please mention your exact version
> when filing bug reports on winehq.org.
> 0048:fixme:actctx:parse_depend_manifests Could not find dependent assembly
> L"Microsoft.Windows.Common-Controls" (6.0.0.0)
> 0050:fixme:actctx:parse_depend_manifests Could not find dependent assembly
> L"Microsoft.Windows.Common-Controls" (6.0.0.0)
> 0050:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr
> 0x80004002
> 0050:err:ole:CoMarshalInterface Failed to marshal the interface
> {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
> 0050:err:ole:apartment_get_local_server_stream Failed: 0x80004002
> 0048:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr
> 0x80004002
> 0048:err:ole:CoMarshalInterface Failed to marshal the interface
> {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002
> 0048:err:ole:apartment_get_local_server_stream Failed: 0x80004002
> 0048:err:ole:start_rpcss Failed to open RpcSs service

А в чем разница этой системы и той, что была исправлена в
https://bugs.etersoft.ru/show_bug.cgi?id=14803#c30 ? Какая сейчас в системе
версия glibc?

Исправление для https://bugs.winehq.org/show_bug.cgi?id=50168 было включено
в wine-6.5, поэтому если проблема не в getrandom(), то видимо нужно попробовать
выполнить тест на регрессию, преварительно убедившись, что в wine-6.5 этой
проблемы нет.

(Ответ Dmitry Timoshkov на комментарий #32)
...
> А в чем разница этой системы и той, что была исправлена в
> https://bugs.etersoft.ru/show_bug.cgi?id=14803#c30 ? Какая сейчас в системе
> версия glibc?
Разница полная, тут новое ядро и glibc.
glibc-2.32-alt4
 
> Исправление для https://bugs.winehq.org/show_bug.cgi?id=50168 было включено
> в wine-6.5, поэтому если проблема не в getrandom(), то видимо нужно
> попробовать
> выполнить тест на регрессию, преварительно убедившись, что в wine-6.5 этой
> проблемы нет.
Я думаю, что важно утвердить, какие сообщения могут появляться. А точнее, отключить ненужный шум:
https://bugs.etersoft.ru/show_bug.cgi?id=15212

В прошлый раз вы мне писали, что у вас тоже появляется ошибка про open RpcSs, при инициализации. Сейчас то же самое.

Но я посмотрел, что вроде сейчас дело не в том, что не запускается rpmcss.exe, а в том, что его никто не запускает.

(In reply to Vitaly Lipatov from comment #33)
> > Исправление для https://bugs.winehq.org/show_bug.cgi?id=50168 было включено
> > в wine-6.5, поэтому если проблема не в getrandom(), то видимо нужно
> > попробовать
> > выполнить тест на регрессию, преварительно убедившись, что в wine-6.5 этой
> > проблемы нет.
> Я думаю, что важно утвердить, какие сообщения могут появляться. А точнее,
> отключить ненужный шум:
> https://bugs.etersoft.ru/show_bug.cgi?id=15212
> 
> В прошлый раз вы мне писали, что у вас тоже появляется ошибка про open
> RpcSs, при инициализации. Сейчас то же самое.
> 
> Но я посмотрел, что вроде сейчас дело не в том, что не запускается
> rpmcss.exe, а в том, что его никто не запускает.

А, так это только при создании префикса, а потом этого сообщения нет? Тогда
это можно игнорировать совершенно спокойно, я ранее уже объяснял, почему
при создании префикса появляется это сообщение - так как в реестр еще не
содержит необходимой информации.

(Ответ Dmitry Timoshkov на комментарий #34)
...
> А, так это только при создании префикса, а потом этого сообщения нет? Тогда
> это можно игнорировать совершенно спокойно, я ранее уже объяснял, почему
> при создании префикса появляется это сообщение - так как в реестр еще не
> содержит необходимой информации.

Ага. Ну и на Fedora я увидел ту же проблему. Тогда мы проведём исследование, а потом вернёмся.

Закрываю, не вернулись.