Hi,
On 9/27/19 1:49 PM, Lennart Poettering wrote:
On Mi, 25.09.19 16:50, Hans de Goede (hdegoede@xxxxxxxxxx) wrote:
Hi all,
Currently, at least in Fedora, but I do not believe that this problem is
unique to Fedora, there are 2 problems with keymap handling in the
initrd.
Hmm, why do you need a correct initrd in the early boot? I can see two
reasons:
1. full disk encryption with the user typing in the password on the
kbd.
Ack that is the main use-case for this.
But isn't the answer to this to link the root OS to the tpm
instead, and use user-keyed crypto only for $HOME? The OS itself
doesn't need to be protected after all, everbody should have the
same files there anyway, it's $HOME that needs protection.
Well until we make sure nothing ever writes outside of the user
homedir security conscious users will likely still want to use
full-disk encryption and there is also plenty of hw which Fedora
supports which does not have a TPM2
2. debugging in the initrd. Does this really matter though? Aren't
people who can usefully debug the initrd also smart enough to load the
kbd mappings themselves (or work with american keybindings for a bit)?
I agree that this is a non-issue.
Aren't you making something here a problem that actually doesn't
matter much?
We have a bug open for this for a long long time and it is even listed on:
https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs_and_issues
That said, if it is worth fixing this,
I think it is safe to say that the people involved from the Fedora
side have decided it is indeed worth fixing this.
why stop at the initrd here,
shouldn't the bootloader get right keymaps too? After all, most boot
loaders I know have a line editor...
That is a very interesting point, on one hand using the bootloader
line-editor sort of matches your dracut-debug scenario, IOW not
so important to fix.
OTOH I agree that if we are looking into fixing the kbd layout
for the initrd it would be interesting to see if we can also fix
it for the bootloader.
Which hence raises the question: isn't this something the boot loader
should manage initially, and then just pass to the kernel/initrd?
i.e. on EFI systems, shouldn't this just be an efi var, that the boot
ldr can read, and then pass on to the kernel (or alternatively, read
by the initrd?) Alternatively, if you care about non-EFI, isn't this
also something you want to tell the boot ldr about, and then have the
boot loader pass to the kernel, maybe via a struct boot_param entry?
(or simply by appending something to the kernel cmdline if that
doesn't fly).
We definitely care about non EFI and we care about a scala on
bootloaders, modifying them all for this really does not scale,
so I believe we really need a solution outside of the bootloader
and parallel to that we can think about also passing this info
to the bootloader somehow.
TL;DR: IMHO regenerating the initrd is not the answer here.
Yeah, leave the initrd alone, it should be immutable outside of kernel
updates, I am sure.
I'm willing to write localed patches implementing this (targetting Fedora 32)
but before I spend time on this, it would be good to have consensus that
this is the best way to handle this. Note I'm open to other suggestions.
I'd be happy to merge patches that just use an EFI variable for this,
so that boot loader, initrd and GNOME can all make use of this.
I know you love EFI variables and I understand why you do, but
unfortunately there are still e.g. a lot of 64 bit core2 duo laptops
and desktops which still run fine and are still being used, so
we still need to support legacy BIOS for those and there are
also other more exotic platforms which do not have EFI.
TL;DR: we do not live in an EFI only world, so using EFI is
not the answer.
Regards,
Hans
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
