[devel-distro] mkimage-profiles: Выполнение mki-copy-$BOOTLOADER дважды

[devel-distro] mkimage-profiles: Выполнение mki-copy-$BOOTLOADER дважды

[Антон Мидюков]

Полтора года назад заметил, что mki-copy-isolinux при сборке образов выполняется дважды.
Сейчас раскопал это подробнее, делюсь промежуточным результатом. 

22.01.2021 22:15, Michael Shigorin пишет:
> On Fri, Jan 22, 2021 at 07:41:09PM +0700, Антон Мидюков wrote:
>>>>> mkimage-profiles runs mki-copy-efiboot twice if used without mki-copy-isolinux.
>>>>> The first time is started, in fact, to copy the kernel.
>>>> Вот это был вообще сюрприз...
>>> Из mkimage-profiles вызываем copy-$BOOTLOADER, а потом в mki-pack-boot он ещё раз вызывается.
>>> Т.е. copy-$BOOTLOADER можно было бы не вызывать, если бы содержимое /boot не пропадало (или восстанавливалось) к моменту вызова mki-pack-boot.
>> Теперь конкретика.
>>
>> В sub.in/stage1/Makefile вызывается build-propagator
>> (tools/mki-build-propagator) и copy-$BOOTLOADER
>> (tools/mki-copy-$BOOTLOADER). Это стадия stage1.
>> Это предпоследняя стадия.
>>
>> Финалом выполняется
>> features.in/build-distro/lib/90-build-distro.mk. В цели
>> pack-image выполняется tools/mki-pack-boot. А уже в нём сначала
>> tools/mki-copy-$BOOT_TYPE, после mki-pack-<такой-то>. Также там
>> мог бы выполняться и mki-build-propagator, если бы в
>> features.in/build-distro/scripts.d/00-cleanup не очищалось
>> initfs, в /boot не было пусто и главное была переменная
>> $PROPAGATOR_MAR_MODULES (ну и сами модули).
>>
>> Таким образом, я понимаю, что так сделано специально, но
>> получается всё равно некрасиво. Лучше было бы где-то сохранять
>> ядро с propagator и потом восстанавливать в /boot финального
>> chroot. Но как получить доступ к /boot в chroot прям из
>> sub.in/stage1/Makefile. Вот только как это сделать? 
> 
> Как-то наверняка можно (в sub.in/stage2/scripts.d/99-elf-stats
> была эквилибристика на перекликающуюся тему), но надо ли?

Надо для того, чтобы mkimage-profiles использовал полноценно mki-pack-boot и не вводил новую сущность $BOOTLOADER, фактически, всегда совпадающую с $BOOT_TYPE.
И сейчас это является препятствием для сборки образа только с refind. В mkimage теперь можно, но в mkimage-profiles нельзя.
А главное это вводит в неприятное заблуждение читающего логи. Вот вроде нашёл про mki-copy-isolinux, а внизу через пару тысяч строк - продолжение, до которого можешь и не дойти с первого раза.
А когда дойдёшь, немножко впадёшь в ступор.

> 
>> Восстанавливать то можно при выполнении scripts.d/ (run-scripts
>> в features.in/build-distro/lib/90-build-distro.mk). А вот в
>> stage1 cкрипт вставлять уже поздно. Они выполняются до.
> 
> Почитай git log по этим файлам -- если там нет _прямого_
> указания на такую задумку, возможно, это просто мой косяк
> (когда постучался об стенку головой, всю картинку в голову
> уложить не получалось -- например, дёргают каждые пять минут
> по в общем-то важным вещам -- и пришлось оставить сделанное
> хоть как-то).
> 
> PS: мне кажется, это стоит документировать в devel-distro@
> -- в смысле если ты не против, то отвечай сразу туда.
> 


-- 
С уважением, Антон Мидюков <antohami@basealt.ru>

[devel-distro] mkimage-profiles: Выполнение mki-copy-$BOOTLOADER дважды

[Антон Мидюков]

Полтора года назад заметил, что mki-copy-isolinux при сборке образов выполняется дважды.
Сейчас раскопал это подробнее, делюсь промежуточным результатом. 

22.01.2021 22:15, Michael Shigorin пишет:
> On Fri, Jan 22, 2021 at 07:41:09PM +0700, Антон Мидюков wrote:
>>>>> mkimage-profiles runs mki-copy-efiboot twice if used without mki-copy-isolinux.
>>>>> The first time is started, in fact, to copy the kernel.
>>>> Вот это был вообще сюрприз...
>>> Из mkimage-profiles вызываем copy-$BOOTLOADER, а потом в mki-pack-boot он ещё раз вызывается.
>>> Т.е. copy-$BOOTLOADER можно было бы не вызывать, если бы содержимое /boot не пропадало (или восстанавливалось) к моменту вызова mki-pack-boot.
>> Теперь конкретика.
>>
>> В sub.in/stage1/Makefile вызывается build-propagator
>> (tools/mki-build-propagator) и copy-$BOOTLOADER
>> (tools/mki-copy-$BOOTLOADER). Это стадия stage1.
>> Это предпоследняя стадия.
>>
>> Финалом выполняется
>> features.in/build-distro/lib/90-build-distro.mk. В цели
>> pack-image выполняется tools/mki-pack-boot. А уже в нём сначала
>> tools/mki-copy-$BOOT_TYPE, после mki-pack-<такой-то>. Также там
>> мог бы выполняться и mki-build-propagator, если бы в
>> features.in/build-distro/scripts.d/00-cleanup не очищалось
>> initfs, в /boot не было пусто и главное была переменная
>> $PROPAGATOR_MAR_MODULES (ну и сами модули).
>>
>> Таким образом, я понимаю, что так сделано специально, но
>> получается всё равно некрасиво. Лучше было бы где-то сохранять
>> ядро с propagator и потом восстанавливать в /boot финального
>> chroot. Но как получить доступ к /boot в chroot прям из
>> sub.in/stage1/Makefile. Вот только как это сделать? 
> 
> Как-то наверняка можно (в sub.in/stage2/scripts.d/99-elf-stats
> была эквилибристика на перекликающуюся тему), но надо ли?

Надо для того, чтобы mkimage-profiles использовал полноценно mki-pack-boot и не вводил новую сущность $BOOTLOADER, фактически, всегда совпадающую с $BOOT_TYPE.
И сейчас это является препятствием для сборки образа только с refind. В mkimage теперь можно, но в mkimage-profiles нельзя.
А главное это вводит в неприятное заблуждение читающего логи. Вот вроде нашёл про mki-copy-isolinux, а внизу через пару тысяч строк - продолжение, до которого можешь и не дойти с первого раза.
А когда дойдёшь, немножко впадёшь в ступор.

> 
>> Восстанавливать то можно при выполнении scripts.d/ (run-scripts
>> в features.in/build-distro/lib/90-build-distro.mk). А вот в
>> stage1 cкрипт вставлять уже поздно. Они выполняются до.
> 
> Почитай git log по этим файлам -- если там нет _прямого_
> указания на такую задумку, возможно, это просто мой косяк
> (когда постучался об стенку головой, всю картинку в голову
> уложить не получалось -- например, дёргают каждые пять минут
> по в общем-то важным вещам -- и пришлось оставить сделанное
> хоть как-то).
> 
> PS: мне кажется, это стоит документировать в devel-distro@
> -- в смысле если ты не против, то отвечай сразу туда.
>

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>