Bug 37050

Summary: инсталятор падает в альтераторе после установки пакетов на настройке сети
Product: Sisyphus Reporter: Michael Shigorin <mike>
Component: alterator-pkgAssignee: manowar <manowar>
Status: CLOSED WONTFIX QA Contact: qa-sisyphus
Severity: blocker    
Priority: P3 CC: aen, antohami, boyarsh, imz, inger, iv, klark, manowar, nbr, sem, shaba, zerg
Version: unstableKeywords: regression
Hardware: e2k   
OS: Linux   
Attachments:
Description Flags
фрагмент /tmp/install2.log при e2k#23240 _с_ alterator-pkg 2.7.2
none
/var/run/alteratord/alteratord.log до обратного монтирования
none
/usr/lib/alterator/backend3/preinstall использованный для отладки
none
strace момента падения: процесс alteratord
none
strace момента падения: процесс alterator-qt-browser
none
strace момента падения: процесс alterator-wizard
none
strace происходящего в preinstall на новом образе 8СП в норме
none
strace происходящего в preinstall на старом образе 8СП (падение)
none
Все логи по результату падения на старом образе 8СП
none
Исправленный preinstall
none
Исправлятор проблемы на 8СП x86_64/EFI
none
Исправлятор проблемы на 8СП x86_64/EFI #2 none

Description Michael Shigorin 2019-07-22 15:22:57 MSK
Наткнулся на проблему работы инсталятора в части альтератора на sisyphus_e2k
(alterator 5.4-alt1, alterator-pkg 2.7.2-alt1, installer 1.9.0-alt1); падает сразу после успешно прошедшей установки пакетов, хвост /tmp/install2.log выглядит так:

Errors from xkbcomp are not fatal to the X server
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /usr/sbin/alterator-wizard
;;; compiled /tmp/.cache/guile/ccache/2.0-LE-8-2.0/usr/sbin/alterator-wizard.go
WARNING: (alterator session state): imported module (alterator algo) overrides core binding `call-with-current-continuation'
WARNING: (alterator lookout evaluation): imported module (alterator presentation events) overrides core binding `when'
frame:on-next is deprecated, use wizard-bind instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:on-next is deprecated, use wizard-bind instead
frame:on-back is deprecated, use wizard-bind instead
frame:on-next is deprecated, use wizard-bind instead
frame:back-activity is deprecated, use wizard-update-activity instead
frame:on-next is deprecated, use wizard-bind instead
frame:on-back is deprecated, use wizard-bind instead
frame:back-activity is deprecated, use wizard-update-activity instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:on-back is deprecated, use wizard-bind instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:back-activity is deprecated, use wizard-update-activity instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:back-activity is deprecated, use wizard-update-activity instead
frame:on-back is deprecated, use wizard-bind instead
frame:on-next is deprecated, use wizard-bind instead
Backtrace:
In interfaces/guile/transport/pipe-channel.scm:
  13: 19 [process-incoming #<procedure b42c40 at interfaces/guile/telegraph.scm:21:7 (cmd)> ...]
In interfaces/guile/lookout.scm:
  96: 18 [#<procedure b3a330 at interfaces/guile/lookout.scm:94:2 (cmds next)> # ...]
  84: 17 [lookout-main # ...]
  61: 16 [mailbox-request #<procedure b42460 at interfaces/guile/object.scm:79:3 args> ...]
In srfi/srfi-1.scm:
 616: 15 [for-each #<procedure 1009ae0 at interfaces/guile/mailbox.scm:28:3 (info)> ...]
In interfaces/guile/mailbox.scm:
  37: 14 [#<procedure 1009ae0 at interfaces/guile/mailbox.scm:28:3 (info)> #]
In ice-9/eval.scm:
 432: 13 [eval # #]
In interfaces/guile/lookout/goto.scm:
  66: 12 [document:replace-in-widget #<procedure c4fb00 at interfaces/guile/object.scm:79:3 args> ...]
  32: 11 [clean-widget #<procedure c4fb00 at interfaces/guile/object.scm:79:3 args> ...]
In interfaces/guile/presentation/container.scm:
 212: 10 [#<procedure c4fbe0 (self thunk)> #<procedure c4fb00 at interfaces/guile/object.scm:79:3 args> ...]
In ice-9/eval.scm:
 432: 9 [eval # #]
 432: 8 [eval # #]
 411: 7 [eval # #]
In interfaces/guile/logfile.scm:
  37: 6 [#<procedure b3f120 at interfaces/guile/logfile.scm:34:4 (cmds next)> # ...]
In interfaces/guile/d.scm:
 162: 5 [#<procedure aa1c00 at interfaces/guile/d.scm:161:2 (cmds next)> # ...]
In srfi/srfi-1.scm:
 643: 4 [append-map #<procedure d-query (cmd)> (#)]
 575: 3 [map #<procedure d-query (cmd)> (("/net-eth/avail_ipv" language # ...))]
In unknown file:
   ?: 2 [request-unix-server "/var/run/alteratord/.socket" ...]
In ice-9/boot-9.scm:
 105: 1 [#<procedure b3e700 at ice-9/boot-9.scm:100:6 (thrown-k . args)> woo-error ...]
 109: 0 [#<procedure b3e700 at ice-9/boot-9.scm:100:6 (thrown-k . args)> woo-error ...]

ice-9/boot-9.scm:109:20: In procedure #<procedure b3e700 at ice-9/boot-9.scm:100:6 (thrown-k . args)>:
ice-9/boot-9.scm:109:20: Throw to key `woo-error' with args `("backend not found: net-eth")'.
<* ((#t))
RET: ()
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.

Вот как выглядит хвост /root/.install-log/install2.log на машинке, успешно установленной из собранного на c8_123 образа (alterator 5.3-alt1, alterator-pkg 2.7-alt1, installer 1.8.48-alt1):

<* ((#t))
RET: ()
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /usr/sbin/alterator-wizard
;;; compiled /tmp/.cache/guile/ccache/2.0-LE-8-2.0/usr/sbin/alterator-wizard.go
WARNING: (alterator session state): imported module (alterator algo) overrides core binding `call-with-current-continuation'
WARNING: (alterator lookout evaluation): imported module (alterator presentation events) overrides core binding `when'
frame:on-next is deprecated, use wizard-bind instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:on-next is deprecated, use wizard-bind instead
frame:on-back is deprecated, use wizard-bind instead
frame:on-next is deprecated, use wizard-bind instead
frame:back-activity is deprecated, use wizard-update-activity instead
frame:on-next is deprecated, use wizard-bind instead
frame:on-back is deprecated, use wizard-bind instead
frame:back-activity is deprecated, use wizard-update-activity instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:on-back is deprecated, use wizard-bind instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:back-activity is deprecated, use wizard-update-activity instead
frame:next-activity is deprecated, use wizard-update-activity instead
frame:back-activity is deprecated, use wizard-update-activity instead
frame:on-back is deprecated, use wizard-bind instead
frame:on-next is deprecated, use wizard-bind instead
;;; compiling /mnt/destination/usr/share/alterator/ui/net-eth/ajax.scm
;;; ui/net-eth/ajax.scm:141:9: warning: possibly unbound variable `form-replace'
;;; ui/net-eth/ajax.scm:145:2: warning: possibly unbound variable `form-replace'
;;; ui/net-eth/ajax.scm:153:9: warning: possibly unbound variable `form-replace'
;;; ui/net-eth/ajax.scm:208:2: warning: possibly unbound variable `form-replace'
;;; ui/net-eth/ajax.scm:217:2: warning: possibly unbound variable `form-replace'
;;; ui/net-eth/ajax.scm:220:2: warning: possibly unbound variable `form-replace'
;;; ui/net-eth/ajax.scm:229:2: warning: possibly unbound variable `form-replace'
;;; compiled /tmp/.cache/guile/ccache/2.0-LE-8-2.0/mnt/destination/usr/share/alterator/ui/net-eth/ajax.scm.go
frame:on-next is deprecated, use wizard-bind instead
frame:back-activity is deprecated, use wizard-update-activity instead
;;; compiling /mnt/destination/usr/share/alterator/ui/root/ajax.scm
;;; ui/root/ajax.scm:59:2: warning: possibly unbound variable `call-with-form-file'
;;; ui/root/ajax.scm:84:2: warning: possibly unbound variable `form-bind-upload'
;;; compiled /tmp/.cache/guile/ccache/2.0-LE-8-2.0/mnt/destination/usr/share/alterator/ui/root/ajax.scm.go
frame:on-next is deprecated, use wizard-bind instead
frame:back-activity is deprecated, use wizard-update-activity instead
;;; compiling /usr/share/alterator/ui/officer/ajax.scm
;;; ui/officer/ajax.scm:59:2: warning: possibly unbound variable `call-with-form-file'
;;; ui/officer/ajax.scm:84:2: warning: possibly unbound variable `form-bind-upload'
;;; compiled /tmp/.cache/guile/ccache/2.0-LE-8-2.0/usr/share/alterator/ui/officer/ajax.scm.go
frame:on-next is deprecated, use wizard-bind instead
frame:on-next is deprecated, use wizard-bind instead
frame:back-activity is deprecated, use wizard-update-activity instead
;;; compiling /mnt/destination/usr/share/alterator/ui/luks/ajax.scm
;;; compiled /tmp/.cache/guile/ccache/2.0-LE-8-2.0/mnt/destination/usr/share/alterator/ui/luks/ajax.scm.go
xinit: connection to X server lost

waiting for X server to shut down (II) Server terminated successfully (0). Closing log file.

По словам boyarsh@ -- похоже на проблему перемен с /run и перемонтирования сокета alteratord, запущенного в /mnt/destination, поверх изначального в корне инсталятора.

_Возможно_, надо перенести монтирование новых tmpfs из alterator-pkg в alterator-preinstall _до_ запуска второго alteratord.
Comment 1 Michael Shigorin 2019-08-14 15:26:08 MSK
Похоже, это блокер и лучше откатить правки, сделанные между 2.7 и 2.7.2,
а дальше уже разбираться -- теперь вот Лёня споткнулся об эти грабли,
пусть сам расскажет, как это именно выглядело у него.

Затрагивает и p9; в sisyphus_e2k откатил, в p9_e2k не успело добраться вроде.
Comment 2 Anton V. Boyarshinov 2019-08-14 18:41:20 MSK
Однако, остаётся удивительным факт, что это работает и не работает не всегда. Похоже, конечно, на рейс, но неясно -- между чем и чем. И, насколько я понимаю, есть ситуаци (например e2k) в которых стабильно не работает, но неясно -- с чем это связано.
Comment 3 Alexey Shabalin 2019-08-14 23:06:49 MSK
(В ответ на комментарий №1)
> Похоже, это блокер и лучше откатить правки, сделанные между 2.7 и 2.7.2,
> а дальше уже разбираться -- теперь вот Лёня споткнулся об эти грабли,
> пусть сам расскажет, как это именно выглядело у него.
> 
> Затрагивает и p9; в sisyphus_e2k откатил, в p9_e2k не успело добраться вроде.

Так же блокером можно считать откат изменений. Другого удобного момента (такого как выход новых дистрибутивов и бранчей)  для перехода на симлинки /var/run и /var/lock еще долго не будет. А делать миграцию на уже установленных системах довольно тяжело и опасно. Поэтому лучше это сделать сейчас.
Comment 4 AEN 2019-08-14 23:19:05 MSK
(В ответ на комментарий №3)
> (В ответ на комментарий №1)
> > Похоже, это блокер и лучше откатить правки, сделанные между 2.7 и 2.7.2,
> > а дальше уже разбираться -- теперь вот Лёня споткнулся об эти грабли,
> > пусть сам расскажет, как это именно выглядело у него.
> > 
> > Затрагивает и p9; в sisyphus_e2k откатил, в p9_e2k не успело добраться вроде.
> 
> Так же блокером можно считать откат изменений. Другого удобного момента (такого
> как выход новых дистрибутивов и бранчей)  для перехода на симлинки /var/run и
> /var/lock еще долго не будет. А делать миграцию на уже установленных системах
> довольно тяжело и опасно. Поэтому лучше это сделать сейчас.

Давайте попробуем локализовать багу, это действительно очень важно.
Comment 5 nbr 2019-08-14 23:25:14 MSK
Мое наблюдение: бага возникает из-за того, что alteratord размещает свой socket не под /var/run а под /tmp. А это, в свою очередь (судя по коду alteratord) бывает когда он запущен не из под root.Вот почему это бывает - вопрос другой.
Еще видели странную группу у файлов - сuse. Что это?
Comment 6 Leonid Krivoshein 2019-08-15 02:00:22 MSK
(In reply to comment #1)
> Похоже, это блокер и лучше откатить правки, сделанные между 2.7 и 2.7.2
> Затрагивает и p9; в sisyphus_e2k откатил, в p9_e2k не успело добраться вроде.

Странно, что разница между alterator-pkg-2.7 и 2.7.2 как-то влияет на этот рейс. Он далеко и где-то совсем в другом. Зато в случае mike@ на Эльбрусе он проявляется хотя бы в логах. Вот он:

In unknown file:
   ?: 2 [request-unix-server "/var/run/alteratord/.socket" ...]

> теперь вот Лёня споткнулся об эти грабли,
> пусть сам расскажет, как это именно выглядело у него.

Думаю, баг один и это точно рейс, специфичный для конкретного железа, в моём случае его нет на p9 и на 8СП логи совсем иные, чистенькие, без единого подозрения. Хвост заканчивается ошибкой о том, что не найден шаг /grub. Лишь детальный анализ этих двух случаев говорит об ошибке не в общей логике, а чётко воспроизводимой проблеме на определённом железе, в большинстве же случаев баг не проявляется.
Comment 7 Leonid Krivoshein 2019-08-15 02:15:18 MSK
(In reply to comment #5)
> Мое наблюдение: бага возникает из-за того, что alteratord размещает свой
> socket не под /var/run а под /tmp.

В /tmp нет сокетов демона, там сокет клиента browser-qt.

> А это, в свою очередь (судя по коду alteratord)
> бывает когда он запущен не из под root.

Во всех случаях все процессы запущены из под root, проверил через ps.

> Еще видели странную группу у файлов - сuse. Что это?

cuse -- это на самом деле _alteratord:

ls -la /var/run/alteratord/.socket
... root cuse ...
grep cuse /etc/group
rpcuser:x:29:
cuse:x:483:
grep _alteratord /mnt/destination/etc/group
_alteratord:x:483

То есть, это GID 483 из целевой системы после выполнения в preinstall обратного bind-mount'а в /var/run/alteratord. Так оно выглядит в старых образах 8СП. На p9 всё наоборот, поскольку там новая история с /run и нет этого обратного монтирования, и там тоже имя группы в целевой системе не совпадает с именем в установочной системе, но в обратную сторону. Это значит, имеет смысл проверить на p9 после установки, какой группе будет принадлежать этот каталог.
Comment 8 Leonid Krivoshein 2019-08-15 03:22:50 MSK
(In reply to comment #4)
> Давайте попробуем локализовать багу, это действительно очень важно.

Думаю, будет непросто добраться до этой ошибки -- железку бы такую заиметь для начала. Но смысл баги после подключения strace'ом к разным PID'ам стал практически понятен. К слову, на p9 strace с libdw пришлось докладывать руками, strace надо бы в образ включить.

В случае проявления баги на 8СП, клиент обращается за очередным шагом к alteratord "по старому адресу" (сокету), тогда как новый alteratord в целевой системе ещё не успел его перекрыть или даже ещё не запустился. У mike@ на e2k это зафиксировалось в логе от _неизвестного файла_ guile. У меня на x86_64 это пришлось доказывать опытным путём. Шаги разделены чётко: начиная со steps_list до remount -- скрипты в установочной системе, все остальные -- в целевой.

Обращение к alteratord происходит в тот момент, когда...

- у mike@: сокет alteratord УЖЕ был удалён, но ещё не был перекрыт каталогом /var/run/alteratord либо альтератор там всё ещё запускался.
- у меня: сокет alteratord ЕЩЁ не был удалён, то есть, ещё раньше, а в установочной стадии шага /grub нет!

Немного разобрался в машинерии. Основной клиент -- guile-скрипт /usr/sbin/alterator-wizard создаёт в /tmp FIFO и работает через него в паре с /usr/bin/alterator-browser-qt. Независимо от происходящего в инсталляторе, примерно раз в секунду один запрашивает у другого авторизацию анонимуса и тут же получает положительный ответ. Иногда по этому соединению происходит более полезный в/в, но RAM точно не хватит, чтобы захватить весь strace.

Принципиальную разницу покажет фильтр по 'stat\(' и '/usr/share/alterator/'. Когда всё хорошо (у меня на p9), пути будут как в исходной системе, так и в целевой. Результат stat() не всегда положительный, но на каждый шаг один из четырёх запросов должен вернуть 0, иначе шаг не найден. Так вот на p9 вперемешку идут пути, которые иногда начинаются с /mnt/destination. А когда всё плохо (у меня на 8СП), ни одного такого пути нет, все обращения только в исходной системе. Последние четыре обращения в поисках шага grub, а его нет здесь.

И самый прикол: когда всё упало, запущено два alteratord, как и должно, сокет его доступен и там, и тут, обращение из исходной системы через alterator-cmdline к шагу /grub выводит корректный результат, мало того: повторный запуск инсталлятора приводит к его ругани о невозможности найти steps-list! Конечно, этого шага нет в целевой системе, ведь browser-qt работает теперь с новым альтератором.

compiled /tmp/.cache/guile/ccache/2.0-LE-8-2.0/usr/sbin/alterator-wizard.go -- похожие строчки у меня тоже были, но с другой версией. Грешу конечно на guile, исходя из точечности воспроизводимости, но судя по вышеописанной логике, там и без guile есть поводов для рейса.

В итоге: перевешивать на manowar@ или кто в этой машинерии лучше понимает, коммиты shaba@ реабилитировать, проверять свежие образы 8СП.
Comment 9 Leonid Krivoshein 2019-08-15 05:24:40 MSK
Предлагаю пока такой воркараунд:

diff --git a/alterator-preinstall/backend3/preinstall b/alterator-preinstall/backend3/preinstall
index a34822c..48423de 100755
--- a/alterator-preinstall/backend3/preinstall
+++ b/alterator-preinstall/backend3/preinstall
@@ -62,6 +62,7 @@ run_preinstall()
        done
 
        notify "package \" \" step $max"
+       sleep 2
 
        # replace itself with alteratord from chroot
        [ -n "${ALTERATOR_DESTDIR:-}" ] || return

Все предыдущие не помогли. Трассировка от mike@ проблему локализует однозначно.
Comment 10 manowar@altlinux.org 2019-08-15 11:55:02 MSK
(В ответ на комментарий №8)

> В итоге: перевешивать на manowar@

Можно, конечно. Но мне непонятен смысл слов

> На p9 всё наоборот, поскольку там новая история с /run

Что за история?

> и нет этого обратного монтирования

Кто-то убрал mount -o bind из backend3/preinstall ?

> Предлагаю пока такой воркараунд:
> +       sleep 2
>
> Все предыдущие не помогли.

А как же alterator-wait из того же самого скрипта? Он, по идее, обязан ждать, пока всё не станет как надо, а не 2 секунды.
Comment 11 Leonid Krivoshein 2019-08-15 14:33:33 MSK
(In reply to comment #10)
> мне непонятен смысл слов
> > На p9 всё наоборот, поскольку там новая история с /run
> Что за история?

Про симлинки /var/run и /var/lock, обсуждается в последнее время в devel@.
shaba@ и antohami@ лучше объяснят, по мне, так свежий тренд FHS. :-]

> > и нет этого обратного монтирования
> Кто-то убрал mount -o bind из backend3/preinstall ?

Пакет во всех репозиториях один и тот же.
На p9 это выглядит так (/var/run -> /run):

# ls -la /run/
... root _alteratord ... alteratord
# ls -la /var/run/
... root _alteratord ... alteratord
# ls -la /run/alteratord/.socket
... root 470 ...
# ls -la /var/run/alteratord/.socket
... root 470 ...
# chroot /mnt/destination /bin/bash
localhost / # ls -la /var/run/alteratord/.socket
... root _alteratord ...

То есть, в целевой системе всё пучком изначально. Это я перепутал в ночи. Здесь GID 470 не мапится на cuse или что-то ещё.

> А как же alterator-wait из того же самого скрипта?

Обязан, но не ждёт. Перезапуск инсталлятора после падения в моём случае с 8СП говорит о том, что alteratord в целевой системе запустился, то есть, alterator-wait должным образом не работает либо из-за занятости вводом/выводом к моменту его вызова не происходит удаления старого сокета. Позже -- происходит.

Первый sleep вроде как должен помочь в случае с e2k, вот только какой? Ни 2, ни 5, ни 180 секунд нам не помогли. Второй sleep вкорячивали перед alterator-wait -- второй как раз наш случай с 8СП на x86_64, сегодня с этой машиной последний день можем работать.

Встречный вопрос: кто выводит сообщение про сокет -- понятно:

http://git.altlinux.org/gears/a/alterator.git?p=alterator.git;a=blob;f=alterator/interfaces/guile/d.scm;h=dcbebbe7cd64d23504ad22009cef270b577b52a4;hb=2c29233a3f88ef85f3d3c93adc78eb8da61ed57a#l119

Непонятно, почему в выводе у mike@ этот d.csm числится как неизвестный файл? Не может это быть симптомом ошибочной компиляции на лету?
Comment 12 manowar@altlinux.org 2019-08-15 15:14:38 MSK
Что я заметил по коду:

* в backend3/preinstall перемонтируется в первой строчке просто /run, а во второй — /var/run (потому что alteratord_socket_dir == /var/run/...):

  mount -o bind /run $destdir/run
  mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir

не есть ли это ошибка?

>> А как же alterator-wait из того же самого скрипта?
> Обязан, но не ждёт.

* (d-wait) , т.е. alterator-wait может выйти из цикла только, если retcode будет равен 200 (либо по exception). Собственно код установки соединения находится в vhttpd/lib/http_client.c. Что там происходит и что может произойти странного, чтобы 200 вернулось тогда, когда не надо? Можно ли сделать этот код более надёжным?

* тестовая пересборка vhttpd иногда завершается с ошибкой в %check, причём именно в части unix-guile, т.е. в том тесте, где используется request-unix-server:

  make[1]: Entering directory '/usr/src/RPM/BUILD/vhttpd-0.7.10/test'
  Running "vhttpd"...
  Completed "vhttpd": 193 passes, 0 failures, 0 exceptions.
  Running inet-socket... ok
  Running unix-socket... ok
  Running inet-channel... ok
  Running unix-channel... ok
  Running inet-http... ok
  Running unix-http... ok
  Running unix-from-socket-http... ok
  Running unix-guile... FAILED
Comment 13 manowar@altlinux.org 2019-08-15 15:17:36 MSK
(В ответ на комментарий №12)

> * (d-wait) , т.е. alterator-wait может выйти из цикла только, если retcode
> будет равен 200 (либо по exception).

На случай exception предлагаю вот такой патч:

diff --git a/alterator-preinstall/backend3/preinstall b/alterator-preinstall/backend3/preinstall
index 77a2bfe..34f0d76 100755
--- a/alterator-preinstall/backend3/preinstall
+++ b/alterator-preinstall/backend3/preinstall
@@ -76,7 +76,7 @@ run_preinstall()
 	chroot $destdir /etc/init.d/alteratord start
 
 	# wait until new alteratord is ready to use
-	alterator-wait
+	while ! alterator-wait; do sleep 1; done
 
 	# notify interface about finish
 	notify "done #t"
Comment 14 Leonid Krivoshein 2019-08-15 15:53:22 MSK
Хорошая новость: как и в случае с p9, в новых ИК 8СП сборках нет этой ошибки на проблемном экземпляре.

(In reply to comment #12)
> * в backend3/preinstall перемонтируется в первой строчке просто /run, а во
> второй — /var/run (потому что alteratord_socket_dir == /var/run/...)

/var/run/alteratord/.socket создаётся внутри целевой системы. Но почему тогда в установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?

>   mount -o bind /run $destdir/run
>   mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir
> 
> не есть ли это ошибка?

Мы вчера с shaba@ тоже пробовали добавить /var/run -- стало ещё хуже, инсталлятор сразу вылетает. Более того, данный код везде работает и проблем не вызывает, только на одной машине и только в режиме UEFI. Но теперь возникает ощущение, что ошибка при выполнении именно этих трёх строк, вот только почему?

> >> А как же alterator-wait из того же самого скрипта?
> > Обязан, но не ждёт.

Проверил специально -- как раз alterator-wait работает ожидаемым образом. Запускал и останавливал снаружи и в чруте, всё отрабатывает корректно. Но непонятно, почему в данном коде несмотря НА клиент продолжает работать со СТАРЫМ альтератором, а не с новым? Сразу после выпадения:

mount |tail -n2
runfs on /mnt/destination/run type tmpfs (...)
/dev/sda4 on /var/run/alteratord type ext4 (...) <-- тут корневой раздел

/var/run/alteratord/.socket после выпадения в наличии. Клиент продолжает разговаривать со старым демоном, до выпадения он доступен, поэтому alterator-wait сразу возвращает $?=0.
Comment 15 manowar@altlinux.org 2019-08-15 16:38:45 MSK
(В ответ на комментарий №14)

> Но почему тогда в установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?

  В коде написано rm -f $alteratord_socket_dir/.socket т.е. rm -f /var/run/alteratord/.socket . Никакого /tmp/alterator там нет. Сам же выше писал:

> В /tmp нет сокетов демона, там сокет клиента browser-qt.

  Так что это другой сокет.

> >   mount -o bind /run $destdir/run
> >   mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir
> > 
> > не есть ли это ошибка?
> 
> Мы вчера с shaba@ тоже пробовали добавить /var/run -- стало ещё хуже,
> инсталлятор сразу вылетает.

  Давайте всё таки попробуем внести ясность. Второй mount выводит сокет демона из чрута наружу. А что делает первый mount, для чего он вообще нужен? Для всех остальных программ, просто, чтобы в чруте был /run на runfs?

  Я не доконца понимаю текущую ситуацию с /run и /var/run, поэтому рискну предположить: после прямой проекции /run в /mnt/destination/run обратная проекция из /mnt/destination/var/run наружу теряет смысл, поскольку к этому моменту /mnt/destination/run === /mnt/destination/var/run === /var/run === /run .
  Нельзя ли породить в чруте свой, отдельный /run на runfs и убрать первый mount?

> > >> А как же alterator-wait из того же самого скрипта?
> > > Обязан, но не ждёт.
> 
> Проверил специально -- как раз alterator-wait работает ожидаемым образом.

  Наверное. Только вот alterator-wait всё-таки работает на стороне бакенда. А нам же нужно чтобы ещё и клиент дождался. А вернее: чтобы клиент _переподключился_ (см. ниже).

> Но непонятно, почему в данном коде несмотря НА клиент продолжает работать
> со СТАРЫМ альтератором, а не с новым? Сразу после выпадения:

  Признаться, в части альтератора, с инсталлятором я работал меньше всего, поэтому не понимаю этой магии с подменой сокета. Расскажите мне, в каком месте кода _клиент_ отключается от старого сокета и подключается к новому? Потому что без переподключения, удаление "файла" $alteratord_socket_dir/.socket, которое делает бакенд, ведь не приведёт к нарушению ранее установленного соединения: в UNIX-системах даже удаление обычного файла не мешает программе продолжать чтение из него по открытому fd до следующего close() + open()? , так ведь?

  И вот пока вижу следующее: внутри кода backend3/preinstall, некий процесс, который кстати сказать, работает в фоновом режиме (&), вызывает программу alterator-wait, которая запрашивает новое соединение с новым сокетом (который только что был проброшен наружу mount -o bind), и получает его. Но почему это должно как-то повлиять на уже установленное соединение между alterator-wizardface и старым сокетом (файл которого был только что удалён ну и что)?
Comment 16 manowar@altlinux.org 2019-08-15 16:54:35 MSK
(В ответ на комментарий №8)

> Немного разобрался в машинерии. Основной клиент -- guile-скрипт
> /usr/sbin/alterator-wizard создаёт в /tmp FIFO и работает через него в паре с
> /usr/bin/alterator-browser-qt. Независимо от происходящего в инсталляторе,
> примерно раз в секунду один запрашивает у другого авторизацию анонимуса и тут
> же получает положительный ответ.

Так может быть вся магия переподключения клиента строится вот на этом "раз в секунду"?! Если так, то предполагаю такой сценарий:

1. backend3/preinstall удаляет старый сокет;
2. ставит на его место новый;
3. посредством alterator-wait ждёт и проверяет, что новый сокет готов к работе;
4. отправляет клиенту "done" в СТАРЫЙ сокет (а куда же ещё, ведь он продолжает работать под СТАРЫМ alteratord!);
5. клиент читает "done" из СТАРОГО сокета (в новый сокет "done" в принципе никто не отправлял);
6. благодаря "опросу примерно раз в секунду" переход к новому шагу инсталлятора должен привести и к подключению к новому сокету, но не приводит, потому что опрос не успевает произойти.

И где, кстати, эта машинерия с "авторизацией анонимуса"?
Comment 17 Leonid Krivoshein 2019-08-15 18:15:01 MSK
(In reply to comment #15)
>   В коде написано rm -f $alteratord_socket_dir/.socket т.е. rm -f
> /var/run/alteratord/.socket . Никакого /tmp/alterator там нет.

В каком коде? Вот здесь и во всех образах код одинаковый:

http://git.altlinux.org/gears/a/alterator-preinstall.git?p=alterator-preinstall.git;a=blob;f=alterator-preinstall/backend3/preinstall;h=a34822c32f753c20907e6894b29e3357d33b47d9;hb=13c881a5d2d9f6de0df304c1b0e4e688caa8df2d#l68

Удаляется что-то другое и это в 99.999% волшебным образом работает.

> Сам же выше писал:
> > В /tmp нет сокетов демона, там сокет клиента browser-qt.

Так и есть -- там только /tmp/alterator/broser-sock.

> > >   mount -o bind /run $destdir/run
> > >   mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir
> > > 
>   Давайте всё таки попробуем внести ясность. Второй mount выводит сокет демона
> из чрута наружу. А что делает первый mount, для чего он вообще нужен? Для всех
> остальных программ, просто, чтобы в чруте был /run на runfs?

Обычно в чруте достаточно смонтировать /proc, /sys и /dev. Так что зачем здесь нужен /run -- хороший вопрос, но скорее к git blame.

> Нельзя ли породить в чруте свой, отдельный /run на runfs и убрать первый
> mount?

Мне казалось, правки shaba@, о которых говорилось выше, именно это и делают. Точнее, именно такой механизм. Он более правильный. Но данный код, кажется, они вообще не затрагивают.

> Расскажите мне, в каком месте кода _клиент_ отключается от старого сокета и
> подключается к новому? Потому что без переподключения, удаление "файла"
> $alteratord_socket_dir/.socket,

Про клиента ничего не знаю -- это Ваша епархия. Очевидно стек scm'ов от telegraph до ранее упомянутого d.csm (предположительно). А бэкэнд -- в этом самом месте preinstall. Я попробовал поменять код на правильный, но это ничего не дало. В смысле rm -f $alteratord_socket_dir/.socket приводит к тому же выпадению инсталлятора. До этого ошибся буквой и результат тот же. На следующем заходе гляну, что там ещё в /tmp/alterator ДО начала. Но похоже, что этот rm вообще ни на что не влияет. Заменил его пока на остановку alteratord с подавлением вывода.

> в UNIX-системах даже удаление обычного файла не мешает программе продолжать
> чтение из него по открытому fd до следующего close() + open()? , так ведь?

Да, всё верно. Но если мы имеем дело со скриптом, нужно ухитриться открыть дескриптор, удалить элемент каталога и далее продолжить работать с открытым файлом (сокетом). Точнее сказать, это делается круглыми и угловыми скобками с амперсандами и в обсуждаемом preinstall этого не видать.

> почему это должно как-то повлиять на уже установленное соединение между
> alterator-wizardface и старым сокетом (файл которого был только что удалён
> ну и что)?

Хороший вопрос. Так никто не говорит, что ошибка именно в preinstall. Но искать-то проще там, где подсвечивает, в смысле именно с этими тремя строками в preinstall параллельно должен работать клиент. Предположу, что там сделан игнор на разрыв трубы, а в/в через неё не частый -- по крайней мере, именно такую реализацию я видел в нём же собственного внутреннего сокета browser-sock.
Comment 18 manowar@altlinux.org 2019-08-15 18:29:36 MSK
(В ответ на комментарий №17)
> (In reply to comment #15)
> >   В коде написано rm -f $alteratord_socket_dir/.socket т.е. rm -f
> > /var/run/alteratord/.socket . Никакого /tmp/alterator там нет.
> 
> В каком коде? Вот здесь и во всех образах код одинаковый:
> 
> http://git.altlinux.org/gears/a/alterator-preinstall.git?p=alterator-preinstall.git;a=blob;f=alterator-preinstall/backend3/preinstall;h=a34822c32f753c20907e6894b29e3357d33b47d9;hb=13c881a5d2d9f6de0df304c1b0e4e688caa8df2d#l68
> 
> Удаляется что-то другое и это в 99.999% волшебным образом работает.

  Извиняюсь. Это у меня почему-то версия alterator-preinstall до сих пор обгоняет Сизиф:

http://git.altlinux.org/people/manowar/packages/?p=alterator-preinstall.git;a=shortlog;h=refs/heads/master

  Я и подумать не мог, что его столько времени никто не менял, учитывая это наше обсуждение ошибки.
Comment 19 manowar@altlinux.org 2019-08-15 18:37:10 MSK
Вопчем думаю, что нужно точно разобраться с тем, как переподкючается клиент и сделать эту процедуру более надёжной.
Comment 20 Leonid Krivoshein 2019-08-15 18:53:37 MSK
(In reply to comment #18)
> http://git.altlinux.org/people/manowar/packages/?p=alterator-preinstall.git;a=shortlog;h=refs/heads/master

chroot $destdir /etc/init.d/alteratord start

А не нужно ли в этом месте бэкэнда подавлять вывод: >/dev/null 2>&1 ?

(In reply to comment #13)
> -    alterator-wait
> +    while ! alterator-wait; do sleep 1; done

Вот это вообще было хорошей идеей, попробовал, но ничего не дало.
Comment 21 Leonid Krivoshein 2019-08-15 20:40:07 MSK
(In reply to comment #0)
> _Возможно_, надо перенести монтирование новых tmpfs из alterator-pkg в
> alterator-preinstall _до_ запуска второго alteratord.

Наблюдаю интересную вещь: нет /tmp/alterator/.socket _до_ начала инсталляции. В процессе инсталляции здесь рядышком появляется browser.sock и больше ничего. Остановка alteratord в установщике в любом месте preinstall приводит к зависанию клиента наглухо на стадии "Сохранение настроек", до перехода к шагу /grub.

Это и что было раньше говорит только об одном: клиент связан с alteratord в установочной системе очень крепко, и его сокет изначально перекрыт либо через /tmp/alterator, либо через /tmp, скорее второе. Поэтому rm -f не работает. И пока клиент крепко связан с установочным alteratord, появление нового сокета в /var/run/alteratord/.socket ни на что не влияет. Это в случае рейса.

(In reply to comment #19)
> Впрочем думаю, что нужно точно разобраться с тем, как переподкючается клиент
> и сделать эту процедуру более надёжной.

Очень верное направление. Но без железа, где проявляется баг, этот рейс можно искать очень долго. Надеюсь, удастся выцепить такую машинку. Со стороны бэкэнда перепробованы все варианты, отлаживать просто нечего. Впрочем, перекрытие сокета через /tmp в случае рейса может иметь место в другом скрипте. Жаль, не осталось времени на отладку, ухожу в отпуск.
Comment 22 manowar@altlinux.org 2019-08-15 21:46:19 MSK
(В ответ на комментарий №21)
> (In reply to comment #19)
> > Впрочем думаю, что нужно точно разобраться с тем, как переподкючается клиент
> > и сделать эту процедуру более надёжной.
> 
> Очень верное направление. Но без железа, где проявляется баг, этот рейс можно
> искать очень долго. Надеюсь, удастся выцепить такую машинку.

Да по боку этот рейс и машинку! Я просто хочу выяснить, как сейчас происходит переподключение клиента (вернее, должно происходить), после чего сделать это надёжно, а не лечить симптомы.
Comment 23 nbr 2019-08-16 09:42:50 MSK
(In reply to comment #22)
> (В ответ на комментарий №21)
> > (In reply to comment #19)
> > > Впрочем думаю, что нужно точно разобраться с тем, как переподкючается клиент
> > > и сделать эту процедуру более надёжной.
> > 
> > Очень верное направление. Но без железа, где проявляется баг, этот рейс можно
> > искать очень долго. Надеюсь, удастся выцепить такую машинку.
> 
> Да по боку этот рейс и машинку! Я просто хочу выяснить, как сейчас происходит
> переподключение клиента (вернее, должно происходить), после чего сделать это
> надёжно, а не лечить симптомы.
/var/run/alteratord/.socket создаётся внутри целевой системы. Но почему тогда в
установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?

; /var/run/alteratord is also used in installer
; to bounce the socket between stage3 and stage2;
; it's also more secure than predefined /tmp subdir
; NB: a copy contained in ../interfaces/guile/d.scm
(define *tmpdir*
  (if (string=? *d-user* "root")
    "/var/run/alteratord"
    (string-append
      (or (getenv "TMPDIR") "/tmp")
      "/alterator")))


Другой вопрос почему в первом stage у нас приехал НЕ рут.
Comment 24 Ivan Zakharyaschev 2019-08-16 11:54:32 MSK
Может быть, будет удобно перейти на абстрактный сокет (как у X-сервера)?

https://unix.stackexchange.com/a/317531/4319 :

"An abstract socket effectively exists in all filesystem namespaces and chroots; you don't have to link anything into the chroot or namespace to use it."
Comment 25 manowar@altlinux.org 2019-08-16 12:27:06 MSK
Очень интересная мысль. Мне нравится. Тогда можно будет организовать переподключение вот по такому сценарию:

1. первый сервер закрывает соединение и прослушивание сокета;
2. клиент на это получает "отлуп";
3. клиент (опционально) выводит сообщение (попап) "Подключение к серверу…";
4. клиент повторяет попытки подключения до тех пор, пока не устанавливает соединение;
5. второй сервер запускается;
6. второй сервер начинает прослушивать сокет;
7. клиент успешно подключается к сокету.
8. клиент убирает попап (если был) и продолжает работу в установленном порядке.
Comment 26 Anton V. Boyarshinov 2019-08-16 13:38:33 MSK
 
> Да по боку этот рейс и машинку! Я просто хочу выяснить, как сейчас происходит
> переподключение клиента (вернее, должно происходить), 

Оно должно было работать так:

59476928 (Stanislav Ievlev     2009-11-10 14:46:32 +0300 80)    # stop old alteratord and kill itself
13c881a5 (Andrey Cherepanov    2014-02-04 18:47:21 +0400 81)    #sleep 1
13c881a5 (Andrey Cherepanov    2014-02-04 18:47:21 +0400 82)    #service alteratord stop

То есть старый alteratord останавливается и клиенту приходится переподключиться.  А вот как оно работает с 2014 года -- загадка.
Comment 27 Anton V. Boyarshinov 2019-08-16 13:40:30 MSK
> > переподключение клиента (вернее, должно происходить), после чего сделать это
> > надёжно, а не лечить симптомы.
> /var/run/alteratord/.socket создаётся внутри целевой системы. Но почему тогда в
> установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?

Я думаю, что когда-то сокет в установщике находился там. Потом сокет переехал, а код не поправили или поправили не полностью.
Comment 28 Anton V. Boyarshinov 2019-08-16 14:00:03 MSK
(В ответ на комментарий №27)
> > > переподключение клиента (вернее, должно происходить), после чего сделать это
> > > надёжно, а не лечить симптомы.
> > /var/run/alteratord/.socket создаётся внутри целевой системы. Но почему тогда в
> > установочной системе rm -f /tmp/alterator/.socket -- вот что вообще за сокет?
> 
> Я думаю, что когда-то сокет в установщике находился там. Потом сокет переехал,
> а код не поправили или поправили не полностью.

Нет, этот rm -f был ошибкой с самого начала, но она, видимо, ни на что не влияла с 2012 года
Comment 29 Leonid Krivoshein 2019-08-17 05:33:28 MSK
(В ответ на комментарий №23)
> Другой вопрос почему в первом stage у нас приехал НЕ рут.

Там везде root, см. #7.

(В ответ на комментарий №24)
> Может быть, будет удобно перейти на абстрактный сокет (как у X-сервера)?

Безопасно ли? Если первый байт 0, строка с путём начинается со второго. Т.е. вопрос выравнивая адреса и вопрос анализа строки за первым байтом для того кода, который на это не рассчитан. Пока не очень понятно, думал это сделано через отдельный домен для таких сокетов.

(В ответ на комментарий №26)
> То есть старый alteratord останавливается и клиенту приходится
> переподключиться.  А вот как оно работает с 2014 года -- загадка.

Сейчас остановка alteratord в установочной системе приводит к зависанию клиента broser-qt на операции "Сохранение настроек", клиент не видит второго запущеного в чруте альтератора. Поскольку есть пересечение по /var/run и /run, остановка в одной системе может влиять на alteratord в чруте, да хотя бы по PID'у.

(В ответ на комментарий №16)
> Так может быть вся магия переподключения клиента строится вот на этом "раз в
> секунду"?! Если так, то предполагаю такой сценарий:

Не успел ответить до отъезда, а фотки с телефона потёр (дома их оставил). В любом случае с моей строны речь шла не о серверном сокете, а о browser-sock, через который обмениваются две часть фронтэнда -- browsert-qt и quile-обёртка alterator-wizard. Так вот, там я увидел игнорирование EPIPE и сначала по strace, а потом и в коде это нашёл. Не знаю, чем обоснована такая странная реализация, тем более, речь о unix-сокете двух процессов, относящихся к фронтэнду, они до последнего никуда не деваются, переключение на новый альтератор их не должно касаться. Может, zerg@ знает?

И ещё раз: пока не знаю, как реализовано переподключение сокета на клиенте, как там вообще происходит обмен с демоном. Эту часть не смотрел хотя бы потому, что очень далёк от guile.
Comment 30 Sergey V Turchin 2019-08-19 10:27:41 MSK
(В ответ на комментарий №29)
> Может, zerg@ знает?
Я этого момента не касался совсем. Если в browser и было что-то для этого, то очень давно и сделано inger@.
Comment 31 Anton V. Boyarshinov 2019-08-19 13:14:16 MSK
 
> Сейчас остановка alteratord в установочной системе приводит к зависанию клиента
> broser-qt на операции "Сохранение настроек", клиент не видит второго запущеного
> в чруте альтератора. Поскольку есть пересечение по /var/run и /run, остановка в
> одной системе может влиять на alteratord в чруте, да хотя бы по PID'у.

Хмм.. Так может быть надо не делать service aleratord stop, а до запуска второго альтератора запоминать pid первого и прицельно его прибивать?
Comment 32 manowar@altlinux.org 2019-08-19 13:44:03 MSK
(В ответ на комментарий №29)

> Так вот, там я увидел игнорирование EPIPE и сначала по
> strace, а потом и в коде это нашёл. Не знаю, чем обоснована такая странная
> реализация

  В том, что касается кода на Scheme, я вижу (with-ignored-sigpipe ...) в части, которая отвечает за общение между browser-qt и alterator-wizardface — http://git.altlinux.org/gears/a/alterator.git?p=alterator.git;a=blob;f=alterator/interfaces/guile/transport/pipe-channel.scm;h=25a12ee2a8686846b71162ea3e99bbda2b21f0bb;hb=2c29233a3f88ef85f3d3c93adc78eb8da61ed57a . Это не та часть, которая говорит с /var/run/alteratord/.sock.
Comment 33 manowar@altlinux.org 2019-08-19 13:56:42 MSK
С той же частью, которая говорит с alteratord через /var/run/alteratord/.sock, всё оказалось относительно просто: она вызывает (request-unix-server ...) **на каждую команду**, на каждый запрос — http://git.altlinux.org/gears/a/alterator.git?p=alterator.git;a=blob;f=alterator/interfaces/guile/d.scm;h=dcbebbe7cd64d23504ad22009cef270b577b52a4;hb=2c29233a3f88ef85f3d3c93adc78eb8da61ed57a#l118 . А эта функция, если посмотреть на http://git.altlinux.org/gears/v/vhttpd.git?p=vhttpd.git;a=blob;f=vhttpd/lib/http_client.c;h=4667d7b11d41d6ad46e281514981983a4d15f5c6;hb=fed6867ce8bea86f135825c60bc1288ba6159f8d#l36 , в свою очередь, **каждый раз создаёт** сокет из строки пути. Очевидно, что это и есть переподключение, а точнее, разовое подключение. Следовательно, работало всё это, скорее всего просто путём mount -o bind одного сокета поверх другого, и, таким образом, сначала запросы шли к старому сокету, а после "затенения" старого сокета новым сокетом, запросы попадали в новый сокет. Если такое затенение работает правильно, то и правда, останавливать старый alteratord не обязательно.
Comment 34 Leonid Krivoshein 2019-08-19 19:36:03 MSK
(В ответ на комментарий №31)
> Хмм.. Так может быть надо не делать service aleratord stop, а до запуска
> второго альтератора запоминать pid первого и прицельно его прибивать?

Прибивать сигналом KILL, чтобы не было обработки TERM/QUIT/итп, вот только что будет, если в этот момент демон будет находиться в состоянии ввода/вывода?

(В ответ на комментарий №32)
> Это не та часть, которая говорит с /var/run/alteratord/.sock.

Да, выше об этом говорил.

(В ответ на комментарий №33)
> ... **каждый раз создаёт** сокет из строки пути. Очевидно, что
> это и есть переподключение, а точнее, разовое подключение. Следовательно,
> работало всё это, скорее всего просто путём mount -o bind одного сокета
> поверх другого, и, таким образом, сначала запросы шли к старому сокету, а
> после "затенения" старого сокета новым сокетом, запросы попадали в новый
> сокет.

Дело в том, что создаётся не совсем сокет, не совсем pipe и не совсем fifo, невзирая на название. Создаётся нечто подобное именованному каналу, но управляемое через Pseudo TTY a.k.a PTY (/dev/pts/%d и /dev/ptmx). И это одна из странностей реализации, на которую может влиять момент перекрытия:

mount -o bind /dev/pts $destdir/dev/pts

Мне вообще этот старый код с mount -o bind не нравится, я бы биндил только /dev, всё остальное же монтировал заново, как shaba@ это сделал с /run и как предлагалось "планом Бидермана". Зачем *здесь* вообще PTY? Тем более, зачем он нужен при обмене одной части фронтэнда с другой да ещё с авторизацией раз в секунду?

Очень важное пояснение можно найти здесь: https://lwn.net/Articles/688809/
См. также: [alterator.git]/alterator/src/libguile-pipe/terminal.c
Comment 35 manowar@altlinux.org 2019-08-20 13:55:35 MSK
Я вот тут подумал, а что если сделать пока вот так:

diff --git a/alterator-net-eth/ui/net-eth/index.scm b/alterator-net-eth/ui/net-eth/index.scm
index c46df1e..72c9ee0 100644
--- a/alterator-net-eth/ui/net-eth/index.scm
+++ b/alterator-net-eth/ui/net-eth/index.scm
@@ -337,7 +337,7 @@
 
 (document:root
   (when loaded
-	(init-interface)
+	(catch/message init-interface)
     (form-bind "name" "change" update-interface)
 	(form-bind "ipv" "change" ipv_changed)
 	(form-bind "ipv_enabled" "change" update-ipv-activity)

Есть шанс, что после этого инсталлер не будет падать после установки пакетов, а будет выводить окошко с ошибкой. Попробуйте, пожалуйста. Если получится, то можно будет написать workaround получше, на уровне frame:next, например — чтобы он делал несколько попыток подключения к бакенду. А можно и ещё глубже его зарыть: сделать, например, так, чтобы в случае "backend not found", сама d-qeury повторяла бы попытки. Ну и сделать, например, так, чтобы количество попыток настраивалось (т.к. нигде, кроме инсталлера, это повторение наверняка не нужно).

Правда, делать новые попытки подключения имеет смысл только в том случае, если там сейчас действительно гонка. Если же новый сокет (второго alteratord) не доступен совсем — ни с первой, ни с двадцатьпервой попытки, то это другая проблема.
Comment 36 Leonid Krivoshein 2019-08-20 17:43:49 MSK
(В ответ на комментарий №35)
> Есть шанс, что после этого инсталлер не будет падать после установки пакетов, > а будет выводить окошко с ошибкой.

Судя по трассировке от mike@, самого шага /net-eth в системе НЕТ:

ice-9/boot-9.scm:109:20: Throw to key `woo-error' with args `("backend not
found: net-eth")'.

Он есть в целевой системе, здесь же вызов произошёл в установочной системе. Так что правка фронтэнда этого шага точно не поможет. Тем более, на e2k нет шага /grub, а за установкой пакетов может быть разное, в зависимости от инсталлятора.

> А можно и ещё глубже его зарыть: сделать, например, так, чтобы в случае
> "backend not found", сама d-qeury повторяла бы попытки.

ДА. Трассировка у mike@ начинается с:

[alterator.git]/interfaces/guile/transport/pipe-channel.scm

Но это поможет только в случае e2k, где попытка поговорить с бэкэндом успевает проскочить до того, как alteratord запустился в целевой системе. При перекрытии /tmp или /tmp/alterator, как в случае рейса на 8СП, это тоже не поможет.
Comment 37 Leonid Krivoshein 2019-08-20 17:58:11 MSK
(В ответ на комментарий №36)
> При перекрытии /tmp или /tmp/alterator, как в случае рейса на 8СП,
> это тоже не поможет.

А может и поможет. Ведь всё дело в нескольких секундах на стороне фронтэнда и перекрытие /tmp/alterator не должно влиять, как уже выяснили выше: настоящий путь к сокету вообще не здесь, а в /var/run.

В d.csm или ещё глубже trow-cacth в цикле из нескольких попыток с задержкой в пару секунд и проверкой на предмет именно ошибки связи с сокетом либо отсутствии шага (не важно какого). То же самое на стороне бэкэнда не помогло.
Comment 38 manowar@altlinux.org 2019-08-20 18:03:32 MSK
(В ответ на комментарий №37)

> В d.csm или ещё глубже trow-cacth в цикле из нескольких попыток с задержкой в
> пару секунд и проверкой на предмет именно ошибки связи с сокетом либо
> отсутствии шага (не важно какого).

Ты это уже попробовал сделать или это только идея? Не понял.
Comment 39 Leonid Krivoshein 2019-08-20 18:51:07 MSK
(В ответ на комментарий №38)
> Ты это уже попробовал сделать или это только идея? Не понял.

Как я могу опробовать вашу идею, если не владею guile? Но идею поддерживаю! :)
Comment 40 Anton V. Boyarshinov 2019-08-21 12:54:33 MSK
(В ответ на комментарий №37)
> (В ответ на комментарий №36)
> > При перекрытии /tmp или /tmp/alterator, как в случае рейса на 8СП,
> > это тоже не поможет.
> 
> А может и поможет. Ведь всё дело в нескольких секундах на стороне фронтэнда и
> перекрытие /tmp/alterator не должно влиять, как уже выяснили выше: настоящий
> путь к сокету вообще не здесь, а в /var/run.

Удаление было по неправильному пути, а вот перекрытие, насколько я могу судить 00 по правильному, в /var/run
Иначе бы вообще ничего и никогда не работало.
Comment 41 Leonid Krivoshein 2019-08-21 20:09:11 MSK
(В ответ на комментарий №40)
> перекрытие, насколько я могу судить
> 00 по правильному, в /var/run
> Иначе бы вообще ничего и никогда не работало.

В случае рейса на 8СП, который пока непонятно, как и на чём отловить, мы имеем биндинг /var/run/alteratord в обратную сторону и именно он почему-то при рейсе работает не так, как ожидается -- клиент продолжает разговаривать со старым альтератором, хотя перекрытие произошло несколькими командами выше. Ранее уже обсудили, что при разговоре клиент устанавливает соединение *каждый раз* новое. Что это значит в случае рейса на 8СП? Может такое быть, что на 8СП при рейсе где-то включается отдельный mount namespace и это перекрытие не срабатывает?
Comment 42 manowar@altlinux.org 2019-08-21 20:18:23 MSK
А ты замелил, что в бакенде стоит sync после notify?

	# notify interface about finish
	notify "done #t"
	sync

Может он иметь какое-то отношение к mount -o bind и к этим сокетам, которые "не совсем сокеты, не совсем pipe и не совсем fifo, невзирая на название"? Или это такой sync, чтобы notify быстрее долетел? Что-то не нравится он мне. Особенно в связи с гонкой.
Comment 43 Leonid Krivoshein 2019-08-21 23:05:36 MSK
(В ответ на комментарий №42)
> Может он иметь какое-то отношение к mount -o bind и к этим сокетам...?

К связи с альтератором он никакого отношения не имеет. Это следует из комментария над данным сниппетом, из смысла функции notify() в том же скрипте и из [alterator-lookout.git]/alterator-lookout/tools/alterator-mailbox-send.c -- бэкэнд сообщает фронтэнду ("done #t") о завершении операции "Saving settings...", которая и есть шаг /preinstall, и в процессе которой запускаются всякие скриптики.

sync здесь можно рассматривать двояко: как sleep(ramdom()) и как приостановку какого-либо ввода/вывода до сброса всех буферов на диск. С точки зрения возможности рейса -- фактор провоцирующий, ага. Но влепили его сюда наверняка вместо sleep(n), чтобы дать кому-то (чему-то) другому что-то успеть доделать.

Например, в том же d.csm есть такой комментарий:

note: don't use control script, because init script pass all stderr to initlog

Управляющий скрипт здесь, надо понимать, это guile-обёртка над функциями запуска/остановки alteratord. Только в d.csm это цикл ожидания с конкретной задержкой до выполнения условия. Можно предположить, что sync'ом в бэкэнде /preinstall могли преследовать те же цели, но не очень надёжным способом. Если так, то для нашего бага сейчас не критично.

Мне куда больше не нравится этот d.csm и вообще весь guile. :-)
Comment 44 Leonid Krivoshein 2019-08-22 04:57:09 MSK
(В ответ на комментарий №42)
>     # notify interface about finish
>     notify "done #t"
> [...]
> Может он иметь какое-то отношение к mount -o bind и к этим сокетам...?

Забыл сказать: notify() имеет отношение к т.н. "клиентскому" сокету a.k.a /tmp/alterator/browser-sock. А вот какое отношение этот сокет имеет ко всей архитектуре альтератора, честно говоря, понять пока так и не смог (нет нужных знаний guile). Сейчас он вообще вынесен за пределы альтератора!

Почему бинд-маунтится /tmp/alterator, где кроме этого сокета лежит ещё и журнал альтератора? В то же время, журнал фронтэнда лежит в /tmp/wizard.log и сабжевый баг (у mike@), судя по успешному откату коммита shaba@, может быть связан именно с этим журналом или способом монтирования в чрут каталога /tmp. Почему один сокет (клиентский) всегда был в /tmp/alterator, а серверный несколько раз прыгал и переименовывался? И как так получилось, что теперь они разнесены?

В поисках ответов на эти вопросы набрёл на то, в чём могут разобраться только аксакалы guile...

1) Когда-то "клиентский" сокет был частью альтератора, а именно одним из транспортов наряду с серверным сокетом. Сейчас есть только один транспорт -- pipe-channel.csm и его код весьма напоминает бывший "серверный" транспорт. См.:

git show 68d028

2) Вот несколько изменений в историческом порядке [alterator.git], которые не были косметическими переименованиями, но касались этих двух сокетов:

git show 530a3a
git show ab2072..df792a
git show 00a51c..c65360

3) Нашёл в пыльном мешке вот это, но ничего не понял:
https://www.altlinux.org/Alterator/drivers/http

4) А вот это мастрид, я считаю:
https://www.altlinux.org/Socket_race_conditions
И не просто мастрид, а брать напильник и дотачивать d.csm!

5) Возможно, на ситуацию с 8СП как-то влияет этот коммит (c) твой:

git show 71f4ff

6) См.: [alterator-wizardface.git]/alterator-wizardface/sbin/alterator-wizard и [alterator-browser-qt5.git]/alterator-browser-qt/browser.cc#184-204 для понимания ситуации с "клиентским" сокетом -- тут код, который не трогал zerg@.

7) Мне больше не нравится обратное монтирование: возможно, сторонний эффект на конкретном железе из-за ошибок в ядре?

8) Если бы знал guile, я бы воспроизвёл ситуацию на e2k, вернув коммит shaba@, поизучал бы кэш "компиляции на лету" и ситуацию с трассировкой, в которой единственный модуль d.csm превращается в *неизвестный файл*.
Comment 45 Leonid Krivoshein 2019-08-22 09:04:06 MSK
Попробую в деталях разжевать ситуацию mike@ на e2k. Код, который трогал shaba@ -- [alterator-pkg]/alterator-pkg/backend3/pkg-init:

# 19: /run теперь в скелете будущего чрута
mkdir -p /mnt/destination/run

# 42: создание других служебных каталогов
mkdir -p /mnt/destination/dev
mkdir -p /mnt/destination/dev/pts
mkdir -p /mnt/destination/proc
mkdir -p /mnt/destination/sys
mkdir -p /mnt/destination/tmp/alterator

# 43: эти же каталоги будут и в чруте
mount --bind /dev /mnt/destination/dev
mount --bind /dev/pts /mnt/destination/dev/pts
mount --bind /proc /mnt/destination/proc
mount --bind /sys /mnt/destination/sys
mount --bind /tmp/alterator /mnt/destination/tmp/alterator

На самом деле из #42-43 убран только /run, остальное так было и раньше. Что здесь плохо (сугубо на мой взгляд), с учётом вышеупомянутого "плана Бидермана" и использования PTY для управления одним из сокетов, что /dev/pts биндится в чрут, тогда как безопаснее сделать новый экземпляр, и тогда у каждой системы будут независимые PTY's, т.е.:

-mount --bind /dev/pts /mnt/destination/dev/pts
+mount -t devpts devpts /mnt/destination/dev/pts

# 46: add symlinks /var/run -> /run, and /var/lock -> /run/lock
# 47: теперь /run в чруте -- это независимый экземпляр.
#     Кстати, зачем здесь mount с "-n"?
mount -n -t tmpfs -o mode=755 runfs /mnt/destination/run

# 48: пока единственное, что будет в чрутовом /run -- пустой под-каталог lock
mkdir -p -- /mnt/destination/run/lock

# 49: в чруте /var/run будет указывать теперь на /run
ln -s ../run /mnt/destination/var/run

# 50: в чруте /var/lock будет указывать теперь на /run/lock
ln -s ../run/lock /mnt/destination/var/lock

Сокеты запущенного альтератора установочной системы после выполнения этих строк будут находиться в:

1) /var/run/alteratord/.socket -- серверный
2) /tmp/alterator/browser-sock -- клиентский
3) /mnt/destination/tmp/alterator/browser-sock -- клиентский

Журналы будут писаться в /var/run/alteratord/alteratord.log и /tmp/wizard.log, соответственно. Пока всё выглядит прилично. И это подтверждается тем фактом, что даже в случае гонок шаг /preinstall ("Сохранение настроек") выполняется до конца, затык происходит дальше -- при попытке переключиться на чрутовый alteratord.

Теперь смотрим код, который shaba@ не трогал -- [alterator-preinstall.git]/alterator-preinstall/backend3/preinstall:

# 38: разве вывод на stdout/stderr этой функции или отдельных вызовов в ней не должен подавляться?
run_preinstall()

# 67: главное -- вовремя проверить! А ничего, что этот шаг уже на 99.9% выполнен не в той системе!? :)
[ -n "${ALTERATOR_DESTDIR:-}" ] || return

# 68: ошибка с самого начала, которая ни на что не влияет, но сбивает с толку
rm -f /tmp/alterator/.socket

# 69-71: собственно сабж
mount -o bind /run /mnt/destination/run
mount -o bind /mnt/destination/var/run/alteratord /var/run/alteratord
chroot /mnt/destination /etc/init.d/alteratord start

Этот код всегда был безобразен и до изменений shaba@ в другом пакете. 69 строка пустила насмарку всё, что ранее делалось в pkg-init#47-50, она здесь вообще лишняя: /run уже был смонтирован в чрут более правильным способом. В 70 строке выполняется *обратное монтирование* пока ещё *пустого* каталога /var/run/alteratord -- ой, здесь же только что был наш серверный сокет, куда он делся!? А куда девался журнал альтератора!?

После выполнения именно 70 строки мы гарантированно получили ситуацию гонок: если будет иметь место обращение к серверному сокету с какой-либо стороны *в установочной системе*, то сокета здесь УЖЕ нет, а появится он тут лишь после выполнения строки 71, но это займёт время... где-то в коде попадалось -t 60, возможно(!) означающее тайм-аут ожидания соединения. Но в случае рейса, а на некоторых системах здесь может иметь место интенсивынй ввод/вывод, запуск альтератора в чруте мог затянуться на более, чем 60 (секунд, надо полагать). Это единственное, чем можно объяснить вот это:

?: 2 [request-unix-server "/var/run/alteratord/.socket" ...]

(В ответ на комментарий №15)
>   Я не доконца понимаю текущую ситуацию с /run и /var/run, поэтому рискну
> предположить: после прямой проекции /run в /mnt/destination/run обратная
> проекция из /mnt/destination/var/run наружу теряет смысл, поскольку к этому
> моменту /mnt/destination/run === /mnt/destination/var/run === /var/run === /run

На мой взгляд сабжевый код должен был выглядеть как-то так:

chroot /mnt/destination /etc/init.d/alteratord start
chroot /mnt/destination alteratord-wait
mount --bind /mnt/destination/var/run/alteratord /var/run/alteratord

При этом сохраняется по сути CVE с правами и владельцами сокета и выше лежащего каталога, описанная в #11, не влияющая на ход установки только благодаря тому, что вся инсталляция выполняется из-под рута. И при этом остаётся *обратное монтрирование*, отражаемое в /proc/mounts довольно странно:

mount |tail -n2
runfs on /mnt/destination/run type tmpfs (...)
/dev/sda4 on /var/run/alteratord type ext4 (...) <-- тут корневой раздел
Comment 46 manowar@altlinux.org 2019-08-22 12:23:53 MSK
(В ответ на комментарий №44)
 
> Забыл сказать: notify() имеет отношение к т.н. "клиентскому" сокету a.k.a
> /tmp/alterator/browser-sock. А вот какое отношение этот сокет имеет ко всей
> архитектуре альтератора, честно говоря, понять пока так и не смог (нет нужных
> знаний guile). Сейчас он вообще вынесен за пределы альтератора!

Архитектура. Конечно, не классический MVC, но около того. Этот сокет нужен для связи между View и Model, а не для связи между Model и Controller.

> Почему бинд-маунтится /tmp/alterator,

Где это происходит?

    mount -o bind /run $destdir/run
    mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir

Тут нет ни /tmp, ни $TMPDIR.

> 1) Когда-то "клиентский" сокет был частью альтератора, а именно одним из
> транспортов наряду с серверным сокетом. Сейчас есть только один транспорт --
> pipe-channel.csm

Почему? В d.scm идёт вызов к request-unix-server, который, через обёртку, превращается ведь в request_unix_server() из http_client.c пакета vhttpd. Отсюда два следствия: 1) этот транспорт — не pipe-channel; 2) та часть d.scm, с которой мы сейчас столкнулись, написана на C, а не на Scheme.
Comment 47 manowar@altlinux.org 2019-08-22 12:31:15 MSK
(В ответ на комментарий №44)

> 4) А вот это мастрид, я считаю:
> https://www.altlinux.org/Socket_race_conditions
> И не просто мастрид, а брать напильник и дотачивать d.csm!

А вот, кстати сказать, абстрактные сокеты, которые предлагались выше. Что у них с правами доступа? Можно ли как-то их регулировать?
Comment 48 Leonid Krivoshein 2019-08-22 19:39:27 MSK
(В ответ на комментарий №46)
> > Почему бинд-маунтится /tmp/alterator,
> Где это происходит?
> Тут нет ни /tmp, ни $TMPDIR.

Тут: [alterator-pkg]/alterator-pkg/backend3/pkg-init#43

Извиняюсь за много букв. Ряд вопросов отпал при изучении. Убил вчера весь день на эту головоломку. Как и серверный сокет, журнал сервера может находиться в двух местах, в зависимости от пользователя, но в нашем случае он ложится в /var/run/alteratord.

Главное, что один рейс в бэкэнде точно найден (комментарий #45), осталось только его убрать :)

(В ответ на комментарий №47)
> А вот, кстати сказать, абстрактные сокеты, которые предлагались выше.
> Что у них с правами доступа? Можно ли как-то их регулировать?

В сишном коде или на шеле я бы поучаствовал, но с guile ничем не могу помочь. :) Предлагается исправлять по образцу, как в этой статье на ВиКи.
Comment 49 Leonid Krivoshein 2019-08-22 22:53:06 MSK
(В ответ на комментарий №47)
> А вот, кстати сказать, абстрактные сокеты, которые предлагались выше.
> Что у них с правами доступа? Можно ли как-то их регулировать?

Чего-то я тупанул. Здесь же речь о предложении imz@. man 7 unix, однако.))

Пространство имён абстрактного сокета является непереносимым расширением Linux. Абстрактные сокеты автоматически исчезают, когда закрыты все открытые ссылки на сокет. Нам это подходит?

Права доступа и владельцы не имеют смысла для абстрактных сокетов: umask не действует при связывании абстрактного сокета, а изменение владельца и смена прав доступа через fchown/fchmod не влияет на доступность сокета. Он вообще живёт в своём пространстве имён, не связанном с файловой системой.

Абстрактный адрес сокета отличается от классического сокета UNIX, основанного на пути в файловой системе, тем, что sun_path[0]=0. Адрес сокета в этом пространстве имен задается дополнительными *байтами* в sun_path, которые покрываются указанной длиной структуры адреса. Нулевые байты в имени не имеют особого значения.
Comment 50 manowar@altlinux.org 2019-08-23 11:57:06 MSK
Пока есть вот такой патчик для реконнекта в случае недоступности alteratord:

http://git.altlinux.org/people/manowar/packages/?p=alterator.git;a=commitdiff;h=fce6b361be91d7092e4fc0a444d75f1a8a77b77b

и, соответственно,

http://git.altlinux.org/people/manowar/packages/?p=alterator-wizardface.git;a=commitdiff;h=0c1750951158f6bdc5b4a1d071876b2c12e121d0

У него, правда, есть проблемы со стеком (из-за колбэка), которые я сейчас постараюсь решить. И следом займусь реконнектом для ситуации, когда соединение с alteratord есть, но "бакенд не найден". Там несколько посложнее.
Comment 51 manowar@altlinux.org 2019-08-23 12:31:07 MSK
Вот новая редакция коммита: http://git.altlinux.org/people/manowar/packages/?p=alterator.git;a=commitdiff;h=ade0288979795f4ed3f794f2dc4d764c8a94408d . Проблем со стеком теперь быть не должно.
Comment 52 manowar@altlinux.org 2019-08-23 13:48:53 MSK
Значит так, товарищи. Проверенные коммиты получились вот такими:

1. переподключение, если alteratord недоступен —
1.1. http://git.altlinux.org/people/manowar/packages/?p=alterator.git;a=commitdiff;h=69d2c04a3ebfdfa860371011149c3cb49d082c42 и
1.2. http://git.altlinux.org/people/manowar/packages/?p=alterator-wizardface.git;a=commitdiff;h=0c1750951158f6bdc5b4a1d071876b2c12e121d0 ;

2. повтор запроса, если бакенд не был найден —
2.1 http://git.altlinux.org/people/manowar/packages/?p=alterator.git;a=commitdiff;h=9eec34a98c4e6dcadba15346cdc5dc24cfb083b3 и
2.2. http://git.altlinux.org/people/manowar/packages/?p=alterator-wizardface.git;a=commitdiff;h=5b22b137487577058f08b41fc1d96de15d89bad5 .

Количество повторов и таймаут во втором случае — это те же самые значения, что и в первом случае (это один и тот же счётчик). В коммите выставлен в 20 раз с перерывом в 500 мс.
Comment 53 manowar@altlinux.org 2019-08-23 13:53:38 MSK
Теперь у нас вроде как есть защита от рейса, повышающая живучесть всей системы. Прошу проверить, помогает ли. Если сразу не поможет, то можно, наверное, выставить количество повторов в какое-нибудь неприличное значение и попробовать за это время что-то руками нахимичить — сокеты перемаунтить и т.д. Ну и сделать выводы.

А я тем временем подумаю, какие сокеты всё-таки нам нужны, и как надёжнее организовать само переподключение между экземплярами alteratord в инсталлере.
Comment 54 manowar@altlinux.org 2019-08-23 14:34:35 MSK
Собственно, пока просится вот такой сценарий в alterator-preinstall:

1. остановка "внешнего" alteratord — теперь это можно делать, т.к. есть переподключение;
2. запуск "внутреннего" alteratord;
3. перемонтирование директории с сокетом наружу;
4. notify "done".
Comment 55 manowar@altlinux.org 2019-08-23 15:02:14 MSK
Если есть замечания или дополнения, то прошу дополнить: https://lists.altlinux.org/pipermail/devel/2019-August/208315.html .
Comment 56 Leonid Krivoshein 2019-08-23 16:37:00 MSK
(В ответ на комментарий №53)
> Теперь у нас вроде как есть защита от рейса, повышающая живучесть всей
> системы. Прошу проверить, помогает ли.

Мне пока не на чем (в отпуске).

> А я тем временем подумаю, какие сокеты всё-таки нам нужны, и как надёжнее
> организовать само переподключение между экземплярами alteratord в инсталлере.

Поскольку абстрактные не связаны с файловой системой, можно сделать клиентский и серверный, назвать соответственно "\0alteratord-browser" и "\0alteratord-server".

(В ответ на комментарий №54)
> Собственно, пока просится вот такой сценарий в alterator-preinstall:

 1. остановка "внешнего" alteratord — теперь это можно делать, т.к. есть
 переподключение;
+2. прямое бинд-монтирование каталога /var/run/alteratord в чрут;
 3. запуск "внутреннего" alteratord;
-3. перемонтирование директории с сокетом наружу;
 4. notify "done".
Comment 57 manowar@altlinux.org 2019-08-23 17:07:56 MSK
(В ответ на комментарий №56)

> +2. прямое бинд-монтирование каталога /var/run/alteratord в чрут;
>  3. запуск "внутреннего" alteratord;
> -3. перемонтирование директории с сокетом наружу;

А поечему именно так? Т.е. почему ты настаиваешь на том, чтобы второй демон завёл свой сокет в готовой директории или даже подобрал уже существующий сокет? Вместо того, чтобы он создал свой сокет с нуля и этот новый сокет стал доступен снаружи после bind? Хочу обратить внимание, что сейчас (и исторически) именно второй вариант.
Comment 58 Leonid Krivoshein 2019-08-23 17:51:54 MSK
(В ответ на комментарий №57)
> А почему именно так? Т.е. почему ты настаиваешь на том, чтобы второй демон
> завёл свой сокет в готовой директории или даже подобрал уже существующий
> сокет?

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

> Вместо того, чтобы он создал свой сокет с нуля и этот новый сокет стал
> доступен снаружи после bind?

Новый демон должен создать свой сокет в том же месте. Старый клиент к нему подключится за счёт биндинга каталога. Прошу обратить внимание: сокета у нас два. И один (в /tmp/alterator) попадает в чрут прямым монтированием в одном скрипте, второй же попадает обратно в другом скрипте через монтирование в противоположную сторону. В разное время! Это никуда не годится. Нужно это всё делать однообразно в одном месте и в один момент.

> Хочу обратить внимание, что сейчас (и исторически) именно
> второй вариант.

Кто, если не мы, делаем историю! :) Исторически решение с обратным монтированием было плохим. Хотя нигде нет такого разграничения на прямое и обратное монтирование, такой общепринятой практики нет. Долгие поиски привели меня к тому, что, например, для докера люди спрашивали: по какой причине не поддерживается обратное монтирование? На мой взгляд, как минимум, эта практика противоречит некоторым соображениям безопасности.

Архитектурно нужно не костыли с задержками, а штатный механизм реакции на "done #t" или что-то подобное, то бишь адекватная реакция альтератора на событие перехода в чрут.

По вопросам в devel@ и абстрактным сокетам можно посмотреть раздел "Transmit file descriptors, credentials" здесь: https://kohlschutter.github.io/junixsocket/unixsockets.html и примеры авторизации с SCM_CREDENTIALS в этом мануале с примерами: https://onz.es/Que%20-%20Linux%20Socket%20Programming%20By%20Example%20-%20fly.pdf
Comment 59 manowar@altlinux.org 2019-08-23 18:22:28 MSK
(В ответ на комментарий №58)

> Прошу обратить внимание: сокета у нас два. И один (в /tmp/alterator) попадает
> в чрут прямым монтированием в одном скрипте

Напомни, пожалуйста, в каком. Я так до сих пор и не видел этот кусок.

В backend3/preinstall /tmp/alterator/.socket **удаляется**, но не монтируется. И это, кстати, ошибка, я считаю. После такого удаления notify() не должен работать! Если и нужно удялять какой-нибудь сокет, то только серверный.
Comment 60 Leonid Krivoshein 2019-08-23 18:48:22 MSK
(В ответ на комментарий №59)
> Напомни, пожалуйста, в каком. Я так до сих пор и не видел этот кусок.

Тут: [alterator-pkg]/alterator-pkg/backend3/pkg-init#43

> В backend3/preinstall /tmp/alterator/.socket **удаляется**, но не монтируется.
> И это, кстати, ошибка, я считаю.

Да, о том, что это было ошибкой с самого начала, выше уже написал Антон Бояршинов.

> После такого удаления notify() не должен работать!

Нет, удаляемый файл ни на что не влияет, он к этим сокетам не относится. А notify(), как я понимаю, связан с клиентским сокетом, с ним у нас нет проблем.
Comment 61 manowar@altlinux.org 2019-08-24 02:28:57 MSK
(В ответ на комментарий №53)
> Теперь у нас вроде как есть защита от рейса, повышающая живучесть всей системы.
> Прошу проверить, помогает ли. Если сразу не поможет, то можно, наверное,
> выставить количество повторов в какое-нибудь неприличное значение и попробовать
> за это время что-то руками нахимичить — сокеты перемаунтить и т.д. Ну и сделать
> выводы.

На всякий случай задание с этими изменениями + чистка alterator-preinstall:
http://git.altlinux.org/tasks/236531/
Comment 62 manowar@altlinux.org 2019-08-29 23:50:52 MSK
Ping? Мы Лёню ждём, да?
Comment 63 Leonid Krivoshein 2019-08-30 01:49:00 MSK
(В ответ на комментарий №62)
> Ping? Мы Лёню ждём, да?

Меня? Так ведь задача от тебя в редмайне. Даже когда выйду 2.09 из отпуска, проверку новой версии на e2k придётся согласовывать, вряд ли мне этим дадут заниматься. Поскольку аналогичная ситуация с вероятностью 50/50 поджидает на новых машинах AMD Ryzen и Intel x86_64 с 8СП, можно будет подключиться с оказией, но в первую очередь я бы исправил в бэкэнде явный рейс в [alterator-preinstall.git]/alterator-preinstall/backend3/preinstall#69-71 (см. комментарий #45).
Comment 64 manowar@altlinux.org 2019-08-30 11:44:45 MSK
Я там уже кое что поправил, и учитывая изменения в других пакетах думаю, что рейса теперь можно не бояться. Так что да, вопрос с проверкой этих изменений. Если главный полегон на E2K, то, значит, ждём mike@? Ну ещё вариант — у нас в офисе проверить, там есть какой-то E2K. Но нужны тогда вводная и образ.
Comment 65 Michael Shigorin 2019-08-30 20:49:55 MSK
Created attachment 8268 [details]
фрагмент /tmp/install2.log при e2k#23240 _с_ alterator-pkg 2.7.2

Проверил p9_e2k с таким довеском:

2019-Aug-30 16:02:49 :: test-only swift task #23240 for p9_e2k resumed by mike:
#100 build alterator-5.5-alt1.src.rpm
#200 build alterator-wizardface-2.2-alt1.src.rpm
#300 build alterator-preinstall-0.7.3-alt1.src.rpm
#400 build alterator-pkg-2.7.2-alt1.src.rpm

=> regular-jeos.iso упал в том же месте, но с несколько иным грохотом:

Error: (backend not found: root). Retry #1
[...]
ice-9/boot-9.scm:109:20: In procedure #<procedure b7e800 at ice-9/boot-9.scm:100:6 (thrown-k . args)>:
ice-9/boot-9.scm:109:20: Throw to key `woo-error' with args `("backend not found: root")'.

При этом alterator-root в образе, разумеется, есть.
Comment 66 Michael Shigorin 2019-08-30 21:24:20 MSK
(В ответ на комментарий №65)
> #100 build alterator-5.5-alt1.src.rpm
> #200 build alterator-wizardface-2.2-alt1.src.rpm
> #300 build alterator-preinstall-0.7.3-alt1.src.rpm

Предыдущее оставил, убрал #400 -- падать перестало:

> #400 build alterator-pkg-2.7.2-alt1.src.rpm
Comment 67 manowar@altlinux.org 2019-08-30 21:32:13 MSK
(В ответ на комментарий №65)

> => regular-jeos.iso упал в том же месте, но с несколько иным грохотом:
> 
> Error: (backend not found: root). Retry #1
> [...]
> ice-9/boot-9.scm:109:20: Throw to key `woo-error' with args `("backend not
> found: root")'.

  Слушай, он именно на ПЕРВОМ retry падает? Специально же там всё сделано, чтобы вместо падения была повторная попытка. Не понимаю пока, как такое могло случиться.
  Если падает после N попыток (там 20 вроде в alterator-wizardface из задания), то это куда не шло. Тогда можно разбираться дальше.
Comment 68 manowar@altlinux.org 2019-08-30 21:34:53 MSK
(В ответ на комментарий №66)

> Предыдущее оставил, убрал #400 -- падать перестало:
> 
> > #400 build alterator-pkg-2.7.2-alt1.src.rpm

  А какая версия сейчас у тебя? Что там за изменения?
Comment 69 Michael Shigorin 2019-08-30 22:43:12 MSK
(В ответ на комментарий №67)
> > Error: (backend not found: root). Retry #1
> > [...]
> Слушай, он именно на ПЕРВОМ retry падает? Специально же там всё сделано,
> чтобы вместо падения была повторная попытка. Не понимаю пока, как такое
> могло случиться.
Не, retry там 19 штук было.  Извини, слишком кратко приложенное процитировал.

(В ответ на комментарий №68)
> > Предыдущее оставил, убрал #400 -- падать перестало:
> > > #400 build alterator-pkg-2.7.2-alt1.src.rpm
> А какая версия сейчас у тебя? Что там за изменения?
Предыдущая 2.7-alt1 (см. comment 0).
Comment 70 manowar@altlinux.org 2019-08-30 23:13:46 MSK
(В ответ на комментарий №69)
> (В ответ на комментарий №67)
> > > Error: (backend not found: root). Retry #1
> > > [...]
> > Слушай, он именно на ПЕРВОМ retry падает? Специально же там всё сделано,
> > чтобы вместо падения была повторная попытка. Не понимаю пока, как такое
> > могло случиться.
> Не, retry там 19 штук было.  Извини, слишком кратко приложенное процитировал.

  Понял. Это другое дело. Тогда можно увеличить до 10000, к примеру, и попробовать за это время разобраться с сокетом — посмотреть в mount -l и /proc и т.д.

> 
> (В ответ на комментарий №68)
> > > Предыдущее оставил, убрал #400 -- падать перестало:
> > > > #400 build alterator-pkg-2.7.2-alt1.src.rpm
> > А какая версия сейчас у тебя? Что там за изменения?
> Предыдущая 2.7-alt1 (см. comment 0).

  Понял. Это я посмотрю завтра, что там такое могло быть, что наводит индукцию на preinstall.
Comment 71 Leonid Krivoshein 2019-09-03 18:35:34 MSK
Created attachment 8275 [details]
/var/run/alteratord/alteratord.log до обратного монтирования

Обратите внимание на pkg-size и концовку (отсутствующие обработчики). Это в любом случае множественные ошибки. И это последнее, что попадает в журнал перед переключением в чрут.
Comment 72 Leonid Krivoshein 2019-09-03 18:57:32 MSK
В том же файле, который в чруте, только две строки:

*** Make a new server socket ***
bind_unix: address /var/run/alteratord/.socket in use

Проблема в том, что судя по stat, это два разных файла. Тот, что в чруте, судя по временной метке, создан примерно в момент перехода в чрут. Однако морда продолжает работать с тем сокетом, что находится под ним, т.е. уже перекрыта чрутовой версией.

Вместе с тем, alterator-cmdline связывается с сокетом из перекрытого чрутового каталога и чудесно обнаруживает шаг /grub.

Локализовать рейс пока не получается. Картина вообще не поддаётся объяснению.
Comment 73 manowar@altlinux.org 2019-09-03 19:03:53 MSK
(В ответ на комментарий №72)
 
> Вместе с тем, alterator-cmdline связывается с сокетом из перекрытого чрутового
> каталога и чудесно обнаруживает шаг /grub.
> 
> Локализовать рейс пока не получается. Картина вообще не поддаётся объяснению.

  Версия с retry будет повторять попытки до тех пор, пока /grub не будет найдет (или не истечёт количество попыток). Поэтому если cmdline связывается, то и wizardface тоже должен с очередной попытки связаться.

  И ещё, как твой репорт связан вот с этим у mike@:

>> Предыдущее оставил, убрал #400 -- падать перестало
Comment 74 Leonid Krivoshein 2019-09-03 19:25:46 MSK
(In reply to comment #73)
> Версия с retry будет повторять попытки до тех пор, пока /grub не найдет
> (или не истечёт количество попыток).

Применить твои изменения на старую версию 8СП проблематично -- их много и они ёмкие, я же не пересобираю старый образ, а на новых 8СП и на WS9 не воспроизводится. При этом нам оставили проблемный Intel x86_64. Кроме того, бесполезно ждать и повторять: в отличие от случая mike@, у меня коннект не рвётся, с первой же попытки проскочит. Инсталлятор при повторном запуске сразу работает с новым alteratord в чруте, поэтому не находит /steps-list. Но и старый не просто так отваливается, потому и привёл лог -- он спотыкается как раз на сокете (не почистили за собой после разрыва pipe в результате внезапного killall).

> 
>   И ещё, как твой репорт связан вот с этим у mike@:
> 
> >> Предыдущее оставил, убрал #400 -- падать перестало

Никак. Второй день дебажу 8СП на проблемном Intel x86_64, где морда продолжает работать со старым альтератором, что бы я не делал. Убрать #400 это всё равно, что не применить твои патчи, а откатить изменения shaba@, чего делать нельзя. То бишь твои изменения фронтэнда не помогли на e2k. Равно как и никакие мои изменения в бэкэндах не помогают решить и даже локализовать проблему. Но, по крайней мере, нашлось несколько конкретных ошибок, частично они выше уже описаны.
Comment 75 Leonid Krivoshein 2019-09-05 15:40:37 MSK
Created attachment 8279 [details]
/usr/lib/alterator/backend3/preinstall использованный для отладки

Чтобы отловить момент рейса, сделал следующее: заменил концовку в preinstall, в том числе, убрав обратное монтирование, что позволило подвесить установочный процесс на alterator-wait, вплоть до выполнения в другой консоли обратного монтирования. После этого подрубился strace'ом ко всем PID'ам альтератора одной командой и записал происходящее падение (буквально доли секунды)...
Comment 76 Leonid Krivoshein 2019-09-05 15:44:04 MSK
Created attachment 8280 [details]
strace момента падения: процесс alteratord
Comment 77 Leonid Krivoshein 2019-09-05 15:45:42 MSK
Created attachment 8281 [details]
strace момента падения: процесс alterator-qt-browser
Comment 78 Leonid Krivoshein 2019-09-05 15:48:11 MSK
Created attachment 8282 [details]
strace момента падения: процесс alterator-wizard
Comment 79 Leonid Krivoshein 2019-09-06 18:43:40 MSK
Created attachment 8283 [details]
strace происходящего в preinstall на новом образе 8СП в норме
Comment 80 Leonid Krivoshein 2019-09-06 18:44:41 MSK
Created attachment 8284 [details]
strace происходящего в preinstall на старом образе 8СП (падение)
Comment 81 Leonid Krivoshein 2019-09-06 18:46:03 MSK
Created attachment 8285 [details]
Все логи по результату падения на старом образе 8СП
Comment 82 Leonid Krivoshein 2019-09-06 18:52:21 MSK
Требуется детальный анализ. По-моему, разница очевидна. В прошлый раз захватывал только момент падения, внося изменения в исходники. В этот раз исходники не менял, захват в другой консоли выполнялся примерно так:

strace -o /run/$filename -f -p $pid &

для каждого интересующего процесса, всё одной строкой (командой) во втором терминале незадолго до момента предполагаемого падения, в процессе preinstall (точка начала в его середине условно примерная) и до момента падения (перехода к шагу /grub -- тоже примерно).

Теперь можно сравнить ситуацию в норме и ситуацию с падением на одной машине.
Comment 83 Leonid Krivoshein 2019-09-11 15:09:38 MSK
Павел, отдельным письмом передаю тебе все собранные данные с комментариями.
В МСК нашлась ещё одна машинка, где баг проявился, можем тебе её переслать.

Теперь главное -- характер системных вызовов везде одинаковый, ничего подозрительного не нашлось в 4-х сравниваемых случаях. Единственное отличие заключается в том, что в случае успеха, сразу после 4-х сбойных обращений из alterator-wizard:

stat("/usr/share/alterator/ui//grub/index.scm", 0x7ffe90f1d3e0) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/ui//grub.scm", 0x7ffe90f1d460) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub/index.scm", 0x7ffe90f1d460) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub.scm", 0x7ffe90f1d4e0) = -1 ENOENT (No such file or directory)

он продолжает перебор путей и находит нужное:

stat("/mnt/destination/usr/share/alterator/ui//grub/index.scm", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
access("/mnt/destination/usr/share/alterator/ui//grub/index.scm", R_OK) = 0
open("/mnt/destination/usr/share/alterator/ui//grub/index.scm", O_RDONLY) = 15

а в случае ошибки, сразу вылетает:

write(1, "<* ((#t))\nRET: ()\n", 18) = 18
write(2, "frame:on-next is deprecated, use"..., 966) = 966
exit_group(1)                     = ?
Comment 84 manowar@altlinux.org 2019-09-11 17:02:33 MSK
(В ответ на комментарий №75)

> командой и записал происходящее падение (буквально доли секунды)...

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

  Поэтому ещё раз прошу перейти вот к этой тактике:

>> Не, retry там 19 штук было.  Извини, слишком кратко приложенное процитировал.
>
>   Понял. Это другое дело. Тогда можно увеличить до 10000, к примеру, и
> попробовать за это время разобраться с сокетом — посмотреть в mount -l
> и /proc и т.д.

  Потому что очень не верится, что если мы имеем процесс, который постоянно повторяет попытки открыть файл F, то, имея в запасе время и консоль, нельзя в конце концов создать ему такие условия, когда он этот файл наконец откроет. В нашем случае — откроет ту версию файла, которая нам нужна. А стоит успешно закончить такой эксперимент, как всё остальное наверняка прояснится в гораздо большей степени, чем сейчас.
Comment 85 manowar@altlinux.org 2019-09-11 17:41:47 MSK
(В ответ на комментарий №70)

> > (В ответ на комментарий №68)
> > > > Предыдущее оставил, убрал #400 -- падать перестало:
> > > > > #400 build alterator-pkg-2.7.2-alt1.src.rpm
> > > А какая версия сейчас у тебя? Что там за изменения?
> > Предыдущая 2.7-alt1 (см. comment 0).
> 
>   Понял. Это я посмотрю завтра, что там такое могло быть, что наводит индукцию
> на preinstall.

  Вроде ж всё очевидно. #400 делает вот такую нехорошую вещь:

    ln -s ../run "$destdir/var/run"
    ln -s ../run/lock "$destdir/var/lock"

после которой разница между /run и /var/run внутри $destdir исчезает. В то же самое время, alterator-preinstall полагается в своей работе именно на то, что /run и /var/run — независимые пути:

    mount -o bind /run $destdir/run
    # Всё! Симлинк $destdir/var/run ведёт теперь в _наш_, т.е. наружный /run.

    mount -o bind $destdir$alteratord_socket_dir $alteratord_socket_dir
    # Превратилось в тавтологию или чего похуже: монтируем _симлинк_
    # "$destdir/var/run -> $destdir/run" в /var/run , который, видимо,
    # просто /run, смонтированный в обе системы (логично предположить
    # что у нас во внешней системе вредный симлинк "/var/run -> /run"
    # также присутствует).

    chroot $destdir service alteratord start
    # Должен теперь бороться с нашим (внешнем) alteratord за один и тот
    # же файл сокета.


  Неудивительно, поэтому, что

> > > > Предыдущее оставил, убрал #400 -- падать перестало:

  Какие тут "протоколы альтератора", какие эс-трейсы с километрами логов?! Должно лечиться простым удалением строки

    mount -o bind /run $destdir/run

  из alterator-preinstall.  Поскольку после #400, т.е. после alterator-pkg-2.7.2-alt1, в $destdir и так есть свой собственный tmpfs и на диске, очевидно, ничего лишнего после установки не останется.
Comment 86 manowar@altlinux.org 2019-09-11 17:51:15 MSK
http://git.altlinux.org/tasks/236531/ -- alterator-preinstall.git v0.7.4-alt1
Comment 87 Leonid Krivoshein 2019-09-11 17:54:39 MSK
(In reply to comment #84)
>   Потому что очень не верится, что если мы имеем процесс, который постоянно
> повторяет попытки открыть файл F, то, имея в запасе время и консоль, нельзя в
> конце концов создать ему такие условия, когда он этот файл наконец откроет.

Это история про Эльбрус. В переводе на мою ситуацию всё наоборот -- он должен, в конце концов, прекратить работать с прежним сокетом. Но мы на самом деле не знаем, почему так происходит. И как показала практика, вкорячивание задержек мне не помогла.

> В нашем случае — откроет ту версию файла, которая нам нужна. А стоит успешно
> закончить такой эксперимент, как всё остальное наверняка прояснится в гораздо
> большей степени, чем сейчас.

По крайней мере, теперь у нас есть свободный экземпляр, где эта редкая проблема воспроизводится. И речь теперь не о локализации бага (это бы тоже не помешало, но мы и так убили на него слишком много времени), а речь об усовершенствовании механизма перехода в чрут, в целом.

Когда мы работаем с сокетом, обе стороны должны от него отключиться и удалить его. Также необходимо учитывать прерываемый ввод-вывод в сокете (не законченный ввод или вывод, прерванный в/в и возобновление после прерывания в системном вызове. Надеяться лишь на то, что каталог с сокетом будет перекрыт (в какой момент!?) и работа возобновиться через новый сокет -- в корне опрометчиво, это и есть архитектурный баг.
Comment 88 Leonid Krivoshein 2019-09-11 17:58:08 MSK
(In reply to comment #85)
> Должно лечиться простым удалением строки
>     mount -o bind /run $destdir/run
> из alterator-preinstall.

Думаешь, мы так не делали? Это первое, что предложил shaba@ -- не помогло. Данный инсталлятор вообще колом после этого встаёт. Позже немного разобрался, почему это происходит. Загляни ещё в pkg-init и remount.
Comment 89 Sergey V Turchin 2019-09-11 18:05:23 MSK
(В ответ на комментарий №88)
> (In reply to comment #85)
> > Должно лечиться простым удалением строки
> >     mount -o bind /run $destdir/run
> > из alterator-preinstall.
> Думаешь, мы так не делали? Это первое, что предложил shaba@ -- не помогло.
Если правильно понимаю, с новым systemd это монтирование надо убирать и менять зависимое от этого.
Comment 90 manowar@altlinux.org 2019-09-11 22:24:01 MSK
(В ответ на комментарий №88)
> (In reply to comment #85)
> > Должно лечиться простым удалением строки
> >     mount -o bind /run $destdir/run
> > из alterator-preinstall.
> 
> Думаешь, мы так не делали? Это первое, что предложил shaba@ -- не помогло.

  Делали или сделали? Какая на сегодняшний день обстановка на проблемной машине? Есть эта строчка или нет?
Comment 91 manowar@altlinux.org 2019-09-11 22:29:15 MSK
(В ответ на комментарий №74)

> Убрать #400 это всё равно, что не применить твои патчи, а откатить
> изменения shaba@, чего делать нельзя.

  В порядке эксперимента можно? mike@ уже попробовал — помогло. Попробуйте, пожалуйста, и вы. Если поможет — инсталлятор начнёт работать также, как и раньше, — то будет уже однозначно понятно, что проблема в конфликте между наличием симлинка "/var/run -> /run" и перемонтированием сокетов.
Comment 92 Alexey Shabalin 2019-09-11 23:19:10 MSK
(В ответ на комментарий №91)
> (В ответ на комментарий №74)
> 
> > Убрать #400 это всё равно, что не применить твои патчи, а откатить
> > изменения shaba@, чего делать нельзя.
> 
>   В порядке эксперимента можно? mike@ уже попробовал — помогло. Попробуйте,
> пожалуйста, и вы. Если поможет — инсталлятор начнёт работать также, как и
> раньше, — то будет уже однозначно понятно, что проблема в конфликте между
> наличием симлинка "/var/run -> /run" и перемонтированием сокетов.

Я не понимаю, зачем Леонид всех путает и мешает все в одно.
mike@ откатил изменения "симлинк /var/run -> /run" на p9 для e2k.
А klark@ воюет на 8СП (x86_64), где нет никаких "симлинков /var/run -> /run".

Не смешивайте проблемы, а лучше вообще в разных багах это обсуждать.
Comment 93 manowar@altlinux.org 2019-09-12 11:34:19 MSK
(В ответ на комментарий №92)
> (В ответ на комментарий №91)
> > (В ответ на комментарий №74)
> > 
> > > Убрать #400 это всё равно, что не применить твои патчи, а откатить
> > > изменения shaba@, чего делать нельзя.
> > 
> >   В порядке эксперимента можно? mike@ уже попробовал — помогло. Попробуйте,
> > пожалуйста, и вы. Если поможет — инсталлятор начнёт работать также, как и
> > раньше, — то будет уже однозначно понятно, что проблема в конфликте между
> > наличием симлинка "/var/run -> /run" и перемонтированием сокетов.
> 
> Я не понимаю, зачем Леонид всех путает и мешает все в одно.
> mike@ откатил изменения "симлинк /var/run -> /run" на p9 для e2k.

Миша, попробуй тогда, пожалуйста, новую сборку preinstall без отката pkg.


> А klark@ воюет на 8СП (x86_64), где нет никаких "симлинков /var/run -> /run".
> Не смешивайте проблемы, а лучше вообще в разных багах это обсуждать.

Вот уж действительно.
Comment 94 manowar@altlinux.org 2019-09-12 12:21:33 MSK
(В ответ на комментарий №87)
> (In reply to comment #84)
> >   Потому что очень не верится, что если мы имеем процесс, который постоянно
> > повторяет попытки открыть файл F, то, имея в запасе время и консоль, нельзя в
> > конце концов создать ему такие условия, когда он этот файл наконец откроет.
> 
> Это история про Эльбрус. В переводе на мою ситуацию всё наоборот -- он должен,
> в конце концов, прекратить работать с прежним сокетом. Но мы на самом деле не
> знаем, почему так происходит. И как показала практика, вкорячивание задержек
> мне не помогла.

  Само по себе не помогло? Вот ты меня упорно не понимаешь или не хочешь понимать. Я сделал таймауты и повторы, в частности, для того, чтобы можно было проводить эксперименты на живой системе. Чтобы можно было поднять количество повторов до практической бесконечности и спокойно исследовать процесс прямо во время его работы — менять окружение, пробовать перемонтирование различными способами. Уже неоднократно об этом писал сюда.
  Если вдруг неудобно или не получается экспериментировать со Scheme, то можно было написать простую тестовую пару клиент-сервер и поставить её в те же самые условия, т.е. в директорию /var/run/alteratord/. Но вместо активного эксперимента, ты упорно сворачиваешь к forensic analysis и признаешь, кажется, только его. Почему — непонятно.

> > В нашем случае — откроет ту версию файла, которая нам нужна. А стоит успешно
> > закончить такой эксперимент, как всё остальное наверняка прояснится в гораздо
> > большей степени, чем сейчас.
> 
> По крайней мере, теперь у нас есть свободный экземпляр, где эта редкая проблема
> воспроизводится. И речь теперь не о локализации бага (это бы тоже не помешало,
> но мы и так убили на него слишком много времени), а речь об усовершенствовании
> механизма перехода в чрут, в целом.
> 
> Когда мы работаем с сокетом, обе стороны должны от него отключиться и удалить
> его. Также необходимо учитывать прерываемый ввод-вывод в сокете (не законченный
> ввод или вывод, прерванный в/в и возобновление после прерывания в системном
> вызове. Надеяться лишь на то, что каталог с сокетом будет перекрыт (в какой
> момент!?) и работа возобновиться через новый сокет -- в корне опрометчиво, это
> и есть архитектурный баг.

  Извини, но это вывод на пустом месте. Не зная точно и конкретно, почему директория с сокетом не перекрывается нормально, нельзя предлагать отключение от сокета в качестве лекарства. Это опять игра в угадайку. @ldv выше правильно отметил, что много лет работало. И раз теперь сломалось, значит есть конкретная причина.
Comment 95 manowar@altlinux.org 2019-09-12 14:37:42 MSK
(В ответ на комментарий №87)

> Когда мы работаем с сокетом, обе стороны должны от него отключиться и удалить
> его.

  Собственно, это элементарно проверить. Клиент и так не подключён к сокету — он подключается каждый раз заново. Слушает только сервер. Следовательно, пока клиент повторяет попытки, Ctrl+Alt+F2 и

    service alteratord stop
    chroot $destdir service alteratord stop
    rm -fv /var/run/alteratord/.socket
    rm -fv $destdir/var/run/alteratord/.socket
    chroot $destdir service alteratord start

> Также необходимо учитывать прерываемый ввод-вывод в сокете (не законченный
> ввод или вывод, прерванный в/в и возобновление после прерывания в системном
> вызове.

  Учитывать это как? Напиши конкретнее, что ты имеешь в виду.
Comment 96 Leonid Krivoshein 2019-09-12 15:22:46 MSK
У нас есть два немного отличающихся проявления одной и той же проблемы: alterator не может перейти к следующему шагу в чруте после шага alterator-pkg. mike@ просил описать в ЭТОМ баге, как я на это нарвался. Если есть желание разделить ЕГО на два отдельных бага и это целесообразно, давайте разделим.

Путается кто-то другой -- я довольно чётко описываю, в каких ситуациях это проявляется на старом образе 8СП в режиме загрузки UEFI/x86_64. Конечно, с e2k я не работаю. Но моё предложение заключалось в том, чтобы после усовершенствования механизма перехода в чрут применить данное решение к обеим случаям, т.е. и к e2k тоже, а не заниматься локализацией проблемы, на которую убито и так слишком много времени.

Относительно продолжения работ по данному багу ещё разок поясню:

1) Всё что можно было исследовать в части бэкэнда -- я сделал, нашёл кучу ошибок и даже частично их описал. Но даже с ними это как-то на удивление работало годами. Поэтому их исправление сейчас -- не первая необходимость.

2) Со схемой и фронт-эндом в любом случае ничем помочь не могу.

3) Временной лимит на данную задачу для меня исчерпан -- cas@ и smi@ ставят другие более срочные сейчас задачи. Поэтому данная задача передана manowar@.

4) С руководством пока окончательно не согласовано, но в офисе МСК нашёлся системный блок, где проблема проявляется. Его можно переправить manowar@. Удалённо выполнять в МСК на нём какие-то действия сейчас просто некому.

По частностям:

1) service alteratord stop -- после этого инсталлятор зависнет, ни к какому другому шагу он больше не перейдёт. Ещё раз: больше недели всё что на шелле, я перелопатил и опробовал всё.

2) "Попробуйте, пожалуйста, и вы." -- mike@ пересобирает новые образы, а здесь как предлагалось? Очень большой объём изменений вносить через vi в старый образ 8СП! Как ты себе это представляешь?

3) "Миша, попробуй тогда, пожалуйста, новую сборку preinstall без отката pkg." -- он пока в отпуске.
Comment 97 manowar@altlinux.org 2019-09-12 17:12:37 MSK
(В ответ на комментарий №96)

> 4) С руководством пока окончательно не согласовано, но в офисе МСК нашёлся
> системный блок, где проблема проявляется. Его можно переправить manowar@.

  Я не против, конечно.

> 1) service alteratord stop -- после этого инсталлятор зависнет, ни к какому
> другому шагу он больше не перейдёт. Ещё раз: больше недели всё что на шелле, я
> перелопатил и опробовал всё.

  Ты уверен, что тут именно зависание? Может быть ты просто количество повторов настроил очень большим? Потому что после истечения заданного количества повторов, инсталлятор должен закончить работу с ошибкой.
Может быть это и в самом деле другая ошибка, как shaba@ писал.
Comment 98 Leonid Krivoshein 2019-09-12 17:53:42 MSK
(In reply to comment #97)
> Ты уверен, что тут именно зависание?

В моём случае на 8СП на проблемных экземплярах это так и этому можно найти некое объяснение. Ведь там работа продолжается со старым сокетом, как уже выяснили. И тут мы такие смелые приходим во вторую консоль и его отрубаем. А морда инсталлятора продолжает работать...

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

Нам ещё привозили третий Ryzen из ICL. Там тоже этот баг проявлялся, но машину уже отдали.
Comment 99 manowar@altlinux.org 2019-09-12 18:49:36 MSK
(В ответ на комментарий №98)
> (In reply to comment #97)
 
> Конечно, вызывает недоумение, а как раньше-то этот ныне закомментированный код
> работал?

  Ты вот об этом backend3/preinstall?

    # stop old alteratord and kill itself
    # sleep 1
    # service alteratord stop

  Так, действительно, делать не стоит, т.к. скрипт убивает своего родителя и, следовательно, самого себя. А по этой причине ответ в инсталлятор может не дойти и он в самом деле зависнет.

  Но я имел в виду не автоматический service alteratord stop, а именно вручную из второй (третьей и т.д.) консоли. Причём не абы когда...

> В моём случае на 8СП на проблемных экземплярах это так и этому можно найти
> некое объяснение. Ведь там работа продолжается со старым сокетом, как уже
> выяснили. И тут мы такие смелые приходим во вторую консоль и его отрубаем. А
> морда инсталлятора продолжает работать...

...а тогда, когда клиент уже выйдет на режим (!) повторов и начнёт писать в лог Retry #1, Retry #2... Тогда будет ясно, что он уже _не продолжает_ работать со старым сокетом, а делает только пыпытки начать работу с сокетом — а это не одно и то же. В таком состоянии service alteratord stop не должен повлиять на ситуацию в худшую сторону.
Comment 100 Ivan Zakharyaschev 2019-09-19 23:04:49 MSK
Тут очень запутанное обсуждение, особенно тяжело что-то понять из-за того, что manowar@ пишет разные предложение: попробуйте так, или вот так, и т.д. А в ответ нет отчётов о том, попробовали или нет и как это изменило поведение.

Т.е. непонятно: тому, кто будет ещё этим заниматься, пробовать что-то новенькое или то, что предлагал manowar@?

К тому же Леонид мне рассказал, что у него есть две флешки:

* синяя "ALT 8 SP FSTEK" -- где это воспроизводится на некоторых системных блоках, с которыми он работает;
* жёлтая, условно назовём её ALT 8.1 SP -- где это не воспроизводится!

Интересно, какое ещё решение это проблемы нажо искать, если с жёлтой флешкой ФДЕ 8.1 SP она уже не воспроизводится...

В таком случае остаётся для начала по крайней мере сделать очередной "forensic analysis" и посмотреть, что отличается в образах на этих двух флешках (или что отличается в пакетах, которые туда попали, в том состоянии репозитория, когда эти образы делались).

Придумывать что-то новенькое, когда ещё даже неизвестно, почему с желтой флешкой проблема исчезла -- странное занятие.
Comment 101 Ivan Zakharyaschev 2019-09-19 23:10:10 MSK
(In reply to comment #100)

> К тому же Леонид мне рассказал, что у него есть две флешки:
> 
> * синяя "ALT 8 SP FSTEK" -- где это воспроизводится на некоторых системных
> блоках, с которыми он работает;
> * жёлтая, условно назовём её ALT 8.1 SP -- где это не воспроизводится!
> 
> Интересно, какое ещё решение это проблемы надо искать, если с жёлтой флешкой
> ALT 8.1 SP она уже не воспроизводится...
> 
> В таком случае остаётся для начала по крайней мере сделать очередной "forensic
> analysis" и посмотреть, что отличается в образах на этих двух флешках (или что
> отличается в пакетах, которые туда попали, в том состоянии репозитория, когда
> эти образы делались).

Леонид, поправь, если что-то не так понял и передал.

А когда и кем эти образы делались? Можно ли просто посмотреть на состав пакетов в них?
Comment 102 Ivan Zakharyaschev 2019-09-19 23:31:31 MSK
Ещё интересное замечание, рассказаное Леонидом (поправь, если не так понял), которого здесь не было написано:

на системных блоках x86_64, где у него наблюдается проблема, она наблюдается только при устанвке в EFI режиме, но не legacy.
Comment 103 manowar@altlinux.org 2019-09-19 23:54:36 MSK
(В ответ на комментарий №100)
> Тут очень запутанное обсуждение, особенно тяжело что-то понять из-за того, что
> manowar@ пишет разные предложение: попробуйте так, или вот так, и т.д. А в
> ответ нет отчётов о том, попробовали или нет и как это изменило поведение.

  Да, это боль.

> Т.е. непонятно: тому, кто будет ещё этим заниматься, пробовать что-то новенькое
> или то, что предлагал manowar@?
> 
> К тому же Леонид мне рассказал, что у него есть две флешки:
> 
> * синяя "ALT 8 SP FSTEK" -- где это воспроизводится на некоторых системных
> блоках, с которыми он работает;
> * жёлтая, условно назовём её ALT 8.1 SP -- где это не воспроизводится!
> 
> Интересно, какое ещё решение это проблемы нажо искать, если с жёлтой флешкой
> ФДЕ 8.1 SP она уже не воспроизводится...

  Скажу, что согласен с Леонидом в одном: что нужно найти не workaround, а истинный корень проблемы — такое место, которое провоцирует нестабильность и ненадёжность при переходе в чрут (и иногда вот проявляется как ошибка), и исправить его. Но я не согласен принимать на веру, что это "mount -o bind" плохо работает или что это доменные сокеты подкачали и отказываться от данного механизма на таком "основании".
Comment 104 AEN 2019-09-20 12:03:13 MSK
(В ответ на комментарий №100)
> Тут очень запутанное обсуждение, особенно тяжело что-то понять из-за того, что
> manowar@ пишет разные предложение: попробуйте так, или вот так, и т.д. А в
> ответ нет отчётов о том, попробовали или нет и как это изменило поведение.
> 
> Т.е. непонятно: тому, кто будет ещё этим заниматься, пробовать что-то новенькое
> или то, что предлагал manowar@?
> 
> К тому же Леонид мне рассказал, что у него есть две флешки:
> 
> * синяя "ALT 8 SP FSTEK" -- где это воспроизводится на некоторых системных
> блоках, с которыми он работает;
> * жёлтая, условно назовём её ALT 8.1 SP -- где это не воспроизводится!
> 
> Интересно, какое ещё решение это проблемы нажо искать, если с жёлтой флешкой
> ФДЕ 8.1 SP она уже не воспроизводится...
> 
> В таком случае остаётся для начала по крайней мере сделать очередной "forensic
> analysis" и посмотреть, что отличается в образах на этих двух флешках (или что
> отличается в пакетах, которые туда попали, в том состоянии репозитория, когда
> эти образы делались).
> 
> Придумывать что-то новенькое, когда ещё даже неизвестно, почему с желтой
> флешкой проблема исчезла -- странное занятие.

+1
Comment 105 Ivan Zakharyaschev 2019-09-20 15:19:30 MSK
(In reply to comment #11)

> > А как же alterator-wait из того же самого скрипта?
> 
> Обязан, но не ждёт. Перезапуск инсталлятора после падения в моём случае с 8СП
> говорит о том, что alteratord в целевой системе запустился, то есть,
> alterator-wait должным образом не работает либо из-за занятости вводом/выводом
> к моменту его вызова не происходит удаления старого сокета. Позже --
> происходит.
> 
> Первый sleep вроде как должен помочь в случае с e2k, вот только какой? Ни 2, ни
> 5, ни 180 секунд нам не помогли. Второй sleep вкорячивали перед alterator-wait
> -- второй как раз наш случай с 8СП на x86_64, сегодня с этой машиной последний
> день можем работать.

А во втором случае sleep прямо перед aletarator-wait в скрипте preinstall не помогал (на 8СП на x86_64)?

Из сообщений не очень понятно.

Имеется в виду после запуска alteratord в чруте и перед alterator-wait.
Comment 106 Leonid Krivoshein 2019-09-20 16:21:52 MSK
Иван описал переданную ситуацию совершенно верно. Но насчёт EFI это замечание выше озвучивалось несколько раз -- на x86_64 это проявляется только в EFI, но не в Legacy. Я даже уточню, хотя с этим багом не связано. На четырёх физических экземплярах есть видеокарта Intel (PCI 0:2:0), на Ryzen'е была видеокарта AMD Vega. На всех пяти машинах число падений инсталлятора в режиме Legacy -- 0, в режиме EFI -- 2 падения. Первое падение здесь offtop, оно связано с ошибкой в инсталляторе при определении видеокарты. Давно исправлено во всех бранчах, но не в старых образах. Второй раз инсталлятор падает уже в середине работы, уже после первого перезапуска.

А вот насчёт этого -- в точку!

(In reply to comment #103)
> 
>   Скажу, что согласен с Леонидом в одном: что нужно найти не workaround, а
> истинный корень проблемы — такое место, которое провоцирует нестабильность и
> ненадёжность при переходе в чрут (и иногда вот проявляется как ошибка), и
> исправить его. Но я не согласен принимать на веру, что это "mount -o bind"
> плохо работает или что это доменные сокеты подкачали и отказываться от данного
> механизма на таком "основании".

Мне удалось через пень-колоду применить ранее озвученный workaround. Не сразу. А в процессе опять же strace'ом пытался понять, почему не запускается, что мешает. И вот тут выяснилась совсем новая интересная информация...

Ранее мы исходили из того, что раз после падения работает alterator-cmdline, раз инсталлятор запускается повторно, с сокетом всё нормализовалось. И мы были уверены, что проблема с механизмом перехода в чрут. Но оказалось, что с переходом в чрут нет проблем, их нет и с сокетом. Как будто ошибка в самом шаге grub и единственное, что помогло, это копирование тех файлов, что он не может найти, в обе стороны. Я опишу потом подробнее всю схему.
Comment 107 Ivan Zakharyaschev 2019-09-20 18:50:27 MSK
(In reply to comment #105)
> (In reply to comment #11)
> 
> > > А как же alterator-wait из того же самого скрипта?
> > 
> > Обязан, но не ждёт. Перезапуск инсталлятора после падения в моём случае с 8СП
> > говорит о том, что alteratord в целевой системе запустился, то есть,
> > alterator-wait должным образом не работает либо из-за занятости вводом/выводом
> > к моменту его вызова не происходит удаления старого сокета. Позже --
> > происходит.
> > 
> > Первый sleep вроде как должен помочь в случае с e2k, вот только какой? Ни 2, ни
> > 5, ни 180 секунд нам не помогли. Второй sleep вкорячивали перед alterator-wait
> > -- второй как раз наш случай с 8СП на x86_64, сегодня с этой машиной последний
> > день можем работать.
> 
> А во втором случае sleep прямо перед aletarator-wait в скрипте preinstall не
> помогал (на 8СП на x86_64)?
> 
> Из сообщений не очень понятно.
> 
> Имеется в виду после запуска alteratord в чруте и перед alterator-wait.

Мне было интересно и я именно это попробовал на x86_64: sleep 60 в начале d-wait. Не исправляет проблему, то же самое.
Comment 108 Leonid Krivoshein 2019-09-20 20:23:17 MSK
(In reply to comment #106)
> ...опишу потом подробнее всю схему.

Если в /usr/lib/alterator/backend3/preinstall сразу после запуска альтератора в чруте (перед alterator-wait) добавить такие строчки:

cp -Lf  /usr/share/install2/installer-steps $destdir/usr/share/install2/
cp -LRf /usr/share/install2/steps $destdir/usr/share/install2/
cp -LRf /usr/share/alterator/design/images/steps \
        $destdir/usr/share/alterator/design/images/
cp -Lf  /usr/lib/alterator/backend3/step-list \
        $destdir/usr/lib/alterator/backend3/
cp -LRf /usr/share/alterator/ui/wizard $destdir/usr/share/alterator/ui/
cp -LRf $destdir/usr/share/alterator/ui/* /usr/share/alterator/ui/

инсталлятор больше не падает, успешно переходит к шагу grub и далее доходит до самого конца. Проблема ровно в том месте, на которое я указывал ранее. Данный workaround позволяет не дойти до места возникновения этой ошибки в одном из включаемых скриптов гайла в alterator-wizard.
Comment 109 Leonid Krivoshein 2019-09-20 20:53:15 MSK
Пожалуй, дополню: безусловно проблему решает лишь последнее копирование:

cp -LRf $destdir/usr/share/alterator/ui/* /usr/share/alterator/ui/

(перед alterator-wait). Пять других нужны были лишь на случай падения инсталлятора и там ещё нужно было делать до них что-то вроде:

sed -i '1,/^installer\-preinstall/d' /usr/share/install2/installer-steps

где installer-preinstall -- последний успешно выполненный шаг. А раз инсталлятор больше не падает, то вроде как и не нужны уже первые пять копирований. Сейчас я эту версию проверяю...

Таким образом, уже можно сделать выводы на предмет того, что именно искать в части отличий. В новом коде добавлен поиск по путям с префиксом /mnt/destination -- шесть вызовов stat(), а не четыре. Но если этот код был и раньше, значит падает не дойдя до него, не перебрав все варианты. И в процессе этой ошибки нет каких-либо других системных вызовов, она чисто логическая, в коде guile.
Comment 110 Leonid Krivoshein 2019-09-21 00:54:28 MSK
Поясню по последнему абзацу. Вот так выглядит сбой в плохом случае:

stat("/usr/share/alterator/ui//grub/index.scm", 0x7ffc052c6520) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/ui//grub.scm", 0x7ffc052c65a0) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub/index.scm", 0x7ffc052c65a0) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub.scm", 0x7ffc052c6620) = -1 ENOENT (No such file or directory)
write(1, "<* ((#t))\nRET: ()\n", 18) = 18

В хорошем случае вывод starce отличается, начиная с 5-й строки:

stat("/usr/share/alterator/ui//grub/index.scm", 0x7ffe90f1d3e0) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/ui//grub.scm", 0x7ffe90f1d460) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub/index.scm", 0x7ffe90f1d460) = -1 ENOENT (No such file or directory)
stat("/usr/share/alterator/templates//grub.scm", 0x7ffe90f1d4e0) = -1 ENOENT (No such file or directory)
stat("/mnt/destination/usr/share/alterator/ui//grub/index.scm", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
access("/mnt/destination/usr/share/alterator/ui//grub/index.scm", R_OK) = 0
open("/mnt/destination/usr/share/alterator/ui//grub/index.scm", O_RDONLY) = 15

Но в случае сбоя до обращения к /mnt/destination/usr/share/alterator/ui//grub/index.scm дело не доходит. workaround превратит этот вывод во что-то такое:

stat("/usr/share/alterator/ui//grub/index.scm", {st_mode=S_IFREG|0644, st_size=1883, ...}) = 0
access("/usr/share/alterator/ui//grub/index.scm", R_OK) = 0
open("/usr/share/alterator/ui//grub/index.scm", O_RDONLY) = 15

На всякий случай напомню предысторию: до шага /grub альтератор стучался по четырём путям для каждого шага и по одному из них находил искомое. Это логично, поскольку все необходимые файлы для первых шагов должны лежать в установочной системе. Но файлов морды для шагов, выполняемых в чруте, в установочной системе нет. Вот здесь по факту тоже всегда пусто:

ls /usr/share/alterator/templates/
ls /mnt/destination/usr/share/alterator/templates/

Если скопировать из чрута в установочную систему UI-файлы только для шага /grub, инсталлятор вылетит на следующем шаге -- /net, итд... Почему он не ищет их в чруте, почему он не доходит до /mnt/destination/usr/share/alterator/ui//grub/index.scm -- не знаю.
Comment 111 Ivan Zakharyaschev 2019-09-21 14:29:49 MSK
Леонид, а может быть, две последовательные ошибки на x86_64 с ALT SP 8 -- связанные вещи?

В legacy-режиме вторая не происходит. А первая, с запуском X-сервера происходит?

Просто я подумал, прочитав твоё последнее сообщение, что когда ты вручную после первой ошибки запускаешь xinit /usr/sbin/alterator-install2, ты, чозможно, теряешь для него параметры или переменные окружения, который добавляют пути для поиска scm-файлов интерфейса шагов.

Помню, ьам есть что-то про чтения доп.файла конфигурации в штатном скрипте.
Comment 112 Leonid Krivoshein 2019-09-21 16:51:24 MSK
(In reply to comment #111)
> Леонид, а может быть, две последовательные ошибки на x86_64 с ALT SP 8 --
> связанные вещи?

Думал об этом -- исключено. Первый баг был обнаружен более 2х лет назад и исправлен более года назад. Ещё раньше я начал применять workaround с fbdev на EFI. Машин с тех пор через меня прошло очень много и ни одна из них второй раз не вываливалась в середине. Первая такая машина появилась совсем недавно -- Ryzen из ICL, но тогда мы грешили на совсем плохое железо.

Другое дело (вчера сразу не догадался посмотреть), имеет смысл проверить "недостающее" в установочной системе на разных образах при переходе к шагу /grub. Вдруг, это ещё приблизит нас к локализации проблемы.
Comment 113 manowar@altlinux.org 2019-09-23 13:05:29 MSK
(В ответ на комментарий №110)

> Если скопировать из чрута в установочную систему UI-файлы только для шага
> /grub, инсталлятор вылетит на следующем шаге -- /net, итд... Почему он не ищет
> их в чруте, почему он не доходит до
> /mnt/destination/usr/share/alterator/ui//grub/index.scm -- не знаю.

  Слушай, но это же очевидно. Искать что-то в /mnt/destination/usr/share/... может только процесс alteratord, работающий _вне_ чрута /mnt/destination, т.е. исходный, первый процесс alteratord. Идея же перехода в чрут заключаается в том, что внутри чрута запускается свой, отдельный alteratord, для которого файл /mnt/destination/usr/share/alterator/ui//grub/index.scm превращается просто в /usr/share/alterator/ui//grub/index.scm. Подкладывать файлы в чрут как делаешь ты — это значит продолжать ехать на первом экземпляре alteratord, а не на втором.

  И следовательно, сказанное тобой в №110 неверно:

(В ответ на комментарий №110)

> Ранее мы исходили из того, что раз после падения работает alterator-cmdline,
> раз инсталлятор запускается повторно, с сокетом всё нормализовалось. И мы были
> уверены, что проблема с механизмом перехода в чрут. Но оказалось, что с
> переходом в чрут нет проблем, их нет и с сокетом.

  Проблема с переключением на сокет второго экземпляра alteratord есть. Может быть даже есть проблема с запуском этого второго экземпляра.
Comment 114 Leonid Krivoshein 2019-09-23 13:40:51 MSK
Падает процесс alterator-wizard, морда альтератора. Это следует из отладочных журналов. Причина падения -- неизвестна. В нормальной ситуации, падения не происходит по той причинеТвоё утвер
Comment 115 Leonid Krivoshein 2019-09-23 13:49:53 MSK
Падает процесс alterator-wizard, морда альтератора. Это следует из отладочных журналов. Я же подключался ко всем активным процессам. Причина падения -- неизвестна. В нормальной ситуации, падения не происходит по той причине, что wizard продолжает поиск в /mnt/destianation. Можешь взять starce и попробовать на любом дистрибутиве, даже необязательно на 8СП.

Твоё утверждение ошибочно потому, что морда, в отличии от демона, в чрут не переходит. Но шаги (фронтэнд) она видеть должна. Она знает, где их искать на диске. Поскольку между установочной системой и целевой они разнесены, она должна искать их и там, и здесь. Но находит в /mnt/destination лишь когда нет рейса, в 99.99% случаев.

Твоя задача как раз понять, где ошибка в guile-логике перебора этих путей. Смотри внимательно на вывод strace. Если бы дело обстояло, как ты говоришь, команда копирования UI-файлов проблему бы не решила. Потому что файлы бэкэнда остались в чруте и с ними работает новый экземпляр демона по перекрытому сокету.
Comment 116 manowar@altlinux.org 2019-09-23 14:48:21 MSK
(В ответ на комментарий №115)

> Твоё утверждение ошибочно потому, что морда, в отличии от демона, в чрут не
> переходит. Но шаги (фронтэнд) она видеть должна.

  Согласен. Я и забыл, что это именно морда. Но тогда встречный вопрос: может быть установочный образ должен просто содержать /usr/share/alterator/ui для всех модулей, как внешних, так и чрутных? Т.е. при подготовке образа инсталлятора нужно ставить все задействованные пакеты alterator-*, а не только половину? Если у нас для legacy и UEFI два разных образа корневой ФС, то это вполне возможная ошибка.
Comment 117 Leonid Krivoshein 2019-09-23 15:12:25 MSK
(In reply to comment #116)
> Но тогда встречный вопрос: может
> быть установочный образ должен просто содержать /usr/share/alterator/ui для
> всех модулей, как внешних, так и чрутных?

Это бы решило проблему. Но не думаю, что это единственное верное решение, ведь редко проявляющаяся ошибка в логике останется в коде. Сейчас мы проверяем на друхих железках x86_64/EFI, хорошо бы проверить и на e2k.

> Т.е. при подготовке образа
> инсталлятора нужно ставить все задействованные пакеты alterator-*, а не только
> половину? Если у нас для legacy и UEFI два разных образа корневой ФС, то это
> вполне возможная ошибка.

Я проверил -- на старых образах 8СП шаги разнесены. От Legacy/EFI не зависит, это в сквоше /altinst. И не только в сквоше, оно и на живой системе так к моменту открытия, скажем, второго шага.
Comment 118 Leonid Krivoshein 2019-09-23 15:58:49 MSK
Created attachment 8310 [details]
Исправленный preinstall
Comment 119 Leonid Krivoshein 2019-09-23 16:04:04 MSK
Created attachment 8311 [details]
Исправлятор проблемы на 8СП x86_64/EFI

Фикса для 8СП помещается на чистую флэшку вместе с исправленным preinstall. При первом падении даём всего две команды:

mount /dev/sdc1 /mnt
/mnt/fix

После этого инсталлятор запускается в графике и больше не падает, сразу выдёргиваем флэшку с фиксой. Установка успешно проходит до конца -- проверили на нескольких проблемных машинах. Учёл замечания Ивана на предмет переменной окружения DURING_INSTALL -- без неё не очень хорошо всё отрабатывало в скрипте postinstall.
Comment 120 Ivan Zakharyaschev 2019-09-23 18:05:58 MSK
(In reply to comment #115)
> Падает процесс alterator-wizard, морда альтератора. Это следует из отладочных
> журналов. Я же подключался ко всем активным процессам. Причина падения --
> неизвестна. В нормальной ситуации, падения не происходит по той причине, что
> wizard продолжает поиск в /mnt/destianation. Можешь взять starce и попробовать
> на любом дистрибутиве, даже необязательно на 8СП.
> 
> Твоё утверждение ошибочно потому, что морда, в отличии от демона, в чрут не
> переходит. Но шаги (фронтэнд) она видеть должна. Она знает, где их искать на
> диске. Поскольку между установочной системой и целевой они разнесены, она
> должна искать их и там, и здесь. Но находит в /mnt/destination лишь когда нет
> рейса, в 99.99% случаев.

Я тоже так считаю.

> Твоя задача как раз понять, где ошибка в guile-логике перебора этих путей.
> Смотри внимательно на вывод strace. Если бы дело обстояло, как ты говоришь,
> команда копирования UI-файлов проблему бы не решила. Потому что файлы бэкэнда
> остались в чруте и с ними работает новый экземпляр демона по перекрытому
> сокету.
Comment 121 Ivan Zakharyaschev 2019-09-23 18:22:36 MSK
(In reply to comment #111)
> Леонид, а может быть, две последовательные ошибки на x86_64 с ALT SP 8 --
> связанные вещи?
> 
> В legacy-режиме вторая не происходит. А первая, с запуском X-сервера
> происходит?
> 
> Просто я подумал, прочитав твоё последнее сообщение, что когда ты вручную после
> первой ошибки запускаешь xinit /usr/sbin/alterator-install2, ты, чозможно,
> теряешь для него параметры или переменные окружения, который добавляют пути для
> поиска scm-файлов интерфейса шагов.

Всё действительно так.

/usr/sbin/install2 экспортирует переменную окружения GUILE_LOAD_PATH, в которую добавлены дополнительные пути в /mnt/destination/

Также я проверил, что попытка запуска или редактирования xorg.conf в /usr/sbin/install2 делается без затирания того, что есть.

Так что, чтобы успешно сделать установку на этих x86_64 компах, делаем так:

когда первый раз выпадаем из-за X-ов, конфигурируем их так, как сказано здесь -- https://forum.altlinux.org/index.php?topic=42871.msg340856#msg340856 , например:

# lspci | fgrep VGA
...смотрим номер, меняем точку на двоеточие
# cat >/etc/X11/xorg.conf
Section "Device"
  Identifier "Card0"
  Driver "fbdev"
  BusID "PCI:00:02:0"
EndSection

и запускаем в первой консоли этот целый скрипт обёртку:

# /usr/sbin/install2

(Он, правда, заново стартует всякие преинсталл-сервисы, но это не мешает успешной установке дальше.) В конце он должен выполнить postinstall-скрипты.
И если дальше нажать Ctrl-D в этом шелле (предварительно, я ещё на других консолях нажал Ctrl-D), то он всё размонтирует и перезагружается.

Это было описание первого способа.

2-ой способ (который, возможно, объясняет, почему в прошлом Леонид сталкивался с первой ошибкой, но не второй):

xorg.conf делаем так же.

А в shell-е на второй консоли на самом деле уже выставлена другая переменная окружения, с таким же хорошим эффектом: ALTERATOR_DATADIR

Там можно вручную запустить, как Леонид:

xinit /usr/sbin/alterator-install2 -- vt7 -dpms -ac \
        -nolisten tcp -logfile /tmp/x11.log >> /tmp/install2.log 2>&1

И установка тоже пройдёт успешно, но в конце не будут выполнены postinstall-скрипты. (Надо вручную запустить.)

Это был 2-ой способ.

1-ый и 2-ой способ можно комбинировать по вкусу.

Плохой ситуации на e2k в образах более свежих, чем 8.1, это никак не затрагивает (и не решает). Но для той ситуации manowar@ высказал много полезных предложений, которые помогут её решить или выяснить, в чём дело.
Comment 122 Leonid Krivoshein 2019-09-23 22:02:04 MSK
Created attachment 8312 [details]
Исправлятор проблемы на 8СП x86_64/EFI #2

(In reply to comment #121)
> (In reply to comment #111)
> > Леонид, а может быть, две последовательные ошибки на x86_64 с ALT SP 8 --
> > связанные вещи?
> > 
> Всё действительно так.
> 

Конечно жаль, что убили на такую фигню столько времени. Зато теперь для моего случая есть аж целых три воркэраунда!

> Это был 2-ой способ.

Всё-таки третий. Я его проверил и автоматизировал. Теперь при вылете на графике в режиме EFI достаточно переключиться на вторую консоль, смонтировать флэшку, запустить с неё этот fix2. А когда инсталлятор запустится, флэшку с фиксой выдернуть.

Думал сначала экспортировать такие же переменные, что на втором терминале, но решил не рисковать. Во втором способе (который ты называешь первым) не нравится, что дважды запускаются инициализирующие скрипты.
Comment 123 Michael Shigorin 2019-10-10 20:10:21 MSK
Возможно, причастно (в e2k-репозиториях не было версий новее 2.3.16
с патчиком насчёт lib32):

$ rpm -qp --lastchange filesystem-2.3.17-alt1.src.rpm 
* Вт авг 28 2018 Dmitry V. Levin <ldv@altlinux.org> 2.3.17-alt1
- Moved /etc/syslog.d from syslog-common to filesystem.
- Made /lib/modules readable and executable by everybody (closes: #5969).
- Added libx32 directories on x86_64 and x32 systems (by Ivan Zakharyaschev).
- Added lib32 directories on %e2k (thx Ivan Zakharyaschev).
- Added %ghost /run/lock/, marked /var/lock/ and /var/lock/* as %ghost
  (by Alexey Shabalin).
Comment 124 manowar@altlinux.org 2019-11-28 15:03:57 MSK
Есть ли здесь какое-то общее решение, которое нужно внести в альтератор или инсталлер? Кажется, нет.
Comment 125 Ivan Zakharyaschev 2019-11-28 15:26:23 MSK
(In reply to comment #124)
> Есть ли здесь какое-то общее решение, которое нужно внести в альтератор или
> инсталлер? Кажется, нет.

Что касается той проблемы, с которой Леонид столкнулся (из-за можно так сказать невнимательности или неполных знаний), то было бы яснее людям, если бы дополнительный путь передавался не через переменную окружения GUILE_LOAD_PATH (на которую легко не обратить внимание при изучении работы), а явно в виде аргумента командам alterator-а.

Но в целом это не звучит как очень серьёзный недочёт, требовавший бы исправления.