Description of problem: I have been trying to set the F19 console font to latarcyrheb-sun16 by setting FONT in /etc/vconsole.conf but it does not seem to have any affect. Version-Release number of selected component (if applicable): kbd-1.15.5-5.fc19 systemd-200-3.fc19 How reproducible: 100% Steps to Reproduce: 1. Boot current F19 pre-Alpha 2. add FONT=latarcyrheb-sun16 to /etc/vconsole.conf 3. reboot system to console 4. login to console and run "setfont latarcyrheb-sun16" Actual results: 3. No change in font (looking at F19 release name for example) 4. font changes! Expected results: System console font to default to value of FONT /etc/vconsole.conf. (See vconsole.conf (5).) Additional info: In earlier testing even setting vconsole.font=latarcyrheb-sun16 on the kernel boot line did not have any affect either.
You might have to recreate your initramfs: # dracut -f So the font is included there. I think plymouth keeps the console busy for systemd-vconsole-setup, as soon as it is started in the initramfs.
There is a bug in systemd-200 (and maybe earlier, I haven't checked) where it skips the parsing of /etc/vconsole.conf if any of the supported vconsole.* arguments is present on the kernel command line. Basically, it does: r = parse_env_file("/proc/cmdline", ...); ... /* Hmm, nothing set on the kernel cmd line? Then let's * try /etc/vconsole.conf */ if (r <= 0) { r = parse_env_file("/etc/vconsole.conf", ...); ... } parse_env_line() returns the count of successful assignments it made, so any assignment from /proc/cmdline would cause /etc/vconsole.conf to be ignored. Accidentally, it works now with current HEAD, because since this commit parse_env_file() simply returns 0 on success: http://cgit.freedesktop.org/systemd/systemd/commit/?id=f73141d7657b3f60b8669bc8386413d8a8a372c6 I'll fix the logic in vconsole-setup.c to make sense.
(In reply to comment #2) > I'll fix the logic in vconsole-setup.c to make sense. http://cgit.freedesktop.org/systemd/systemd/commit/?id=2034ec42ec9e18db1ec908c87bb7c24cc63d2412
Thanks! If I remove vconsole.keymap=us from the kernel line, add "FONT=latarcyrheb-sun16", run "dracut -f", and reboot then this fixes bug 927564.
To recreate fix locally in TC5 minimal install: 1. add FONT=latarcyrheb-sun16 to vconsole.conf 2. run dracut -f 3. reboot either removing vconsole.keymap=.. *or* add vconsole.font=... to kernel boot line
Comment 5 no longer seems to work with systemd-201.
Discussed at 2013-04-15 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-04-15/f19alpha-blocker-review-7.2013-04-15-16.00.log.txt . This was rejected as a freeze exception issue on the basis that the impact doesn't seem to be terrible, it can be worked around by passing kernel parameters, and it can be fixed well enough with an update. If you feel we've analyzed the issue wrong, please re-propose with more details. Thanks!
another fix for systemd-202 http://cgit.freedesktop.org/systemd/systemd/commit/?id=fee79e010f1f8ad2bce6b41c67e8ddd4f419ff4b do not set the non-unicode mode for LANG=C
systemd-202-2.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/FEDORA-2013-6070/systemd-202-2.fc19
systemd-202-3.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/systemd-202-3.fc19
Package systemd-202-3.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-202-3.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-6488/systemd-202-3.fc19 then log in and leave karma (feedback).
systemd-202-3.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
vconsole.conf still has no effect on a fully updated Fedora 19 (see bug #1000504). Neither the font nor the keymap are getting loaded. And yes, I did run "dracut -f".
It looks like this is dracut's fault: dracut just does not include vconsole.conf and locale.conf in the initramfs at all! After adding: install_items+=" /etc/vconsole.conf /etc/locale.conf " to /etc/dracut.conf, I get bug #970030 instead. But the keymap is still the US one.
> But the keymap is still the US one. Nevermind, I had just "de" set rather than "de-latin1", and it looks like de is a mix between de-latin1 and us (it has the US key assignments where the umlauts should be). So, to sum up, I see 2 issues: 1. dracut not installing vconsole.conf in the initramfs by default and 2. bug #970030 or something with similar symptoms (sounds like the result of Karel Volný's step 3 in bug #1000504).
(In reply to Kevin Kofler from comment #14) > It looks like this is dracut's fault: dracut just does not include > vconsole.conf and locale.conf in the initramfs at all! > > After adding: > install_items+=" /etc/vconsole.conf /etc/locale.conf " > to /etc/dracut.conf, I get bug #970030 instead. But the keymap is still the > US one. Well, it does on my system. Please attach debug-log.txt of: # dracut --debug -f test.img 2>debug-log.txt # rm -f test.img
Created attachment 798768 [details] debug-log.txt So here's the debug-log.txt, as requested. I commented out the install_items line I had added to dracut.conf. In case that matters: I forgot to mention that I have dracut-nohostonly and dracut-norescue installed.
(In reply to Kevin Kofler from comment #17) > Created attachment 798768 [details] > debug-log.txt > > So here's the debug-log.txt, as requested. I commented out the install_items > line I had added to dracut.conf. > > In case that matters: I forgot to mention that I have dracut-nohostonly and > dracut-norescue installed. well, with dracut-nohostonly vconsole.conf and locale.conf will not be copied to the initramfs and you have to specify the parameters on the kernel command line: "vconsole.font=latarcyrheb-sun16 vconsole.keymap=<yourkeymap> locale.LANG=<yourLANG>"
Well, I don't think that's a good idea (also considering that grub2-mkconfig no longer writes those options by default), but the install_items workaround works in any case, so I'll return this to closed state. (The systemd bug is clearly fixed, it honors the files just fine if they're there.) Now the real issue I'm having is what looks like bug #970030.