Hello, everybody, I'd like to know your opinion on one issue we have hit on live installations due to the DracutHostOnly feature [1]. Long story short: 1) Anaconda installs the kernel package 2) installation of the kernel package triggers dracut to generate initrd 3) dracut now generates so called "host-only" initrd, which, among the other things, means, that it contains only one keymap -- the one that was set in /etc/vconsole.conf at the time dracut was triggered to run 4) Anaconda configures the installed system based on the values set during the installation. The actual result is that if users type in their LUKS password with a keyboard layout different from 'us', let's say 'gb' they cannot type the password again on boot, because the initrd has only the 'us' keymap (set by default in the configuration file), even if there is 'vconsole.keymap=gb' as a boot option. There are two basic approaches how to fix this on the installer side: 1) write out keyboard configuration before packages are installed 2) regenerate the initrd at the end of the installation Both these solutions are not ideal from my point of view. And even if one of them is accepted and applied, there would still be the problem with systems, that have an initrd that blocks functionality of boot options (maybe there are more than vconsole.keymap, I don't know). So, is it a right thing to do to generate 3 MB smaller initrd's (the summed up size of all keymaps) not supporting some boot options? Does HostOnly mean the initrd works only with a specific host or that it works only with a specific configuration of a specific host? I understand having firmware for hardware that does not exist in the system might be useless, but not supporting boot with a different configuration options seems to me as a different thing. [1] https://bugzilla.redhat.com/show_bug.cgi?id=994180 -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
