ALT Linux Distributions development
 help / color / mirror / Atom feed
* [devel-distro] Возвращаем возможность задания порядка загрузки ядер
@ 2019-12-04 18:02 Антон Мидюков
  2020-02-25 18:31 ` Leonid Krivoshein
  0 siblings, 1 reply; 38+ messages in thread
From: Антон Мидюков @ 2019-12-04 18:02 UTC (permalink / raw)
  To: devel-distro

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

Доброго времени суток

Так как у нас по дефолту включена сортировка пакетов, то
порядок в $KFLAVOURS перестал иметь значение.
Ядра всегда устанавливаются в алфавитном порядке.
Поэтому смысла сортировать по buildtime нет.

See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806

Также была исправлена моя печатка, сделанная при починке возможности
грузить несколько ядер. При создании симлинка использовалась
переменная $kver, т.е. весь список ядер, а не последнее значение $KVER в
списке.

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


[-- Attachment #2: 0001-build-vm-kernel-uboot-return-possibility-of-changing.patch --]
[-- Type: text/x-patch, Size: 3809 bytes --]

>From dbe8fc74f4868c8755a14b2ec93171920e3c50df Mon Sep 17 00:00:00 2001
From: Anton Midyukov <antohami@altlinux.org>
Date: Sat, 9 Nov 2019 20:44:03 +0700
Subject: [PATCH] build-vm, kernel, uboot: return possibility of changing boot
 sequence of kernels
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Since packet sorting is enabled by default, then
the order in KFLAVORS has ceased to matter.
Kernels are always installed in alphabetical order.
Therefore, it makes no sense to sort by buildtime.
See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806

Also fixed my typo. When creating a symlink, the variable
$kver was used, i.e. the entire list of kernels, not the
last value $KVER of the list.

---
 .../build-vm/image-scripts.d/07-kernel        | 23 ++++++++++++-------
 features.in/kernel/config.mk                  |  1 +
 .../image-scripts.d/90-uboot-config-install   | 17 +++++++++-----
 3 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/features.in/build-vm/image-scripts.d/07-kernel b/features.in/build-vm/image-scripts.d/07-kernel
index e496a735d9..fd4280825d 100755
--- a/features.in/build-vm/image-scripts.d/07-kernel
+++ b/features.in/build-vm/image-scripts.d/07-kernel
@@ -2,13 +2,20 @@
 # predictable file locations make bootloader configuration simple;
 # this script relates to features.in/stage2/stage1/scripts.d/81-make-initfs
 
-kver="$(rpm -qa 'kernel-image*' \
-            --qf '%{installtime} %{version}-%{name}-%{release}\n' \
-        | sort -n \
-        | cut -f 2 -d ' ' \
-        | sed 's/kernel-image-//')"
+[ -n "$GLOBAL_KFLAVOURS" ] ||
+  { echo "** KFLAVOURS is empty" >&2; exit 0; }
 
-[ -n "$kver" ] || { echo "** unable to deduce kernel version" >&2; exit 1; }
+kver=
+echo $GLOBAL_KFLAVOURS
+for KFLAVOUR in $GLOBAL_KFLAVOURS; do
+	kver+=" $(rpm -qa 'kernel-image*' \
+		--qf '%{version}-%{name}-%{release}\n' \
+	| grep "$KFLAVOUR" \
+	| sed 's/kernel-image-//')"
+done
+
+[ ! -z "${kver#"${kver%%[! ]*}"}" ] ||
+  { echo "** unable to deduce kernel version" >&2; exit 1; }
 
 cd /boot
 
@@ -20,6 +27,6 @@ for KVER in $kver; do
 done
 
 # NB: e2k kernel builds "image" instead of "vmlinuz"
-[ -f vmlinuz-$kver ] && ln -s vmlinuz-$kver vmlinuz ||:
-ln -s initrd-$kver.img initrd.img	# missing at this stage
+[ -f vmlinuz-$KVER ] && ln -s vmlinuz-$KVER vmlinuz ||:
+ln -s initrd-$KVER.img initrd.img	# missing at this stage
 :
diff --git a/features.in/kernel/config.mk b/features.in/kernel/config.mk
index 3a00a2d469..c8caff06c0 100644
--- a/features.in/kernel/config.mk
+++ b/features.in/kernel/config.mk
@@ -20,6 +20,7 @@ else
 endif
 endif
 endif
+	@$(call xport,KFLAVOURS)
 
 # r8168 is a kludge, never install it by default
 use/kernel/net:
diff --git a/features.in/uboot/image-scripts.d/90-uboot-config-install b/features.in/uboot/image-scripts.d/90-uboot-config-install
index b52d33d861..5dab7d1628 100755
--- a/features.in/uboot/image-scripts.d/90-uboot-config-install
+++ b/features.in/uboot/image-scripts.d/90-uboot-config-install
@@ -1,12 +1,17 @@
 #!/bin/sh -x
 
-kver="$(rpm -qa 'kernel-image*' \
-            --qf '%{installtime} %{version}-%{name}-%{release}\n' \
-        | sort -n \
-        | cut -f 2 -d ' ' \
-        | sed 's/kernel-image-//')"
+[ -n "$GLOBAL_KFLAVOURS" ] ||
+  { echo "** KFLAVOURS is empty" >&2; exit 0; }
 
-[ -n "$kver" ] || { echo "** unable to deduce kernel version" >&2; exit 1; }
+kver=
+for KFLAVOUR in $GLOBAL_KFLAVOURS; do
+	kver+=" $(rpm -qa 'kernel-image*' \
+		--qf '%{version}-%{name}-%{release}\n' \
+	| grep "$KFLAVOUR" \
+	| sed 's/kernel-image-//')"
+done
+[ ! -z "${kver#"${kver%%[! ]*}"}" ] ||
+  { echo "** unable to deduce kernel version" >&2; exit 1; }
 
 for KVER in $kver; do
 	/sbin/installkernel --uboot --keep-initrd "$KVER"
-- 
2.21.0


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

* Re: [devel-distro] Возвращаем возможность задания порядка загрузки ядер
  2019-12-04 18:02 [devel-distro] Возвращаем возможность задания порядка загрузки ядер Антон Мидюков
@ 2020-02-25 18:31 ` Leonid Krivoshein
  2020-02-25 18:58   ` [devel-distro] Несколько ядер в stage1 и stage2 Антон Мидюков
  0 siblings, 1 reply; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-25 18:31 UTC (permalink / raw)
  To: devel-distro
  Cc: Алексей
	Новодворский

Антон, привет!


Осталось теперь со всем этим взлететь^W понять, как делать многоядерный 
дистрибутив. :-) Поговорил с Михаилом Ефремовым, он идею приветствует. 
Надо бы собрать регулярку с двумя ядрами, чтобы понять, какие требуются 
изменения в профиле. Готовим "план Б" на случай, если LTS 5.4 не 
получшеет к 9.1...



04.12.2019 21:02, Антон Мидюков пишет:
> Доброго времени суток
>
> Так как у нас по дефолту включена сортировка пакетов, то
> порядок в $KFLAVOURS перестал иметь значение.
> Ядра всегда устанавливаются в алфавитном порядке.
> Поэтому смысла сортировать по buildtime нет.
>
> See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806
>
> Также была исправлена моя печатка, сделанная при починке возможности
> грузить несколько ядер. При создании симлинка использовалась
> переменная $kver, т.е. весь список ядер, а не последнее значение $KVER в
> списке.
>


-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-25 18:31 ` Leonid Krivoshein
@ 2020-02-25 18:58   ` Антон Мидюков
  2020-02-25 19:31     ` Leonid Krivoshein
  0 siblings, 1 reply; 38+ messages in thread
From: Антон Мидюков @ 2020-02-25 18:58 UTC (permalink / raw)
  To: devel-distro
  Cc: Алексей
	Новодворский

26.02.2020 01:31, Leonid Krivoshein пишет:
> Антон, привет!
>
Привет, Леонид!
> Осталось теперь со всем этим взлететь^W понять, как делать 
> многоядерный дистрибутив. :-) Поговорил с Михаилом Ефремовым, он идею 
> приветствует. Надо бы собрать регулярку с двумя ядрами, чтобы понять, 
> какие требуются изменения в профиле. Готовим "план Б" на случай, если 
> LTS 5.4 не получшеет к 9.1...
>
rootfs мы можем делать с любым количеством ядер :-) Я так понимаю речь 
про ISO, а это другое моё более раннее письмо (сменил тему):

https://lists.altlinux.org/pipermail/devel-distro/2019-October/001778.html

Я застрял на том, что надо как-то ядро выбирать в syslinux, grub и 
rEFInd. Подумай, как можно реализовать выбор ядер в них. В syslinux же и 
поправить название ядра нельзя интерактивно?

Но и актуализировать надо патчи, сейчас они не наложатся. Я начну их 
воскрешать. Потом нужно ещё livecd-install поправить (знаю где).

По инсталлятору вопрос, как он их будет ставить? Его тоже надо будет 
смотреть и править (в него не заглядывал).

Работы много, быстро не взлететь.

>
> 04.12.2019 21:02, Антон Мидюков пишет:
>> Доброго времени суток
>>
>> Так как у нас по дефолту включена сортировка пакетов, то
>> порядок в $KFLAVOURS перестал иметь значение.
>> Ядра всегда устанавливаются в алфавитном порядке.
>> Поэтому смысла сортировать по buildtime нет.
>>
>> See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806
>>
>> Также была исправлена моя печатка, сделанная при починке возможности
>> грузить несколько ядер. При создании симлинка использовалась
>> переменная $kver, т.е. весь список ядер, а не последнее значение $KVER в
>> списке.
>>
>
>
-- 
С уважением, Антон Мидюков <antohami@altlinux.org>



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-25 18:58   ` [devel-distro] Несколько ядер в stage1 и stage2 Антон Мидюков
@ 2020-02-25 19:31     ` Leonid Krivoshein
  2020-02-26  6:02       ` Nikolai Kostrigin
  2020-02-26 11:01       ` Антон Мидюков
  0 siblings, 2 replies; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-25 19:31 UTC (permalink / raw)
  To: devel-distro


25.02.2020 21:58, Антон Мидюков пишет:
> 26.02.2020 01:31, Leonid Krivoshein пишет:
>> Антон, привет!
>>
> Привет, Леонид!
>> Осталось теперь со всем этим взлететь^W понять, как делать 
>> многоядерный дистрибутив. :-) Поговорил с Михаилом Ефремовым, он идею 
>> приветствует. Надо бы собрать регулярку с двумя ядрами, чтобы понять, 
>> какие требуются изменения в профиле. Готовим "план Б" на случай, если 
>> LTS 5.4 не получшеет к 9.1...
>>
> rootfs мы можем делать с любым количеством ядер :-) Я так понимаю речь 
> про ISO, а это другое моё более раннее письмо (сменил тему):
>
> https://lists.altlinux.org/pipermail/devel-distro/2019-October/001778.html 
>
>

После того письма у меня наприходило более 1000 непрочитанных (без 
преувеличения!), хорошо, хоть это нашёл, только чуток промазал. :-)


> Я застрял на том, что надо как-то ядро выбирать в syslinux, grub и 
> rEFInd. Подумай, как можно реализовать выбор ядер в них. В syslinux же 
> и поправить название ядра нельзя интерактивно?

Интерактивно не нужно. То есть, кажется, в syslinux это было уже 
реализовано генерацией отдельных пунктов и завязано на какую-то клавишу, 
типа F3, F4, F5. В grub'е тоже возможна завязка на горячие клавиши, но 
там структура меню всё равно другой будет. Там ещё нет локализации и 
брэндинга, так что на grub я бы пока не ориентировался, хотя все очень 
ратуют ЗА него, ещё лучше к 9.1. В случае refind используется 
конгломерат загрузчиков, как там делать -- лучше спросить у Николая 
Костригина и Михаила Шигорина, вроде эту мешанину собирались упорядочить 
и перетащить в m-p из mkimage. Если не изменяет память, второй уровень 
из текстовых строк в refind строить можно (типа подменю), а на первый 
уровень места для значков может не хватить.


>
> Но и актуализировать надо патчи, сейчас они не наложатся. Я начну их 
> воскрешать. Потом нужно ещё livecd-install поправить (знаю где).
>
> По инсталлятору вопрос, как он их будет ставить? Его тоже надо будет 
> смотреть и править (в него не заглядывал).
>

Инсталлятор ставит всё одним-двумя apt-get'ами по выбранному профилю 
(alterator-pkg). По-минимуму, здесь придётся поправить лишь одно: чтобы 
автоматически в этот выбор попадало то ядро, на котором загрузились. 
Иначе последующий make-initrd приведёт к не очень красивому бутсплэшу, а 
может, и железо будет определяться не совсем корректно, что приведёт 
машину к окирпичиванию. Лучше ставить все ядра и класть более 
универсальные initrd (у нас такой только с пропагатором идёт), а вот 
выбор дефолтного (симлинком в /boot) оставить пост-установочному 
скрипту. Это в идеале, чтобы "работало везде", но на initrd времени 
уйдёт больше, конечно.


> Работы много, быстро не взлететь.

У меня пока совсем нет времени в этом ковыряться. ((


>
>>
>> 04.12.2019 21:02, Антон Мидюков пишет:
>>> Доброго времени суток
>>>
>>> Так как у нас по дефолту включена сортировка пакетов, то
>>> порядок в $KFLAVOURS перестал иметь значение.
>>> Ядра всегда устанавливаются в алфавитном порядке.
>>> Поэтому смысла сортировать по buildtime нет.
>>>
>>> See-also: https://bugzilla.altlinux.org/show_bug.cgi?id=30806
>>>
>>> Также была исправлена моя печатка, сделанная при починке возможности
>>> грузить несколько ядер. При создании симлинка использовалась
>>> переменная $kver, т.е. весь список ядер, а не последнее значение 
>>> $KVER в
>>> списке.
>>>
>>
>>

-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-25 19:31     ` Leonid Krivoshein
@ 2020-02-26  6:02       ` Nikolai Kostrigin
  2020-02-26 10:43         ` Leonid Krivoshein
  2020-02-26 11:01       ` Антон Мидюков
  1 sibling, 1 reply; 38+ messages in thread
From: Nikolai Kostrigin @ 2020-02-26  6:02 UTC (permalink / raw)
  To: devel-distro


25.02.2020 22:31, Leonid Krivoshein пишет:
> а на первый уровень места для значков может не хватить.

это последнее за что нужно переживать: в rEFInd есть прокрутка ленты
непомещающихся значков

-- 
Best regards,
Nikolai Kostrigin



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-26  6:02       ` Nikolai Kostrigin
@ 2020-02-26 10:43         ` Leonid Krivoshein
  2020-02-26 10:55           ` Anton V. Boyarshinov
  0 siblings, 1 reply; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-26 10:43 UTC (permalink / raw)
  To: devel-distro


26.02.2020 9:02, Nikolai Kostrigin пишет:
> 25.02.2020 22:31, Leonid Krivoshein пишет:
>> а на первый уровень места для значков может не хватить.
> это последнее за что нужно переживать: в rEFInd есть прокрутка ленты
> непомещающихся значков

Всё равно переживаю. :-) Интерфейс refind с рюшечками, несмотря на все 
красивости, местами уже искажёнными, понятен отнюдь не всем, а тут ещё 
прокрутка, то есть, часть значимых значков на экране изначально видна не 
будет.



-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-26 10:43         ` Leonid Krivoshein
@ 2020-02-26 10:55           ` Anton V. Boyarshinov
  0 siblings, 0 replies; 38+ messages in thread
From: Anton V. Boyarshinov @ 2020-02-26 10:55 UTC (permalink / raw)
  To: devel-distro

В Wed, 26 Feb 2020 13:43:25 +0300
Leonid Krivoshein <klark.devel@gmail.com> пишет:

> 26.02.2020 9:02, Nikolai Kostrigin пишет:
> > 25.02.2020 22:31, Leonid Krivoshein пишет:  
> >> а на первый уровень места для значков может не хватить.  
> > это последнее за что нужно переживать: в rEFInd есть прокрутка ленты
> > непомещающихся значков  
> 
> Всё равно переживаю. :-) Интерфейс refind с рюшечками, несмотря на все 
> красивости, местами уже искажёнными, понятен отнюдь не всем, а тут ещё 
> прокрутка, то есть, часть значимых значков на экране изначально видна не 
> будет.

О да. Я сколько раз его видел, но каждый раз задумываюсь -- куда тут нажимать...


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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-25 19:31     ` Leonid Krivoshein
  2020-02-26  6:02       ` Nikolai Kostrigin
@ 2020-02-26 11:01       ` Антон Мидюков
  2020-02-26 12:02         ` Sergey V Turchin
  2020-02-27  1:46         ` Leonid Krivoshein
  1 sibling, 2 replies; 38+ messages in thread
From: Антон Мидюков @ 2020-02-26 11:01 UTC (permalink / raw)
  To: devel-distro

26.02.2020 02:31, Leonid Krivoshein пишет:
>
> 25.02.2020 21:58, Антон Мидюков пишет:
>> 26.02.2020 01:31, Leonid Krivoshein пишет:
[...]
>> Я застрял на том, что надо как-то ядро выбирать в syslinux, grub и 
>> rEFInd. Подумай, как можно реализовать выбор ядер в них. В syslinux 
>> же и поправить название ядра нельзя интерактивно?
>
> Интерактивно не нужно. 

Нужно для проверки, работает вообще или нет :-) Я собрал 
regular-jeos-sysv.iso с grub-efi. Интерактивно поменял имя ядра и 
propagator. Загрузился удачно. Установился тоже удачно. Установились оба 
ядра. Инcталлятор править не нужно, если такое поведение устраивает, то 
только livecd-install нужно исправить.

Так что осталось только выбор ядер организовать при загрузке в syslinux, 
grub и rEFInd.

> То есть, кажется, в syslinux это было уже реализовано генерацией 
> отдельных пунктов и завязано на какую-то клавишу, типа F3, F4, F5. 
По F5 можно выбрать опции загрузки ядра: Default, Safe Settings, No 
ACPI, No Local APIC. Не уверен, что это то место, где нужно сделать 
выбор ядер.
> В grub'е тоже возможна завязка на горячие клавиши, но там структура 
> меню всё равно другой будет.
Можешь ссылками какими-нибудь поделиться? Я ничего нужного не нашёл.
> Там ещё нет локализации и брэндинга, так что на grub я бы пока не 
> ориентировался, хотя все очень ратуют ЗА него, ещё лучше к 9.1.

Да, можно и нужно сделать. Но на aarch64 похоже этого не сделать.

> В случае refind используется конгломерат загрузчиков, как там делать 
> -- лучше спросить у Николая Костригина и Михаила Шигорина, вроде эту 
> мешанину собирались упорядочить и перетащить в m-p из mkimage. Если не 
> изменяет память, второй уровень из текстовых строк в refind строить 
> можно (типа подменю), а на первый уровень места для значков может не 
> хватить.
>
Подменю нормальный вариант, что для rEFInd, что для grub.
>
>>
>> Но и актуализировать надо патчи, сейчас они не наложатся. Я начну их 
>> воскрешать. Потом нужно ещё livecd-install поправить (знаю где).
>>
>> По инсталлятору вопрос, как он их будет ставить? Его тоже надо будет 
>> смотреть и править (в него не заглядывал).
>>
>
> Инсталлятор ставит всё одним-двумя apt-get'ами по выбранному профилю 
> (alterator-pkg). По-минимуму, здесь придётся поправить лишь одно: 
> чтобы автоматически в этот выбор попадало то ядро, на котором 
> загрузились. Иначе последующий make-initrd приведёт к не очень 
> красивому бутсплэшу, а может, и железо будет определяться не совсем 
> корректно, что приведёт машину к окирпичиванию. Лучше ставить все ядра 
> и класть более универсальные initrd (у нас такой только с пропагатором 
> идёт), а вот выбор дефолтного (симлинком в /boot) оставить 
> пост-установочному скрипту. Это в идеале, чтобы "работало везде", но 
> на initrd времени уйдёт больше, конечно.
>
1. Я считаю, что по дефолту должно ставиться только то ядро, с которым 
загрузились. Остальные должны удаляться до установки загрузчика. Можно 
какую-нибудь галочку сделать, чтобы изменить это поведение. Ядра то могу 
быть под какую-нибудь особую железку, которой другие ядра не подходят. 
Да и не нужны пользователю кучи ядер. Нужно одно, которое будет работать.

2. Универсальный initrd делается добавлением нужных фич. Нужно 
определиться какие нам фичи нужны, и сделать их платформо-независимыми. 
Но это другая задача.

>
>> Работы много, быстро не взлететь.
>
Первые испытания обнадёживают :-)

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



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-26 11:01       ` Антон Мидюков
@ 2020-02-26 12:02         ` Sergey V Turchin
  2020-02-27  1:53           ` Leonid Krivoshein
  2020-02-27  1:46         ` Leonid Krivoshein
  1 sibling, 1 reply; 38+ messages in thread
From: Sergey V Turchin @ 2020-02-26 12:02 UTC (permalink / raw)
  To: Distributions development

On Wednesday, 26 February 2020 14:01:33 MSK Антон Мидюков wrote:

[...]
> Так что осталось только выбор ядер организовать при загрузке в syslinux,
Допиливать в design-bootloader-source. Там хоть выбор архитектуры можно 
наделать, но писать сложновато на PostScript.

[...]

-- 
Regards, Sergey.

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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-26 11:01       ` Антон Мидюков
  2020-02-26 12:02         ` Sergey V Turchin
@ 2020-02-27  1:46         ` Leonid Krivoshein
  2020-02-27 10:04           ` Anton V. Boyarshinov
  1 sibling, 1 reply; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-27  1:46 UTC (permalink / raw)
  To: devel-distro


26.02.2020 14:01, Антон Мидюков пишет:
> 26.02.2020 02:31, Leonid Krivoshein пишет:
>>
>> 25.02.2020 21:58, Антон Мидюков пишет:
>>> 26.02.2020 01:31, Leonid Krivoshein пишет:
> [...]
>>> Я застрял на том, что надо как-то ядро выбирать в syslinux, grub и 
>>> rEFInd. Подумай, как можно реализовать выбор ядер в них. В syslinux 
>>> же и поправить название ядра нельзя интерактивно?
>>
>> Интерактивно не нужно. 
>
> Нужно для проверки, работает вообще или нет :-) Я собрал 
> regular-jeos-sysv.iso с grub-efi. Интерактивно поменял имя ядра и 
> propagator.

Интерактивно, в смысле -- в его редакторе?


> Загрузился удачно. Установился тоже удачно. Установились оба ядра.

А initrd? Он в инсталляторе только один создаётся.
И что в меню после установки? Тоже только одно ядро?
Уверен, в установленной системе со вторым ядром не загрузишься, хоть 
пакет и стоит.
И даже, если запускать второй раз make-initrd -k ... , будет искажённый 
plymouth, проверено ни один раз.


> Инcталлятор править не нужно, если такое поведение устраивает, то 
> только livecd-install нужно исправить.
>
> Так что осталось только выбор ядер организовать при загрузке в 
> syslinux, grub и rEFInd.
>

Пока начал с syslinux. Самое простое -- текстовое меню. В m-p оно 
собирается из кусочков. Действия по изменению в целевом 
/syslinux/isolinux.cfg тривиальные:

label linux
   kernel alt0/vmlinuz
   append initrd=alt0/full.cz ...

Обращаем внимание на /syslinux/gfxboot.cfg (mainmenu.entries=8) и тут же 
bootlogo, ru.hlp, ru.tr.

bootlogo -- это cpio-архив с бинарём и дублем файла languages из 
/syslinux. В ru.hlp и ru.tr -- выводимое на экран. По клавише F5 
выбирается архитектура ядра -- 32 бит или 64 бит на Альт Workstation 9, 
т.е два ядра в меню syslinux поддерживалось издревле, этот 4-й syslinux 
-- та ещё поросль мха.))

Содержимое этих файлов к пакету syslinux не имеют отношения. Полагаю, 
отрыть источник можно где-то в брэндинге.


>> То есть, кажется, в syslinux это было уже реализовано генерацией 
>> отдельных пунктов и завязано на какую-то клавишу, типа F3, F4, F5. 
> По F5 можно выбрать опции загрузки ядра: Default, Safe Settings, No 
> ACPI, No Local APIC. Не уверен, что это то место, где нужно сделать 
> выбор ядер.

Выгрыз из /syslinux/ru.hlp

F5 Ядро: выбор профиля параметров ядра.
bits
Выбор архитектуры
Вы должны выбрать, устанавливать 32-разрядную или 64-разрядную версию 
ALT Workstation 9.0.

Есть гипотеза: в /syslinux/isolinux.cfg после gfxboot указывается 
message, скорее всего, он тоже с брэндингом приезжает (тема "ALTLinux") 
и вероятно не стыкуется с данным хэлпом по клавише F5. Нужно 
поковыряться в истории гита на предмет изменений того, что этот файл 
генерирует.



>> В grub'е тоже возможна завязка на горячие клавиши, но там структура 
>> меню всё равно другой будет.
> Можешь ссылками какими-нибудь поделиться? Я ничего нужного не нашёл.

https://www.gnu.org/software/grub/manual/grub/html_node/menuentry.html#menuentry
https://www.gnu.org/software/grub/manual/grub/html_node/submenu.html#submenu

menuentry 'ALT Workstation 9' --hotkey=i ...

Гоша говорил... но вот оказывается это всё. Ещё есть vendors keys, но 
это немного о другом. Возможно, заработает на скрытых пунктах подменю, а 
там и целые скрипты писать можно.


>> Там ещё нет локализации и брэндинга, так что на grub я бы пока не 
>> ориентировался, хотя все очень ратуют ЗА него, ещё лучше к 9.1.
>
> Да, можно и нужно сделать. Но на aarch64 похоже этого не сделать.

На aarch64 пока не нужно. Хотя с брэндингом начать никогда не поздно, 
только графика для aarch64 д.б. опцией в m-p. Согласен с shaba@, что 
язык тут не нужен. Нет клиентов у этого интерфейса. Сейчас выбор языка 
всё равно делается на других шагах.


>
>> В случае refind используется конгломерат загрузчиков, как там делать 
>> -- лучше спросить у Николая Костригина и Михаила Шигорина, вроде эту 
>> мешанину собирались упорядочить и перетащить в m-p из mkimage. Если 
>> не изменяет память, второй уровень из текстовых строк в refind 
>> строить можно (типа подменю), а на первый уровень места для значков 
>> может не хватить.
>>
> Подменю нормальный вариант, что для rEFInd, что для grub.

Для grub -- да. В refind'е там странная конструкция сейчас, что-то типа 
языков руками захардкорено, но языки тут и не нужны. И есть что-то про 
iMac'и, но боюсь давно не проверялось и может не работать. По крайней 
мере, недавно жалоба была, а это субменю всё равно никто не видит.


>>
>>>
>>> Но и актуализировать надо патчи, сейчас они не наложатся. Я начну их 
>>> воскрешать. Потом нужно ещё livecd-install поправить (знаю где).
>>>
>>> По инсталлятору вопрос, как он их будет ставить? Его тоже надо будет 
>>> смотреть и править (в него не заглядывал).
>>>
>>
>> Инсталлятор ставит всё одним-двумя apt-get'ами по выбранному профилю 
>> (alterator-pkg). По-минимуму, здесь придётся поправить лишь одно: 
>> чтобы автоматически в этот выбор попадало то ядро, на котором 
>> загрузились. Иначе последующий make-initrd приведёт к не очень 
>> красивому бутсплэшу, а может, и железо будет определяться не совсем 
>> корректно, что приведёт машину к окирпичиванию. Лучше ставить все 
>> ядра и класть более универсальные initrd (у нас такой только с 
>> пропагатором идёт), а вот выбор дефолтного (симлинком в /boot) 
>> оставить пост-установочному скрипту. Это в идеале, чтобы "работало 
>> везде", но на initrd времени уйдёт больше, конечно.
>>
> 1. Я считаю, что по дефолту должно ставиться только то ядро, с которым 
> загрузились. Остальные должны удаляться до установки загрузчика. Можно 
> какую-нибудь галочку сделать, чтобы изменить это поведение. Ядра то 
> могу быть под какую-нибудь особую железку, которой другие ядра не 
> подходят. Да и не нужны пользователю кучи ядер. Нужно одно, которое 
> будет работать.
>

Одна задача: не взлетели с std-def, ребутаемся и пробуем с un-def. 
Вторая задача: запихиваем на один ISO-диск несколько загрузочных систем 
или даже архитектур (mike@ такое делал для Эльбрусов, кстати, но m-p не 
заточен под такое сейчас, только через ISO-data или переупаковкой 
руками). Хотя, сейчас он вернётся, и скажет своё веское...))


> 2. Универсальный initrd делается добавлением нужных фич. Нужно 
> определиться какие нам фичи нужны, и сделать их 
> платформо-независимыми. Но это другая задача.

Платформо-зависимого там тоже немало. Мы же конкретными модулями должны 
забить его и скрипт как раз в mkimage это умеет делать, и список модулей 
там же вроде рядышком. Только пропагатор туда, если не пихать, получится 
вполне штатный initrd.


>>> Работы много, быстро не взлететь.
>>
> Первые испытания обнадёживают :-)
>

Твоими стараниями! Спасибо!!!


-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-26 12:02         ` Sergey V Turchin
@ 2020-02-27  1:53           ` Leonid Krivoshein
  2020-02-27  6:01             ` Sergey V Turchin
  2020-02-27 10:06             ` Anton V. Boyarshinov
  0 siblings, 2 replies; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-27  1:53 UTC (permalink / raw)
  To: devel-distro


26.02.2020 15:02, Sergey V Turchin пишет:
> On Wednesday, 26 February 2020 14:01:33 MSK Антон Мидюков wrote:
>
> [...]
>> Так что осталось только выбор ядер организовать при загрузке в syslinux,
> Допиливать в design-bootloader-source. Там хоть выбор архитектуры можно
> наделать, но писать сложновато на PostScript.

Сергей, ты уверен, что это именно PostScript? Для того генерата, что 
лежит на наших ISO, выглядит слишком просто, похоже на примитивную 
бинарную разметку и не определяется, как PostScript. Ещё сейчас 
обнаружил, что message на ISO-диск вообще не попадает, хотя в конфиге 
такое прописано:

ui gfxboot bootlogo message

Чем это чревато?

-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27  1:53           ` Leonid Krivoshein
@ 2020-02-27  6:01             ` Sergey V Turchin
  2020-02-27 10:06             ` Anton V. Boyarshinov
  1 sibling, 0 replies; 38+ messages in thread
From: Sergey V Turchin @ 2020-02-27  6:01 UTC (permalink / raw)
  To: Distributions development

On Thursday, 27 February 2020 04:53:42 MSK Leonid Krivoshein wrote:
> 26.02.2020 15:02, Sergey V Turchin пишет:
> > On Wednesday, 26 February 2020 14:01:33 MSK Антон Мидюков wrote:
> > 
> > [...]
> > 
> >> Так что осталось только выбор ядер организовать при загрузке в syslinux,
> > 
> > Допиливать в design-bootloader-source. Там хоть выбор архитектуры можно
> > наделать, но писать сложновато на PostScript.
> 
> Сергей, ты уверен, что это именно PostScript? Для того генерата, что
> лежит на наших ISO, выглядит слишком просто, похоже на примитивную
> бинарную разметку и не определяется, как PostScript.
Postscript-like, как написано в html-ке из gfxboot.

> Ещё сейчас
> обнаружил, что message на ISO-диск вообще не попадает, хотя в конфиге
> такое прописано:
> 
> ui gfxboot bootlogo message
> 
> Чем это чревато?


-- 
Regards, Sergey.

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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27  1:46         ` Leonid Krivoshein
@ 2020-02-27 10:04           ` Anton V. Boyarshinov
  2020-02-27 11:42             ` Leonid Krivoshein
  0 siblings, 1 reply; 38+ messages in thread
From: Anton V. Boyarshinov @ 2020-02-27 10:04 UTC (permalink / raw)
  To: Leonid Krivoshein; +Cc: Distributions development


> А initrd? Он в инсталляторе только один создаётся.
> И что в меню после установки? Тоже только одно ядро?
> Уверен, в установленной системе со вторым ядром не загрузишься, хоть 
> пакет и стоит.
> И даже, если запускать второй раз make-initrd -k ... , будет искажённый 
> plymouth, проверено ни один раз.

Ничто не мешает сделать initrd, в котором будут модули для двух ядер. Тем более, что в установщике они всё равно в отдельном cpio chank, а не в том, который делается make-initrd
 
> 
> > Инcталлятор править не нужно, если такое поведение устраивает, то 
> > только livecd-install нужно исправить.
> >
> > Так что осталось только выбор ядер организовать при загрузке в 
> > syslinux, grub и rEFInd.
> >  
> 
> Пока начал с syslinux. Самое простое -- текстовое меню. В m-p оно 
> собирается из кусочков. Действия по изменению в целевом 
> /syslinux/isolinux.cfg тривиальные:
> 
> label linux
>    kernel alt0/vmlinuz
>    append initrd=alt0/full.cz ...
> 
> Обращаем внимание на /syslinux/gfxboot.cfg (mainmenu.entries=8) и тут же 
> bootlogo, ru.hlp, ru.tr.
> 
> bootlogo -- это cpio-архив с бинарём и дублем файла languages из 
> /syslinux. В ru.hlp и ru.tr -- выводимое на экран. По клавише F5 
> выбирается архитектура ядра -- 32 бит или 64 бит на Альт Workstation 9, 
> т.е два ядра в меню syslinux поддерживалось издревле, этот 4-й syslinux 
> -- та ещё поросль мха.))
> 
> Содержимое этих файлов к пакету syslinux не имеют отношения. Полагаю, 
> отрыть источник можно где-то в брэндинге.
> 
> 
> >> То есть, кажется, в syslinux это было уже реализовано генерацией 
> >> отдельных пунктов и завязано на какую-то клавишу, типа F3, F4, F5.   
> > По F5 можно выбрать опции загрузки ядра: Default, Safe Settings, No 
> > ACPI, No Local APIC. Не уверен, что это то место, где нужно сделать 
> > выбор ядер.  
> 
> Выгрыз из /syslinux/ru.hlp
> 
> F5 Ядро: выбор профиля параметров ядра.
> bits
> Выбор архитектуры
> Вы должны выбрать, устанавливать 32-разрядную или 64-разрядную версию 
> ALT Workstation 9.0.
> 
> Есть гипотеза: в /syslinux/isolinux.cfg после gfxboot указывается 
> message, скорее всего, он тоже с брэндингом приезжает (тема "ALTLinux") 
> и вероятно не стыкуется с данным хэлпом по клавише F5. Нужно 
> поковыряться в истории гита на предмет изменений того, что этот файл 
> генерирует.
> 
> 
> 
> >> В grub'е тоже возможна завязка на горячие клавиши, но там структура 
> >> меню всё равно другой будет.  
> > Можешь ссылками какими-нибудь поделиться? Я ничего нужного не нашёл.  
> 
> https://www.gnu.org/software/grub/manual/grub/html_node/menuentry.html#menuentry
> https://www.gnu.org/software/grub/manual/grub/html_node/submenu.html#submenu
> 
> menuentry 'ALT Workstation 9' --hotkey=i ...
> 
> Гоша говорил... но вот оказывается это всё. Ещё есть vendors keys, но 
> это немного о другом. Возможно, заработает на скрытых пунктах подменю, а 
> там и целые скрипты писать можно.
> 
> 
> >> Там ещё нет локализации и брэндинга, так что на grub я бы пока не 
> >> ориентировался, хотя все очень ратуют ЗА него, ещё лучше к 9.1.  
> >
> > Да, можно и нужно сделать. Но на aarch64 похоже этого не сделать.  
> 
> На aarch64 пока не нужно. Хотя с брэндингом начать никогда не поздно, 
> только графика для aarch64 д.б. опцией в m-p. Согласен с shaba@, что 
> язык тут не нужен. Нет клиентов у этого интерфейса. Сейчас выбор языка 
> всё равно делается на других шагах.
> 
> 
> >  
> >> В случае refind используется конгломерат загрузчиков, как там делать 
> >> -- лучше спросить у Николая Костригина и Михаила Шигорина, вроде эту 
> >> мешанину собирались упорядочить и перетащить в m-p из mkimage. Если 
> >> не изменяет память, второй уровень из текстовых строк в refind 
> >> строить можно (типа подменю), а на первый уровень места для значков 
> >> может не хватить.
> >>  
> > Подменю нормальный вариант, что для rEFInd, что для grub.  
> 
> Для grub -- да. В refind'е там странная конструкция сейчас, что-то типа 
> языков руками захардкорено, но языки тут и не нужны. И есть что-то про 
> iMac'и, но боюсь давно не проверялось и может не работать. По крайней 
> мере, недавно жалоба была, а это субменю всё равно никто не видит.
> 
> 
> >>  
> >>>
> >>> Но и актуализировать надо патчи, сейчас они не наложатся. Я начну их 
> >>> воскрешать. Потом нужно ещё livecd-install поправить (знаю где).
> >>>
> >>> По инсталлятору вопрос, как он их будет ставить? Его тоже надо будет 
> >>> смотреть и править (в него не заглядывал).
> >>>  
> >>
> >> Инсталлятор ставит всё одним-двумя apt-get'ами по выбранному профилю 
> >> (alterator-pkg). По-минимуму, здесь придётся поправить лишь одно: 
> >> чтобы автоматически в этот выбор попадало то ядро, на котором 
> >> загрузились. Иначе последующий make-initrd приведёт к не очень 
> >> красивому бутсплэшу, а может, и железо будет определяться не совсем 
> >> корректно, что приведёт машину к окирпичиванию. Лучше ставить все 
> >> ядра и класть более универсальные initrd (у нас такой только с 
> >> пропагатором идёт), а вот выбор дефолтного (симлинком в /boot) 
> >> оставить пост-установочному скрипту. Это в идеале, чтобы "работало 
> >> везде", но на initrd времени уйдёт больше, конечно.
> >>  
> > 1. Я считаю, что по дефолту должно ставиться только то ядро, с которым 
> > загрузились. Остальные должны удаляться до установки загрузчика. Можно 
> > какую-нибудь галочку сделать, чтобы изменить это поведение. Ядра то 
> > могу быть под какую-нибудь особую железку, которой другие ядра не 
> > подходят. Да и не нужны пользователю кучи ядер. Нужно одно, которое 
> > будет работать.
> >  
> 
> Одна задача: не взлетели с std-def, ребутаемся и пробуем с un-def. 
> Вторая задача: запихиваем на один ISO-диск несколько загрузочных систем 
> или даже архитектур (mike@ такое делал для Эльбрусов, кстати, но m-p не 
> заточен под такое сейчас, только через ISO-data или переупаковкой 
> руками). Хотя, сейчас он вернётся, и скажет своё веское...))
> 
> 
> > 2. Универсальный initrd делается добавлением нужных фич. Нужно 
> > определиться какие нам фичи нужны, и сделать их 
> > платформо-независимыми. Но это другая задача.  
> 
> Платформо-зависимого там тоже немало. Мы же конкретными модулями должны 
> забить его и скрипт как раз в mkimage это умеет делать, и список модулей 
> там же вроде рядышком. Только пропагатор туда, если не пихать, получится 
> вполне штатный initrd.
> 
> 
> >>> Работы много, быстро не взлететь.  
> >>  
> > Первые испытания обнадёживают :-)
> >  
> 
> Твоими стараниями! Спасибо!!!
> 
> 
> -- 
> Best regards,
> Leonid Krivoshein.
> 
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro


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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27  1:53           ` Leonid Krivoshein
  2020-02-27  6:01             ` Sergey V Turchin
@ 2020-02-27 10:06             ` Anton V. Boyarshinov
  1 sibling, 0 replies; 38+ messages in thread
From: Anton V. Boyarshinov @ 2020-02-27 10:06 UTC (permalink / raw)
  To: Leonid Krivoshein; +Cc: Distributions development

On Thu, 27 Feb 2020 04:53:42 +0300 Leonid Krivoshein wrote:

> 26.02.2020 15:02, Sergey V Turchin пишет:
> > On Wednesday, 26 February 2020 14:01:33 MSK Антон Мидюков wrote:
> >
> > [...]  
> >> Так что осталось только выбор ядер организовать при загрузке в syslinux,  
> > Допиливать в design-bootloader-source. Там хоть выбор архитектуры можно
> > наделать, но писать сложновато на PostScript.  
> 
> Сергей, ты уверен, что это именно PostScript?
Я -- уверен. То есть не PostScript как таковой, конечно, но очень
PostScript-подобный язык, с такой же стековой организацией и многими совпадающими операторами.

> Для того генерата, что 
> лежит на наших ISO, выглядит слишком просто, похоже на примитивную 
> бинарную разметку и не определяется, как PostScript.
Потому, что он компилируется из тех исходников, которые лежат в design-bootloader-source в какой-то специфический формат, о котором вообще думать не хочется.

> Ещё сейчас 
> обнаружил, что message на ISO-диск вообще не попадает, хотя в конфиге 
> такое прописано:
> 
> ui gfxboot bootlogo message
> 
> Чем это чревато?
> 
> -- 
> Best regards,
> Leonid Krivoshein.
> 
> _______________________________________________
> devel-distro mailing list
> devel-distro@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel-distro


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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27 10:04           ` Anton V. Boyarshinov
@ 2020-02-27 11:42             ` Leonid Krivoshein
  2020-02-27 11:50               ` Anton V. Boyarshinov
  2020-02-27 11:58               ` Антон Мидюков
  0 siblings, 2 replies; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-27 11:42 UTC (permalink / raw)
  To: Anton V. Boyarshinov; +Cc: Distributions development



27.02.2020 13:04, Anton V. Boyarshinov пишет:
>> А initrd? Он в инсталляторе только один создаётся.
>> И что в меню после установки? Тоже только одно ядро?
>> Уверен, в установленной системе со вторым ядром не загрузишься, хоть
>> пакет и стоит.
>> И даже, если запускать второй раз make-initrd -k ... , будет искажённый
>> plymouth, проверено ни один раз.
> Ничто не мешает сделать initrd, в котором будут модули для двух ядер. Тем более, что в установщике они всё равно в отдельном cpio chank, а не в том, который делается make-initrd
>   

Для этого нужно править make-initrd и скрипт в установщике, который его 
вызывает. По дефолту без параметров сейчас создаётся initrd для текущего 
ядра, а с -k flavour для указанного. Нужна ручка типа -a | --all, чтобы 
создавалось для всех ядер. Или разрешить несколько -k... Или делать 
перепаковку cpio?


>>> Инcталлятор править не нужно, если такое поведение устраивает, то
>>> только livecd-install нужно исправить.
>>>
>>> Так что осталось только выбор ядер организовать при загрузке в
>>> syslinux, grub и rEFInd.
>>>   
>> Пока начал с syslinux. Самое простое -- текстовое меню. В m-p оно
>> собирается из кусочков. Действия по изменению в целевом
>> /syslinux/isolinux.cfg тривиальные:
>>
>> label linux
>>     kernel alt0/vmlinuz
>>     append initrd=alt0/full.cz ...
>>
>> Обращаем внимание на /syslinux/gfxboot.cfg (mainmenu.entries=8) и тут же
>> bootlogo, ru.hlp, ru.tr.
>>
>> bootlogo -- это cpio-архив с бинарём и дублем файла languages из
>> /syslinux. В ru.hlp и ru.tr -- выводимое на экран. По клавише F5
>> выбирается архитектура ядра -- 32 бит или 64 бит на Альт Workstation 9,
>> т.е два ядра в меню syslinux поддерживалось издревле, этот 4-й syslinux
>> -- та ещё поросль мха.))
>>
>> Содержимое этих файлов к пакету syslinux не имеют отношения. Полагаю,
>> отрыть источник можно где-то в брэндинге.
>>
>>
>>>> То есть, кажется, в syslinux это было уже реализовано генерацией
>>>> отдельных пунктов и завязано на какую-то клавишу, типа F3, F4, F5.
>>> По F5 можно выбрать опции загрузки ядра: Default, Safe Settings, No
>>> ACPI, No Local APIC. Не уверен, что это то место, где нужно сделать
>>> выбор ядер.
>> Выгрыз из /syslinux/ru.hlp
>>
>> F5 Ядро: выбор профиля параметров ядра.
>> bits
>> Выбор архитектуры
>> Вы должны выбрать, устанавливать 32-разрядную или 64-разрядную версию
>> ALT Workstation 9.0.
>>
>> Есть гипотеза: в /syslinux/isolinux.cfg после gfxboot указывается
>> message, скорее всего, он тоже с брэндингом приезжает (тема "ALTLinux")
>> и вероятно не стыкуется с данным хэлпом по клавише F5. Нужно
>> поковыряться в истории гита на предмет изменений того, что этот файл
>> генерирует.
>>
>>
>>
>>>> В grub'е тоже возможна завязка на горячие клавиши, но там структура
>>>> меню всё равно другой будет.
>>> Можешь ссылками какими-нибудь поделиться? Я ничего нужного не нашёл.
>> https://www.gnu.org/software/grub/manual/grub/html_node/menuentry.html#menuentry
>> https://www.gnu.org/software/grub/manual/grub/html_node/submenu.html#submenu
>>
>> menuentry 'ALT Workstation 9' --hotkey=i ...
>>
>> Гоша говорил... но вот оказывается это всё. Ещё есть vendors keys, но
>> это немного о другом. Возможно, заработает на скрытых пунктах подменю, а
>> там и целые скрипты писать можно.
>>
>>
>>>> Там ещё нет локализации и брэндинга, так что на grub я бы пока не
>>>> ориентировался, хотя все очень ратуют ЗА него, ещё лучше к 9.1.
>>> Да, можно и нужно сделать. Но на aarch64 похоже этого не сделать.
>> На aarch64 пока не нужно. Хотя с брэндингом начать никогда не поздно,
>> только графика для aarch64 д.б. опцией в m-p. Согласен с shaba@, что
>> язык тут не нужен. Нет клиентов у этого интерфейса. Сейчас выбор языка
>> всё равно делается на других шагах.
>>
>>
>>>   
>>>> В случае refind используется конгломерат загрузчиков, как там делать
>>>> -- лучше спросить у Николая Костригина и Михаила Шигорина, вроде эту
>>>> мешанину собирались упорядочить и перетащить в m-p из mkimage. Если
>>>> не изменяет память, второй уровень из текстовых строк в refind
>>>> строить можно (типа подменю), а на первый уровень места для значков
>>>> может не хватить.
>>>>   
>>> Подменю нормальный вариант, что для rEFInd, что для grub.
>> Для grub -- да. В refind'е там странная конструкция сейчас, что-то типа
>> языков руками захардкорено, но языки тут и не нужны. И есть что-то про
>> iMac'и, но боюсь давно не проверялось и может не работать. По крайней
>> мере, недавно жалоба была, а это субменю всё равно никто не видит.
>>
>>
>>>>   
>>>>> Но и актуализировать надо патчи, сейчас они не наложатся. Я начну их
>>>>> воскрешать. Потом нужно ещё livecd-install поправить (знаю где).
>>>>>
>>>>> По инсталлятору вопрос, как он их будет ставить? Его тоже надо будет
>>>>> смотреть и править (в него не заглядывал).
>>>>>   
>>>> Инсталлятор ставит всё одним-двумя apt-get'ами по выбранному профилю
>>>> (alterator-pkg). По-минимуму, здесь придётся поправить лишь одно:
>>>> чтобы автоматически в этот выбор попадало то ядро, на котором
>>>> загрузились. Иначе последующий make-initrd приведёт к не очень
>>>> красивому бутсплэшу, а может, и железо будет определяться не совсем
>>>> корректно, что приведёт машину к окирпичиванию. Лучше ставить все
>>>> ядра и класть более универсальные initrd (у нас такой только с
>>>> пропагатором идёт), а вот выбор дефолтного (симлинком в /boot)
>>>> оставить пост-установочному скрипту. Это в идеале, чтобы "работало
>>>> везде", но на initrd времени уйдёт больше, конечно.
>>>>   
>>> 1. Я считаю, что по дефолту должно ставиться только то ядро, с которым
>>> загрузились. Остальные должны удаляться до установки загрузчика. Можно
>>> какую-нибудь галочку сделать, чтобы изменить это поведение. Ядра то
>>> могу быть под какую-нибудь особую железку, которой другие ядра не
>>> подходят. Да и не нужны пользователю кучи ядер. Нужно одно, которое
>>> будет работать.
>>>   
>> Одна задача: не взлетели с std-def, ребутаемся и пробуем с un-def.
>> Вторая задача: запихиваем на один ISO-диск несколько загрузочных систем
>> или даже архитектур (mike@ такое делал для Эльбрусов, кстати, но m-p не
>> заточен под такое сейчас, только через ISO-data или переупаковкой
>> руками). Хотя, сейчас он вернётся, и скажет своё веское...))
>>
>>
>>> 2. Универсальный initrd делается добавлением нужных фич. Нужно
>>> определиться какие нам фичи нужны, и сделать их
>>> платформо-независимыми. Но это другая задача.
>> Платформо-зависимого там тоже немало. Мы же конкретными модулями должны
>> забить его и скрипт как раз в mkimage это умеет делать, и список модулей
>> там же вроде рядышком. Только пропагатор туда, если не пихать, получится
>> вполне штатный initrd.
>>
>>
>>>>> Работы много, быстро не взлететь.
>>>>   
>>> Первые испытания обнадёживают :-)
>>>   
>> Твоими стараниями! Спасибо!!!

-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27 11:42             ` Leonid Krivoshein
@ 2020-02-27 11:50               ` Anton V. Boyarshinov
  2020-02-27 12:31                 ` Leonid Krivoshein
  2020-02-27 11:58               ` Антон Мидюков
  1 sibling, 1 reply; 38+ messages in thread
From: Anton V. Boyarshinov @ 2020-02-27 11:50 UTC (permalink / raw)
  To: Leonid Krivoshein; +Cc: Distributions development

On Thu, 27 Feb 2020 14:42:25 +0300 Leonid Krivoshein wrote:

> Для этого нужно править make-initrd и скрипт в установщике, который его 
> вызывает. По дефолту без параметров сейчас создаётся initrd для текущего 
> ядра, а с -k flavour для указанного. 

Ничего подобного. При сборке установщика собирается initrd без модулей при помощи make-initrd, собираются отдельно модули из списка, упаковываются и результат конкатенируется.

> Нужна ручка типа -a | --all, чтобы 
> создавалось для всех ядер. Или разрешить несколько -k... Или делать 
> перепаковку cpio?

Его не надо перепаковывать, ядро отлично понимает в качестве initrd несколько конкатенированных cpio архивов.


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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27 11:42             ` Leonid Krivoshein
  2020-02-27 11:50               ` Anton V. Boyarshinov
@ 2020-02-27 11:58               ` Антон Мидюков
  2020-02-27 12:39                 ` Leonid Krivoshein
  2020-02-27 13:09                 ` Leonid Krivoshein
  1 sibling, 2 replies; 38+ messages in thread
From: Антон Мидюков @ 2020-02-27 11:58 UTC (permalink / raw)
  To: devel-distro

27.02.2020 18:42, Leonid Krivoshein пишет:
>
>
> 27.02.2020 13:04, Anton V. Boyarshinov пишет:
>>> А initrd? Он в инсталляторе только один создаётся.
>>> И что в меню после установки? Тоже только одно ядро?
>>> Уверен, в установленной системе со вторым ядром не загрузишься, хоть
>>> пакет и стоит.
>>> И даже, если запускать второй раз make-initrd -k ... , будет искажённый
>>> plymouth, проверено ни один раз.
>> Ничто не мешает сделать initrd, в котором будут модули для двух ядер. 
>> Тем более, что в установщике они всё равно в отдельном cpio chank, а 
>> не в том, который делается make-initrd
>
> Для этого нужно править make-initrd и скрипт в установщике, который 
> его вызывает. По дефолту без параметров сейчас создаётся initrd для 
> текущего ядра, а с -k flavour для указанного. Нужна ручка типа -a | 
> --all, чтобы создавалось для всех ядер. Или разрешить несколько -k... 
> Или делать перепаковку cpio?
>
Подожди. Мой эксперимент показал, что после установки нормально 
установились оба ядра и для обоих ядер были нормально сгенерированные 
initrd. Не могу этого объяснить, но это результат эксперимента.

Это первое. А второе: правильно ставить только то ядро, с которым 
загрузились. Т.е. постинсталл скриптом остальные удалять. Потому что 
среди прочих ядер можно и реал-тайм ядро впихнуть, и ядро для какой-то 
особенной железки (Байкал М, например). Нужны ли пользователю после 
установки несколько ядер? Не нужны. Ему нужно то, которое позволит ему 
загрузиться и работать. Если инсталлятор не запускается с ядром 
таким-то, то с ним и DE не запустится. И зачем такое ядро пользователю?


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



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27 11:50               ` Anton V. Boyarshinov
@ 2020-02-27 12:31                 ` Leonid Krivoshein
    0 siblings, 1 reply; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-27 12:31 UTC (permalink / raw)
  To: Anton V. Boyarshinov; +Cc: Distributions development



27.02.2020 14:50, Anton V. Boyarshinov пишет:
> On Thu, 27 Feb 2020 14:42:25 +0300 Leonid Krivoshein wrote:
>
>> Для этого нужно править make-initrd и скрипт в установщике, который его
>> вызывает. По дефолту без параметров сейчас создаётся initrd для текущего
>> ядра, а с -k flavour для указанного.
> Ничего подобного. При сборке установщика собирается initrd без модулей при помощи make-initrd, собираются отдельно модули из списка, упаковываются и результат конкатенируется.

Не, мы тут уже говорили не о создании загрузочного (универсального, 
установочного ISO), а о том, как это должно выглядеть в установщике, 
когда система ставится на жёсткий диск. Там make-initrd вызывается. Мы 
вообще сколько ядер/initrd будем ставить на диск при наличии двух и более?


>> Нужна ручка типа -a | --all, чтобы
>> создавалось для всех ядер. Или разрешить несколько -k... Или делать
>> перепаковку cpio?
> Его не надо перепаковывать, ядро отлично понимает в качестве initrd несколько конкатенированных cpio архивов.

Да, знаю, но кажется выравнивание по 4Кб должно при этом соблюдаться.



-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27 11:58               ` Антон Мидюков
@ 2020-02-27 12:39                 ` Leonid Krivoshein
  2020-02-27 12:48                   ` Антон Мидюков
  2020-02-27 13:09                 ` Leonid Krivoshein
  1 sibling, 1 reply; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-27 12:39 UTC (permalink / raw)
  To: devel-distro



27.02.2020 14:58, Антон Мидюков пишет:
> 27.02.2020 18:42, Leonid Krivoshein пишет:
>>
>> 27.02.2020 13:04, Anton V. Boyarshinov пишет:
>>>> А initrd? Он в инсталляторе только один создаётся.
>>>> И что в меню после установки? Тоже только одно ядро?
>>>> Уверен, в установленной системе со вторым ядром не загрузишься, хоть
>>>> пакет и стоит.
>>>> И даже, если запускать второй раз make-initrd -k ... , будет 
>>>> искажённый
>>>> plymouth, проверено ни один раз.
>>> Ничто не мешает сделать initrd, в котором будут модули для двух 
>>> ядер. Тем более, что в установщике они всё равно в отдельном cpio 
>>> chank, а не в том, который делается make-initrd
>>
>> Для этого нужно править make-initrd и скрипт в установщике, который 
>> его вызывает. По дефолту без параметров сейчас создаётся initrd для 
>> текущего ядра, а с -k flavour для указанного. Нужна ручка типа -a | 
>> --all, чтобы создавалось для всех ядер. Или разрешить несколько -k... 
>> Или делать перепаковку cpio?
>>
> Подожди. Мой эксперимент показал, что после установки нормально 
> установились оба ядра и для обоих ядер были нормально сгенерированные 
> initrd. Не могу этого объяснить, но это результат эксперимента.
>

Так ты же не ответил на вопросы выше, а это я другому Антону отвечал.)
Где создаётся? Я так понял, что на ISO'шке. А на жёстком диске?


> Это первое. А второе: правильно ставить только то ядро, с которым 
> загрузились. Т.е. постинсталл скриптом остальные удалять. Потому что 
> среди прочих ядер можно и реал-тайм ядро впихнуть, и ядро для какой-то 
> особенной железки (Байкал М, например). Нужны ли пользователю после 
> установки несколько ядер? Не нужны. Ему нужно то, которое позволит ему 
> загрузиться и работать. Если инсталлятор не запускается с ядром 
> таким-то, то с ним и DE не запустится. И зачем такое ядро пользователю?
>

Парашют. Если загрузились на одном ядре-initrd с внешнего носителя, ещё 
не значит, что с него же загрузимся с жёсткого диска. И, что более 
вероятно, графика в инсталляторе может работать на fbdev/vesa, а при 
попытке работы с нормальным drm на std-def после ребута получим 
недогруженную в иксы систему. В этом тоже смысл двух ядер-initrd.



-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27 12:39                 ` Leonid Krivoshein
@ 2020-02-27 12:48                   ` Антон Мидюков
  0 siblings, 0 replies; 38+ messages in thread
From: Антон Мидюков @ 2020-02-27 12:48 UTC (permalink / raw)
  To: devel-distro

27.02.2020 19:39, Leonid Krivoshein пишет:
>
>
> 27.02.2020 14:58, Антон Мидюков пишет:
>> 27.02.2020 18:42, Leonid Krivoshein пишет:
>>>
>>> 27.02.2020 13:04, Anton V. Boyarshinov пишет:
>>>>> А initrd? Он в инсталляторе только один создаётся.
>>>>> И что в меню после установки? Тоже только одно ядро?
>>>>> Уверен, в установленной системе со вторым ядром не загрузишься, хоть
>>>>> пакет и стоит.
>>>>> И даже, если запускать второй раз make-initrd -k ... , будет 
>>>>> искажённый
>>>>> plymouth, проверено ни один раз.
>>>> Ничто не мешает сделать initrd, в котором будут модули для двух 
>>>> ядер. Тем более, что в установщике они всё равно в отдельном cpio 
>>>> chank, а не в том, который делается make-initrd
>>>
>>> Для этого нужно править make-initrd и скрипт в установщике, который 
>>> его вызывает. По дефолту без параметров сейчас создаётся initrd для 
>>> текущего ядра, а с -k flavour для указанного. Нужна ручка типа -a | 
>>> --all, чтобы создавалось для всех ядер. Или разрешить несколько 
>>> -k... Или делать перепаковку cpio?
>>>
>> Подожди. Мой эксперимент показал, что после установки нормально 
>> установились оба ядра и для обоих ядер были нормально сгенерированные 
>> initrd. Не могу этого объяснить, но это результат эксперимента.
>>
>
> Так ты же не ответил на вопросы выше, а это я другому Антону отвечал.)
А я письмо так и не дописал :-(
> Где создаётся? Я так понял, что на ISO'шке. А на жёстком диске?
>
На жёстком диске, после установки. Оба ядра нормально грузятся.
>
>> Это первое. А второе: правильно ставить только то ядро, с которым 
>> загрузились. Т.е. постинсталл скриптом остальные удалять. Потому что 
>> среди прочих ядер можно и реал-тайм ядро впихнуть, и ядро для 
>> какой-то особенной железки (Байкал М, например). Нужны ли 
>> пользователю после установки несколько ядер? Не нужны. Ему нужно то, 
>> которое позволит ему загрузиться и работать. Если инсталлятор не 
>> запускается с ядром таким-то, то с ним и DE не запустится. И зачем 
>> такое ядро пользователю?
>>
>
> Парашют. Если загрузились на одном ядре-initrd с внешнего носителя, 
> ещё не значит, что с него же загрузимся с жёсткого диска. И, что более 
> вероятно, графика в инсталляторе может работать на fbdev/vesa, а при 
> попытке работы с нормальным drm на std-def после ребута получим 
> недогруженную в иксы систему. В этом тоже смысл двух ядер-initrd.
>
Если не грузится, пусть ставит заново с другим ядром :-)

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



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  @ 2020-02-27 12:51                     ` Антон Мидюков
  2020-02-27 13:02                       ` Leonid Krivoshein
  0 siblings, 1 reply; 38+ messages in thread
From: Антон Мидюков @ 2020-02-27 12:51 UTC (permalink / raw)
  To: devel-distro

27.02.2020 19:47, Aleksey Novodvorsky пишет:
> чт, 27 февр. 2020 г., 15:36 Leonid Krivoshein <klark.devel@gmail.com>:
>
>>
>> 27.02.2020 14:50, Anton V. Boyarshinov пишет:
>>> On Thu, 27 Feb 2020 14:42:25 +0300 Leonid Krivoshein wrote:
>>>
>>>> Для этого нужно править make-initrd и скрипт в установщике, который его
>>>> вызывает. По дефолту без параметров сейчас создаётся initrd для текущего
>>>> ядра, а с -k flavour для указанного.
>>> Ничего подобного. При сборке установщика собирается initrd без модулей
>> при помощи make-initrd, собираются отдельно модули из списка, упаковываются
>> и результат конкатенируется.
>>
>> Не, мы тут уже говорили не о создании загрузочного (универсального,
>> установочного ISO), а о том, как это должно выглядеть в установщике,
>> когда система ставится на жёсткий диск. Там make-initrd вызывается. Мы
>> вообще сколько ядер/initrd будем ставить на диск при наличии двух и более?
>>
> Мы говорили во вторник про std-def и un-def. Давайте пока не будем обобщить
> задачу.
>
И всё равно. Вопрос тот же. Нужно ли ставить их оба, или ставить только 
то, с которым загрузились при установке?

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



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27 12:51                     ` Антон Мидюков
@ 2020-02-27 13:02                       ` Leonid Krivoshein
    0 siblings, 1 reply; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-27 13:02 UTC (permalink / raw)
  To: devel-distro



27.02.2020 15:51, Антон Мидюков пишет:
> 27.02.2020 19:47, Aleksey Novodvorsky пишет:
>> чт, 27 февр. 2020 г., 15:36 Leonid Krivoshein <klark.devel@gmail.com>:
>>
>>>
>>> 27.02.2020 14:50, Anton V. Boyarshinov пишет:
>>>> On Thu, 27 Feb 2020 14:42:25 +0300 Leonid Krivoshein wrote:
>>>>
>>>>> Для этого нужно править make-initrd и скрипт в установщике, 
>>>>> который его
>>>>> вызывает. По дефолту без параметров сейчас создаётся initrd для 
>>>>> текущего
>>>>> ядра, а с -k flavour для указанного.
>>>> Ничего подобного. При сборке установщика собирается initrd без модулей
>>> при помощи make-initrd, собираются отдельно модули из списка, 
>>> упаковываются
>>> и результат конкатенируется.
>>>
>>> Не, мы тут уже говорили не о создании загрузочного (универсального,
>>> установочного ISO), а о том, как это должно выглядеть в установщике,
>>> когда система ставится на жёсткий диск. Там make-initrd вызывается. Мы
>>> вообще сколько ядер/initrd будем ставить на диск при наличии двух и 
>>> более?
>>>
>> Мы говорили во вторник про std-def и un-def. Давайте пока не будем 
>> обобщить
>> задачу.
>>
> И всё равно. Вопрос тот же. Нужно ли ставить их оба, или ставить 
> только то, с которым загрузились при установке?
>

Вот и предлагается это решить в обсуждении.
Я предложил ставить оба на жёсткий диск и обосновал.
Тем более, ты это уже успешно реализовал...


-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-27 11:58               ` Антон Мидюков
  2020-02-27 12:39                 ` Leonid Krivoshein
@ 2020-02-27 13:09                 ` Leonid Krivoshein
  1 sibling, 0 replies; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-27 13:09 UTC (permalink / raw)
  To: devel-distro



27.02.2020 14:58, Антон Мидюков пишет:
> 27.02.2020 18:42, Leonid Krivoshein пишет:
>>
>>
>> 27.02.2020 13:04, Anton V. Boyarshinov пишет:
>>>> А initrd? Он в инсталляторе только один создаётся.
>>>> И что в меню после установки? Тоже только одно ядро?
>>>> Уверен, в установленной системе со вторым ядром не загрузишься, хоть
>>>> пакет и стоит.
>>>> И даже, если запускать второй раз make-initrd -k ... , будет 
>>>> искажённый
>>>> plymouth, проверено ни один раз.
>>> Ничто не мешает сделать initrd, в котором будут модули для двух 
>>> ядер. Тем более, что в установщике они всё равно в отдельном cpio 
>>> chank, а не в том, который делается make-initrd
>>
>> Для этого нужно править make-initrd и скрипт в установщике, который 
>> его вызывает. По дефолту без параметров сейчас создаётся initrd для 
>> текущего ядра, а с -k flavour для указанного. Нужна ручка типа -a | 
>> --all, чтобы создавалось для всех ядер. Или разрешить несколько -k... 
>> Или делать перепаковку cpio?
>>
> Подожди. Мой эксперимент показал, что после установки нормально 
> установились оба ядра и для обоих ядер были нормально сгенерированные 
> initrd. Не могу этого объяснить, но это результат эксперимента.
>

Это значит, что многоядерный функционал был заложен и в инсталляторе, и 
что там стоит цикл по всем ядрам, а не единичный вызов make-initrd. Об 
этом расскажет лог установщика в /root. Нужно искать место, поломавшую 
эту функциональность при генерации брэндинга.


> Это первое. А второе: правильно ставить только то ядро, с которым 
> загрузились. Т.е. постинсталл скриптом остальные удалять. Потому что 
> среди прочих ядер можно и реал-тайм ядро впихнуть, и ядро для какой-то 
> особенной железки (Байкал М, например). Нужны ли пользователю после 
> установки несколько ядер? Не нужны. Ему нужно то, которое позволит ему 
> загрузиться и работать. Если инсталлятор не запускается с ядром 
> таким-то, то с ним и DE не запустится. И зачем такое ядро пользователю?
>
>

-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  @ 2020-02-28  3:21                           ` Leonid Krivoshein
  2020-02-28  3:35                             ` Антон Мидюков
  0 siblings, 1 reply; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-28  3:21 UTC (permalink / raw)
  To: devel-distro


27.02.2020 16:11, Aleksey Novodvorsky пишет:
> чт, 27 февр. 2020 г., 16:07 Leonid Krivoshein <klark.devel@gmail.com 
> <mailto:klark.devel@gmail.com>>:
>
>
>     27.02.2020 15:51, Антон Мидюков пишет:
>     [...]
>     > И всё равно. Вопрос тот же. Нужно ли ставить их оба, или ставить
>     > только то, с которым загрузились при установке?
>     >
>
>     Вот и предлагается это решить в обсуждении.
>     Я предложил ставить оба на жёсткий диск и обосновал.
>     Тем более, ты это уже успешно реализовал...
>
>
> Согласен с тем, что оба. По крайней мере пока.
>


Если сильно дорожим x86_64 и i586 в графике, заморачиваемся с gfxboot 
для syslinux и grub, то ценой не знаю пока точно какого времени 
восстанавливаем то, что висит на кнопке F7 
(design-bootloader/src/panel.inc) -- оно никуда не девалось, просто 
кнопка появляется в зависимости от имени каталога, в котором лежит ядро 
и initrd. У нас оно лежит в alt0. Если в имени будет присутствовать 
x86_64, gfxboot будет считать его одним, если i386 или x86, то другим. 
Нужно будет поменять переводы и подсказки вокруг, не перепутав наш 
un-def с егойным .undef. См. также: src/common.inc:/check_arch_boot_dir, 
а вот эти надо убирать: /32bit_popup, /64bit_popup.

Но мне тоже не понравился этот недокументированный транслятор байт-кода, 
ориентированный только на Intel ix86. Если других архитектур у нас 
подавляющее большинство, то для них мы так F7 не забиндим и нужно делать 
через подменю или отдельными пунктами в главном меню, а это совсем 
другая структура меню получится. Реализовать так быстрей и проще, но там 
не будет графики, зато можно сделать универсально.


-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-28  3:21                           ` Leonid Krivoshein
@ 2020-02-28  3:35                             ` Антон Мидюков
  2020-02-28  3:50                               ` Anton Farygin
  0 siblings, 1 reply; 38+ messages in thread
From: Антон Мидюков @ 2020-02-28  3:35 UTC (permalink / raw)
  To: devel-distro

28.02.2020 10:21, Leonid Krivoshein пишет:
>
> 27.02.2020 16:11, Aleksey Novodvorsky пишет:
>> чт, 27 февр. 2020 г., 16:07 Leonid Krivoshein <klark.devel@gmail.com 
>> <mailto:klark.devel@gmail.com>>:
>>
>>
>>     27.02.2020 15:51, Антон Мидюков пишет:
>>     [...]
>>     > И всё равно. Вопрос тот же. Нужно ли ставить их оба, или ставить
>>     > только то, с которым загрузились при установке?
>>     >
>>
>>     Вот и предлагается это решить в обсуждении.
>>     Я предложил ставить оба на жёсткий диск и обосновал.
>>     Тем более, ты это уже успешно реализовал...
>>
>>
>> Согласен с тем, что оба. По крайней мере пока.
>>
>
>
> Если сильно дорожим x86_64 и i586 в графике, заморачиваемся с gfxboot 
> для syslinux и grub, то ценой не знаю пока точно какого времени 
> восстанавливаем то, что висит на кнопке F7 
> (design-bootloader/src/panel.inc) -- оно никуда не девалось, просто 
> кнопка появляется в зависимости от имени каталога, в котором лежит 
> ядро и initrd. У нас оно лежит в alt0. Если в имени будет 
> присутствовать x86_64, gfxboot будет считать его одним, если i386 или 
> x86, то другим. Нужно будет поменять переводы и подсказки вокруг, не 
> перепутав наш un-def с егойным .undef. См. также: 
> src/common.inc:/check_arch_boot_dir, а вот эти надо убирать: 
> /32bit_popup, /64bit_popup.
>
> Но мне тоже не понравился этот недокументированный транслятор 
> байт-кода, ориентированный только на Intel ix86. Если других 
> архитектур у нас подавляющее большинство, то для них мы так F7 не 
> забиндим и нужно делать через подменю или отдельными пунктами в 
> главном меню, а это совсем другая структура меню получится. 
> Реализовать так быстрей и проще, но там не будет графики, зато можно 
> сделать универсально.
>
А может не будем для syslinux выбор ядер делать? Всё новое железо будет 
с UEFI без legacy, а свежее ядро нужно только новому железу. И тогда 
наша задача сведётся к реализации подменю для rEFInd на данном этапе. 
Для i586 вообще нового железа в принципе больше не будет никогда. 
Сэкономим на размере образов к тому же.

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



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-28  3:35                             ` Антон Мидюков
@ 2020-02-28  3:50                               ` Anton Farygin
  2020-02-28  3:52                                 ` Leonid Krivoshein
  2020-02-28  3:57                                 ` Антон Мидюков
  0 siblings, 2 replies; 38+ messages in thread
From: Anton Farygin @ 2020-02-28  3:50 UTC (permalink / raw)
  To: devel-distro

On 28.02.2020 06:35, Антон Мидюков wrote:
> 28.02.2020 10:21, Leonid Krivoshein пишет:
>>
>> 27.02.2020 16:11, Aleksey Novodvorsky пишет:
>>> чт, 27 февр. 2020 г., 16:07 Leonid Krivoshein <klark.devel@gmail.com 
>>> <mailto:klark.devel@gmail.com>>:
>>>
>>>
>>>     27.02.2020 15:51, Антон Мидюков пишет:
>>>     [...]
>>>     > И всё равно. Вопрос тот же. Нужно ли ставить их оба, или ставить
>>>     > только то, с которым загрузились при установке?
>>>     >
>>>
>>>     Вот и предлагается это решить в обсуждении.
>>>     Я предложил ставить оба на жёсткий диск и обосновал.
>>>     Тем более, ты это уже успешно реализовал...
>>>
>>>
>>> Согласен с тем, что оба. По крайней мере пока.
>>>
>>
>>
>> Если сильно дорожим x86_64 и i586 в графике, заморачиваемся с gfxboot 
>> для syslinux и grub, то ценой не знаю пока точно какого времени 
>> восстанавливаем то, что висит на кнопке F7 
>> (design-bootloader/src/panel.inc) -- оно никуда не девалось, просто 
>> кнопка появляется в зависимости от имени каталога, в котором лежит 
>> ядро и initrd. У нас оно лежит в alt0. Если в имени будет 
>> присутствовать x86_64, gfxboot будет считать его одним, если i386 или 
>> x86, то другим. Нужно будет поменять переводы и подсказки вокруг, не 
>> перепутав наш un-def с егойным .undef. См. также: 
>> src/common.inc:/check_arch_boot_dir, а вот эти надо убирать: 
>> /32bit_popup, /64bit_popup.
>>
>> Но мне тоже не понравился этот недокументированный транслятор 
>> байт-кода, ориентированный только на Intel ix86. Если других 
>> архитектур у нас подавляющее большинство, то для них мы так F7 не 
>> забиндим и нужно делать через подменю или отдельными пунктами в 
>> главном меню, а это совсем другая структура меню получится. 
>> Реализовать так быстрей и проще, но там не будет графики, зато можно 
>> сделать универсально.
>>
> А может не будем для syslinux выбор ядер делать? Всё новое железо 
> будет с UEFI без legacy, а свежее ядро нужно только новому железу. И 
> тогда наша задача сведётся к реализации подменю для rEFInd на данном 
> этапе. Для i586 вообще нового железа в принципе больше не будет 
> никогда. Сэкономим на размере образов к тому же.
>
А если учесть то, что от refind надо уходить, то остаётся только grub.

Но придётся поработать над вопросами подписи ядер и модулей на этапе сборки.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-28  3:50                               ` Anton Farygin
@ 2020-02-28  3:52                                 ` Leonid Krivoshein
  2020-02-28  3:57                                 ` Антон Мидюков
  1 sibling, 0 replies; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-28  3:52 UTC (permalink / raw)
  To: devel-distro



28.02.2020 6:50, Anton Farygin пишет:
> On 28.02.2020 06:35, Антон Мидюков wrote:
>> 28.02.2020 10:21, Leonid Krivoshein пишет:
>>>
>>> 27.02.2020 16:11, Aleksey Novodvorsky пишет:
>>>> чт, 27 февр. 2020 г., 16:07 Leonid Krivoshein 
>>>> <klark.devel@gmail.com <mailto:klark.devel@gmail.com>>:
>>>>
>>>>
>>>>     27.02.2020 15:51, Антон Мидюков пишет:
>>>>     [...]
>>>>     > И всё равно. Вопрос тот же. Нужно ли ставить их оба, или ставить
>>>>     > только то, с которым загрузились при установке?
>>>>     >
>>>>
>>>>     Вот и предлагается это решить в обсуждении.
>>>>     Я предложил ставить оба на жёсткий диск и обосновал.
>>>>     Тем более, ты это уже успешно реализовал...
>>>>
>>>>
>>>> Согласен с тем, что оба. По крайней мере пока.
>>>>
>>>
>>>
>>> Если сильно дорожим x86_64 и i586 в графике, заморачиваемся с 
>>> gfxboot для syslinux и grub, то ценой не знаю пока точно какого 
>>> времени восстанавливаем то, что висит на кнопке F7 
>>> (design-bootloader/src/panel.inc) -- оно никуда не девалось, просто 
>>> кнопка появляется в зависимости от имени каталога, в котором лежит 
>>> ядро и initrd. У нас оно лежит в alt0. Если в имени будет 
>>> присутствовать x86_64, gfxboot будет считать его одним, если i386 
>>> или x86, то другим. Нужно будет поменять переводы и подсказки 
>>> вокруг, не перепутав наш un-def с егойным .undef. См. также: 
>>> src/common.inc:/check_arch_boot_dir, а вот эти надо убирать: 
>>> /32bit_popup, /64bit_popup.
>>>
>>> Но мне тоже не понравился этот недокументированный транслятор 
>>> байт-кода, ориентированный только на Intel ix86. Если других 
>>> архитектур у нас подавляющее большинство, то для них мы так F7 не 
>>> забиндим и нужно делать через подменю или отдельными пунктами в 
>>> главном меню, а это совсем другая структура меню получится. 
>>> Реализовать так быстрей и проще, но там не будет графики, зато можно 
>>> сделать универсально.
>>>
>> А может не будем для syslinux выбор ядер делать? Всё новое железо 
>> будет с UEFI без legacy, а свежее ядро нужно только новому железу. И 
>> тогда наша задача сведётся к реализации подменю для rEFInd на данном 
>> этапе. Для i586 вообще нового железа в принципе больше не будет 
>> никогда. Сэкономим на размере образов к тому же.
>>
> А если учесть то, что от refind надо уходить, то остаётся только grub.
>
> Но придётся поработать над вопросами подписи ядер и модулей на этапе 
> сборки.
>

Ещё такая корректировочка: речь только о syslinux, для grub это не 
пройдёт, там всё равно так не сделать. И да, только для Legacy-загрузки, 
которая с этого года должна уходить в прошлое. Тоже считаю, что надо 
всецело на grub переходить. Что с графической темой, что без, меню будет 
единым на всех архитектурах.


-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-28  3:50                               ` Anton Farygin
  2020-02-28  3:52                                 ` Leonid Krivoshein
@ 2020-02-28  3:57                                 ` Антон Мидюков
  2020-02-28  4:02                                   ` Anton Farygin
  2020-02-28 10:32                                   ` Leonid Krivoshein
  1 sibling, 2 replies; 38+ messages in thread
From: Антон Мидюков @ 2020-02-28  3:57 UTC (permalink / raw)
  To: devel-distro

28.02.2020 10:50, Anton Farygin пишет:
> On 28.02.2020 06:35, Антон Мидюков wrote:
>> 28.02.2020 10:21, Leonid Krivoshein пишет:
>>>
>>> 27.02.2020 16:11, Aleksey Novodvorsky пишет:
>>>> чт, 27 февр. 2020 г., 16:07 Leonid Krivoshein 
>>>> <klark.devel@gmail.com <mailto:klark.devel@gmail.com>>:
>>>>
>>>>
>>>>     27.02.2020 15:51, Антон Мидюков пишет:
>>>>     [...]
>>>>     > И всё равно. Вопрос тот же. Нужно ли ставить их оба, или ставить
>>>>     > только то, с которым загрузились при установке?
>>>>     >
>>>>
>>>>     Вот и предлагается это решить в обсуждении.
>>>>     Я предложил ставить оба на жёсткий диск и обосновал.
>>>>     Тем более, ты это уже успешно реализовал...
>>>>
>>>>
>>>> Согласен с тем, что оба. По крайней мере пока.
>>>>
>>>
>>>
>>> Если сильно дорожим x86_64 и i586 в графике, заморачиваемся с 
>>> gfxboot для syslinux и grub, то ценой не знаю пока точно какого 
>>> времени восстанавливаем то, что висит на кнопке F7 
>>> (design-bootloader/src/panel.inc) -- оно никуда не девалось, просто 
>>> кнопка появляется в зависимости от имени каталога, в котором лежит 
>>> ядро и initrd. У нас оно лежит в alt0. Если в имени будет 
>>> присутствовать x86_64, gfxboot будет считать его одним, если i386 
>>> или x86, то другим. Нужно будет поменять переводы и подсказки 
>>> вокруг, не перепутав наш un-def с егойным .undef. См. также: 
>>> src/common.inc:/check_arch_boot_dir, а вот эти надо убирать: 
>>> /32bit_popup, /64bit_popup.
>>>
>>> Но мне тоже не понравился этот недокументированный транслятор 
>>> байт-кода, ориентированный только на Intel ix86. Если других 
>>> архитектур у нас подавляющее большинство, то для них мы так F7 не 
>>> забиндим и нужно делать через подменю или отдельными пунктами в 
>>> главном меню, а это совсем другая структура меню получится. 
>>> Реализовать так быстрей и проще, но там не будет графики, зато можно 
>>> сделать универсально.
>>>
>> А может не будем для syslinux выбор ядер делать? Всё новое железо 
>> будет с UEFI без legacy, а свежее ядро нужно только новому железу. И 
>> тогда наша задача сведётся к реализации подменю для rEFInd на данном 
>> этапе. Для i586 вообще нового железа в принципе больше не будет 
>> никогда. Сэкономим на размере образов к тому же.
>>
> А если учесть то, что от refind надо уходить, то остаётся только grub.
Надо, но не прямо сейчас. Так что прямо сейчас актуален именно rEFInd. И 
это прямо сейчас продлится неопределённо долго, так как:
>
> Но придётся поработать над вопросами подписи ядер и модулей на этапе 
> сборки.
>

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



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-28  3:57                                 ` Антон Мидюков
@ 2020-02-28  4:02                                   ` Anton Farygin
  2020-02-28  4:11                                     ` Антон Мидюков
  2020-02-28 10:32                                   ` Leonid Krivoshein
  1 sibling, 1 reply; 38+ messages in thread
From: Anton Farygin @ 2020-02-28  4:02 UTC (permalink / raw)
  To: devel-distro

On 28.02.2020 06:57, Антон Мидюков wrote:
> Надо, но не прямо сейчас. Так что прямо сейчас актуален именно rEFInd. 
> И это прямо сейчас продлится неопределённо долго, так как: 

в refind объявили deprecated метод загрузки через ELILO (т.к. последний 
не развивается) и вся эта машинерия с refind+elilo закончится через 
какое-то время.

Так что да, надо начинать прямо сейчас и тогда получится за вменяемое 
время от него отказаться.

Хотя, конечно же после сборки ядер с подписью у нас и refind можно будет 
оставить (без ELILO) и grub будет работать нормально.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-28  4:02                                   ` Anton Farygin
@ 2020-02-28  4:11                                     ` Антон Мидюков
  2020-02-28  8:33                                       ` Anton Farygin
  0 siblings, 1 reply; 38+ messages in thread
From: Антон Мидюков @ 2020-02-28  4:11 UTC (permalink / raw)
  To: devel-distro

28.02.2020 11:02, Anton Farygin пишет:
> On 28.02.2020 06:57, Антон Мидюков wrote:
>> Надо, но не прямо сейчас. Так что прямо сейчас актуален именно 
>> rEFInd. И это прямо сейчас продлится неопределённо долго, так как: 
>
> в refind объявили deprecated метод загрузки через ELILO (т.к. 
> последний не развивается) и вся эта машинерия с refind+elilo 
> закончится через какое-то время.
>
> Так что да, надо начинать прямо сейчас и тогда получится за вменяемое 
> время от него отказаться.
>
> Хотя, конечно же после сборки ядер с подписью у нас и refind можно 
> будет оставить (без ELILO) и grub будет работать нормально.
>
У меня какой-то неправильный UEFI, раз он со включенным Secure Boot 
грузит образ regular-jeos-sysv.iso, собранный с grub-efi?

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



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-28  4:11                                     ` Антон Мидюков
@ 2020-02-28  8:33                                       ` Anton Farygin
  0 siblings, 0 replies; 38+ messages in thread
From: Anton Farygin @ 2020-02-28  8:33 UTC (permalink / raw)
  To: devel-distro

On 28.02.2020 07:11, Антон Мидюков wrote:
> 28.02.2020 11:02, Anton Farygin пишет:
>> On 28.02.2020 06:57, Антон Мидюков wrote:
>>> Надо, но не прямо сейчас. Так что прямо сейчас актуален именно 
>>> rEFInd. И это прямо сейчас продлится неопределённо долго, так как: 
>>
>> в refind объявили deprecated метод загрузки через ELILO (т.к. 
>> последний не развивается) и вся эта машинерия с refind+elilo 
>> закончится через какое-то время.
>>
>> Так что да, надо начинать прямо сейчас и тогда получится за вменяемое 
>> время от него отказаться.
>>
>> Хотя, конечно же после сборки ядер с подписью у нас и refind можно 
>> будет оставить (без ELILO) и grub будет работать нормально.
>>
> У меня какой-то неправильный UEFI, раз он со включенным Secure Boot 
> грузит образ regular-jeos-sysv.iso, собранный с grub-efi?
>
Нет, это у нас такой shim



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-28  3:57                                 ` Антон Мидюков
  2020-02-28  4:02                                   ` Anton Farygin
@ 2020-02-28 10:32                                   ` Leonid Krivoshein
  2020-03-04 16:09                                     ` Антон Мидюков
  1 sibling, 1 reply; 38+ messages in thread
From: Leonid Krivoshein @ 2020-02-28 10:32 UTC (permalink / raw)
  To: devel-distro



28.02.2020 6:57, Антон Мидюков пишет:
> 28.02.2020 10:50, Anton Farygin пишет:
>> On 28.02.2020 06:35, Антон Мидюков wrote:
>>> 28.02.2020 10:21, Leonid Krivoshein пишет:
>>>>
>>>> 27.02.2020 16:11, Aleksey Novodvorsky пишет:
>>>>> чт, 27 февр. 2020 г., 16:07 Leonid Krivoshein 
>>>>> <klark.devel@gmail.com <mailto:klark.devel@gmail.com>>:
>>>>>
>>>>>
>>>>>     27.02.2020 15:51, Антон Мидюков пишет:
>>>>>     [...]
>>>>>     > И всё равно. Вопрос тот же. Нужно ли ставить их оба, или 
>>>>> ставить
>>>>>     > только то, с которым загрузились при установке?
>>>>>     >
>>>>>
>>>>>     Вот и предлагается это решить в обсуждении.
>>>>>     Я предложил ставить оба на жёсткий диск и обосновал.
>>>>>     Тем более, ты это уже успешно реализовал...
>>>>>
>>>>>
>>>>> Согласен с тем, что оба. По крайней мере пока.
>>>>>
>>>>
>>>>
>>>> Если сильно дорожим x86_64 и i586 в графике, заморачиваемся с 
>>>> gfxboot для syslinux и grub, то ценой не знаю пока точно какого 
>>>> времени восстанавливаем то, что висит на кнопке F7 
>>>> (design-bootloader/src/panel.inc) -- оно никуда не девалось, просто 
>>>> кнопка появляется в зависимости от имени каталога, в котором лежит 
>>>> ядро и initrd. У нас оно лежит в alt0. Если в имени будет 
>>>> присутствовать x86_64, gfxboot будет считать его одним, если i386 
>>>> или x86, то другим. Нужно будет поменять переводы и подсказки 
>>>> вокруг, не перепутав наш un-def с егойным .undef. См. также: 
>>>> src/common.inc:/check_arch_boot_dir, а вот эти надо убирать: 
>>>> /32bit_popup, /64bit_popup.
>>>>
>>>> Но мне тоже не понравился этот недокументированный транслятор 
>>>> байт-кода, ориентированный только на Intel ix86. Если других 
>>>> архитектур у нас подавляющее большинство, то для них мы так F7 не 
>>>> забиндим и нужно делать через подменю или отдельными пунктами в 
>>>> главном меню, а это совсем другая структура меню получится. 
>>>> Реализовать так быстрей и проще, но там не будет графики, зато 
>>>> можно сделать универсально.
>>>>
>>> А может не будем для syslinux выбор ядер делать? Всё новое железо 
>>> будет с UEFI без legacy, а свежее ядро нужно только новому железу. И 
>>> тогда наша задача сведётся к реализации подменю для rEFInd на данном 
>>> этапе. Для i586 вообще нового железа в принципе больше не будет 
>>> никогда. Сэкономим на размере образов к тому же.
>>>
>> А если учесть то, что от refind надо уходить, то остаётся только grub.
> Надо, но не прямо сейчас. Так что прямо сейчас актуален именно rEFInd. 
> И это прямо сейчас продлится неопределённо долго

Наш .efi.img (в ElTorrito) вырос за последние годы почти вдвое и на 
каком-то железе это уже проблема загрузки. Теперь мы добавим туда ещё 
одно ядро с initrd и число совместимых машин по EFI-загрузке резко 
упадёт. Уж лучше перейти на grub на без графики, чем вот так. Но раз с 
grub'ом получилось, раз SecureBoot уже есть, осталось только сборку темы 
в ISO добавить -- сама тема для grub тоже есть.


> , так как:
>>
>> Но придётся поработать над вопросами подписи ядер и модулей на этапе 
>> сборки.
>>
>

-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-02-28 10:32                                   ` Leonid Krivoshein
@ 2020-03-04 16:09                                     ` Антон Мидюков
  2020-03-04 17:50                                       ` Leonid Krivoshein
  2020-03-11 19:49                                       ` Антон Мидюков
  0 siblings, 2 replies; 38+ messages in thread
From: Антон Мидюков @ 2020-03-04 16:09 UTC (permalink / raw)
  To: devel-distro

[-- Attachment #1: Type: text/plain, Size: 3174 bytes --]

28.02.2020 17:32, Leonid Krivoshein пишет:
> 28.02.2020 6:57, Антон Мидюков пишет:
>> 28.02.2020 10:50, Anton Farygin пишет:
>>> [...]
>>> А если учесть то, что от refind надо уходить, то остаётся только grub.
>> Надо, но не прямо сейчас. Так что прямо сейчас актуален именно 
>> rEFInd. И это прямо сейчас продлится неопределённо долго
>
> Наш .efi.img (в ElTorrito) вырос за последние годы почти вдвое и на 
> каком-то железе это уже проблема загрузки. Теперь мы добавим туда ещё 
> одно ядро с initrd и число совместимых машин по EFI-загрузке резко 
> упадёт. Уж лучше перейти на grub на без графики, чем вот так. Но раз с 
> grub'ом получилось, раз SecureBoot уже есть, осталось только сборку 
> темы в ISO добавить -- сама тема для grub тоже есть.
>
Я сделал подменю для grub: одно для выбора языка, другое - для выбора 
flavour ядра. Прикладываю патчи для m-p.

По выбору языка. Пока графическую тему не прикрутили, язык самого grub 
не меняется, так как не ASCII символы не поддерживаются в текстовом режиме.

По выбору flavour ядра. Придётся серьёзно поработать над mkimage. Сейчас 
есть две проблемы:

1. ядра сортируются как и другие пакеты в алфавитном порядке. Таким 
образом происходит коллизия, имя дефолтного flavour может не совпадать, 
так как зависит от порядка в переменной KFLAVOURS. Я думаю, нужно 
исправлять mkimage, чтобы он не упорядочивал пакеты ядер в алфавитном 
порядке.

2. Если мы не делаем для syslinux выбор ядер, то получаем проблему. Как 
ядра в efiboot передавать? В efiboot они копируются из syslinux/alt0

И наконец, если не делать выбор ядер для rEFInd, то надо в efiboot 
дополнительные условия вводить, чтобы не копировать для него ядра.

Так что, думается, надо вообще сделать grubefiboot какой-нибудь, чтобы 
ещё и grubaa64boot нужен не был. grubx86boot ты больше не занимался?

Или таки править efiboot и вызывать его также дважды как и другие 
загрузчики.

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


[-- Attachment #2: 0001-grub-Added-submenu-for-languages-change.patch --]
[-- Type: text/x-patch, Size: 6233 bytes --]

>From be9cfcf212fd923ac476233463d83f75f1ee5a9d Mon Sep 17 00:00:00 2001
From: Anton Midyukov <antohami@altlinux.org>
Date: Tue, 3 Mar 2020 20:50:43 +0700
Subject: [PATCH 1/4] grub: Added submenu for languages change

---
 features.in/grub/cfg.in/00defaults.cfg            |  1 +
 features.in/grub/cfg.in/20install2.cfg            |  2 +-
 features.in/grub/cfg.in/25install-vnc-connect.cfg |  2 +-
 features.in/grub/cfg.in/25install-vnc-listen.cfg  |  2 +-
 features.in/grub/cfg.in/30live.cfg                |  2 +-
 features.in/grub/cfg.in/32live_rw.cfg             |  2 +-
 features.in/grub/cfg.in/40lang.cfg                | 14 ++++++++++++++
 features.in/grub/generate.mk                      | 10 ++++++++++
 8 files changed, 30 insertions(+), 5 deletions(-)
 create mode 100644 features.in/grub/cfg.in/40lang.cfg

diff --git a/features.in/grub/cfg.in/00defaults.cfg b/features.in/grub/cfg.in/00defaults.cfg
index 88b56d9873..cad492cd73 100644
--- a/features.in/grub/cfg.in/00defaults.cfg
+++ b/features.in/grub/cfg.in/00defaults.cfg
@@ -4,3 +4,4 @@ insmod minicmd
 insmod normal
 insmod test
 set timeout=@timeout@
+if [ ! "$language" ]; then language=@LOCALE@; fi
diff --git a/features.in/grub/cfg.in/20install2.cfg b/features.in/grub/cfg.in/20install2.cfg
index 9cf86bbed0..b88f44ae01 100644
--- a/features.in/grub/cfg.in/20install2.cfg
+++ b/features.in/grub/cfg.in/20install2.cfg
@@ -1,6 +1,6 @@
 
 default='linux'
 menuentry 'Install @relname@' --hotkey 'i' --id 'linux' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ vga=@bootvga@ @bootargs@
+  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ vga=@bootvga@ @bootargs@ lang=$language
   initrd@linux_suffix@ @boot_path@/full.cz
 }
diff --git a/features.in/grub/cfg.in/25install-vnc-connect.cfg b/features.in/grub/cfg.in/25install-vnc-connect.cfg
index b4a435dc58..7a1ce36d25 100644
--- a/features.in/grub/cfg.in/25install-vnc-connect.cfg
+++ b/features.in/grub/cfg.in/25install-vnc-connect.cfg
@@ -1,5 +1,5 @@
 
 menuentry '^VNC install @relname@ (edit to set server IP address)' --id 'vncconnect' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ showopts @bootargs@ headless no_alt_virt_keyboard vncconnect=IP
+  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ showopts @bootargs@ headless no_alt_virt_keyboard vncconnect=IP lang=$language
   initrd@linux_suffix@ @boot_path@/full.cz
 }
diff --git a/features.in/grub/cfg.in/25install-vnc-listen.cfg b/features.in/grub/cfg.in/25install-vnc-listen.cfg
index 7b6146ad0c..90a285fdda 100644
--- a/features.in/grub/cfg.in/25install-vnc-listen.cfg
+++ b/features.in/grub/cfg.in/25install-vnc-listen.cfg
@@ -1,6 +1,6 @@
 
 menuentry 'VNC install @relname@ (<E>, set password and connect here)' --id 'vncpasswd' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ showopts @bootargs@ headless no_alt_virt_keyboard vncpassword=VNCPWD
+  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ showopts @bootargs@ headless no_alt_virt_keyboard vncpassword=VNCPWD lang=$language
   initrd@linux_suffix@ @boot_path@/full.cz
 }
 
diff --git a/features.in/grub/cfg.in/30live.cfg b/features.in/grub/cfg.in/30live.cfg
index 5e4b85ada6..be62b59a79 100644
--- a/features.in/grub/cfg.in/30live.cfg
+++ b/features.in/grub/cfg.in/30live.cfg
@@ -1,5 +1,5 @@
 menuentry 'LiveCD (no hard disk needed)' --id 'live' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot live automatic=method:cdrom ramdisk_size=@live_size@ stagename=live showopts lowmem vga=@bootvga@ @bootargs@
+  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot live automatic=method:cdrom ramdisk_size=@live_size@ stagename=live showopts lowmem vga=@bootvga@ @bootargs@ lang=$language
   initrd@linux_suffix@ @boot_path@/full.cz
 }
 
diff --git a/features.in/grub/cfg.in/32live_rw.cfg b/features.in/grub/cfg.in/32live_rw.cfg
index 4bac28aa65..240b6a4e12 100644
--- a/features.in/grub/cfg.in/32live_rw.cfg
+++ b/features.in/grub/cfg.in/32live_rw.cfg
@@ -1,4 +1,4 @@
 menuentry 'LiveCD with sessions support' --id 'session' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot live automatic=method:cdrom ramdisk_size=@live_size@ stagename=live showopts live_rw vga=@bootvga@ @bootargs@
+  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot live automatic=method:cdrom ramdisk_size=@live_size@ stagename=live showopts live_rw vga=@bootvga@ @bootargs@ lang=$language
   initrd@linux_suffix@ @boot_path@/full.cz
 }
diff --git a/features.in/grub/cfg.in/40lang.cfg b/features.in/grub/cfg.in/40lang.cfg
new file mode 100644
index 0000000000..85cc9241a1
--- /dev/null
+++ b/features.in/grub/cfg.in/40lang.cfg
@@ -0,0 +1,14 @@
+submenu "Change Language" {
+	insmod regexp
+	for langstr in "ru_RU=Russian" "en_US=English" "pt_BR=Portuguese" "kk_KZ=Kazakh" "uk_UA=Ukrainian"; do
+		regexp -s 2:langname -s 1:langcode '(.*)=(.*)' "$langstr"
+		menuentry "${langname}" "$langcode" {
+			language="$2"
+			export language
+			configfile ${prefix}/grub.cfg
+		}
+	done
+	menuentry "Return to the Main menu" {
+		configfile ${prefix}/grub.cfg
+	}
+}
diff --git a/features.in/grub/generate.mk b/features.in/grub/generate.mk
index 3a9f332fd7..f6bdd586e2 100644
--- a/features.in/grub/generate.mk
+++ b/features.in/grub/generate.mk
@@ -19,6 +19,10 @@ ifndef GRUB_DIRECT
 GRUB_CFG := $(GRUB_CFG) $(SUBPROFILE_DIRS) defaults fwsetup_efi
 endif
 
+ifdef LOCALE
+GRUB_CFG := $(GRUB_CFG) lang
+endif
+
 DSTDIR  := $(BUILDDIR)/stage1/files/boot/grub/.in
 DSTCFGS := $(DSTDIR)/*.cfg
 
@@ -77,6 +81,12 @@ bootargs: clean
 		sed -i "s,@bootvga@,$(BOOTVGA)," $(DSTCFGS); \
 	fi; \
 	sed -i "s,@bootvga@,,;s,vga= ,," $(DSTCFGS)
+	@if [ -n "$(LOCALE)" ]; then \
+		sed -i "s,@LOCALE@,$(LOCALE),g" $(DSTCFGS); \
+	else \
+		sed -i "s, lang=.language,,g" $(DSTCFGS); \
+	fi; \
+	sed -i "/language=@LOCALE@/d" $(DSTCFGS)
 
 clean: copy
 	@if [ "$(GRUB_UI)" = gfxboot ]; then \
-- 
2.24.1


[-- Attachment #3: 0004-grub-Added-submenu-for-kernel-flavour-change.patch --]
[-- Type: text/x-patch, Size: 8726 bytes --]

>From 4f12576d3fa806e482ff6e16db25e2f21385d616 Mon Sep 17 00:00:00 2001
From: Anton Midyukov <antohami@altlinux.org>
Date: Wed, 4 Mar 2020 14:26:38 +0700
Subject: [PATCH 4/4] grub: Added submenu for kernel flavour change

---
 features.in/grub/cfg.in/20install2.cfg        |  4 ++--
 .../grub/cfg.in/25install-vnc-connect.cfg     |  4 ++--
 .../grub/cfg.in/25install-vnc-listen.cfg      |  4 ++--
 features.in/grub/cfg.in/30live.cfg            |  4 ++--
 features.in/grub/cfg.in/32live_rw.cfg         |  4 ++--
 features.in/grub/cfg.in/80rescue.cfg          |  4 ++--
 features.in/grub/cfg.in/82rescue_rw.cfg       |  4 ++--
 features.in/grub/cfg.in/84rescue_remote.cfg   |  4 ++--
 features.in/grub/cfg.in/90kernel.cfg          | 19 +++++++++++++++++++
 features.in/grub/generate.mk                  |  7 +++++++
 10 files changed, 42 insertions(+), 16 deletions(-)
 create mode 100644 features.in/grub/cfg.in/90kernel.cfg

diff --git a/features.in/grub/cfg.in/20install2.cfg b/features.in/grub/cfg.in/20install2.cfg
index b88f44ae01..f6e3995550 100644
--- a/features.in/grub/cfg.in/20install2.cfg
+++ b/features.in/grub/cfg.in/20install2.cfg
@@ -1,6 +1,6 @@
 
 default='linux'
 menuentry 'Install @relname@' --hotkey 'i' --id 'linux' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ vga=@bootvga@ @bootargs@ lang=$language
-  initrd@linux_suffix@ @boot_path@/full.cz
+  linux@linux_suffix@ @boot_path@/vmlinuz$KFLAVOUR changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ vga=@bootvga@ @bootargs@ lang=$language
+  initrd@linux_suffix@ @boot_path@/full$KFLAVOUR.cz
 }
diff --git a/features.in/grub/cfg.in/25install-vnc-connect.cfg b/features.in/grub/cfg.in/25install-vnc-connect.cfg
index 7a1ce36d25..805435cb20 100644
--- a/features.in/grub/cfg.in/25install-vnc-connect.cfg
+++ b/features.in/grub/cfg.in/25install-vnc-connect.cfg
@@ -1,5 +1,5 @@
 
 menuentry '^VNC install @relname@ (edit to set server IP address)' --id 'vncconnect' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ showopts @bootargs@ headless no_alt_virt_keyboard vncconnect=IP lang=$language
-  initrd@linux_suffix@ @boot_path@/full.cz
+  linux@linux_suffix@ @boot_path@/vmlinuz$KFLAVOUR changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ showopts @bootargs@ headless no_alt_virt_keyboard vncconnect=IP lang=$language
+  initrd@linux_suffix@ @boot_path@/full$KFLAVOUR.cz
 }
diff --git a/features.in/grub/cfg.in/25install-vnc-listen.cfg b/features.in/grub/cfg.in/25install-vnc-listen.cfg
index 90a285fdda..0aef0dc4d0 100644
--- a/features.in/grub/cfg.in/25install-vnc-listen.cfg
+++ b/features.in/grub/cfg.in/25install-vnc-listen.cfg
@@ -1,6 +1,6 @@
 
 menuentry 'VNC install @relname@ (<E>, set password and connect here)' --id 'vncpasswd' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ showopts @bootargs@ headless no_alt_virt_keyboard vncpassword=VNCPWD lang=$language
-  initrd@linux_suffix@ @boot_path@/full.cz
+  linux@linux_suffix@ @boot_path@/vmlinuz$KFLAVOUR changedisk fastboot automatic=method:cdrom ramdisk_size=@altinst_size@ showopts @bootargs@ headless no_alt_virt_keyboard vncpassword=VNCPWD lang=$language
+  initrd@linux_suffix@ @boot_path@/full$KFLAVOUR.cz
 }
 
diff --git a/features.in/grub/cfg.in/30live.cfg b/features.in/grub/cfg.in/30live.cfg
index be62b59a79..f750dd0780 100644
--- a/features.in/grub/cfg.in/30live.cfg
+++ b/features.in/grub/cfg.in/30live.cfg
@@ -1,6 +1,6 @@
 menuentry 'LiveCD (no hard disk needed)' --id 'live' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot live automatic=method:cdrom ramdisk_size=@live_size@ stagename=live showopts lowmem vga=@bootvga@ @bootargs@ lang=$language
-  initrd@linux_suffix@ @boot_path@/full.cz
+  linux@linux_suffix@ @boot_path@/vmlinuz$KFLAVOUR changedisk fastboot live automatic=method:cdrom ramdisk_size=@live_size@ stagename=live showopts lowmem vga=@bootvga@ @bootargs@ lang=$language
+  initrd@linux_suffix@ @boot_path@/full$KFLAVOUR.cz
 }
 
 
diff --git a/features.in/grub/cfg.in/32live_rw.cfg b/features.in/grub/cfg.in/32live_rw.cfg
index 240b6a4e12..b487f9417a 100644
--- a/features.in/grub/cfg.in/32live_rw.cfg
+++ b/features.in/grub/cfg.in/32live_rw.cfg
@@ -1,4 +1,4 @@
 menuentry 'LiveCD with sessions support' --id 'session' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot live automatic=method:cdrom ramdisk_size=@live_size@ stagename=live showopts live_rw vga=@bootvga@ @bootargs@ lang=$language
-  initrd@linux_suffix@ @boot_path@/full.cz
+  linux@linux_suffix@ @boot_path@/vmlinuz$KFLAVOUR changedisk fastboot live automatic=method:cdrom ramdisk_size=@live_size@ stagename=live showopts live_rw vga=@bootvga@ @bootargs@ lang=$language
+  initrd@linux_suffix@ @boot_path@/full$KFLAVOUR.cz
 }
diff --git a/features.in/grub/cfg.in/80rescue.cfg b/features.in/grub/cfg.in/80rescue.cfg
index a9d2575cfb..e06a63afe2 100644
--- a/features.in/grub/cfg.in/80rescue.cfg
+++ b/features.in/grub/cfg.in/80rescue.cfg
@@ -1,4 +1,4 @@
 menuentry 'Rescue LiveCD' --id 'rescue' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot live automatic=method:cdrom ramdisk_size=@rescue_size@ stagename=rescue splash=0 showopts @rescue_bootargs@
-  initrd@linux_suffix@ @boot_path@/full.cz
+  linux@linux_suffix@ @boot_path@/vmlinuz$KFLAVOUR changedisk fastboot live automatic=method:cdrom ramdisk_size=@rescue_size@ stagename=rescue splash=0 showopts @rescue_bootargs@
+  initrd@linux_suffix@ @boot_path@/full$KFLAVOUR.cz
 }
diff --git a/features.in/grub/cfg.in/82rescue_rw.cfg b/features.in/grub/cfg.in/82rescue_rw.cfg
index 753c642bc3..45dcb0007a 100644
--- a/features.in/grub/cfg.in/82rescue_rw.cfg
+++ b/features.in/grub/cfg.in/82rescue_rw.cfg
@@ -1,4 +1,4 @@
 menuentry 'Rescue with sessions support' --id 'rescue_session' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot live automatic=method:cdrom,label:ALT* ramdisk_size=@rescue_size@ stagename=rescue splash=0 showopts @rescue_bootargs@ live_rw
-  initrd@linux_suffix@ @boot_path@/full.cz
+  linux@linux_suffix@ @boot_path@/vmlinuz$KFLAVOUR changedisk fastboot live automatic=method:cdrom,label:ALT* ramdisk_size=@rescue_size@ stagename=rescue splash=0 showopts @rescue_bootargs@ live_rw
+  initrd@linux_suffix@ @boot_path@/full$KFLAVOUR.cz
 }
diff --git a/features.in/grub/cfg.in/84rescue_remote.cfg b/features.in/grub/cfg.in/84rescue_remote.cfg
index 738abd79ad..0b483f95c0 100644
--- a/features.in/grub/cfg.in/84rescue_remote.cfg
+++ b/features.in/grub/cfg.in/84rescue_remote.cfg
@@ -1,4 +1,4 @@
 menuentry 'Rescue with remote SSH access (DHCP)' --id 'rescue_remote' {
-  linux@linux_suffix@ @boot_path@/vmlinuz changedisk fastboot live automatic=method:cdrom ramdisk_size=@rescue_size@ splash=0 showopts stagename=rescue @rescue_bootargs@ max_loop=16 ip=dhcp port=22 rootpw=AUTO hash=@rescue_hash@
-  initrd@linux_suffix@ @boot_path@/full.cz
+  linux@linux_suffix@ @boot_path@/vmlinuz$KFLAVOUR changedisk fastboot live automatic=method:cdrom ramdisk_size=@rescue_size@ splash=0 showopts stagename=rescue @rescue_bootargs@ max_loop=16 ip=dhcp port=22 rootpw=AUTO hash=@rescue_hash@
+  initrd@linux_suffix@ @boot_path@/full$KFLAVOUR.cz
 }
diff --git a/features.in/grub/cfg.in/90kernel.cfg b/features.in/grub/cfg.in/90kernel.cfg
new file mode 100644
index 0000000000..2c355f3cbc
--- /dev/null
+++ b/features.in/grub/cfg.in/90kernel.cfg
@@ -0,0 +1,19 @@
+submenu "Change Kernel Flavour" {
+	insmod regexp
+	regexp -s 1:kflavours -s 2:kflavourstr '(.*) (.*)' "@KFLAVOUR@"
+	menuentry "${kflavourstr}" {
+		KFLAVOUR=
+		export KFLAVOUR
+		configfile ${prefix}/grub.cfg
+	}
+	for kflavourstr in ${kflavours}; do
+		menuentry "${kflavourstr}" {
+			KFLAVOUR="-$1"
+			export KFLAVOUR
+			configfile ${prefix}/grub.cfg
+		}
+	done
+	menuentry "Return to the Main menu" {
+		configfile ${prefix}/grub.cfg
+	}
+}
diff --git a/features.in/grub/generate.mk b/features.in/grub/generate.mk
index f6bdd586e2..a5a7dd087a 100644
--- a/features.in/grub/generate.mk
+++ b/features.in/grub/generate.mk
@@ -23,6 +23,10 @@ ifdef LOCALE
 GRUB_CFG := $(GRUB_CFG) lang
 endif
 
+ifneq ($(words $(KFLAVOURS)),1)
+GRUB_CFG := $(GRUB_CFG) kernel
+endif
+
 DSTDIR  := $(BUILDDIR)/stage1/files/boot/grub/.in
 DSTCFGS := $(DSTDIR)/*.cfg
 
@@ -87,6 +91,9 @@ bootargs: clean
 		sed -i "s, lang=.language,,g" $(DSTCFGS); \
 	fi; \
 	sed -i "/language=@LOCALE@/d" $(DSTCFGS)
+	@if [ $$(echo $(KFLAVOURS) | wc -w) -gt 1 ]; then \
+		sed -i "s,@KFLAVOUR@,$(KFLAVOURS),g" $(DSTCFGS); \
+	fi
 
 clean: copy
 	@if [ "$(GRUB_UI)" = gfxboot ]; then \
-- 
2.24.1


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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-03-04 16:09                                     ` Антон Мидюков
@ 2020-03-04 17:50                                       ` Leonid Krivoshein
  2020-03-04 18:00                                         ` Антон Мидюков
  2020-03-05  7:50                                         ` Sergey V Turchin
  2020-03-11 19:49                                       ` Антон Мидюков
  1 sibling, 2 replies; 38+ messages in thread
From: Leonid Krivoshein @ 2020-03-04 17:50 UTC (permalink / raw)
  To: devel-distro



04.03.2020 19:09, Антон Мидюков пишет:
> 28.02.2020 17:32, Leonid Krivoshein пишет:
>> 28.02.2020 6:57, Антон Мидюков пишет:
>>> 28.02.2020 10:50, Anton Farygin пишет:
>>>> [...]
>>>> А если учесть то, что от refind надо уходить, то остаётся только grub.
>>> Надо, но не прямо сейчас. Так что прямо сейчас актуален именно 
>>> rEFInd. И это прямо сейчас продлится неопределённо долго
>>
>> Наш .efi.img (в ElTorrito) вырос за последние годы почти вдвое и на 
>> каком-то железе это уже проблема загрузки. Теперь мы добавим туда ещё 
>> одно ядро с initrd и число совместимых машин по EFI-загрузке резко 
>> упадёт. Уж лучше перейти на grub на без графики, чем вот так. Но раз 
>> с grub'ом получилось, раз SecureBoot уже есть, осталось только сборку 
>> темы в ISO добавить -- сама тема для grub тоже есть.
>>
> Я сделал подменю для grub: одно для выбора языка, другое - для выбора 
> flavour ядра. Прикладываю патчи для m-p.
>
> По выбору языка. Пока графическую тему не прикрутили, язык самого grub 
> не меняется, так как не ASCII символы не поддерживаются в текстовом 
> режиме.
>

Серьёзная заявка!


> По выбору flavour ядра. Придётся серьёзно поработать над mkimage. 
> Сейчас есть две проблемы:
>
> 1. ядра сортируются как и другие пакеты в алфавитном порядке. Таким 
> образом происходит коллизия, имя дефолтного flavour может не 
> совпадать, так как зависит от порядка в переменной KFLAVOURS. Я думаю, 
> нужно исправлять mkimage, чтобы он не упорядочивал пакеты ядер в 
> алфавитном порядке.
>

Сортировку пакетов можно отключить глобально, но это нежелательное 
поведение с точки зрения предсказуемости образа. Мне кажется, нужно 
зависеть не от порядка KFLAVOURS, а того, какое ядро указано основным 
(KVLAVOUR -- есть такая переменная?), а всё остальное брать из 
переменной KFLAVOURS.


> 2. Если мы не делаем для syslinux выбор ядер, то получаем проблему. 
> Как ядра в efiboot передавать? В efiboot они копируются из syslinux/alt0
>
> И наконец, если не делать выбор ядер для rEFInd, то надо в efiboot 
> дополнительные условия вводить, чтобы не копировать для него ядра.
>
> Так что, думается, надо вообще сделать grubefiboot какой-нибудь, чтобы 
> ещё и grubaa64boot нужен не был.

Да, похоже на то.


> grubx86boot ты больше не занимался?
>

Нет.


> Или таки править efiboot и вызывать его также дважды как и другие 
> загрузчики.
>

Тебе видней, поскольку речь об m-p!



-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-03-04 17:50                                       ` Leonid Krivoshein
@ 2020-03-04 18:00                                         ` Антон Мидюков
  2020-03-04 18:03                                           ` Leonid Krivoshein
  2020-03-05  7:50                                         ` Sergey V Turchin
  1 sibling, 1 reply; 38+ messages in thread
From: Антон Мидюков @ 2020-03-04 18:00 UTC (permalink / raw)
  To: devel-distro

05.03.2020 00:50, Leonid Krivoshein пишет:
>
>
> 04.03.2020 19:09, Антон Мидюков пишет:
>> 28.02.2020 17:32, Leonid Krivoshein пишет:
>>> 28.02.2020 6:57, Антон Мидюков пишет:
> [...]
>> По выбору flavour ядра. Придётся серьёзно поработать над mkimage. 
>> Сейчас есть две проблемы:
>>
>> 1. ядра сортируются как и другие пакеты в алфавитном порядке. Таким 
>> образом происходит коллизия, имя дефолтного flavour может не 
>> совпадать, так как зависит от порядка в переменной KFLAVOURS. Я 
>> думаю, нужно исправлять mkimage, чтобы он не упорядочивал пакеты ядер 
>> в алфавитном порядке.
>>
>
> Сортировку пакетов можно отключить глобально, но это нежелательное 
> поведение с точки зрения предсказуемости образа. Мне кажется, нужно 
> зависеть не от порядка KFLAVOURS, а того, какое ядро указано основным 
> (KVLAVOUR -- есть такая переменная?), а всё остальное брать из 
> переменной KFLAVOURS.
>
В mkimage основное ядро определяется по симлинку vmlinuz. Поэтому 
порядок установки важен. Если передавать переменную, это придётся же 
потом документировать в mkimage :-)

[...]

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



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-03-04 18:00                                         ` Антон Мидюков
@ 2020-03-04 18:03                                           ` Leonid Krivoshein
  0 siblings, 0 replies; 38+ messages in thread
From: Leonid Krivoshein @ 2020-03-04 18:03 UTC (permalink / raw)
  To: devel-distro



04.03.2020 21:00, Антон Мидюков пишет:
> 05.03.2020 00:50, Leonid Krivoshein пишет:
>>
>>
>> 04.03.2020 19:09, Антон Мидюков пишет:
>>> 28.02.2020 17:32, Leonid Krivoshein пишет:
>>>> 28.02.2020 6:57, Антон Мидюков пишет:
>> [...]
>>> По выбору flavour ядра. Придётся серьёзно поработать над mkimage. 
>>> Сейчас есть две проблемы:
>>>
>>> 1. ядра сортируются как и другие пакеты в алфавитном порядке. Таким 
>>> образом происходит коллизия, имя дефолтного flavour может не 
>>> совпадать, так как зависит от порядка в переменной KFLAVOURS. Я 
>>> думаю, нужно исправлять mkimage, чтобы он не упорядочивал пакеты 
>>> ядер в алфавитном порядке.
>>>
>>
>> Сортировку пакетов можно отключить глобально, но это нежелательное 
>> поведение с точки зрения предсказуемости образа. Мне кажется, нужно 
>> зависеть не от порядка KFLAVOURS, а того, какое ядро указано основным 
>> (KVLAVOUR -- есть такая переменная?), а всё остальное брать из 
>> переменной KFLAVOURS.
>>
> В mkimage основное ядро определяется по симлинку vmlinuz. Поэтому 
> порядок установки важен. Если передавать переменную, это придётся же 
> потом документировать в mkimage :-)

А кто последний встал, тот и симлинк? Это надо менять.


>
> [...]
>

-- 
Best regards,
Leonid Krivoshein.



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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-03-04 17:50                                       ` Leonid Krivoshein
  2020-03-04 18:00                                         ` Антон Мидюков
@ 2020-03-05  7:50                                         ` Sergey V Turchin
  1 sibling, 0 replies; 38+ messages in thread
From: Sergey V Turchin @ 2020-03-05  7:50 UTC (permalink / raw)
  To: Distributions development

On Wednesday, 4 March 2020 20:50:10 MSK Leonid Krivoshein wrote:

[...]
> Сортировку пакетов можно отключить глобально, но это нежелательное
> поведение с точки зрения предсказуемости образа.
С тех пор, как обнаружил это, всегда отключаю, т.к. в образ предсказуемо 
пападает абсолютно не то, что нужно. С отключенной певедение аналогично 
установленной системе.

Проблему нежелательных пакетов решаю через RPM::Ignore в местном apt.conf .
 
[...]

-- 
Regards, Sergey.

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

* Re: [devel-distro] Несколько ядер в stage1 и stage2
  2020-03-04 16:09                                     ` Антон Мидюков
  2020-03-04 17:50                                       ` Leonid Krivoshein
@ 2020-03-11 19:49                                       ` Антон Мидюков
  1 sibling, 0 replies; 38+ messages in thread
From: Антон Мидюков @ 2020-03-11 19:49 UTC (permalink / raw)
  To: devel-distro

04.03.2020 23:09, Антон Мидюков пишет:
> 28.02.2020 17:32, Leonid Krivoshein пишет:
>> 28.02.2020 6:57, Антон Мидюков пишет:
>>> 28.02.2020 10:50, Anton Farygin пишет:
>>>> [...]
>>>> А если учесть то, что от refind надо уходить, то остаётся только grub.
>>> Надо, но не прямо сейчас. Так что прямо сейчас актуален именно 
>>> rEFInd. И это прямо сейчас продлится неопределённо долго
>>
>> Наш .efi.img (в ElTorrito) вырос за последние годы почти вдвое и на 
>> каком-то железе это уже проблема загрузки. Теперь мы добавим туда ещё 
>> одно ядро с initrd и число совместимых машин по EFI-загрузке резко 
>> упадёт. Уж лучше перейти на grub на без графики, чем вот так. Но раз 
>> с grub'ом получилось, раз SecureBoot уже есть, осталось только сборку 
>> темы в ISO добавить -- сама тема для grub тоже есть.
>>
> Я сделал подменю для grub: одно для выбора языка, другое - для выбора 
> flavour ядра. Прикладываю патчи для m-p.
>
> По выбору языка. Пока графическую тему не прикрутили, язык самого grub 
> не меняется, так как не ASCII символы не поддерживаются в текстовом 
> режиме.
Графическую тему прикручивать научился. Но нужно будет обновить переводы 
grub, чтобы были переведены пункты меню: Install - установить и т.д.
>
> По выбору flavour ядра. Придётся серьёзно поработать над mkimage. 
> Сейчас есть две проблемы:
>
> 1. ядра сортируются как и другие пакеты в алфавитном порядке. Таким 
> образом происходит коллизия, имя дефолтного flavour может не 
> совпадать, так как зависит от порядка в переменной KFLAVOURS. Я думаю, 
> нужно исправлять mkimage, чтобы он не упорядочивал пакеты ядер в 
> алфавитном порядке.
С этим разобрался. Это нужно было делать в mkimage-profiles. В смысле 
симлинк vmlinuz создавать правильный. И проблемы этой больше нет.
>
> 2. Если мы не делаем для syslinux выбор ядер, то получаем проблему. 
> Как ядра в efiboot передавать? В efiboot они копируются из syslinux/alt0

А вот с этим нет. Наверное, можно закостылить пока. Копировать в 
syslinux, а потом оттуда забирать в /BOOT/EFI

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

Тогда останется только livecd-install научить жить по-новому. И можно 
дистрибутивы делать :-)

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



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

end of thread, other threads:[~2020-03-11 19:49 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-04 18:02 [devel-distro] Возвращаем возможность задания порядка загрузки ядер Антон Мидюков
2020-02-25 18:31 ` Leonid Krivoshein
2020-02-25 18:58   ` [devel-distro] Несколько ядер в stage1 и stage2 Антон Мидюков
2020-02-25 19:31     ` Leonid Krivoshein
2020-02-26  6:02       ` Nikolai Kostrigin
2020-02-26 10:43         ` Leonid Krivoshein
2020-02-26 10:55           ` Anton V. Boyarshinov
2020-02-26 11:01       ` Антон Мидюков
2020-02-26 12:02         ` Sergey V Turchin
2020-02-27  1:53           ` Leonid Krivoshein
2020-02-27  6:01             ` Sergey V Turchin
2020-02-27 10:06             ` Anton V. Boyarshinov
2020-02-27  1:46         ` Leonid Krivoshein
2020-02-27 10:04           ` Anton V. Boyarshinov
2020-02-27 11:42             ` Leonid Krivoshein
2020-02-27 11:50               ` Anton V. Boyarshinov
2020-02-27 12:31                 ` Leonid Krivoshein
2020-02-27 12:51                     ` Антон Мидюков
2020-02-27 13:02                       ` Leonid Krivoshein
2020-02-28  3:21                           ` Leonid Krivoshein
2020-02-28  3:35                             ` Антон Мидюков
2020-02-28  3:50                               ` Anton Farygin
2020-02-28  3:52                                 ` Leonid Krivoshein
2020-02-28  3:57                                 ` Антон Мидюков
2020-02-28  4:02                                   ` Anton Farygin
2020-02-28  4:11                                     ` Антон Мидюков
2020-02-28  8:33                                       ` Anton Farygin
2020-02-28 10:32                                   ` Leonid Krivoshein
2020-03-04 16:09                                     ` Антон Мидюков
2020-03-04 17:50                                       ` Leonid Krivoshein
2020-03-04 18:00                                         ` Антон Мидюков
2020-03-04 18:03                                           ` Leonid Krivoshein
2020-03-05  7:50                                         ` Sergey V Turchin
2020-03-11 19:49                                       ` Антон Мидюков
2020-02-27 11:58               ` Антон Мидюков
2020-02-27 12:39                 ` Leonid Krivoshein
2020-02-27 12:48                   ` Антон Мидюков
2020-02-27 13:09                 ` Leonid Krivoshein

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