ALT Linux Distributions development
 help / color / mirror / Atom feed
* [devel-distro] full.cz или initrd.img
@ 2022-02-14  2:52 Антон Мидюков
  2022-02-14  7:29 ` Sergey V Turchin
                   ` (3 more replies)
  0 siblings, 4 replies; 18+ messages in thread
From: Антон Мидюков @ 2022-02-14  2:52 UTC (permalink / raw)
  To: Distributions development

Здравствуйте

Я на днях попробовал и у меня получилось вместо full.cz делать initrd.img для загрузки с propagator.
Долго думал, почему до сих пор делаем full.cz. Могу предположить, что для того, чтобы не переделывать
mkimage и не делать преобразование списка модулей в конфиг initrd.mk.
Также обнаружилась одна ошибка в make-initrd-propagator, которая мешала упаковки initrd с propagator.
Если есть firmware-linux, то make-initrd обрывается из-за того, что существует каталог
firmware-linux. Исправление тривиальное (mkdir -p). Исправил в Сизифе, в p10 и p9 задания в ожидании тестирования.

Потому хочу и с propagator собирать теперь обычный initrd.img. Это имеет несколько плюсов:
1. Для добавления модулей не нужно совершать несколько дополнительных действий
2. Унифицируется сборка initrd.img с propagator и bootchain Используется одинаковый алгоритм добавления модулей ядра.
   Вспоминается проблема отсутствия необходимых firmware для nouveau при упаковке mkmodpack, которую долго не могли
   выявить, но потом всё же исправили. Не исключено, что есть ещё проблемы, которые из вида ускользают.
3. Проще анализировать состав initrd.img. initrd-ls сегфолтится при попытке просмотреть full.cz

В связи с этим, мне кажется, стоит выкинуть из mkimage mki-build-propagator, а вместо него добавить mki-make-initrd,
в которой и делать добавление модулей из списка в initrd.mk Ну и заменить везде full.cz на initrd.img везде. 

Возможно, я заблуждаюсь, и есть более резонные причины.

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-14  2:52 [devel-distro] full.cz или initrd.img Антон Мидюков
@ 2022-02-14  7:29 ` Sergey V Turchin
  2022-02-14  7:38   ` Антон Мидюков
  2022-02-14 10:07 ` Anton V. Boyarshinov
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 18+ messages in thread
From: Sergey V Turchin @ 2022-02-14  7:29 UTC (permalink / raw)
  To: Distributions development

On Monday, 14 February 2022 05:52:14 MSK Антон Мидюков wrote:
> Здравствуйте
> 
> Я на днях попробовал и у меня получилось вместо full.cz делать initrd.img
> для загрузки с propagator. 
Загрузка с CD/DVD-привода не домается?

[...]

-- 
Regards, Sergey.

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-14  7:29 ` Sergey V Turchin
@ 2022-02-14  7:38   ` Антон Мидюков
  0 siblings, 0 replies; 18+ messages in thread
From: Антон Мидюков @ 2022-02-14  7:38 UTC (permalink / raw)
  To: devel-distro

14.02.2022 14:29, Sergey V Turchin пишет:
> On Monday, 14 February 2022 05:52:14 MSK Антон Мидюков wrote:
>> Здравствуйте
>>
>> Я на днях попробовал и у меня получилось вместо full.cz делать initrd.img
>> для загрузки с propagator. 
> Загрузка с CD/DVD-привода не домается?
> 
> [...]
> 

В virtualbox и qemu -cdrom грузится. CD/DVD-привода у меня нет.

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-14  2:52 [devel-distro] full.cz или initrd.img Антон Мидюков
  2022-02-14  7:29 ` Sergey V Turchin
@ 2022-02-14 10:07 ` Anton V. Boyarshinov
  2022-02-14 18:53 ` Leonid Krivoshein
  2022-02-16 11:32 ` Alexey Gladkov
  3 siblings, 0 replies; 18+ messages in thread
From: Anton V. Boyarshinov @ 2022-02-14 10:07 UTC (permalink / raw)
  To: Антон
	Мидюков
  Cc: Distributions development

В Mon, 14 Feb 2022 09:52:14 +0700
Антон Мидюков <midyukov-anton@ya.ru> пишет:

> Долго думал, почему до сих пор делаем full.cz. Могу предположить, что для того, чтобы не переделывать
> mkimage и не делать преобразование списка модулей в конфиг initrd.mk

Просто потому что оно работало, да. Насколько я понимаю, никаких
осмысленных решений не принималось, просто работающее было оставлено
как есть.

Вероятно, теперь действительно пришло время сделать единообразно.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-14  2:52 [devel-distro] full.cz или initrd.img Антон Мидюков
  2022-02-14  7:29 ` Sergey V Turchin
  2022-02-14 10:07 ` Anton V. Boyarshinov
@ 2022-02-14 18:53 ` Leonid Krivoshein
  2022-02-15  1:27   ` Антон Мидюков
  2022-02-15  9:04   ` Anton V. Boyarshinov
  2022-02-16 11:32 ` Alexey Gladkov
  3 siblings, 2 replies; 18+ messages in thread
From: Leonid Krivoshein @ 2022-02-14 18:53 UTC (permalink / raw)
  To: devel-distro


14.02.2022 5:52, Антон Мидюков пишет:
> [...]
> 2. Унифицируется сборка initrd.img с propagator и bootchain Используется одинаковый алгоритм добавления модулей ядра.
> [...]
> В связи с этим, мне кажется, стоит выкинуть из mkimage mki-build-propagator, а вместо него добавить mki-make-initrd,

Дело хорошее, но надо учесть, что full.cz собираемый 
make-initrd-propagator, состоит из трёх кусков (чанок), выравненных по 
границе в 4Кб, а initrd.img -- из одного или двух кусков. Первый кусок, 
обычно, это микрокод процессора для ucode. Второй кусок -- основной 
образ initrd. Третий кусок -- отдельный слой корневой ramfs с модулями 
ядра и firmware. Часть из них местами попадает во второй кусок. В 
initrd.img с bootchain второй и третий кусок сейчас объединены в один.

Полагаю, изначальное разделение на три куска было сделано неслучайно. 
Микрокод процессора иначе не загрузится. Код ядра обычно сжат, он 
грузится загрузчиком отдельно. Образ initrd (второй слой) тоже есть 
смысл сжимать, загрузчик его распаковывает при загрузке. Слой с модулями 
ядра нет смысла сжимать в большинстве случаев, так как каждый модуль уже 
сжат отдельно и ядро само умеет загружать модули в таком виде. Насчёт 
файлов firmware я не анализировал, возможно ей место во втором куске.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-14 18:53 ` Leonid Krivoshein
@ 2022-02-15  1:27   ` Антон Мидюков
  2022-02-15 22:01     ` Leonid Krivoshein
  2022-02-15  9:04   ` Anton V. Boyarshinov
  1 sibling, 1 reply; 18+ messages in thread
From: Антон Мидюков @ 2022-02-15  1:27 UTC (permalink / raw)
  To: devel-distro

15.02.2022 01:53, Leonid Krivoshein пишет:
> 
> 14.02.2022 5:52, Антон Мидюков пишет:
>> [...]
>> 2. Унифицируется сборка initrd.img с propagator и bootchain Используется одинаковый алгоритм добавления модулей ядра.
>> [...]
>> В связи с этим, мне кажется, стоит выкинуть из mkimage mki-build-propagator, а вместо него добавить mki-make-initrd,
> 
> Дело хорошее, но надо учесть, что full.cz собираемый make-initrd-propagator, состоит из трёх кусков (чанок), выравненных по границе в 4Кб, а initrd.img -- из одного или двух кусков. Первый кусок, обычно, это микрокод процессора для ucode. Второй кусок -- основной образ initrd. Третий кусок -- отдельный слой корневой ramfs с модулями ядра и firmware. Часть из них местами попадает во второй кусок. В initrd.img с bootchain второй и третий кусок сейчас объединены в один.
> 
> Полагаю, изначальное разделение на три куска было сделано неслучайно. Микрокод процессора иначе не загрузится. Код ядра обычно сжат, он грузится загрузчиком отдельно. Образ initrd (второй слой) тоже есть смысл сжимать, загрузчик его распаковывает при загрузке. Слой с модулями ядра нет смысла сжимать в большинстве случаев, так как каждый модуль уже сжат отдельно и ядро само умеет загружать модули в таком виде. Насчёт файлов firmware я не анализировал, возможно ей место во втором куске.
> 
> 

А почему мы тогда не имеем проблем на установленных системах, если только full.cz упакован правильно?

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-14 18:53 ` Leonid Krivoshein
  2022-02-15  1:27   ` Антон Мидюков
@ 2022-02-15  9:04   ` Anton V. Boyarshinov
  1 sibling, 0 replies; 18+ messages in thread
From: Anton V. Boyarshinov @ 2022-02-15  9:04 UTC (permalink / raw)
  To: Leonid Krivoshein; +Cc: Distributions development


> Полагаю, изначальное разделение на три куска было сделано неслучайно. 
А я полагаю, что разделение именно на 3, а не на 2 куска именно что
случайно.

> грузится загрузчиком отдельно. Образ initrd (второй слой) тоже есть 
> смысл сжимать, загрузчик его распаковывает при загрузке. Слой с модулями 
> ядра нет смысла сжимать в большинстве случаев, так как каждый модуль уже 
> сжат отдельно и ядро само умеет загружать модули в таком виде.

Это не всегда так, кроме того, оверхед на сжатие уже сжатого (при сборке
образа) и разжатие при установке не такой значительный, чтоб ради него
огород городить.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-15  1:27   ` Антон Мидюков
@ 2022-02-15 22:01     ` Leonid Krivoshein
  2022-02-16  1:51       ` Антон Мидюков
  0 siblings, 1 reply; 18+ messages in thread
From: Leonid Krivoshein @ 2022-02-15 22:01 UTC (permalink / raw)
  To: devel-distro


15.02.2022 4:27, Антон Мидюков пишет:
> 15.02.2022 01:53, Leonid Krivoshein пишет:
>> 14.02.2022 5:52, Антон Мидюков пишет:
>>> [...]
>>> 2. Унифицируется сборка initrd.img с propagator и bootchain Используется одинаковый алгоритм добавления модулей ядра.
>>> [...]
>>> В связи с этим, мне кажется, стоит выкинуть из mkimage mki-build-propagator, а вместо него добавить mki-make-initrd,
>> Дело хорошее, но надо учесть, что full.cz собираемый make-initrd-propagator, состоит из трёх кусков (чанок), выравненных по границе в 4Кб, а initrd.img -- из одного или двух кусков. Первый кусок, обычно, это микрокод процессора для ucode. Второй кусок -- основной образ initrd. Третий кусок -- отдельный слой корневой ramfs с модулями ядра и firmware. Часть из них местами попадает во второй кусок. В initrd.img с bootchain второй и третий кусок сейчас объединены в один.
>>
>> Полагаю, изначальное разделение на три куска было сделано неслучайно. Микрокод процессора иначе не загрузится. Код ядра обычно сжат, он грузится загрузчиком отдельно. Образ initrd (второй слой) тоже есть смысл сжимать, загрузчик его распаковывает при загрузке. Слой с модулями ядра нет смысла сжимать в большинстве случаев, так как каждый модуль уже сжат отдельно и ядро само умеет загружать модули в таком виде. Насчёт файлов firmware я не анализировал, возможно ей место во втором куске.
>>
>>
> А почему мы тогда не имеем проблем на установленных системах, если только full.cz упакован правильно?

Так я не говорю про правильно или неправильно. Но раз Антон считает, что 
оверхед на повторное сжатие незначителен, тогда новая схема с 
единственным слоем (плюс ucode, если фича не запрещена) вполне годится. 
А насчёт ucode для универсальных загрузочных носителей у меня другие 
сомнения: нужно ли обновлять микрокод ядра средствами 
исталлятора/live/rescue? Не может ли это в каких-то экзотических случаях 
приводить окирпичиванию железа? Не стоит ли по умолчанию фичу ucode 
запрещать? Просто, вопрос для знатоков. По идее, свежий BIOS и так 
должен выполнять ту же процедуру.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-15 22:01     ` Leonid Krivoshein
@ 2022-02-16  1:51       ` Антон Мидюков
  2022-02-16 10:36         ` Konstantin Lepikhov
  0 siblings, 1 reply; 18+ messages in thread
From: Антон Мидюков @ 2022-02-16  1:51 UTC (permalink / raw)
  To: devel-distro

16.02.2022 05:01, Leonid Krivoshein пишет:
> 
> 15.02.2022 4:27, Антон Мидюков пишет:
>> 15.02.2022 01:53, Leonid Krivoshein пишет:
>>> 14.02.2022 5:52, Антон Мидюков пишет:
>>>> [...]
>>>> 2. Унифицируется сборка initrd.img с propagator и bootchain Используется одинаковый алгоритм добавления модулей ядра.
>>>> [...]
>>>> В связи с этим, мне кажется, стоит выкинуть из mkimage mki-build-propagator, а вместо него добавить mki-make-initrd,
>>> Дело хорошее, но надо учесть, что full.cz собираемый make-initrd-propagator, состоит из трёх кусков (чанок), выравненных по границе в 4Кб, а initrd.img -- из одного или двух кусков. Первый кусок, обычно, это микрокод процессора для ucode. Второй кусок -- основной образ initrd. Третий кусок -- отдельный слой корневой ramfs с модулями ядра и firmware. Часть из них местами попадает во второй кусок. В initrd.img с bootchain второй и третий кусок сейчас объединены в один.
>>>
>>> Полагаю, изначальное разделение на три куска было сделано неслучайно. Микрокод процессора иначе не загрузится. Код ядра обычно сжат, он грузится загрузчиком отдельно. Образ initrd (второй слой) тоже есть смысл сжимать, загрузчик его распаковывает при загрузке. Слой с модулями ядра нет смысла сжимать в большинстве случаев, так как каждый модуль уже сжат отдельно и ядро само умеет загружать модули в таком виде. Насчёт файлов firmware я не анализировал, возможно ей место во втором куске.
>>>
>>>
>> А почему мы тогда не имеем проблем на установленных системах, если только full.cz упакован правильно?
> 
> Так я не говорю про правильно или неправильно. Но раз Антон считает, что оверхед на повторное сжатие незначителен, тогда новая схема с единственным слоем (плюс ucode, если фича не запрещена) вполне годится. А насчёт ucode для универсальных загрузочных носителей у меня другие сомнения: нужно ли обновлять микрокод ядра средствами исталлятора/live/rescue? Не может ли это в каких-то экзотических случаях приводить окирпичиванию железа? Не стоит ли по умолчанию фичу ucode запрещать? Просто, вопрос для знатоков. По идее, свежий BIOS и так должен выполнять ту же процедуру.
> 
> 

В STAGE1 initrd собирается без ucode. Или он как-то по-особому попадал в full.cz раньше?

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или  initrd.img
  2022-02-16  1:51       ` Антон Мидюков
@ 2022-02-16 10:36         ` Konstantin Lepikhov
  2022-02-16 10:39           ` Антон Мидюков
  0 siblings, 1 reply; 18+ messages in thread
From: Konstantin Lepikhov @ 2022-02-16 10:36 UTC (permalink / raw)
  To: devel-distro

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 одновременно.

-- 
WBR et al.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-16 10:36         ` Konstantin Lepikhov
@ 2022-02-16 10:39           ` Антон Мидюков
  2022-02-16 22:05             ` Leonid Krivoshein
  0 siblings, 1 reply; 18+ messages in thread
From: Антон Мидюков @ 2022-02-16 10:39 UTC (permalink / raw)
  To: devel-distro

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 одновременно.
> 

Тогда всё правильно, это уже на установленной системе делается.

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-14  2:52 [devel-distro] full.cz или initrd.img Антон Мидюков
                   ` (2 preceding siblings ...)
  2022-02-14 18:53 ` Leonid Krivoshein
@ 2022-02-16 11:32 ` Alexey Gladkov
  2022-02-16 22:01   ` Leonid Krivoshein
  3 siblings, 1 reply; 18+ messages in thread
From: Alexey Gladkov @ 2022-02-16 11:32 UTC (permalink / raw)
  To: Distributions development

On Mon, Feb 14, 2022 at 09:52:14AM +0700, Антон Мидюков wrote:
> 3. Проще анализировать состав initrd.img. initrd-ls сегфолтится при попытке просмотреть full.cz

Можешь мне в личку скинуть пример full.cz или сказать как его просто
собрать ?

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-16 11:32 ` Alexey Gladkov
@ 2022-02-16 22:01   ` Leonid Krivoshein
  2022-02-16 22:30     ` Alexey Gladkov
  0 siblings, 1 reply; 18+ messages in thread
From: Leonid Krivoshein @ 2022-02-16 22:01 UTC (permalink / raw)
  To: devel-distro


16.02.2022 14:32, Alexey Gladkov пишет:
> On Mon, Feb 14, 2022 at 09:52:14AM +0700, Антон Мидюков wrote:
>> 3. Проще анализировать состав initrd.img. initrd-ls сегфолтится при попытке просмотреть full.cz
> Можешь мне в личку скинуть пример full.cz или сказать как его просто
> собрать ?

У меня раньше не сегфолтился.


-- 
Best regards,
Leonid Krivoshein.



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-16 10:39           ` Антон Мидюков
@ 2022-02-16 22:05             ` Leonid Krivoshein
  2022-02-17  1:31               ` Антон Мидюков
  0 siblings, 1 reply; 18+ messages in thread
From: Leonid Krivoshein @ 2022-02-16 22:05 UTC (permalink / raw)
  To: devel-distro



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=

Тогда всё хорошо, ничего не надо менять.


-- 
Best regards,
Leonid Krivoshein.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-16 22:01   ` Leonid Krivoshein
@ 2022-02-16 22:30     ` Alexey Gladkov
  2022-02-17  1:21       ` Антон Мидюков
  0 siblings, 1 reply; 18+ messages in thread
From: Alexey Gladkov @ 2022-02-16 22:30 UTC (permalink / raw)
  To: Distributions development

On Thu, Feb 17, 2022 at 01:01:16AM +0300, Leonid Krivoshein wrote:
> 
> 16.02.2022 14:32, Alexey Gladkov пишет:
> > On Mon, Feb 14, 2022 at 09:52:14AM +0700, Антон Мидюков wrote:
> > > 3. Проще анализировать состав initrd.img. initrd-ls сегфолтится при попытке просмотреть full.cz
> > Можешь мне в личку скинуть пример full.cz или сказать как его просто
> > собрать ?
> 
> У меня раньше не сегфолтился.

Я уже нашёл проблему и исправил в master. Там проблема была в том, что в
full.cz добавлялся пустой cpio.

-- 
Rgrds, legion



^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-16 22:30     ` Alexey Gladkov
@ 2022-02-17  1:21       ` Антон Мидюков
  0 siblings, 0 replies; 18+ messages in thread
From: Антон Мидюков @ 2022-02-17  1:21 UTC (permalink / raw)
  To: devel-distro

17.02.2022 05:30, Alexey Gladkov пишет:
> On Thu, Feb 17, 2022 at 01:01:16AM +0300, Leonid Krivoshein wrote:
>>
>> 16.02.2022 14:32, Alexey Gladkov пишет:
>>> On Mon, Feb 14, 2022 at 09:52:14AM +0700, Антон Мидюков wrote:
>>>> 3. Проще анализировать состав initrd.img. initrd-ls сегфолтится при попытке просмотреть full.cz
>>> Можешь мне в личку скинуть пример full.cz или сказать как его просто
>>> собрать ?
>>
>> У меня раньше не сегфолтился.
> 
> Я уже нашёл проблему и исправил в master. Там проблема была в том, что в
> full.cz добавлялся пустой cpio.
> 

Ошибка у меня в mkimage-profiles. В третьем слое должен был быть VERSION - версия propagator.

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


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-16 22:05             ` Leonid Krivoshein
@ 2022-02-17  1:31               ` Антон Мидюков
  2022-02-17  2:04                 ` Leonid Krivoshein
  0 siblings, 1 reply; 18+ messages in thread
From: Антон Мидюков @ 2022-02-17  1:31 UTC (permalink / raw)
  To: devel-distro

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, так что и отключать его не нужно.


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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [devel-distro] full.cz или initrd.img
  2022-02-17  1:31               ` Антон Мидюков
@ 2022-02-17  2:04                 ` Leonid Krivoshein
  0 siblings, 0 replies; 18+ messages in thread
From: Leonid Krivoshein @ 2022-02-17  2:04 UTC (permalink / raw)
  To: devel-distro



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.


^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2022-02-17  2:04 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-14  2:52 [devel-distro] full.cz или initrd.img Антон Мидюков
2022-02-14  7:29 ` Sergey V Turchin
2022-02-14  7:38   ` Антон Мидюков
2022-02-14 10:07 ` Anton V. Boyarshinov
2022-02-14 18:53 ` Leonid Krivoshein
2022-02-15  1:27   ` Антон Мидюков
2022-02-15 22:01     ` Leonid Krivoshein
2022-02-16  1:51       ` Антон Мидюков
2022-02-16 10:36         ` Konstantin Lepikhov
2022-02-16 10:39           ` Антон Мидюков
2022-02-16 22:05             ` Leonid Krivoshein
2022-02-17  1:31               ` Антон Мидюков
2022-02-17  2:04                 ` Leonid Krivoshein
2022-02-15  9:04   ` Anton V. Boyarshinov
2022-02-16 11:32 ` Alexey Gladkov
2022-02-16 22:01   ` Leonid Krivoshein
2022-02-16 22:30     ` Alexey Gladkov
2022-02-17  1:21       ` Антон Мидюков

ALT Linux Distributions development

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel-distro/0 devel-distro/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel-distro devel-distro/ http://lore.altlinux.org/devel-distro \
		devel-distro@lists.altlinux.org devel-distro@lists.altlinux.ru devel-distro@lists.altlinux.com
	public-inbox-index devel-distro

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel-distro


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git