а если увеличить ramdisk_size ?

(In reply to comment #1)
> а если увеличить ramdisk_size ?

Увеличивал и до величин, указанных в isolinux.cfg, и до произвольных величин, порядка 3Гб. Не влияет на результат.

Проверил сегодня 8 СП Server и Desktop и дистрибутивы 8 СП также не подвержены данной проблеме.

(В ответ на комментарий №0)
> В дистрибутивах на базе p9 сломана загрузка инсталлятора с помощью PXE.
> 
> Проблема воспроизводится на реальном железе и в VirtualBox. Проблема
> воспроизводится на образах:
> 
> - regular-rescue-latest-x86_64
> - alt-kworkstation-8.90-beta20190805-install-x86_64
> - alt-workstation-8.940_beta4-x86_64
> 
> Проблема выражается в зависании загрузки altinst, в результате чего не
> происходит распаковка altlinst в /dev/ram3. Вообще ничего не происходит.
А как выглядит это "ничего не происходит"? Что последнее отображается на экране? Работает ли при этом переключение виртуальных консолей?

Консоли работают. Процесс виснет после закачивания файла по HTTP перед монтированием рамдиска из-за того, что пытается прочесть дальше из всё ещё открытого сокета.

Я внёс необходимые исправления - можно проверять:
#236866 EPERM #2 sisyphus propagator.git=20190829-alt1

(In reply to comment #4)
> Я внёс необходимые исправления - можно проверять:
> #236866 EPERM #2 sisyphus propagator.git=20190829-alt1

В коде всё хорошо. Но вот этот кусок:

-               if (load_ramdisk_fd(fd, size) != RETURN_OK)
+               results = load_ramdisk_fd(fd, size);
+               close(fd);
+               if (results != RETURN_OK)
                    return RETURN_ERROR;

...работает в зависимости от load_ramdisk_fd() и статусов, которые получает и возвращает данная функция. Я бы немного переписал, чтобы возвращать исходное значение и не зависеть от того, кто и как переделает потом load_ramdisk_fd():

-               if (load_ramdisk_fd(fd, size) != RETURN_OK)
-                   return RETURN_ERROR;
+               results = load_ramdisk_fd(fd, size);
+               if (results != RETURN_OK) {
+                   close(fd);
+                   return results;
+               }

Кстати, выше по коду используется такая же техника.

(In reply to comment #5)
> (In reply to comment #4)
> > Я внёс необходимые исправления - можно проверять:
> > #236866 EPERM #2 sisyphus propagator.git=20190829-alt1
> 
> В коде всё хорошо. Но вот этот кусок:
> 
> -               if (load_ramdisk_fd(fd, size) != RETURN_OK)
> +               results = load_ramdisk_fd(fd, size);
> +               close(fd);
> +               if (results != RETURN_OK)
>                     return RETURN_ERROR;
> 
> ...работает в зависимости от load_ramdisk_fd() и статусов, которые получает и
> возвращает данная функция. Я бы немного переписал, чтобы возвращать исходное
> значение и не зависеть от того, кто и как переделает потом load_ramdisk_fd():
> 
> -               if (load_ramdisk_fd(fd, size) != RETURN_OK)
> -                   return RETURN_ERROR;
> +               results = load_ramdisk_fd(fd, size);
> +               if (results != RETURN_OK) {
> +                   close(fd);
> +                   return results;
> +               }
> 
> Кстати, выше по коду используется такая же техника.

По-моему fd здесь нужно закрывать не зависимо от того, что вернула функция load_ramdisk_fd -- иначе он просто утечёт. В этом смысле вариант sin@ лучше.

> Я внёс необходимые исправления - можно проверять:
> #236866 EPERM #2 sisyphus propagator.git=20190829-alt1

Падает по SIG11, сразу после начала скачивания. Если ввести несуществующий каталог, то в error_log сервера попадает запись о запросе (и клиент также падает по SIG11). Если ввести правильный путь -- записи о скачиваемомо файле в access_log нет.

(In reply to comment #6)
> По-моему fd здесь нужно закрывать не зависимо от того, что вернула функция
> load_ramdisk_fd -- иначе он просто утечёт. В этом смысле вариант sin@ лучше.

Если дальше по коду или в вызывающей стороне нет close(fd), конечно нужно. Я это не смотрел. Но возвращать лучше results.

(In reply to comment #7)
> > Я внёс необходимые исправления - можно проверять:
> > #236866 EPERM #2 sisyphus propagator.git=20190829-alt1
> 
> Падает по SIG11, сразу после начала скачивания. Если ввести несуществующий
> каталог, то в error_log сервера попадает запись о запросе (и клиент также
> падает по SIG11). Если ввести правильный путь -- записи о скачиваемомо файле в
> access_log нет.

А что падает? Какова методика тестирования? Как воспроизвести? Где сами логи? Там нечему, судя по логике исправлений, падать такому, что бы не падало и раньше. Ну, или я что-то сильно упускаю...
У меня пересобранный workstation на профиле от sem@ (beta4) с новым propagator успешно переcобрался. И подвисания во время загрузки более не возникает.

(In reply to comment #9)
> (In reply to comment #7)
> > > Я внёс необходимые исправления - можно проверять:
> > > #236866 EPERM #2 sisyphus propagator.git=20190829-alt1
> > 
> > Падает по SIG11, сразу после начала скачивания. Если ввести несуществующий
> > каталог, то в error_log сервера попадает запись о запросе (и клиент также
> > падает по SIG11). Если ввести правильный путь -- записи о скачиваемомо файле в
> > access_log нет.
> 
> А что падает? Какова методика тестирования? Как воспроизвести? Где сами логи?
> Там нечему, судя по логике исправлений, падать такому, что бы не падало и
> раньше. Ну, или я что-то сильно упускаю...
> У меня пересобранный workstation на профиле от sem@ (beta4) с новым propagator
> успешно переcобрался. И подвисания во время загрузки более не возникает.

Да, ещё один момент. Проверялся ли этой методикой тестирования текущий propagator?

Created attachment 8272 [details]
Консоль 3

Created attachment 8273 [details]
Консоль 1

> А что падает?
А кто ж его знает -- пропагатор неразговорчив. Скриншоты консолей после падения приложил.

> Какова методика тестирования?
Сетевая установка по http в virt-manager (qemu). На клиенте полтора гигабайта памяти (по идее должно хватать, при полугигабайте корректно сообщает, что мало памяти). Устанавливается образ alt-server-9, бета, пересобранная с пропагатором из задания.

> Как воспроизвести? Где сами логи?
access_log пустой (не считая обращений с моей машины для проверки работы http сервера).
В error_log одна запись 404 not found при вводе неправильного пути к образу. Правда нужны?

>Да, ещё один момент. Проверялся ли этой методикой тестирования текущий
propagator?

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

Created attachment 8274 [details]
Консоль3 -- пропагатор из p9

Результат с пропагатором из p9:
При указании правильного параметра Directory (см ниже) зависания не происходит и начинается установка (образ alt-server-9).
С пропагатором из задания по прежнему (и с правильным и с неправильным параметрами) SIG11

Попутно выявилась маленькая недоработка. При указании Directory без ведущего слэша (а необходимость его указания не вполне очевидна, так как URL конструируется внутри пропагатора) происходит "File not found". Представляется разумным добавлять этот /, если его нет  (или вообще всегда, так как // превращаются в /).

Мы нашли проблему, я собрал новый propagator. Проблема была в размере буфера:

#236866 EPERM #3 sisyphus propagator.git=20190829-alt1

(В ответ на комментарий №16)
> Мы нашли проблему, я собрал новый propagator. Проблема была в размере буфера:
> 
> #236866 EPERM #3 sisyphus propagator.git=20190829-alt1

На моём стенде работает нормально.

(В ответ на комментарий №17)
> (В ответ на комментарий №16)
> > Мы нашли проблему, я собрал новый propagator. Проблема была в размере буфера:
> > 
> > #236866 EPERM #3 sisyphus propagator.git=20190829-alt1
> 
> На моём стенде работает нормально

2 nir@ : а у Вас?.

(In reply to comment #18)
> (В ответ на комментарий №17)
> > (В ответ на комментарий №16)
> > > Мы нашли проблему, я собрал новый propagator. Проблема была в размере буфера:
> > > 
> > > #236866 EPERM #3 sisyphus propagator.git=20190829-alt1
> > 
> > На моём стенде работает нормально
> 
> 2 nir@ : а у Вас?.

Проверил сборку sin@ с использованием autoinstall.scm и без него. Описанную проблему не наблюдаю:

- При указании некорректного пути к каталогу выводится сообщение об ошибке.
- При указании корректного пути к каталогу stage2 скачивается и распаковывается.

Игорь, спасибо. Хорошая новость.

(In reply to comment #15)
> 
> Попутно выявилась маленькая недоработка. При указании Directory без ведущего
> слэша (а необходимость его указания не вполне очевидна, так как URL
> конструируется внутри пропагатора) происходит "File not found". Представляется
> разумным добавлять этот /, если его нет  (или вообще всегда, так как //
> превращаются в /).

Здесь я не очень понял о каком слеше идёт речь. В нашем случае конфиг pxelinux выглядит следующим образом:

        LABEL p9-workstation
        MENU LABEL ALT Linux Workstation 9 beta4 Install
        LINUX http://10.64.0.6/iso/alt-workstation-8.940_beta4-x86_64/syslinux/alt0/vmlinuz
        APPEND nosplash live fastboot ramdisk_size=380909 stagename=altinst automatic=method:http,network:dhcp,server:10.64.0.6,directory:/iso/alt-workstation-8.940_beta4-x
86_6
        INITRD http://10.64.0.6/iso/alt-workstation-8.940_beta4-x86_64/syslinux/alt0/full.cz

> Здесь я не очень понял о каком слеше идёт речь. В нашем случае конфиг pxelinux
> выглядит следующим образом:

О ведущем слэше в компоненте directory. Этот компонет может быть не указан в pxelinux.cfg и тогда вводится вручную, при этом необходимость ведущего слэша нечевидна, так как вводится не полный url, и часть его компонентов (как минимум http:// и /altinst) добавляются пропагатором. Мне кажется, было бы удобнее, если бы обязательный разделитель между hostname и directory добавлялся бы автоматически (как сейчас добавляется финальный слэш), но это мелкое соображение по usability и не имеет прямого отношения к этому багу.

 
>         LABEL p9-workstation
>         MENU LABEL ALT Linux Workstation 9 beta4 Install
>         LINUX
> http://10.64.0.6/iso/alt-workstation-8.940_beta4-x86_64/syslinux/alt0/vmlinuz
>         APPEND nosplash live fastboot ramdisk_size=380909 stagename=altinst
> automatic=method:http,network:dhcp,server:10.64.0.6,directory:/iso/alt-workstation-8.940_beta4-x
> 86_6
>         INITRD
> http://10.64.0.6/iso/alt-workstation-8.940_beta4-x86_64/syslinux/alt0/full.cz

#236866 DONE