From: Andrei Borzenkov <arvidjaar@gmail.com>
To: Christian Hesse <list@eworm.de>
Cc: The development of GNU GRUB <grub-devel@gnu.org>
Subject: Re: [PATCH 1/1] support loading of custom initrd images
Date: Sat, 6 Feb 2016 09:51:27 +0300 [thread overview]
Message-ID: <56B597EF.9000503@gmail.com> (raw)
In-Reply-To: <20160205184450.197ddab7@leda.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
05.02.2016 20:44, Christian Hesse пишет:
>>> +Give custom initrd images to be loaded in addition to the initrd image
>>> +found for the kernel. One use case is to load Intel ucode image.
>>> +
>>
>> Is there any other use case? Both dracut and initramfs-tools already add
>> early cpio with microcode to generated initrd. This is bootloader
>> agnostic and better solution.
>
> Running Arch Linux here, mkinitcpio does not do that.
>
> The ucode has to be in uncompressed initramfs, so dracut and initramfs-tools
> use a concatenated image?
Yes.
> I think this was discussed for mkinitcpio, but denied for any reason. Would
> have to search for references...
> We have a downstream bug about dealing with Intel ucode in bug tracker. [0]
>
> Nevertheless I have another use case:
> I do use Yubikeys in challenge/response mode to open my LUKS encrypted
> partition. [1] (This is not specific for mkinitcpio but works with dracut as
> well.) The challenges are stored in an extra initramfs. This is required if
> you want to update the challenge on every use - recompressing the initramfs
> on every boot is not a good option.
>
Why your initrd cannot simply read this file from /boot itself?
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2016-02-06 6:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 10:43 [PATCH 1/1] support loading of custom initrd images Christian Hesse
2016-02-05 17:04 ` Andrei Borzenkov
2016-02-05 17:44 ` Christian Hesse
2016-02-06 6:51 ` Andrei Borzenkov [this message]
2016-02-08 8:22 ` Christian Hesse
2016-02-08 8:30 ` [PATCH v2 " Christian Hesse
2016-02-08 16:10 ` Christian Hesse
2016-02-05 18:23 ` [PATCH " Vladimir 'phcoder' Serbinenko
2016-02-08 8:27 ` Christian Hesse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B597EF.9000503@gmail.com \
--to=arvidjaar@gmail.com \
--cc=grub-devel@gnu.org \
--cc=list@eworm.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.