| 2023-10-25 09:54:49 |
Sergio Costas |
description |
When working with ubuntu core or ubuntu core desktop, neither /etc/default/locale nor /etc/default/keyboard are modificable, so it's not possible to set the global keyboard or the global language. |
[Impact]
When working with ubuntu core or ubuntu core desktop, neither */etc/default/locale* nor */etc/default/keyboard* are modifiable, so it's not possible to set the global keyboard or the global language. This is required to allow to set the GDM language, and the default one during installation.
The first half of the solution is to create the folder */etc/writable/default*, and make soft-links from */etc/default/locale* to */etc/writable/default/locale* and from */etc/default/keyboard* to */etc/writable/default/keyboard*, just like it is already being done with */etc/hostname*, */etc/issue*, */etc/localtime*, */etc/motd* and , */etc/timezone*.
This solution, unfortunately, isn't complete. Although any application that just reads the files will work, not all of the applications that write to them will; specifically the systemd utilities that set the contents for those files, because they don't open the file directly; instead, they create first the new file in the same folder than the old one, fill its contents, and only then delete the old one and rename the new one. To solve this, systemd in Ubuntu already has several patches that detect if a file is a soft-link, in which case it replaces the old path with the destination one.
Currently I have in place a patch for Ubuntu Core Desktop that implements both changes for both */etc/default/locale* and */etc/default/keyboard*.
[Test plan]
Using *localectl set-lang LANG="xx_YY.UTF-8"* should change the locale to the specified one. Also, *localectl* should return the current locale.
[Where problems could occur]
In general, applications just read the content of the file and use the DBus interface to set the locale, so only those applications that modify by themselves the */etc/default/keyboard* and/or */etc/default/locale* would present a problem, in which case they would require specific patches. Anyway, those applications neither would work with the current state (with those files in a read-only filesystem). |
|
