From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FSL_HELO_HOME autolearn=no autolearn_force=no version=3.4.1 Date: Thu, 23 Nov 2017 15:22:36 +0100 From: Konstantin Lepikhov To: devel@lists.altlinux.org Message-ID: <20171123142236.GA7748@lks.home> Mail-Followup-To: devel@lists.altlinux.org References: <20170906120909.GA8403@lks.home> <20170906133734.GE13205@altlinux.org> <20170907074727.GA5493@lks.home> <20170907092831.GA27490@altlinux.org> <20170907101743.GA19849@lks.home> <20170908210136.GA19351@altlinux.org> <20170908220652.GA4857@lks.home> <20171122142351.085e3c7f@sem-notebook> <20171123115542.GA13450@lks.home> <20171123165603.3cf0dc39@sem.office.basealt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171123165603.3cf0dc39@sem.office.basealt.ru> X-Operation-System: ALT Linux starter kit (Trientalis) 4.14.0-lks-wks-alt1 User-Agent: Mutt/1.8.3 (2017-05-23) Subject: Re: [devel] Q: postinst hook for firmware-* X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Nov 2017 14:22:40 -0000 Archived-At: List-Archive: List-Post: 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.