#37150 – Сломана загрузка с помощью PXE

Bug 37150 - Сломана загрузка с помощью PXE

Summary: Сломана загрузка с помощью PXE

Status:	CLOSED FIXED

Alias:	None

Product:	Альт Рабочая станция
Classification:	Distributions
Component:	Установка (show other bugs)
Version:	9.0
Hardware:	x86_64 Linux

Importance:	P3 blocker
Assignee:	Mikhail Efremov
QA Contact:	qa-p8@altlinux.org

URL:
Keywords:	distro-blocker

Depends on:	34231
Blocks:
	Show dependency tree

Reported:	2019-08-28 17:00 MSK by Igor Chudov
Modified:	2019-09-16 16:57 MSK (History)
CC List:	7 users (show)

See Also:

Attachments
Консоль 3 (27.71 KB, image/png) 2019-09-03 12:02 MSK, Anton V. Boyarshinov	no flags	Details
Консоль 1 (12.83 KB, image/png) 2019-09-03 12:03 MSK, Anton V. Boyarshinov	no flags	Details
Консоль3 -- пропагатор из p9 (26.92 KB, image/png) 2019-09-03 12:39 MSK, Anton V. Boyarshinov	no flags	Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description

Igor Chudov 2019-08-28 17:00:06 MSK

В дистрибутивах на базе 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. Вообще ничего не происходит.

В то же время дистрибутивы на базе p8 не подвержены данной проблеме.

Параметры загрузки pxelinux выглядят, например, так:

nosplash rootdelay=3 stop=,preudev,udev, net.ifnames=0 selinux=0 live fastboot ramdisk_size=380909 udev.log-priority=debug stagename=altinst automatic=method:http,network:dhcp,server:<ipv4>,directory:/iso/alt-workstation-8.940_beta4-x86_64

Comment 1

Anton V. Boyarshinov 2019-08-29 16:22:42 MSK

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

Comment 2

Igor Chudov 2019-08-29 17:00:22 MSK

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

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

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

Comment 3

Anton V. Boyarshinov 2019-08-29 17:32:38 MSK

(В ответ на комментарий №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. Вообще ничего не происходит.
А как выглядит это "ничего не происходит"? Что последнее отображается на экране? Работает ли при этом переключение виртуальных консолей?

Comment 4

Evgeny Sinelnikov 2019-08-29 22:56:53 MSK

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

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

Comment 5

Leonid Krivoshein 2019-09-02 16:46:33 MSK

(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;
+               }

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

Comment 6

Ivan A. Melnikov 2019-09-02 17:10:58 MSK

(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@ лучше.

Comment 7

Anton V. Boyarshinov 2019-09-02 17:36:23 MSK

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

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

Comment 8

Leonid Krivoshein 2019-09-02 17:47:59 MSK

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

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

Comment 9

Evgeny Sinelnikov 2019-09-02 17:58:52 MSK

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

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

Comment 10

Evgeny Sinelnikov 2019-09-02 18:09:20 MSK

(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?

Comment 11

Anton V. Boyarshinov 2019-09-03 12:02:57 MSK

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

Comment 12

Anton V. Boyarshinov 2019-09-03 12:03:24 MSK

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

Comment 13

Anton V. Boyarshinov 2019-09-03 12:10:36 MSK

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

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

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

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

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

Comment 14

Anton V. Boyarshinov 2019-09-03 12:39:45 MSK

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

Comment 15

Anton V. Boyarshinov 2019-09-03 12:55:14 MSK

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

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

Comment 16

Evgeny Sinelnikov 2019-09-04 11:36:46 MSK

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

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

Comment 17

Anton V. Boyarshinov 2019-09-04 12:45:36 MSK

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

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

Comment 18

AEN 2019-09-04 13:10:19 MSK

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

2 nir@ : а у Вас?.

Comment 19

Igor Chudov 2019-09-04 15:00:36 MSK

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

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

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

Comment 20

AEN 2019-09-04 15:06:11 MSK

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

Comment 21

Evgeny Sinelnikov 2019-09-04 15:08:30 MSK

(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

Comment 22

Anton V. Boyarshinov 2019-09-04 15:17:54 MSK

> Здесь я не очень понял о каком слеше идёт речь. В нашем случае конфиг 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

Comment 23

Anton V. Boyarshinov 2019-09-16 16:57:13 MSK

#236866 DONE