Re: Make systemd-localed modify the kernel commandline for the initrd keymap?

[Michael Chapman <mike@xxxxxxxxxxxxxxxxx>]

On Thu, 26 Sep 2019, Hans de Goede wrote:
> 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?

Hmm, these are good points. I do like the idea of using a 
locally-generated overlay initrd though.
 
> > 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.

Perhaps I've been overly eager to rebuild the initrd on my systems when 
changing files under /etc. I think that's because I've seen just how much 
Dracut copies into the initrd, and I always get the feeling that if I 
forget to rebuild it something will break on the next reboot...

Just to pick an example, I was fiddling around with /etc/udev/rules.d 
files a little while ago. I just assumed I'd need to rebuild the initrd 
for those.

Perhaps a more common example is /etc/crypttab. That certainly needs to be 
in the initrd if the root filesystem is encrypted.

So I guess I'm already in the habit of rebuilding the initrd when 
modifying config in /etc that might be needed on boot, and changing the 
locale wouldn't be any different.
 
> > 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 ?

I think that would be useful just generally.
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel