Description of problem: changing system virtual console locale/keymap does not affect initramfs Version-Release number of selected component (if applicable): F21 Alpha How reproducible: always Steps to Reproduce: 1. change VC keymap using localectl Actual results: initramfs is left unchanged Expected results: since this keymap affects luks/cryptsetup, the initramfs should be updated with most recent keymap
In fact localectl affects initramfs, but this takes as long as initramfs is not regenerated. This does not happen by localectl but e.g. on new kernel install.
localectl is only "front-end" for /etc/locale.conf and /etc/vconsole.conf. Regenerating initramfs image as consequence of running the tool would be very surprising for many users. Maybe we could add a line to the manpage mentioning that regeneration of initramfs image is advised for some setups, i.e. hard-drives encrypted by luks.
... but only for non-host-only images.
I'm not sure if it will ever be possible to change an initramfs using localectl, but I think that your problem might be solved by https://admin.fedoraproject.org/updates/systemd-216-12. Could you please try and report back?
VC font problems were resolved in bug 1150384. Closing this bug.
@Jan Synacek: This is not related to VC font problems and not to the PolicyKit change in systemd-216-12. And no, it still doesn't work to change locale/keymap and afterwards regenerate initramfs. But I see your point that this is not possible as of now without major changes. Since this is not fixed and neiter of us seems to see an easy way to fix this, I'm marking this bug as WONTFIX.
Why would you mark a bug as WONTFIX? WONTFIX means that the maintainers refuse or cannot fix the bug. So it's a resolution that can only reasonably be set by a maintainer of the package. I think Jan changed the status of this bug by mistake: this one is about setting the right config, 1150384 was about applying it during boot. I think we should implement this: (In reply to Michal Sekletar from comment #2) > Maybe we could add a line to the manpage mentioning that regeneration of > initramfs image is advised for some setups, i.e. hard-drives encrypted by > luks.
Sorry.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #7) > Why would you mark a bug as WONTFIX? WONTFIX means that the maintainers > refuse or cannot fix the bug. So it's a resolution that can only reasonably > be set by a maintainer of the package. > > I think Jan changed the status of this bug by mistake: this one is about > setting the right config, 1150384 was about applying it during boot. I think > we should implement this: Arguably the regeneration of the initramfs should be strictly handled by the administrator that ran the relevant configuration tool and or edited the configuration file(s) by hand but since you seem to be heading down this road ensure you... a) handle the use cases where no initramfs is being used ( do nothing ) b) notify the user when the command starts regenerating with a msg that the initramfs is being regenerated since it can take some time c) handle the uses case where the end user manually edits the configuration files
(In reply to Jóhann B. Guðmundsson from comment #9) > Arguably the regeneration of the initramfs should be strictly handled by the > administrator that ran the relevant configuration tool Exactly. We are only adding a hint to the man page.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
https://github.com/systemd/systemd/pull/3754
Did you want to mark this as CLOSED WONTFIX? The commit you referenced in comment #13 doesn't fix this issue but tell the user what to do. In case you're interested in fixing this bug, bug #1059485 and bug #1304795 look quite similar. They probably could use the same piece of software to regenerate initramfs, maybe some rpm triggers.
No, I meant to mark it as NEXTRELEASE, since it will be handled to the little extent that we can in some future version of systemd. I think the dangers of automatically rebuilding the initramfs are too big. If anything, we should work on a better mechanism to update the boot options, which can achieve the same effect. But as long as grub is the main boot loader, this is too risky and complicated.