[devel] Q: postinst hook for firmware-*
Mikhail Efremov
sem на altlinux.org
Чт Ноя 23 16:56:03 MSK 2017
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
Подробная информация о списке рассылки Devel