[systemd-devel] Make systemd-localed modify the kernel commandline for the initrd keymap?

[Hans de Goede]

Hi,

On 26-09-2019 11:10, Michael Chapman wrote:
> On Thu, 26 Sep 2019, Hans de Goede wrote:
> [...]
>> I believe that the best alternative is to have localed append / update
>> a rd.vconsole.keymap=foo argument to the kernel commandline, to override
>> the vconsole.conf KEYMAP setting, but only in the initrd (so that later
>> runtime changes when booted still work).
>>
>> The way I see this working is that localed does a read-modify-write of
>> all the BLS .conf files under /boot/loader/entries and updates their
>> "options" line to have rd.vconsole.keymap=foo appended or updated if
>> already present.
> 
> To be honest, I really do think having the initrd rebuilt completely is a
> better approach... but I do not think localed should be directly
> responsible for that.

As I already mentioned there are 2 issues with rebuilding the initrd:

1) It might break booting the system and, assuming we rebuild the initrd
for all installed kernels on a locale change, then their will not be
an older one to fallback to as there normally is, which is BAD.

2) We are moving (and in case of rpmostree based distros already shipping)
to pre-generated (on the distros buildsys) initrds, which likely will
also be signed.

How do you propose to solve these 2 issues?

> There are a lot of reasons the initrd needs to be rebuilt. Changing the
> system locale is just one of them. It seems unreasonable to have every
> tool know how to append boot parameters.

Actually there are not that many reasons, Note that all other config info
needed for the initrd, like the rootfs UUID, which raid/lvm members to
assemble, etc. is already on the kernel commandline, so it seems logical
to put the locale (which is config info) there too and pre systemd at least
Fedora was already doing this.

> I would be a lot happier seeing a "well-known" binary that various things
> can call to rebuild the initrd, somewhat akin to the kernel-install we
> have already. That way distributions can plug in whatever tooling they use
> for initrds (e.g. dracut, initramfs-tools, ...)

So maybe we need a well-known binary to update the kernel-commandline ?

Regards,

Hans