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

[Konstantin Lepikhov <lakostis@altlinux.org>]

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.