[devel-distro] full.cz или initrd.img

[Leonid Krivoshein]

17.02.2022 4:31, Антон Мидюков пишет:
> 17.02.2022 05:05, Leonid Krivoshein пишет:
>>
>> 16.02.2022 13:39, Антон Мидюков пишет:
>>> 16.02.2022 17:36, Konstantin Lepikhov пишет:
>>>> Hi Антон!
>>>>
>>>> On 02/16/2022, at 08:51:35 AM you wrote:
>>>>
>>>> <skip>
>>>>>>> А почему мы тогда не имеем проблем на установленных системах, если только full.cz упакован правильно?
>>>>>> Так я не говорю про правильно или неправильно. Но раз Антон считает, что оверхед на повторное сжатие незначителен, тогда новая схема с единственным слоем (плюс ucode, если фича не запрещена) вполне годится. А насчёт ucode для универсальных загрузочных носителей у меня другие сомнения: нужно ли обновлять микрокод ядра средствами исталлятора/live/rescue? Не может ли это в каких-то экзотических случаях приводить окирпичиванию железа? Не стоит ли по умолчанию фичу ucode запрещать? Просто, вопрос для знатоков. По идее, свежий BIOS и так должен выполнять ту же процедуру.
>>>>>>
>>>>>>
>>>>> В STAGE1 initrd собирается без ucode. Или он как-то по-особому попадал в full.cz раньше?
>>>> ucode вообще то cpu specific, если мы говорим о early loading ucode. Я
>>>> как-то не очень представляю, как вы собираетесь собирать livecd с ucode
>>>> для intel и amd одновременно.
>>>>
>>> Тогда всё правильно, это уже на установленной системе делается.
>> Извините, наверное ложная тревога. Был уверен, что ucode создаётся, так как иначе фичу надо дизейблить. Возможно она отключается ещё и с AUTODETECT=
>>
> В STAGE1, где собирается initrd, не устанавливается make-initrd-ucode, так что и отключать его не нужно.

Да, уже разобрался. Оказалось выше я описал 3 слоя для initrd обычной 
rootfs, а как верно заметил Антон, 3 слоя универсальных загрузочных 
носителей создавались по принципу "так получилось". ))


-- 
Best regards,
Leonid Krivoshein.