FS#72230 - [linux-lts] /etc/vconsole.conf's FONT setting is now only applied to tty1
Attached to Project:
Arch Linux
Opened by Emanuele Torre (emanuele6) - Friday, 24 September 2021, 17:05 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 25 September 2021, 07:00 GMT
Opened by Emanuele Torre (emanuele6) - Friday, 24 September 2021, 17:05 GMT
Last edited by Andreas Radke (AndyRTR) - Saturday, 25 September 2021, 07:00 GMT
|
Details
Description:
This is my /etc/vconsole.conf file: KEYMAP=it FONT=ter-v32n Today, I rebooted my PC (after I think ~1 week) and I noticed that my font was not being applied the virtual consoles. I ran `sudo updatedb' and `locate ter-v32n' which confirmed that the font was still installed correctly (this was not cause by a font package); I also tried to run `sudo setfont ter-v32n' in the "tty2" virtual console and it successfully changed the font to ter-v32n (only in tty2) Then I rebooted once again and noticed, before starting my graphical environment from the "tty1" virtual console, that the font was actually being applied, but only to "tty1", not to the other virtual consoles. At this point, I started to suspect of the kernel so I downgraded it to 5.10.67-1 (from the current version: 5.10.68-1) and rebooted. Surprisingly, (I was not expecting this to actually be a bug introduced by a kernel package update, especially by an LTS kernel package update), it solved the problem; the font setting is applied in all the virtual consoles. I also re-updated the kernel to 5.10.68-1 and rebooted again to confirm that the FONT setting is still only loaded in "tty1". Cheers, emanuele6 Additional info: After re-updating, I also checked whether the KEYMAP setting was being applied to all consoles and it actually was, KEYMAP changed to "it" in all virtual consoles, but FONT. I am not sure if this means anything or is relevant. |
This task depends upon
The recent package update only updated $pkgver (and consequently the
source URL).
Could this be an upstream bug?
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.68
then report it to https://bugzilla.kernel.org/ and probably CC it to the stable kernel ML.
see if it also had the "bug".
After running `sudo pacman -S core/linux', I rebooted and I noticed that
the problem went away; also when using the linux-lts kernel.
Then I tried rebooting to linux-lts, first after uninstalling core/linux
and then after alse re-installing core/linux-lts
(with `sudo pacman -S core/linux-lts' ), and the problem was still gone.
I am not complaining. :)
Then could this be a bug in the core/linux-lts update script (that made it
not update a module correctly or that made it not remove a cache file or
something like that), that was then resolved by running the install
script for core/linux?
Either way, now, I don't have the problem anymore so you can close the
report if you want.
Thank you for your time,
emanuele6
This ArchLinux installation is more than two years old and I have had
that same configuration file basically since the installation that never
caused problems, so I don't really understand how and why only the
update from LTS 5.10.67 to LTS 5.10.68 caused the problem, downgrading
to 5.10.67-1 solved it, re-upgrading to 5.10.68-1 didn't solve it and
then installing and uninstalling core/linux solved it permanently, but
unfortunately I can't investigate it much since it just works now.