[devel] Q: postinst hook for firmware-*

[devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

Привет!

В процессе обновления пакета firmware-intel-ucode я заметил такую вещь:
- пакеты *-ucode что intel что amd используются make-initrd для генерации
  early microcode в initramfs и это хорошо.
- но мы никак не ловим вариант, когда пакет с ucode обновляется, и даже
  после обновления *-ucode пакета в initramfs все равно будет устаревшая
  версия microcode.

Я считаю это неправильно, поскольку требует лишних телодвижений после
обновления пакета + это совершенно непрозрачно для пользователя. Поэтому
предлагаю добавить post hook который будет дергать make-initrd (и возможно
делать тоже самое и для пакета linux-firmware, поскольку там храниться
amd-ucode).

Кто что думает и как лучше поступить?

-- 
WBR et al.

Re: [devel] Q: postinst hook for firmware-*

[Dmitry V. Levin]

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

Hi,

On Mon, Sep 04, 2017 at 01:56:40PM +0200, Konstantin Lepikhov wrote:
> Привет!
> 
> В процессе обновления пакета firmware-intel-ucode я заметил такую вещь:
> - пакеты *-ucode что intel что amd используются make-initrd для генерации
>   early microcode в initramfs и это хорошо.
> - но мы никак не ловим вариант, когда пакет с ucode обновляется, и даже
>   после обновления *-ucode пакета в initramfs все равно будет устаревшая
>   версия microcode.
> 
> Я считаю это неправильно, поскольку требует лишних телодвижений после
> обновления пакета + это совершенно непрозрачно для пользователя. Поэтому
> предлагаю добавить post hook который будет дергать make-initrd (и возможно
> делать тоже самое и для пакета linux-firmware, поскольку там храниться
> amd-ucode).
> 
> Кто что думает и как лучше поступить?

Пакеты kernel-image не дёргают make-initrd самостоятельно, полагаясь на
/usr/lib/rpm/boot_kernel.filetrigger; если эти файлы склонны расползаться
по пакетам, может быть, лучше подойдёт файлтриггер?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

Hi Dmitry!

On 09/04/2017, at 07:01:38 PM you wrote:

> Hi,
> 
> On Mon, Sep 04, 2017 at 01:56:40PM +0200, Konstantin Lepikhov wrote:
> > Привет!
> > 
> > В процессе обновления пакета firmware-intel-ucode я заметил такую вещь:
> > - пакеты *-ucode что intel что amd используются make-initrd для генерации
> >   early microcode в initramfs и это хорошо.
> > - но мы никак не ловим вариант, когда пакет с ucode обновляется, и даже
> >   после обновления *-ucode пакета в initramfs все равно будет устаревшая
> >   версия microcode.
> > 
> > Я считаю это неправильно, поскольку требует лишних телодвижений после
> > обновления пакета + это совершенно непрозрачно для пользователя. Поэтому
> > предлагаю добавить post hook который будет дергать make-initrd (и возможно
> > делать тоже самое и для пакета linux-firmware, поскольку там храниться
> > amd-ucode).
> > 
> > Кто что думает и как лучше поступить?
> 
> Пакеты kernel-image не дёргают make-initrd самостоятельно, полагаясь на
> /usr/lib/rpm/boot_kernel.filetrigger; если эти файлы склонны расползаться
> по пакетам, может быть, лучше подойдёт файлтриггер?
Так если мне нужно перегенерить initrd, то я не против дернуть тот же
boot_kernel.filetrigger. Где это задается? Внутри rpm?


-- 
WBR et al.

Re: [devel] Q: postinst hook for firmware-*

[Dmitry V. Levin]

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

On Mon, Sep 04, 2017 at 09:18:42PM +0200, Konstantin Lepikhov wrote:
> Hi Dmitry!
> 
> On 09/04/2017, at 07:01:38 PM you wrote:
> 
> > Hi,
> > 
> > On Mon, Sep 04, 2017 at 01:56:40PM +0200, Konstantin Lepikhov wrote:
> > > Привет!
> > > 
> > > В процессе обновления пакета firmware-intel-ucode я заметил такую вещь:
> > > - пакеты *-ucode что intel что amd используются make-initrd для генерации
> > >   early microcode в initramfs и это хорошо.
> > > - но мы никак не ловим вариант, когда пакет с ucode обновляется, и даже
> > >   после обновления *-ucode пакета в initramfs все равно будет устаревшая
> > >   версия microcode.
> > > 
> > > Я считаю это неправильно, поскольку требует лишних телодвижений после
> > > обновления пакета + это совершенно непрозрачно для пользователя. Поэтому
> > > предлагаю добавить post hook который будет дергать make-initrd (и возможно
> > > делать тоже самое и для пакета linux-firmware, поскольку там храниться
> > > amd-ucode).
> > > 
> > > Кто что думает и как лучше поступить?
> > 
> > Пакеты kernel-image не дёргают make-initrd самостоятельно, полагаясь на
> > /usr/lib/rpm/boot_kernel.filetrigger; если эти файлы склонны расползаться
> > по пакетам, может быть, лучше подойдёт файлтриггер?
> Так если мне нужно перегенерить initrd, то я не против дернуть тот же
> boot_kernel.filetrigger. Где это задается? Внутри rpm?

Прямо в boot_kernel.filetrigger; это пакет bootloader-utils.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

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

Hi Dmitry!

On 09/05/2017, at 12:35:09 AM you wrote:

<skip>
> > > Пакеты kernel-image не дёргают make-initrd самостоятельно, полагаясь на
> > > /usr/lib/rpm/boot_kernel.filetrigger; если эти файлы склонны расползаться
> > > по пакетам, может быть, лучше подойдёт файлтриггер?
> > Так если мне нужно перегенерить initrd, то я не против дернуть тот же
> > boot_kernel.filetrigger. Где это задается? Внутри rpm?
> 
> Прямо в boot_kernel.filetrigger; это пакет bootloader-utils.
Подойдет ли такое изменение?

-- 
WBR et al.

[-- Attachment #2: 0001-kernel.filetrigger-ucode-support.patch --]
[-- Type: text/x-patch, Size: 1830 bytes --]

>From c974d0d02c1275c600929b3590e6ef644a4e8159 Mon Sep 17 00:00:00 2001
From: "Konstantin A. Lepikhov" <lakostis@altlinux.ru>
Date: Wed, 6 Sep 2017 13:49:26 +0200
Subject: [PATCH] kernel.filetrigger: ucode support

We need to rebuild initramfs on CPU ucode changes otherwise everything
will continue use outdated version till next kernel update.
---
 kernel.filetrigger | 27 ++++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/kernel.filetrigger b/kernel.filetrigger
index 9cdf01e..38ea249 100755
--- a/kernel.filetrigger
+++ b/kernel.filetrigger
@@ -9,6 +9,7 @@
 BOOTDIR=/boot
 VMLINUZ_PREFIX=/boot/vmlinuz
 MODULES_PREFIX=/lib/modules
+UCODE_PREFIX=/lib/firmware
 INITRD_AUTOUPDATE=
 
 . /etc/sysconfig/installkernel
@@ -99,6 +100,27 @@ $VERSION"
 	last_added="$VERSION"
 }
 
+ucode_handled=
+handle_ucode()
+{
+	local f VENDOR VERSION
+	f="$1"; shift
+	# filename format: $UCODE_PREFIX/<vendor>-ucode/*
+	VENDOR=${f#$UCODE_PREFIX/}
+	VENDOR=${VENDOR%%-ucode/*}
+	ucode_handled="$ucode_handled $VENDOR"
+	set +f
+	f="$(readlink -e /boot/vmlinuz)"
+	if [ -n "$f" -a -n "$kernel_versions_handled" ]; then
+		VERSION=${f#$VMLINUZ_PREFIX-}
+		case "$kernel_version_handled" in
+			"* $VERSION*")
+			ucode_handled=
+			;;
+		esac
+	fi
+}
+
 while read f; do
 	case "$f" in
 		$VMLINUZ_PREFIX-[0-9].*-*-*)
@@ -107,10 +129,13 @@ while read f; do
 		$MODULES_PREFIX/*-*-*/*/*.ko*)
 			handle_module "$f"
 			;;
+		$UCODE_PREFIX/*-ucode/*)
+			handle_ucode "$f"
+			;;
 	esac
 done
 
-if [ -n "$kernel_versions_handled" -a "$INITRD_AUTOUPDATE" = all ]; then
+if [ -n "$kernel_versions_handled" -o -n "$ucode_handled" ] && [ "$INITRD_AUTOUPDATE" = all ]; then
 	set +f
 	ls -c $VMLINUZ_PREFIX-[0-9].*-*-* 2> /dev/null | while read f; do
 		[ "$f" != "$(readlink -e /boot/vmlinuz)" ] ||
-- 
2.10.4

Re: [devel] Q: postinst hook for firmware-*

[Dmitry V. Levin]

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

On Wed, Sep 06, 2017 at 02:09:09PM +0200, Konstantin Lepikhov wrote:
> Hi Dmitry!
> 
> On 09/05/2017, at 12:35:09 AM you wrote:
> 
> <skip>
> > > > Пакеты kernel-image не дёргают make-initrd самостоятельно, полагаясь на
> > > > /usr/lib/rpm/boot_kernel.filetrigger; если эти файлы склонны расползаться
> > > > по пакетам, может быть, лучше подойдёт файлтриггер?
> > > Так если мне нужно перегенерить initrd, то я не против дернуть тот же
> > > boot_kernel.filetrigger. Где это задается? Внутри rpm?
> > 
> > Прямо в boot_kernel.filetrigger; это пакет bootloader-utils.
> Подойдет ли такое изменение?
> 
> -- 
> WBR et al.

> >From c974d0d02c1275c600929b3590e6ef644a4e8159 Mon Sep 17 00:00:00 2001
> From: "Konstantin A. Lepikhov" <lakostis@altlinux.ru>
> Date: Wed, 6 Sep 2017 13:49:26 +0200
> Subject: [PATCH] kernel.filetrigger: ucode support
> 
> We need to rebuild initramfs on CPU ucode changes otherwise everything
> will continue use outdated version till next kernel update.
> ---
>  kernel.filetrigger | 27 ++++++++++++++++++++++++++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel.filetrigger b/kernel.filetrigger
> index 9cdf01e..38ea249 100755
> --- a/kernel.filetrigger
> +++ b/kernel.filetrigger
> @@ -9,6 +9,7 @@
>  BOOTDIR=/boot
>  VMLINUZ_PREFIX=/boot/vmlinuz
>  MODULES_PREFIX=/lib/modules
> +UCODE_PREFIX=/lib/firmware
>  INITRD_AUTOUPDATE=
>  
>  . /etc/sysconfig/installkernel
> @@ -99,6 +100,27 @@ $VERSION"
>  	last_added="$VERSION"
>  }
>  
> +ucode_handled=
> +handle_ucode()
> +{
> +	local f VENDOR VERSION
> +	f="$1"; shift
> +	# filename format: $UCODE_PREFIX/<vendor>-ucode/*
> +	VENDOR=${f#$UCODE_PREFIX/}
> +	VENDOR=${VENDOR%%-ucode/*}
> +	ucode_handled="$ucode_handled $VENDOR"

содержимое ucode_handled дальше только проверяется на непустоту,
можно записывать туда что-то более простое, например, ucode_handled=1

> +	set +f

set +f дальше не используется и, видимо, не нужен.

> +	f="$(readlink -e /boot/vmlinuz)"
> +	if [ -n "$f" -a -n "$kernel_versions_handled" ]; then
> +		VERSION=${f#$VMLINUZ_PREFIX-}
> +		case "$kernel_version_handled" in
> +			"* $VERSION*")
> +			ucode_handled=
> +			;;
> +		esac
> +	fi

Это лучше делать всего один раз после обработки цикла по файлам.
Хотя почему это исключение сделано именно для /boot/vmlinuz, неочевидно.

> +}
> +
>  while read f; do
>  	case "$f" in
>  		$VMLINUZ_PREFIX-[0-9].*-*-*)
> @@ -107,10 +129,13 @@ while read f; do
>  		$MODULES_PREFIX/*-*-*/*/*.ko*)
>  			handle_module "$f"
>  			;;
> +		$UCODE_PREFIX/*-ucode/*)
> +			handle_ucode "$f"

Получается, что здесь достаточно написать ucode_detected=1,

> +			;;
>  	esac
>  done

А сюда поместить сброс ucode_detected в случае, если он уже был обработан.

> -if [ -n "$kernel_versions_handled" -a "$INITRD_AUTOUPDATE" = all ]; then
> +if [ -n "$kernel_versions_handled" -o -n "$ucode_handled" ] && [ "$INITRD_AUTOUPDATE" = all ]; then
>  	set +f
>  	ls -c $VMLINUZ_PREFIX-[0-9].*-*-* 2> /dev/null | while read f; do
>  		[ "$f" != "$(readlink -e /boot/vmlinuz)" ] ||


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

Hi Dmitry!

On 09/06/2017, at 04:37:35 PM you wrote:

> 
> содержимое ucode_handled дальше только проверяется на непустоту,
> можно записывать туда что-то более простое, например, ucode_handled=1
> 
ok

> > +	set +f
> 
> set +f дальше не используется и, видимо, не нужен.
ну как бы readlink может обломаться, если у нас нет /boot/vmlinuz. Я не
знаю, эта проверка есть в handle_kernel, я ее добавил по аналогии.

> 
> > +	f="$(readlink -e /boot/vmlinuz)"
> > +	if [ -n "$f" -a -n "$kernel_versions_handled" ]; then
> > +		VERSION=${f#$VMLINUZ_PREFIX-}
> > +		case "$kernel_version_handled" in
> > +			"* $VERSION*")
> > +			ucode_handled=
> > +			;;
> > +		esac
> > +	fi
> 
> Это лучше делать всего один раз после обработки цикла по файлам.
> Хотя почему это исключение сделано именно для /boot/vmlinuz, неочевидно.
я тут не очень понял логику, которая ниже по коду - если у нас выставлен
INITRD_AUTOUPDATE=all это значит что будет обновлятся initramfs для всех
ядер, или только тех, что попали в обновление? Почему там еще раз
проверяется является ли файл /boot/vmlinuz?

> 
> > +}
> > +
> >  while read f; do
> >  	case "$f" in
> >  		$VMLINUZ_PREFIX-[0-9].*-*-*)
> > @@ -107,10 +129,13 @@ while read f; do
> >  		$MODULES_PREFIX/*-*-*/*/*.ko*)
> >  			handle_module "$f"
> >  			;;
> > +		$UCODE_PREFIX/*-ucode/*)
> > +			handle_ucode "$f"
> 
> Получается, что здесь достаточно написать ucode_detected=1,
> 
> > +			;;
> >  	esac
> >  done
> 
> А сюда поместить сброс ucode_detected в случае, если он уже был обработан.
ok

-- 
WBR et al.

Re: [devel] Q: postinst hook for firmware-*

[Dmitry V. Levin]

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

On Thu, Sep 07, 2017 at 12:03:43AM +0200, Konstantin Lepikhov wrote:
> Hi Dmitry!
> 
> On 09/06/2017, at 04:37:35 PM you wrote:
> 
> > 
> > содержимое ucode_handled дальше только проверяется на непустоту,
> > можно записывать туда что-то более простое, например, ucode_handled=1
> > 
> ok
> 
> > > +	set +f
> > 
> > set +f дальше не используется и, видимо, не нужен.
> ну как бы readlink может обломаться, если у нас нет /boot/vmlinuz.

Это же +f, а не +e.

> Я не знаю, эта проверка есть в handle_kernel, я ее добавил по аналогии.
> 
> > 
> > > +	f="$(readlink -e /boot/vmlinuz)"
> > > +	if [ -n "$f" -a -n "$kernel_versions_handled" ]; then
> > > +		VERSION=${f#$VMLINUZ_PREFIX-}
> > > +		case "$kernel_version_handled" in
> > > +			"* $VERSION*")
> > > +			ucode_handled=
> > > +			;;
> > > +		esac
> > > +	fi
> > 
> > Это лучше делать всего один раз после обработки цикла по файлам.
> > Хотя почему это исключение сделано именно для /boot/vmlinuz, неочевидно.
> я тут не очень понял логику, которая ниже по коду - если у нас выставлен
> INITRD_AUTOUPDATE=all это значит что будет обновлятся initramfs для всех
> ядер, или только тех, что попали в обновление?

Судя по всему, для всех (commit 0.4.10-alt3~2), хотя зачем понадобилась
такая странная логика, я не знаю.

> Почему там еще раз проверяется является ли файл /boot/vmlinuz?

Чтобы не обновить дважды (commit 0.4.10-alt3^0).


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

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

Hi Dmitry!

On 09/06/2017, at 04:37:35 PM you wrote:

<skip>
> Получается, что здесь достаточно написать ucode_detected=1,
> 
> > +			;;
> >  	esac
> >  done
> 
> А сюда поместить сброс ucode_detected в случае, если он уже был обработан.
> 
> > -if [ -n "$kernel_versions_handled" -a "$INITRD_AUTOUPDATE" = all ]; then
> > +if [ -n "$kernel_versions_handled" -o -n "$ucode_handled" ] && [ "$INITRD_AUTOUPDATE" = all ]; then
> >  	set +f
> >  	ls -c $VMLINUZ_PREFIX-[0-9].*-*-* 2> /dev/null | while read f; do
> >  		[ "$f" != "$(readlink -e /boot/vmlinuz)" ] ||
> 
> 
Тогда все можно сделать еще проще, см. патч.

-- 
WBR et al.

[-- Attachment #2: 0001-kernel.filetrigger-ucode-support.patch --]
[-- Type: text/x-patch, Size: 1638 bytes --]

>From 2c6c138d7240ccd2301bcd25270e37379033f79f Mon Sep 17 00:00:00 2001
From: "Konstantin A. Lepikhov" <lakostis@altlinux.ru>
Date: Wed, 6 Sep 2017 13:49:26 +0200
Subject: [PATCH] kernel.filetrigger: ucode support

We need to rebuild initramfs on CPU ucode changes otherwise everything
will continue use outdated version till next kernel update.
---
 kernel.filetrigger | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/kernel.filetrigger b/kernel.filetrigger
index 9cdf01e..3f14faf 100755
--- a/kernel.filetrigger
+++ b/kernel.filetrigger
@@ -9,6 +9,7 @@
 BOOTDIR=/boot
 VMLINUZ_PREFIX=/boot/vmlinuz
 MODULES_PREFIX=/lib/modules
+UCODE_PREFIX=/lib/firmware
 INITRD_AUTOUPDATE=
 
 . /etc/sysconfig/installkernel
@@ -99,6 +100,7 @@ $VERSION"
 	last_added="$VERSION"
 }
 
+ucode_detected=
 while read f; do
 	case "$f" in
 		$VMLINUZ_PREFIX-[0-9].*-*-*)
@@ -107,6 +109,9 @@ while read f; do
 		$MODULES_PREFIX/*-*-*/*/*.ko*)
 			handle_module "$f"
 			;;
+		$UCODE_PREFIX/*-ucode/*)
+			ucode_detected=1
+			;;
 	esac
 done
 
@@ -119,6 +124,10 @@ if [ -n "$kernel_versions_handled" -a "$INITRD_AUTOUPDATE" = all ]; then
 		# regenerate initrd image without updating symlinks
 		/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
 	done
+elif [ -n "$ucode_detected" ]; then
+	VERSION=$(uname -r)
+	# regenerate initrd image without updating symlinks
+	/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
 elif [ -n "$module_versions_handled" ]; then
 	module_versions_handled="$(printf '%s\n' "$module_versions_handled" |sort -u)"
 	for m in $module_versions_handled; do
-- 
2.10.4

Re: [devel] Q: postinst hook for firmware-*

[Dmitry V. Levin]

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

On Thu, Sep 07, 2017 at 09:47:27AM +0200, Konstantin Lepikhov wrote:
> Тогда все можно сделать еще проще, см. патч.
[...]
> @@ -119,6 +124,10 @@ if [ -n "$kernel_versions_handled" -a "$INITRD_AUTOUPDATE" = all ]; then
>  		# regenerate initrd image without updating symlinks
>  		/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
>  	done
> +elif [ -n "$ucode_detected" ]; then
> +	VERSION=$(uname -r)
> +	# regenerate initrd image without updating symlinks
> +	/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
>  elif [ -n "$module_versions_handled" ]; then

Обработка варианта $ucode_detected не должна исключать обработку
$module_versions_handled, в остальном выглядит правдоподобно.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

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

Hi Dmitry!

On 09/07/2017, at 12:28:31 PM you wrote:

> On Thu, Sep 07, 2017 at 09:47:27AM +0200, Konstantin Lepikhov wrote:
> > Тогда все можно сделать еще проще, см. патч.
> [...]
> > @@ -119,6 +124,10 @@ if [ -n "$kernel_versions_handled" -a "$INITRD_AUTOUPDATE" = all ]; then
> >  		# regenerate initrd image without updating symlinks
> >  		/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
> >  	done
> > +elif [ -n "$ucode_detected" ]; then
> > +	VERSION=$(uname -r)
> > +	# regenerate initrd image without updating symlinks
> > +	/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
> >  elif [ -n "$module_versions_handled" ]; then
> 
> Обработка варианта $ucode_detected не должна исключать обработку
> $module_versions_handled, в остальном выглядит правдоподобно.
Понял, прикладываю исправленный вариант.

-- 
WBR et al.

[-- Attachment #2: 0001-kernel.filetrigger-ucode-support.patch --]
[-- Type: text/x-patch, Size: 1823 bytes --]

>From aa8d4bf741fbb36c90231ec8a57a9d431c595dbe Mon Sep 17 00:00:00 2001
From: "Konstantin A. Lepikhov" <lakostis@altlinux.ru>
Date: Wed, 6 Sep 2017 13:49:26 +0200
Subject: [PATCH] kernel.filetrigger: ucode support

We need to rebuild initramfs on CPU ucode changes otherwise everything
will continue use outdated version till next kernel update.
---
 kernel.filetrigger | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/kernel.filetrigger b/kernel.filetrigger
index 9cdf01e..0a07292 100755
--- a/kernel.filetrigger
+++ b/kernel.filetrigger
@@ -9,6 +9,7 @@
 BOOTDIR=/boot
 VMLINUZ_PREFIX=/boot/vmlinuz
 MODULES_PREFIX=/lib/modules
+UCODE_PREFIX=/lib/firmware
 INITRD_AUTOUPDATE=
 
 . /etc/sysconfig/installkernel
@@ -99,6 +100,7 @@ $VERSION"
 	last_added="$VERSION"
 }
 
+ucode_detected=
 while read f; do
 	case "$f" in
 		$VMLINUZ_PREFIX-[0-9].*-*-*)
@@ -107,6 +109,9 @@ while read f; do
 		$MODULES_PREFIX/*-*-*/*/*.ko*)
 			handle_module "$f"
 			;;
+		$UCODE_PREFIX/*-ucode/*)
+			ucode_detected=1
+			;;
 	esac
 done
 
@@ -119,7 +124,13 @@ if [ -n "$kernel_versions_handled" -a "$INITRD_AUTOUPDATE" = all ]; then
 		# regenerate initrd image without updating symlinks
 		/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
 	done
-elif [ -n "$module_versions_handled" ]; then
+elif [ -n "$module_versions_handled" -o -n "$ucode_detected" ]; then
+	if [ -n "$ucode_detected" ]; then
+		VERSION=$(uname -r)
+		# regenerate initrd image without updating symlinks
+		/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
+	fi
+	[ -n "$module_versions_handled" ] || exit 0
 	module_versions_handled="$(printf '%s\n' "$module_versions_handled" |sort -u)"
 	for m in $module_versions_handled; do
 		for k in $kernel_versions_handled; do
-- 
2.10.4

Re: [devel] Q: postinst hook for firmware-*

[Dmitry V. Levin]

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

On Thu, Sep 07, 2017 at 12:17:43PM +0200, Konstantin Lepikhov wrote:
> Hi Dmitry!
> 
> On 09/07/2017, at 12:28:31 PM you wrote:
> 
> > On Thu, Sep 07, 2017 at 09:47:27AM +0200, Konstantin Lepikhov wrote:
> > > Тогда все можно сделать еще проще, см. патч.
> > [...]
> > > @@ -119,6 +124,10 @@ if [ -n "$kernel_versions_handled" -a "$INITRD_AUTOUPDATE" = all ]; then
> > >  		# regenerate initrd image without updating symlinks
> > >  		/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
> > >  	done
> > > +elif [ -n "$ucode_detected" ]; then
> > > +	VERSION=$(uname -r)
> > > +	# regenerate initrd image without updating symlinks
> > > +	/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
> > >  elif [ -n "$module_versions_handled" ]; then
> > 
> > Обработка варианта $ucode_detected не должна исключать обработку
> > $module_versions_handled, в остальном выглядит правдоподобно.
> Понял, прикладываю исправленный вариант.
> 
> -- 
> WBR et al.

> >From aa8d4bf741fbb36c90231ec8a57a9d431c595dbe Mon Sep 17 00:00:00 2001
> From: "Konstantin A. Lepikhov" <lakostis@altlinux.ru>
> Date: Wed, 6 Sep 2017 13:49:26 +0200
> Subject: [PATCH] kernel.filetrigger: ucode support
> 
> We need to rebuild initramfs on CPU ucode changes otherwise everything
> will continue use outdated version till next kernel update.
> ---
>  kernel.filetrigger | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel.filetrigger b/kernel.filetrigger
> index 9cdf01e..0a07292 100755
> --- a/kernel.filetrigger
> +++ b/kernel.filetrigger
> @@ -9,6 +9,7 @@
>  BOOTDIR=/boot
>  VMLINUZ_PREFIX=/boot/vmlinuz
>  MODULES_PREFIX=/lib/modules
> +UCODE_PREFIX=/lib/firmware
>  INITRD_AUTOUPDATE=
>  
>  . /etc/sysconfig/installkernel
> @@ -99,6 +100,7 @@ $VERSION"
>  	last_added="$VERSION"
>  }
>  
> +ucode_detected=
>  while read f; do
>  	case "$f" in
>  		$VMLINUZ_PREFIX-[0-9].*-*-*)
> @@ -107,6 +109,9 @@ while read f; do
>  		$MODULES_PREFIX/*-*-*/*/*.ko*)
>  			handle_module "$f"
>  			;;
> +		$UCODE_PREFIX/*-ucode/*)
> +			ucode_detected=1
> +			;;
>  	esac
>  done
>  
> @@ -119,7 +124,13 @@ if [ -n "$kernel_versions_handled" -a "$INITRD_AUTOUPDATE" = all ]; then
>  		# regenerate initrd image without updating symlinks
>  		/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
>  	done
> -elif [ -n "$module_versions_handled" ]; then
> +elif [ -n "$module_versions_handled" -o -n "$ucode_detected" ]; then
> +	if [ -n "$ucode_detected" ]; then
> +		VERSION=$(uname -r)
> +		# regenerate initrd image without updating symlinks
> +		/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
> +	fi

Что-то я сразу не спросил: для какого ядра хочется обновить initrd
при обновлении ucode? текущее, как написано в патче?
то, на которое /boot/vmlinuz указывает?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

Hi Dmitry!

On 09/09/2017, at 12:01:37 AM you wrote:

> Что-то я сразу не спросил: для какого ядра хочется обновить initrd
> при обновлении ucode? текущее, как написано в патче?
> то, на которое /boot/vmlinuz указывает?
конечно текущее - для новых ядер ucode подхватится сам. Текущий
kernel.trigger не учитывает как раз случай, когда новый ucode приехал, а
ядра остались старые. 

-- 
WBR et al.

Re: [devel] Q: postinst hook for firmware-*

[Mikhail Efremov]

On Sat, 9 Sep 2017 00:06:53 +0200 Konstantin Lepikhov wrote:
> Hi Dmitry!
> 
> On 09/09/2017, at 12:01:37 AM you wrote:
> 
> > Что-то я сразу не спросил: для какого ядра хочется обновить initrd
> > при обновлении ucode? текущее, как написано в патче?
> > то, на которое /boot/vmlinuz указывает?  
> конечно текущее - для новых ядер ucode подхватится сам. Текущий
> kernel.trigger не учитывает как раз случай, когда новый ucode
> приехал, а ядра остались старые. 

По умолчанию это правильное поведение, наверно. Но должна быть
возможность это выключить. Потому что я не хочу, чтобы initrd, с
которым я уже загрузился и, с достаточно большой вероятностью, смогу
загрузиться опять, менялся на новый, с которым получится ли
загрузиться - неизвестно. Я сам перегенерю initrd, если нужно. Обычно
же вообще не нужно, потому что на момент перезагрузки чаще всего уже
есть более свежее ядро с новым initrd.
Должно быть какое-то специально значение переменной INITRD_AUTOUPDATE,
что-нибудь типа INITRD_AUTOUPDATE=nevermore.

-- 
WBR, Mikhail Efremov

Re: [devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

Hi Mikhail!

On 22-11-17, at 02:23:51  you wrote:

> On Sat, 9 Sep 2017 00:06:53 +0200 Konstantin Lepikhov wrote:
> > Hi Dmitry!
> > 
> > On 09/09/2017, at 12:01:37 AM you wrote:
> > 
> > > Что-то я сразу не спросил: для какого ядра хочется обновить initrd
> > > при обновлении ucode? текущее, как написано в патче?
> > > то, на которое /boot/vmlinuz указывает?  
> > конечно текущее - для новых ядер ucode подхватится сам. Текущий
> > kernel.trigger не учитывает как раз случай, когда новый ucode
> > приехал, а ядра остались старые. 
> 
> По умолчанию это правильное поведение, наверно. Но должна быть
> возможность это выключить. Потому что я не хочу, чтобы initrd, с
> которым я уже загрузился и, с достаточно большой вероятностью, смогу
> загрузиться опять, менялся на новый, с которым получится ли
> загрузиться - неизвестно. Я сам перегенерю initrd, если нужно. Обычно
> же вообще не нужно, потому что на момент перезагрузки чаще всего уже
> есть более свежее ядро с новым initrd.
> Должно быть какое-то специально значение переменной INITRD_AUTOUPDATE,
> что-нибудь типа INITRD_AUTOUPDATE=nevermore.
> 
Feel free to add. Хотя мне интересно, вы сами сталкивались с такой
ситуацией, когда обновление microcode ломало загрузку?

-- 
WBR et al.

Re: [devel] Q: postinst hook for firmware-*

[Sergey Afonin]

On Thursday 23 November 2017, Konstantin Lepikhov wrote:

> > Должно быть какое-то специально значение переменной INITRD_AUTOUPDATE,
> > что-нибудь типа INITRD_AUTOUPDATE=nevermore.
> > 
> Feel free to add. Хотя мне интересно, вы сами сталкивались с такой
> ситуацией, когда обновление microcode ломало загрузку?
 
Можно допустить какой-то случай поломки make-initrd например. Одно дело,
когда мы получили проблему с initrd для нового ядра и можем подконтрольно
проверить и откатиться, а совсем другое - это когда сервер не перегрузился
в момент случайной аварии, и надо куда-то мчаться.

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: postinst hook for firmware-*

[Mikhail Efremov]

On Thu, 23 Nov 2017 12:55:42 +0100 Konstantin Lepikhov wrote:
> Hi Mikhail!
> 
> On 22-11-17, at 02:23:51  you wrote:
> 
> > On Sat, 9 Sep 2017 00:06:53 +0200 Konstantin Lepikhov wrote:  
> > > Hi Dmitry!
> > > 
> > > On 09/09/2017, at 12:01:37 AM you wrote:
> > >   
> > > > Что-то я сразу не спросил: для какого ядра хочется обновить initrd
> > > > при обновлении ucode? текущее, как написано в патче?
> > > > то, на которое /boot/vmlinuz указывает?    
> > > конечно текущее - для новых ядер ucode подхватится сам. Текущий
> > > kernel.trigger не учитывает как раз случай, когда новый ucode
> > > приехал, а ядра остались старые.   
> > 
> > По умолчанию это правильное поведение, наверно. Но должна быть
> > возможность это выключить. Потому что я не хочу, чтобы initrd, с
> > которым я уже загрузился и, с достаточно большой вероятностью, смогу
> > загрузиться опять, менялся на новый, с которым получится ли
> > загрузиться - неизвестно. Я сам перегенерю initrd, если нужно. Обычно
> > же вообще не нужно, потому что на момент перезагрузки чаще всего уже
> > есть более свежее ядро с новым initrd.
> > Должно быть какое-то специально значение переменной INITRD_AUTOUPDATE,
> > что-нибудь типа INITRD_AUTOUPDATE=nevermore.
> >   
> Feel free to add. Хотя мне интересно, вы сами сталкивались с такой
> ситуацией, когда обновление microcode ломало загрузку?

Дело не в обновлении microcode, а в том, что меняется initrd. И если по
каким-то причинам новый initrd оказался не рабочим, то загрузиться с
текущим ядром уже не получится. Да, бывает обратная ситуация, когда
нужно перегенерить initrd, но такие случаи более-менее предсказуемы,
думаю.

-- 
WBR, Mikhail Efremov

Re: [devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

Hi Mikhail!

On 23-11-17, at 04:56:03  you wrote:

> On Thu, 23 Nov 2017 12:55:42 +0100 Konstantin Lepikhov wrote:
> > Hi Mikhail!
> > 
> > On 22-11-17, at 02:23:51  you wrote:
> > 
> > > On Sat, 9 Sep 2017 00:06:53 +0200 Konstantin Lepikhov wrote:  
> > > > Hi Dmitry!
> > > > 
> > > > On 09/09/2017, at 12:01:37 AM you wrote:
> > > >   
> > > > > Что-то я сразу не спросил: для какого ядра хочется обновить initrd
> > > > > при обновлении ucode? текущее, как написано в патче?
> > > > > то, на которое /boot/vmlinuz указывает?    
> > > > конечно текущее - для новых ядер ucode подхватится сам. Текущий
> > > > kernel.trigger не учитывает как раз случай, когда новый ucode
> > > > приехал, а ядра остались старые.   
> > > 
> > > По умолчанию это правильное поведение, наверно. Но должна быть
> > > возможность это выключить. Потому что я не хочу, чтобы initrd, с
> > > которым я уже загрузился и, с достаточно большой вероятностью, смогу
> > > загрузиться опять, менялся на новый, с которым получится ли
> > > загрузиться - неизвестно. Я сам перегенерю initrd, если нужно. Обычно
> > > же вообще не нужно, потому что на момент перезагрузки чаще всего уже
> > > есть более свежее ядро с новым initrd.
> > > Должно быть какое-то специально значение переменной INITRD_AUTOUPDATE,
> > > что-нибудь типа INITRD_AUTOUPDATE=nevermore.
> > >   
> > Feel free to add. Хотя мне интересно, вы сами сталкивались с такой
> > ситуацией, когда обновление microcode ломало загрузку?
> 
> Дело не в обновлении microcode, а в том, что меняется initrd. И если по
> каким-то причинам новый initrd оказался не рабочим, то загрузиться с
> текущим ядром уже не получится. Да, бывает обратная ситуация, когда
> нужно перегенерить initrd, но такие случаи более-менее предсказуемы,
> думаю.
> 
Для mission critical вещей есть такая вещь как monolitic kernel.
Железобетонно и предсказуемо.

-- 
WBR et al.

Re: [devel] Q: postinst hook for firmware-*

[Mikhail Efremov]

On Thu, 23 Nov 2017 15:22:36 +0100 Konstantin Lepikhov wrote:
> Hi Mikhail!
> 
> On 23-11-17, at 04:56:03  you wrote:
> 
> > On Thu, 23 Nov 2017 12:55:42 +0100 Konstantin Lepikhov wrote:  
> > > Hi Mikhail!
> > > 
> > > On 22-11-17, at 02:23:51  you wrote:
> > >   
> > > > On Sat, 9 Sep 2017 00:06:53 +0200 Konstantin Lepikhov wrote:    
> > > > > Hi Dmitry!
> > > > > 
> > > > > On 09/09/2017, at 12:01:37 AM you wrote:
> > > > >     
> > > > > > Что-то я сразу не спросил: для какого ядра хочется обновить initrd
> > > > > > при обновлении ucode? текущее, как написано в патче?
> > > > > > то, на которое /boot/vmlinuz указывает?      
> > > > > конечно текущее - для новых ядер ucode подхватится сам. Текущий
> > > > > kernel.trigger не учитывает как раз случай, когда новый ucode
> > > > > приехал, а ядра остались старые.     
> > > > 
> > > > По умолчанию это правильное поведение, наверно. Но должна быть
> > > > возможность это выключить. Потому что я не хочу, чтобы initrd, с
> > > > которым я уже загрузился и, с достаточно большой вероятностью, смогу
> > > > загрузиться опять, менялся на новый, с которым получится ли
> > > > загрузиться - неизвестно. Я сам перегенерю initrd, если нужно. Обычно
> > > > же вообще не нужно, потому что на момент перезагрузки чаще всего уже
> > > > есть более свежее ядро с новым initrd.
> > > > Должно быть какое-то специально значение переменной INITRD_AUTOUPDATE,
> > > > что-нибудь типа INITRD_AUTOUPDATE=nevermore.
> > > >     
> > > Feel free to add. Хотя мне интересно, вы сами сталкивались с такой
> > > ситуацией, когда обновление microcode ломало загрузку?  
> > 
> > Дело не в обновлении microcode, а в том, что меняется initrd. И если по
> > каким-то причинам новый initrd оказался не рабочим, то загрузиться с
> > текущим ядром уже не получится. Да, бывает обратная ситуация, когда
> > нужно перегенерить initrd, но такие случаи более-менее предсказуемы,
> > думаю.
> >   
> Для mission critical вещей есть такая вещь как monolitic kernel.
> Железобетонно и предсказуемо.

Мне и на десктопе хочется иметь ядро, с которым можно загрузиться.

-- 
WBR, Mikhail Efremov

Re: [devel] Q: postinst hook for firmware-*

[Dmitry V. Levin]

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

On Thu, Nov 23, 2017 at 07:19:30PM +0300, Mikhail Efremov wrote:
> On Thu, 23 Nov 2017 15:22:36 +0100 Konstantin Lepikhov wrote:
> > Hi Mikhail!
> > 
> > On 23-11-17, at 04:56:03  you wrote:
> > 
> > > On Thu, 23 Nov 2017 12:55:42 +0100 Konstantin Lepikhov wrote:  
> > > > Hi Mikhail!
> > > > 
> > > > On 22-11-17, at 02:23:51  you wrote:
> > > >   
> > > > > On Sat, 9 Sep 2017 00:06:53 +0200 Konstantin Lepikhov wrote:    
> > > > > > Hi Dmitry!
> > > > > > 
> > > > > > On 09/09/2017, at 12:01:37 AM you wrote:
> > > > > >     
> > > > > > > Что-то я сразу не спросил: для какого ядра хочется обновить initrd
> > > > > > > при обновлении ucode? текущее, как написано в патче?
> > > > > > > то, на которое /boot/vmlinuz указывает?      
> > > > > > конечно текущее - для новых ядер ucode подхватится сам. Текущий
> > > > > > kernel.trigger не учитывает как раз случай, когда новый ucode
> > > > > > приехал, а ядра остались старые.     
> > > > > 
> > > > > По умолчанию это правильное поведение, наверно. Но должна быть
> > > > > возможность это выключить. Потому что я не хочу, чтобы initrd, с
> > > > > которым я уже загрузился и, с достаточно большой вероятностью, смогу
> > > > > загрузиться опять, менялся на новый, с которым получится ли
> > > > > загрузиться - неизвестно. Я сам перегенерю initrd, если нужно. Обычно
> > > > > же вообще не нужно, потому что на момент перезагрузки чаще всего уже
> > > > > есть более свежее ядро с новым initrd.
> > > > > Должно быть какое-то специально значение переменной INITRD_AUTOUPDATE,
> > > > > что-нибудь типа INITRD_AUTOUPDATE=nevermore.
> > > > >     
> > > > Feel free to add. Хотя мне интересно, вы сами сталкивались с такой
> > > > ситуацией, когда обновление microcode ломало загрузку?  
> > > 
> > > Дело не в обновлении microcode, а в том, что меняется initrd. И если по
> > > каким-то причинам новый initrd оказался не рабочим, то загрузиться с
> > > текущим ядром уже не получится. Да, бывает обратная ситуация, когда
> > > нужно перегенерить initrd, но такие случаи более-менее предсказуемы,
> > > думаю.
> > >   
> > Для mission critical вещей есть такая вещь как monolitic kernel.
> > Железобетонно и предсказуемо.
> 
> Мне и на десктопе хочется иметь ядро, с которым можно загрузиться.

Предложение: генерить новые initrd на каждый чих, но при этом хранить *все*
сгенерённые initrd до тех пор, пока хранится их ядро.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Michael Shigorin]

On Thu, Nov 23, 2017 at 09:15:50PM +0300, Dmitry V. Levin wrote:
> Предложение: генерить новые initrd на каждый чих, но при этом
> хранить *все* сгенерённые initrd до тех пор, пока хранится их
> ядро.

Возможно, достаточно при загрузке хардлинкать в сторонку текущие
vmlinuz+initrd.img, при этом "сторонку" можно даже в загрузчик
штатно прописать как "last bootable" или вроде того.

Если /boot не r/o, разумеется.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Q: postinst hook for firmware-*

[Sergey Afonin]

On Thursday 23 November 2017, Dmitry V. Levin wrote:

> > Мне и на десктопе хочется иметь ядро, с которым можно загрузиться.
> 
> Предложение: генерить новые initrd на каждый чих, но при этом 
> хранить *все* сгенерённые initrd до тех пор, пока хранится их ядро.

Тут суть в том, что по внезапному reboot/reset должен загрузиться
тот initrd, с которым уже когда-то загружались, а не тот, который
никогда не проверяли.

-- 
С уважением, Сергей Афонин.

Re: [devel] Q: postinst hook for firmware-*

[Alexey Gladkov]

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

On Fri, Nov 24, 2017 at 12:46:54PM +0400, Sergey Afonin wrote:
> Тут суть в том, что по внезапному reboot/reset должен загрузиться
> тот initrd, с которым уже когда-то загружались, а не тот, который
> никогда не проверяли.

Для этого в некоторых системах есть понятие "последнее загрузившееся". Это
можно сделать и у нас путём обновления симлинка в /boot после успешной
загрузки. Вопрос в том, что считать успешной загрузкой т.к. очевидно что
доступный корень это не достаточное условие.

-- 
Rgrds, legion


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Sergey Y. Afonin]

On Thursday 23 November 2017, Konstantin Lepikhov wrote:

> Для mission critical вещей есть такая вещь как monolitic kernel.
> Железобетонно и предсказуемо.

Вообще-то ALT на сервера ставят. И текущее состояние вполне себе
железобетонно и предсказуемо, как и monolitic kernel.

-- 
С уважением, Сергей Афонин

Re: [devel] Q: postinst hook for firmware-*

[Michael Shigorin]

On Thu, Nov 23, 2017 at 03:22:36PM +0100, Konstantin Lepikhov wrote:
> > Дело не в обновлении microcode, а в том, что меняется initrd.
> > И если по каким-то причинам новый initrd оказался не рабочим,
> > то загрузиться с текущим ядром уже не получится. Да, бывает
> > обратная ситуация, когда нужно перегенерить initrd, но такие
> > случаи более-менее предсказуемы, думаю.
> Для mission critical вещей есть такая вещь как monolitic kernel.
> Железобетонно и предсказуемо.

Это другая крайность.

Мне кажется, что не следует перекладывать риск тех, кому не пофиг
на микрокод, на всех.  У всех, кому не пофиг на ядро, оно обновится 
(вместе со штатной и _ожидаемой_ перегенерацией initrd) примерно
в течение недели.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Q: postinst hook for firmware-*

[Anton Farygin]

23.11.2017 21:08, Michael Shigorin пишет:
> On Thu, Nov 23, 2017 at 03:22:36PM +0100, Konstantin Lepikhov wrote:
>>> Дело не в обновлении microcode, а в том, что меняется initrd.
>>> И если по каким-то причинам новый initrd оказался не рабочим,
>>> то загрузиться с текущим ядром уже не получится. Да, бывает
>>> обратная ситуация, когда нужно перегенерить initrd, но такие
>>> случаи более-менее предсказуемы, думаю.
>> Для mission critical вещей есть такая вещь как monolitic kernel.
>> Железобетонно и предсказуемо.
> Это другая крайность.
>
> Мне кажется, что не следует перекладывать риск тех, кому не пофиг
> на микрокод, на всех.  У всех, кому не пофиг на ядро, оно обновится
> (вместе со штатной и _ожидаемой_ перегенерацией initrd) примерно
> в течение недели.
>
Конечно, микрокод хотелось бы обновить как можно быстрее.


По мне так будет достаточно вывести после установки обновления микрокода 
сообщение о том, что нужно перегенерить initrd.

Re: [devel] Q: postinst hook for firmware-*

[Sergey Y. Afonin]

On Thursday 23 November 2017, Anton Farygin wrote:

> По мне так будет достаточно вывести после установки обновления
> микрокода сообщение о том, что нужно перегенерить initrd.
 
Да, вот это не повредит. И можно, сразу, готовую строчку для 
исполнения в консоли подсказывать.

Кстати, что-то менять в initrd, но неперезагружаться при этом - это
же бессмысленно ?

-- 
С уважением, Сергей Афонин

Re: [devel] Q: postinst hook for firmware-*

[Konstantin Lepikhov]

Hi Michael!

On 23-11-17, at 09:08:58  you wrote:

> On Thu, Nov 23, 2017 at 03:22:36PM +0100, Konstantin Lepikhov wrote:
> > > Дело не в обновлении microcode, а в том, что меняется initrd.
> > > И если по каким-то причинам новый initrd оказался не рабочим,
> > > то загрузиться с текущим ядром уже не получится. Да, бывает
> > > обратная ситуация, когда нужно перегенерить initrd, но такие
> > > случаи более-менее предсказуемы, думаю.
> > Для mission critical вещей есть такая вещь как monolitic kernel.
> > Железобетонно и предсказуемо.
> 
> Это другая крайность.
> 
> Мне кажется, что не следует перекладывать риск тех, кому не пофиг
> на микрокод, на всех.  У всех, кому не пофиг на ядро, оно обновится 
> (вместе со штатной и _ожидаемой_ перегенерацией initrd) примерно
> в течение недели.
> 
Это все прекрасно и замечательно, но:
- Добавленный функционал по микрокоду это просто логическое продолжение
  того, что делает триггер сейчас - а именно поддерживает initrd в
  актуальном состоянии.

см. код

$ cat ~/git/work/bootloader-utils/kernel.filetrigger
...
ucode_detected=
while read f; do
	case "$f" in
	...
		$UCODE_PREFIX/*-ucode/*)
			ucode_detected=1
			;;
	esac
done
...
	if [ -n "$ucode_detected" ]; then
		VERSION=$(uname -r)
		# regenerate initrd image without updating symlinks
		/sbin/installkernel $INSTALLKERNEL_ARGS --nodefault --noflavour "$VERSION"
	fi
...

Да, initrd пересоздается, но для текущего ядра и пересоздается возможно
тем же самым make-inird которым он создавался изначально. И в системе есть
другие ядра, и initrd для них остается нетронутым. Если же ядро одно, то я
не знаю, это редкий случай.

Да, можно вынести эту логику в отдельный триггер, который будет ставиться
вместе с make-initrd-ucode чтобы всем было хорошо, но мне не хочется
дублировать код.

PS В тему "а вдруг что": давайте тогда придумаем механизм сохранения
  предыдущей версии systemd после обновления, он знаете ли вашу систему
  так поломать может при обновлении, никакой initrd не спасет. Не далее
  как раз такое случилось - #ALT 34193

-- 
WBR et al.

Re: [devel] Q: postinst hook for firmware-*

[Dmitry V. Levin]

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

Hi,

On Fri, Nov 24, 2017 at 12:06:35AM +0100, Konstantin Lepikhov wrote:
> Hi Michael!
> 
> On 23-11-17, at 09:08:58  you wrote:
> 
> > On Thu, Nov 23, 2017 at 03:22:36PM +0100, Konstantin Lepikhov wrote:
> > > > Дело не в обновлении microcode, а в том, что меняется initrd.
> > > > И если по каким-то причинам новый initrd оказался не рабочим,
> > > > то загрузиться с текущим ядром уже не получится. Да, бывает
> > > > обратная ситуация, когда нужно перегенерить initrd, но такие
> > > > случаи более-менее предсказуемы, думаю.
> > > Для mission critical вещей есть такая вещь как monolitic kernel.
> > > Железобетонно и предсказуемо.
> > 
> > Это другая крайность.
> > 
> > Мне кажется, что не следует перекладывать риск тех, кому не пофиг
> > на микрокод, на всех.  У всех, кому не пофиг на ядро, оно обновится 
> > (вместе со штатной и _ожидаемой_ перегенерацией initrd) примерно
> > в течение недели.
> > 
> Это все прекрасно и замечательно, но:
> - Добавленный функционал по микрокоду это просто логическое продолжение
>   того, что делает триггер сейчас - а именно поддерживает initrd в
>   актуальном состоянии.

Я бы пошёл ещё дальше и обновлял бы initrd всякий раз, когда в основной
системе обновляется что-либо из того, что включено в initrd.
Правда, для того, чтобы это более-менее корректно реализовать, придётся
научить make-initrd складировать информацию о файлах, скопированных
в initrd.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Alexey Gladkov]

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

On Fri, Nov 24, 2017 at 02:41:05AM +0300, Dmitry V. Levin wrote:
> Я бы пошёл ещё дальше и обновлял бы initrd всякий раз, когда в основной
> системе обновляется что-либо из того, что включено в initrd.
> Правда, для того, чтобы это более-менее корректно реализовать, придётся
> научить make-initrd складировать информацию о файлах, скопированных
> в initrd.

Это совсем не сложно.

Куда положить список файлов ?

-- 
Rgrds, legion


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Dmitry V. Levin]

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

On Fri, Nov 24, 2017 at 01:43:59AM +0100, Alexey Gladkov wrote:
> On Fri, Nov 24, 2017 at 02:41:05AM +0300, Dmitry V. Levin wrote:
> > Я бы пошёл ещё дальше и обновлял бы initrd всякий раз, когда в основной
> > системе обновляется что-либо из того, что включено в initrd.
> > Правда, для того, чтобы это более-менее корректно реализовать, придётся
> > научить make-initrd складировать информацию о файлах, скопированных
> > в initrd.
> 
> Это совсем не сложно.
> 
> Куда положить список файлов ?

Первое, что приходит в голову - это /var/lib/initrd/${initrd%.img}.in


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] Q: postinst hook for firmware-*

[Alexey Gladkov]

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

On Fri, Nov 24, 2017 at 04:41:26AM +0300, Dmitry V. Levin wrote:
> On Fri, Nov 24, 2017 at 01:43:59AM +0100, Alexey Gladkov wrote:
> > On Fri, Nov 24, 2017 at 02:41:05AM +0300, Dmitry V. Levin wrote:
> > > Я бы пошёл ещё дальше и обновлял бы initrd всякий раз, когда в основной
> > > системе обновляется что-либо из того, что включено в initrd.
> > > Правда, для того, чтобы это более-менее корректно реализовать, придётся
> > > научить make-initrd складировать информацию о файлах, скопированных
> > > в initrd.
> > 
> > Это совсем не сложно.
> > 
> > Куда положить список файлов ?
> 
> Первое, что приходит в голову - это /var/lib/initrd/${initrd%.img}.in

Добавил фичу и теперь для всех у кого в /etc/initrd.mk есть
`FEATURES += imagelog` будет сохраняться список файлов и фич.

http://git.altlinux.org/people/legion/packages/make-initrd.git?p=make-initrd.git;a=commit;h=82a3161c2ae3a1eae7f1b75c0b0aedaef1087659

-- 
Rgrds, legion


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [devel] Q: agp modules in initrd ?

[Anton Farygin]

24.11.2017 03:43, Alexey Gladkov пишет:
> On Fri, Nov 24, 2017 at 02:41:05AM +0300, Dmitry V. Levin wrote:
>> Я бы пошёл ещё дальше и обновлял бы initrd всякий раз, когда в основной
>> системе обновляется что-либо из того, что включено в initrd.
>> Правда, для того, чтобы это более-менее корректно реализовать, придётся
>> научить make-initrd складировать информацию о файлах, скопированных
>> в initrd.
> Это совсем не сложно.
>
> Куда положить список файлов ?
>
Кстати, уж коль пошла речь про initrd, пока вспомнил - может быть знаешь 
почему в наш initrd попадают все -agp модули ?

Вот, для примера, на моём xps 9560:

Packed modules: autofs4 button crc16 drm drm_kms_helper evdev ext4 
fscrypto hid hid-generic i2c-algo-bit i2c-core i915 input-leds intel-agp 
intel-gtt jbd2 mbcache nvme nvme-core serio_raw shpchp sis-agp via-agp 
video

Технически конечно их никто не должен загрузить, но всё-таки странно. 
autofs4 тоже непонятно каким образом туда влетел.

Re: [devel] Q: agp modules in initrd ?

[Alexey Gladkov]

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

On Fri, Nov 24, 2017 at 07:37:21AM +0300, Anton Farygin wrote:
> Кстати, уж коль пошла речь про initrd, пока вспомнил - может быть знаешь 
> почему в наш initrd попадают все -agp модули ?
> 
> Вот, для примера, на моём xps 9560:
> 
> Packed modules: autofs4 button crc16 drm drm_kms_helper evdev ext4 
> fscrypto hid hid-generic i2c-algo-bit i2c-core i915 input-leds intel-agp 
> intel-gtt jbd2 mbcache nvme nvme-core serio_raw shpchp sis-agp via-agp 
> video
> 
> Технически конечно их никто не должен загрузить, но всё-таки странно. 
> autofs4 тоже непонятно каким образом туда влетел.

Покажи пожалуйста вывод команд:

make-initrd guess-modules /
make-initrd guess-config 

-- 
Rgrds, legion


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [devel] Q: agp modules in initrd ?

[Anton Farygin]

24.11.2017 13:06, Alexey Gladkov пишет:
> On Fri, Nov 24, 2017 at 07:37:21AM +0300, Anton Farygin wrote:
>> Кстати, уж коль пошла речь про initrd, пока вспомнил - может быть знаешь
>> почему в наш initrd попадают все -agp модули ?
>>
>> Вот, для примера, на моём xps 9560:
>>
>> Packed modules: autofs4 button crc16 drm drm_kms_helper evdev ext4
>> fscrypto hid hid-generic i2c-algo-bit i2c-core i915 input-leds intel-agp
>> intel-gtt jbd2 mbcache nvme nvme-core serio_raw shpchp sis-agp via-agp
>> video
>>
>> Технически конечно их никто не должен загрузить, но всё-таки странно.
>> autofs4 тоже непонятно каким образом туда влетел.
> Покажи пожалуйста вывод команд:
>
> make-initrd guess-modules /
> make-initrd guess-config
>
# make-initrd guess-modules /
Generating module dependencies on host ...
/lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme-core.ko
/lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme.ko
/lib/modules/4.13.14-un-def-alt1/kernel/drivers/pci/hotplug/shpchp.ko
/lib/modules/4.13.14-un-def-alt1/kernel/fs/crypto/fscrypto.ko
/lib/modules/4.13.14-un-def-alt1/kernel/fs/ext4/ext4.ko
/lib/modules/4.13.14-un-def-alt1/kernel/fs/jbd2/jbd2.ko
/lib/modules/4.13.14-un-def-alt1/kernel/fs/mbcache.ko
/lib/modules/4.13.14-un-def-alt1/kernel/lib/crc16.ko
# make-initrd guess-config
Generating module dependencies on host ...
RESCUE_MODULES += \
         hid-generic hid evdev input-leds serio_raw

MODULES_ADD += \
         ext4 nvme-core nvme shpchp

FEATURES += \
         add-modules cleanup compress fstab rdshell sysvinit ucode

Re: [devel] Q: agp modules in initrd ?

[Alexey Gladkov]

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

On Fri, Nov 24, 2017 at 01:32:04PM +0300, Anton Farygin wrote:
> 24.11.2017 13:06, Alexey Gladkov пишет:
> > On Fri, Nov 24, 2017 at 07:37:21AM +0300, Anton Farygin wrote:
> >> Кстати, уж коль пошла речь про initrd, пока вспомнил - может быть знаешь
> >> почему в наш initrd попадают все -agp модули ?
> >>
> >> Вот, для примера, на моём xps 9560:
> >>
> >> Packed modules: autofs4 button crc16 drm drm_kms_helper evdev ext4
> >> fscrypto hid hid-generic i2c-algo-bit i2c-core i915 input-leds intel-agp
> >> intel-gtt jbd2 mbcache nvme nvme-core serio_raw shpchp sis-agp via-agp
> >> video
> >>
> >> Технически конечно их никто не должен загрузить, но всё-таки странно.
> >> autofs4 тоже непонятно каким образом туда влетел.
> > Покажи пожалуйста вывод команд:
> >
> > make-initrd guess-modules /
> > make-initrd guess-config
> >
> # make-initrd guess-modules /
> Generating module dependencies on host ...
> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme-core.ko
> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme.ko
> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/pci/hotplug/shpchp.ko
> /lib/modules/4.13.14-un-def-alt1/kernel/fs/crypto/fscrypto.ko
> /lib/modules/4.13.14-un-def-alt1/kernel/fs/ext4/ext4.ko
> /lib/modules/4.13.14-un-def-alt1/kernel/fs/jbd2/jbd2.ko
> /lib/modules/4.13.14-un-def-alt1/kernel/fs/mbcache.ko
> /lib/modules/4.13.14-un-def-alt1/kernel/lib/crc16.ko
> # make-initrd guess-config
> Generating module dependencies on host ...
> RESCUE_MODULES += \
>          hid-generic hid evdev input-leds serio_raw
> 
> MODULES_ADD += \
>          ext4 nvme-core nvme shpchp
> 
> FEATURES += \
>          add-modules cleanup compress fstab rdshell sysvinit ucode
> 
> 

Какие дополнительные фичи у тебя подключены ?

-- 
Rgrds, legion


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [devel] Q: agp modules in initrd ?

[Anton Farygin]

24.11.2017 14:15, Alexey Gladkov пишет:
> On Fri, Nov 24, 2017 at 01:32:04PM +0300, Anton Farygin wrote:
>> 24.11.2017 13:06, Alexey Gladkov пишет:
>>> On Fri, Nov 24, 2017 at 07:37:21AM +0300, Anton Farygin wrote:
>>>> Кстати, уж коль пошла речь про initrd, пока вспомнил - может быть знаешь
>>>> почему в наш initrd попадают все -agp модули ?
>>>>
>>>> Вот, для примера, на моём xps 9560:
>>>>
>>>> Packed modules: autofs4 button crc16 drm drm_kms_helper evdev ext4
>>>> fscrypto hid hid-generic i2c-algo-bit i2c-core i915 input-leds intel-agp
>>>> intel-gtt jbd2 mbcache nvme nvme-core serio_raw shpchp sis-agp via-agp
>>>> video
>>>>
>>>> Технически конечно их никто не должен загрузить, но всё-таки странно.
>>>> autofs4 тоже непонятно каким образом туда влетел.
>>> Покажи пожалуйста вывод команд:
>>>
>>> make-initrd guess-modules /
>>> make-initrd guess-config
>>>
>> # make-initrd guess-modules /
>> Generating module dependencies on host ...
>> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme-core.ko
>> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme.ko
>> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/pci/hotplug/shpchp.ko
>> /lib/modules/4.13.14-un-def-alt1/kernel/fs/crypto/fscrypto.ko
>> /lib/modules/4.13.14-un-def-alt1/kernel/fs/ext4/ext4.ko
>> /lib/modules/4.13.14-un-def-alt1/kernel/fs/jbd2/jbd2.ko
>> /lib/modules/4.13.14-un-def-alt1/kernel/fs/mbcache.ko
>> /lib/modules/4.13.14-un-def-alt1/kernel/lib/crc16.ko
>> # make-initrd guess-config
>> Generating module dependencies on host ...
>> RESCUE_MODULES += \
>>           hid-generic hid evdev input-leds serio_raw
>>
>> MODULES_ADD += \
>>           ext4 nvme-core nvme shpchp
>>
>> FEATURES += \
>>           add-modules cleanup compress fstab rdshell sysvinit ucode
>>
>>
> Какие дополнительные фичи у тебя подключены ?
>
Ты про это?
# rpm -qa|grep make-initrd
make-initrd-luks-2.0.5-alt1.x86_64
make-initrd-2.0.5-alt1.x86_64
make-initrd-busybox-1.24.2-alt2.x86_64
make-initrd-lvm-2.0.5-alt1.x86_64
make-initrd-ucode-2.0.5-alt1.x86_64
make-initrd-devmapper-2.0.5-alt1.x86_64
make-initrd-plymouth-2.0.5-alt1.x86_64


# cat /etc/initrd/initrd.mk
# trying to detect modules and features to access to root volume
AUTODETECT = all
FEATURES += plymouth ucode
FEATURES+=systemd
MODULES_PRELOAD+=autofs4

Re: [devel] Q: agp modules in initrd ?

[Alexey Gladkov]

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

On Fri, Nov 24, 2017 at 02:25:49PM +0300, Anton Farygin wrote:
> 24.11.2017 14:15, Alexey Gladkov пишет:
> > On Fri, Nov 24, 2017 at 01:32:04PM +0300, Anton Farygin wrote:
> >> 24.11.2017 13:06, Alexey Gladkov пишет:
> >>> On Fri, Nov 24, 2017 at 07:37:21AM +0300, Anton Farygin wrote:
> >>>> Кстати, уж коль пошла речь про initrd, пока вспомнил - может быть знаешь
> >>>> почему в наш initrd попадают все -agp модули ?
> >>>>
> >>>> Вот, для примера, на моём xps 9560:
> >>>>
> >>>> Packed modules: autofs4 button crc16 drm drm_kms_helper evdev ext4
> >>>> fscrypto hid hid-generic i2c-algo-bit i2c-core i915 input-leds intel-agp
> >>>> intel-gtt jbd2 mbcache nvme nvme-core serio_raw shpchp sis-agp via-agp
> >>>> video
> >>>>
> >>>> Технически конечно их никто не должен загрузить, но всё-таки странно.
> >>>> autofs4 тоже непонятно каким образом туда влетел.
> >>> Покажи пожалуйста вывод команд:
> >>>
> >>> make-initrd guess-modules /
> >>> make-initrd guess-config
> >>>
> >> # make-initrd guess-modules /
> >> Generating module dependencies on host ...
> >> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme-core.ko
> >> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme.ko
> >> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/pci/hotplug/shpchp.ko
> >> /lib/modules/4.13.14-un-def-alt1/kernel/fs/crypto/fscrypto.ko
> >> /lib/modules/4.13.14-un-def-alt1/kernel/fs/ext4/ext4.ko
> >> /lib/modules/4.13.14-un-def-alt1/kernel/fs/jbd2/jbd2.ko
> >> /lib/modules/4.13.14-un-def-alt1/kernel/fs/mbcache.ko
> >> /lib/modules/4.13.14-un-def-alt1/kernel/lib/crc16.ko
> >> # make-initrd guess-config
> >> Generating module dependencies on host ...
> >> RESCUE_MODULES += \
> >>           hid-generic hid evdev input-leds serio_raw
> >>
> >> MODULES_ADD += \
> >>           ext4 nvme-core nvme shpchp
> >>
> >> FEATURES += \
> >>           add-modules cleanup compress fstab rdshell sysvinit ucode
> >>
> >>
> > Какие дополнительные фичи у тебя подключены ?
> >
> Ты про это?
> # rpm -qa|grep make-initrd
> make-initrd-luks-2.0.5-alt1.x86_64
> make-initrd-2.0.5-alt1.x86_64
> make-initrd-busybox-1.24.2-alt2.x86_64
> make-initrd-lvm-2.0.5-alt1.x86_64
> make-initrd-ucode-2.0.5-alt1.x86_64
> make-initrd-devmapper-2.0.5-alt1.x86_64
> make-initrd-plymouth-2.0.5-alt1.x86_64
> 
> 
> # cat /etc/initrd/initrd.mk
> # trying to detect modules and features to access to root volume
> AUTODETECT = all
> FEATURES += plymouth ucode
> FEATURES+=systemd

В сизифе такой фичи нет. А что это за фича если не секрет ?

> MODULES_PRELOAD+=autofs4
> 

Теперь я могу ответить.

> почему в наш initrd попадают все -agp модули ?

Потому что ты используешь plymouth. Эта фича добавляет эти agp модули.

-- 
Rgrds, legion


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [devel] Q: agp modules in initrd ?

[Anton Farygin]

24.11.2017 15:44, Alexey Gladkov пишет:
> On Fri, Nov 24, 2017 at 02:25:49PM +0300, Anton Farygin wrote:
>> 24.11.2017 14:15, Alexey Gladkov пишет:
>>> On Fri, Nov 24, 2017 at 01:32:04PM +0300, Anton Farygin wrote:
>>>> 24.11.2017 13:06, Alexey Gladkov пишет:
>>>>> On Fri, Nov 24, 2017 at 07:37:21AM +0300, Anton Farygin wrote:
>>>>>> Кстати, уж коль пошла речь про initrd, пока вспомнил - может быть знаешь
>>>>>> почему в наш initrd попадают все -agp модули ?
>>>>>>
>>>>>> Вот, для примера, на моём xps 9560:
>>>>>>
>>>>>> Packed modules: autofs4 button crc16 drm drm_kms_helper evdev ext4
>>>>>> fscrypto hid hid-generic i2c-algo-bit i2c-core i915 input-leds intel-agp
>>>>>> intel-gtt jbd2 mbcache nvme nvme-core serio_raw shpchp sis-agp via-agp
>>>>>> video
>>>>>>
>>>>>> Технически конечно их никто не должен загрузить, но всё-таки странно.
>>>>>> autofs4 тоже непонятно каким образом туда влетел.
>>>>> Покажи пожалуйста вывод команд:
>>>>>
>>>>> make-initrd guess-modules /
>>>>> make-initrd guess-config
>>>>>
>>>> # make-initrd guess-modules /
>>>> Generating module dependencies on host ...
>>>> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme-core.ko
>>>> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/nvme/host/nvme.ko
>>>> /lib/modules/4.13.14-un-def-alt1/kernel/drivers/pci/hotplug/shpchp.ko
>>>> /lib/modules/4.13.14-un-def-alt1/kernel/fs/crypto/fscrypto.ko
>>>> /lib/modules/4.13.14-un-def-alt1/kernel/fs/ext4/ext4.ko
>>>> /lib/modules/4.13.14-un-def-alt1/kernel/fs/jbd2/jbd2.ko
>>>> /lib/modules/4.13.14-un-def-alt1/kernel/fs/mbcache.ko
>>>> /lib/modules/4.13.14-un-def-alt1/kernel/lib/crc16.ko
>>>> # make-initrd guess-config
>>>> Generating module dependencies on host ...
>>>> RESCUE_MODULES += \
>>>>            hid-generic hid evdev input-leds serio_raw
>>>>
>>>> MODULES_ADD += \
>>>>            ext4 nvme-core nvme shpchp
>>>>
>>>> FEATURES += \
>>>>            add-modules cleanup compress fstab rdshell sysvinit ucode
>>>>
>>>>
>>> Какие дополнительные фичи у тебя подключены ?
>>>
>> Ты про это?
>> # rpm -qa|grep make-initrd
>> make-initrd-luks-2.0.5-alt1.x86_64
>> make-initrd-2.0.5-alt1.x86_64
>> make-initrd-busybox-1.24.2-alt2.x86_64
>> make-initrd-lvm-2.0.5-alt1.x86_64
>> make-initrd-ucode-2.0.5-alt1.x86_64
>> make-initrd-devmapper-2.0.5-alt1.x86_64
>> make-initrd-plymouth-2.0.5-alt1.x86_64
>>
>>
>> # cat /etc/initrd/initrd.mk
>> # trying to detect modules and features to access to root volume
>> AUTODETECT = all
>> FEATURES += plymouth ucode
>> FEATURES+=systemd
> В сизифе такой фичи нет. А что это за фича если не секрет ?
>
Честно не в курсе. Я ничего специально не делал ;)

Re: [devel] Q: agp modules in initrd ?

[Alexey Gladkov]

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

On Fri, Nov 24, 2017 at 04:10:04PM +0300, Anton Farygin wrote:
> >> # cat /etc/initrd/initrd.mk
> >> # trying to detect modules and features to access to root volume
> >> AUTODETECT = all
> >> FEATURES += plymouth ucode
> >> FEATURES+=systemd
> > В сизифе такой фичи нет. А что это за фича если не секрет ?
> >
> Честно не в курсе. Я ничего специально не делал ;)

Ты аккуратнее с этим. Если кто-нибудь создаст
/usr/share/make-initrd/features/systemd, то тебе прилетит
неожиданный подарок.

-- 
Rgrds, legion


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [devel] Q: agp modules in initrd ?

[Anton Farygin]

24.11.2017 18:04, Alexey Gladkov пишет:
> On Fri, Nov 24, 2017 at 04:10:04PM +0300, Anton Farygin wrote:
>>>> # cat /etc/initrd/initrd.mk
>>>> # trying to detect modules and features to access to root volume
>>>> AUTODETECT = all
>>>> FEATURES += plymouth ucode
>>>> FEATURES+=systemd
>>> В сизифе такой фичи нет. А что это за фича если не секрет ?
>>>
>> Честно не в курсе. Я ничего специально не делал ;)
> Ты аккуратнее с этим. Если кто-нибудь создаст
> /usr/share/make-initrd/features/systemd, то тебе прилетит
> неожиданный подарок.
>
Это дефолт из дистрибутива, похоже.

Будем искать.

Re: [devel] Q: agp modules in initrd ?

[Mikhail Efremov]

On Fri, 24 Nov 2017 18:07:09 +0300 Anton Farygin wrote:
> 24.11.2017 18:04, Alexey Gladkov пишет:
> > On Fri, Nov 24, 2017 at 04:10:04PM +0300, Anton Farygin wrote:  
> >>>> # cat /etc/initrd/initrd.mk
> >>>> # trying to detect modules and features to access to root volume
> >>>> AUTODETECT = all
> >>>> FEATURES += plymouth ucode
> >>>> FEATURES+=systemd  
> >>> В сизифе такой фичи нет. А что это за фича если не секрет ?
> >>>  
> >> Честно не в курсе. Я ничего специально не делал ;)  
> > Ты аккуратнее с этим. Если кто-нибудь создаст
> > /usr/share/make-initrd/features/systemd, то тебе прилетит
> > неожиданный подарок.
> >  
> Это дефолт из дистрибутива, похоже.
> 
> Будем искать.

Такая фича была в p6, как я вижу. С тех пор в конфиг так и добавляется.

-- 
WBR, Mikhail Efremov

Re: [devel] Q: agp modules in initrd ?

[Anton Farygin]

24.11.2017 18:47, Mikhail Efremov пишет:
> On Fri, 24 Nov 2017 18:07:09 +0300 Anton Farygin wrote:
>> 24.11.2017 18:04, Alexey Gladkov пишет:
>>> On Fri, Nov 24, 2017 at 04:10:04PM +0300, Anton Farygin wrote:
>>>>>> # cat /etc/initrd/initrd.mk
>>>>>> # trying to detect modules and features to access to root volume
>>>>>> AUTODETECT = all
>>>>>> FEATURES += plymouth ucode
>>>>>> FEATURES+=systemd
>>>>> В сизифе такой фичи нет. А что это за фича если не секрет ?
>>>>>   
>>>> Честно не в курсе. Я ничего специально не делал ;)
>>> Ты аккуратнее с этим. Если кто-нибудь создаст
>>> /usr/share/make-initrd/features/systemd, то тебе прилетит
>>> неожиданный подарок.
>>>   
>> Это дефолт из дистрибутива, похоже.
>>
>> Будем искать.
> Такая фича была в p6, как я вижу. С тех пор в конфиг так и добавляется.
>
Уберёшь ?

Re: [devel] Q: agp modules in initrd ?

[Mikhail Efremov]

On Fri, 24 Nov 2017 19:04:36 +0300 Anton Farygin wrote:
> 24.11.2017 18:47, Mikhail Efremov пишет:
> > On Fri, 24 Nov 2017 18:07:09 +0300 Anton Farygin wrote:  
> >> 24.11.2017 18:04, Alexey Gladkov пишет:  
> >>> On Fri, Nov 24, 2017 at 04:10:04PM +0300, Anton Farygin wrote:  
> >>>>>> # cat /etc/initrd/initrd.mk
> >>>>>> # trying to detect modules and features to access to root volume
> >>>>>> AUTODETECT = all
> >>>>>> FEATURES += plymouth ucode
> >>>>>> FEATURES+=systemd  
> >>>>> В сизифе такой фичи нет. А что это за фича если не секрет ?
> >>>>>     
> >>>> Честно не в курсе. Я ничего специально не делал ;)  
> >>> Ты аккуратнее с этим. Если кто-нибудь создаст
> >>> /usr/share/make-initrd/features/systemd, то тебе прилетит
> >>> неожиданный подарок.
> >>>     
> >> Это дефолт из дистрибутива, похоже.
> >>
> >> Будем искать.  
> > Такая фича была в p6, как я вижу. С тех пор в конфиг так и добавляется.
> >  
> Уберёшь ?

Да, конечно. Там ещё и MODULES_PRELOAD+=autofs4 добавляется, кстати.
Кто-нибудь в курсе, это еще нужно в случае systemd или это тоже
устарело?

-- 
WBR, Mikhail Efremov

Re: [devel] Q: agp modules in initrd ?

[Anton Farygin]

24.11.2017 19:20, Mikhail Efremov пишет:
> On Fri, 24 Nov 2017 19:04:36 +0300 Anton Farygin wrote:
>> 24.11.2017 18:47, Mikhail Efremov пишет:
>>> On Fri, 24 Nov 2017 18:07:09 +0300 Anton Farygin wrote:
>>>> 24.11.2017 18:04, Alexey Gladkov пишет:
>>>>> On Fri, Nov 24, 2017 at 04:10:04PM +0300, Anton Farygin wrote:
>>>>>>>> # cat /etc/initrd/initrd.mk
>>>>>>>> # trying to detect modules and features to access to root volume
>>>>>>>> AUTODETECT = all
>>>>>>>> FEATURES += plymouth ucode
>>>>>>>> FEATURES+=systemd
>>>>>>> В сизифе такой фичи нет. А что это за фича если не секрет ?
>>>>>>>      
>>>>>> Честно не в курсе. Я ничего специально не делал ;)
>>>>> Ты аккуратнее с этим. Если кто-нибудь создаст
>>>>> /usr/share/make-initrd/features/systemd, то тебе прилетит
>>>>> неожиданный подарок.
>>>>>      
>>>> Это дефолт из дистрибутива, похоже.
>>>>
>>>> Будем искать.
>>> Такая фича была в p6, как я вижу. С тех пор в конфиг так и добавляется.
>>>   
>> Уберёшь ?
> Да, конечно. Там ещё и MODULES_PRELOAD+=autofs4 добавляется, кстати.
> Кто-нибудь в курсе, это еще нужно в случае systemd или это тоже
> устарело?
>
Не могу представить, зачем в initramfs может понадобиться autofs4.

Re: [devel] Q: agp modules in initrd ?

[Mikhail Efremov]

On Fri, 24 Nov 2017 19:21:47 +0300 Anton Farygin wrote:
> 24.11.2017 19:20, Mikhail Efremov пишет:
> > On Fri, 24 Nov 2017 19:04:36 +0300 Anton Farygin wrote:  
> >> 24.11.2017 18:47, Mikhail Efremov пишет:  
> >>> On Fri, 24 Nov 2017 18:07:09 +0300 Anton Farygin wrote:  
> >>>> 24.11.2017 18:04, Alexey Gladkov пишет:  
> >>>>> On Fri, Nov 24, 2017 at 04:10:04PM +0300, Anton Farygin wrote:  
> >>>>>>>> # cat /etc/initrd/initrd.mk
> >>>>>>>> # trying to detect modules and features to access to root volume
> >>>>>>>> AUTODETECT = all
> >>>>>>>> FEATURES += plymouth ucode
> >>>>>>>> FEATURES+=systemd  
> >>>>>>> В сизифе такой фичи нет. А что это за фича если не секрет ?
> >>>>>>>        
> >>>>>> Честно не в курсе. Я ничего специально не делал ;)  
> >>>>> Ты аккуратнее с этим. Если кто-нибудь создаст
> >>>>> /usr/share/make-initrd/features/systemd, то тебе прилетит
> >>>>> неожиданный подарок.
> >>>>>        
> >>>> Это дефолт из дистрибутива, похоже.
> >>>>
> >>>> Будем искать.  
> >>> Такая фича была в p6, как я вижу. С тех пор в конфиг так и добавляется.
> >>>     
> >> Уберёшь ?  
> > Да, конечно. Там ещё и MODULES_PRELOAD+=autofs4 добавляется, кстати.
> > Кто-нибудь в курсе, это еще нужно в случае systemd или это тоже
> > устарело?
> >  
> Не могу представить, зачем в initramfs может понадобиться autofs4.

Он добавляется только в случае syatemd. Если никто не вспомнит зачем
это было нужно, то тоже уберу.

-- 
WBR, Mikhail Efremov

Re: [devel] Q: agp modules in initrd ?

[Konstantin Lepikhov]

Hi Anton!

On 11/24/2017, at 07:37:21 AM you wrote:

> 24.11.2017 03:43, Alexey Gladkov пишет:
> > On Fri, Nov 24, 2017 at 02:41:05AM +0300, Dmitry V. Levin wrote:
> >> Я бы пошёл ещё дальше и обновлял бы initrd всякий раз, когда в основной
> >> системе обновляется что-либо из того, что включено в initrd.
> >> Правда, для того, чтобы это более-менее корректно реализовать, придётся
> >> научить make-initrd складировать информацию о файлах, скопированных
> >> в initrd.
> > Это совсем не сложно.
> >
> > Куда положить список файлов ?
> >
> Кстати, уж коль пошла речь про initrd, пока вспомнил - может быть знаешь 
> почему в наш initrd попадают все -agp модули ?
> 
> Вот, для примера, на моём xps 9560:
> 
> Packed modules: autofs4 button crc16 drm drm_kms_helper evdev ext4 
> fscrypto hid hid-generic i2c-algo-bit i2c-core i915 input-leds intel-agp 
> intel-gtt jbd2 mbcache nvme nvme-core serio_raw shpchp sis-agp via-agp 
> video
agpgart все еще может требоваться модулем drm_kms_helper и drm:
kernel/drivers/gpu/drm/drm_kms_helper.ko.xz: kernel/drivers/gpu/drm/drm.ko.xz kernel/drivers/char/agp/agpgart.ko.xz ...

Про остальные -agp не знаю, прямых зависимостей на них нет в modules.dep.

-- 
WBR et al.