[make-initrd] Установка окружения в stage1 для передачи в stage2

[make-initrd] Установка окружения в stage1 для передачи в stage2

[Leonid Krivoshein]

Алексей, привет!


Подскажи, пожалуйста, правильно ли я пониманию, что для передачи 
переменной окружения в stage2 нужно сделать:

printf '%s="%s"\n' "$name" "$value" >> /.initrd/kernenv

и обобщённой функции, типа add_to_env(), пока не предусмотрено?



-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] Установка окружения в stage1 для передачи в stage2

[Alexey Gladkov]

On Sat, Apr 03, 2021 at 02:05:51PM +0300, Leonid Krivoshein wrote:
> Алексей, привет!
> 
> 
> Подскажи, пожалуйста, правильно ли я пониманию, что для передачи переменной
> окружения в stage2 нужно сделать:
> 
> printf '%s="%s"\n' "$name" "$value" >> /.initrd/kernenv

Если под stage2 имеется в виду то, что запустит initrd после себя, то да.
Только тогда уж '%s=%q\n'.

> и обобщённой функции, типа add_to_env(), пока не предусмотрено?

Пока потребителей не было я такого не писал. Не уверен нужна ли отдельная
функция.

-- 
Rgrds, legion

Re: [make-initrd] Установка окружения в stage1 для передачи в stage2

[Leonid Krivoshein]

03.04.2021 14:48, Alexey Gladkov пишет:
> On Sat, Apr 03, 2021 at 02:05:51PM +0300, Leonid Krivoshein wrote:
>> Алексей, привет!
>>
>>
>> Подскажи, пожалуйста, правильно ли я пониманию, что для передачи переменной
>> окружения в stage2 нужно сделать:
>>
>> printf '%s="%s"\n' "$name" "$value" >> /.initrd/kernenv
> Если под stage2 имеется в виду то, что запустит initrd после себя, то да.
> Только тогда уж '%s=%q\n'.

Понял, большое спасибо!


>> и обобщённой функции, типа add_to_env(), пока не предусмотрено?
> Пока потребителей не было я такого не писал. Не уверен нужна ли отдельная
> функция.

Не возражаешь, если добавлю тогда в pipeline_sh_functions?

Дело в том, что propagator оставлял после себя определённое окружение, 
которое как-то используется в stage2. Мне не нравится, что он передавал 
даже пароли на FTP через него, я даже не смог пока найти клиента для 
PIGGYBACK=1 -- это используется, когда в stage1 был смонтирован каталог 
по NFS или CIFS, и при выходе всё начисто отмонтируется. В основном же 
там экспортируется то, что было передано через командную строку, типа 
метода, сервера, каталога, итд. В общем, если уж делать совместимость со 
stage2, то сразу правильно надо её реализовать.


-- 
Best regards,
Leonid Krivoshein.

Re: [make-initrd] Установка окружения в stage1 для передачи в stage2

[Alexey Gladkov]

On Sat, Apr 03, 2021 at 03:24:26PM +0300, Leonid Krivoshein wrote:
> > > и обобщённой функции, типа add_to_env(), пока не предусмотрено?
> > Пока потребителей не было я такого не писал. Не уверен нужна ли отдельная
> > функция.
> 
> Не возражаешь, если добавлю тогда в pipeline_sh_functions?

Я не против, но где ты хочешь эту функцию использовать ?

> Дело в том, что propagator оставлял после себя определённое окружение,
> которое как-то используется в stage2. Мне не нравится, что он передавал даже
> пароли на FTP через него, я даже не смог пока найти клиента для PIGGYBACK=1
> -- это используется, когда в stage1 был смонтирован каталог по NFS или CIFS,
> и при выходе всё начисто отмонтируется. В основном же там экспортируется то,
> что было передано через командную строку, типа метода, сервера, каталога,
> итд. В общем, если уж делать совместимость со stage2, то сразу правильно
> надо её реализовать.

Это не моё дело, но я бы посоветовал вам не реализовывать сразу весь
функционал propagator. Реализуйте сначала то, чем пользуетесь.

-- 
Rgrds, legion

Re: [make-initrd] Установка окружения в stage1 для передачи в stage2

[Leonid Krivoshein]

03.04.2021 16:34, Alexey Gladkov пишет:
> On Sat, Apr 03, 2021 at 03:24:26PM +0300, Leonid Krivoshein wrote:
>>>> и обобщённой функции, типа add_to_env(), пока не предусмотрено?
>>> Пока потребителей не было я такого не писал. Не уверен нужна ли отдельная
>>> функция.
>> Не возражаешь, если добавлю тогда в pipeline_sh_functions?
> Я не против, но где ты хочешь эту функцию использовать ?

В стадиях pipeline -- вместо waitdev и после него.

После -- в liveboot, который заменит пропагатор и init-bottom из 
make-initrd-propagator.
Если получится поделить liveboot на отдельные стадии pipeline, будет 
очень здорово.
Но сначала хочу добиться того, чтобы перемычка между stage1 и stage2 
заработала правильно.
Потом уже, по-возможности, вписывать это всё в идеологию pipeline.

Вместо waitdev -- в нескольких "сетевых методах" a.k.a. ftp, http, cifs 
и nfs.
Первые два в нынешнем пропагаторе работают совсем иначе, нежели чем 
getimage.
Они закачивают ISO-образ целиком сразу в /dev/ramN, независимо от lowmem.
Я пока не уверен, что такое поведение правильно оставлять.
Вторые два монтируют ISO-образ по сети и начисто отмонтируют всё на 
выходе из stage1.
При этом в ряде случаев (altinst и live) остаётся смонтирован ISO образ 
в /root/image,
последний слой (NFS/CIFS-каталог) отмонтируется "lazy" через umount -fl 
/image.

В пропагаторе функция называется add_to_env().
Давай назовём её тут stage2_setenv() и это будет именно set/reset, а не add.


>> Дело в том, что propagator оставлял после себя определённое окружение,
>> которое как-то используется в stage2. Мне не нравится, что он передавал даже
>> пароли на FTP через него, я даже не смог пока найти клиента для PIGGYBACK=1
>> -- это используется, когда в stage1 был смонтирован каталог по NFS или CIFS,
>> и при выходе всё начисто отмонтируется. В основном же там экспортируется то,
>> что было передано через командную строку, типа метода, сервера, каталога,
>> итд. В общем, если уж делать совместимость со stage2, то сразу правильно
>> надо её реализовать.
> Это не моё дело, но я бы посоветовал вам не реализовывать сразу весь
> функционал propagator. Реализуйте сначала то, чем пользуетесь.

Согласен, я начал с локальной загрузки a.k.a "cdrom" и "disk", то бишь 
liveboot (следом за wiatdev).
Надеюсь за сегодня-завтра сделать и до-отладить в первом приближении.

Кстати, захотелось стадию pipeline: debug -- выводим результаты 
предыдущих шагов и вызываем rdshell.


-- 
Best regards,
Leonid Krivoshein.