Nick, thanks for the comment. I had a conspiracy theory that there was a race condition here in early boot during cloud-config.service when cloud-init tried writing /etc/default/keyboard directly to write out before invoking systemctl restart console-setup. The conditions I was seeing was the error message:
Could not get properties: Access Denied
This generic message which lead me to believe something was interacting incorrectly with dbus during systemd-localed activation.
Turns, out this was a programming issue in the cloud-init PR we put up to address this. When cloud-init is trying to write /etc/default/keyboard, the content is correct, but the file permissions were off.
The utility function we were using was trying to set perms on /etc/default/keyboard to 644 providing a decimal value of 644 instead of an octal value of mode=0o644
This resulted in setting permissions 1204 on /etc/default/keyboard .... which is equivalent of:
chmod u=w,o=,g=r,+t /etc/default/keyboard.
leaving us with a file with no read permissions for root and a sticky bit set:
root@testlocale-manticdaily:~# ls -l /etc/default/keyboard
-rw-r----T 1 root root 120 Aug 25 02:31 /etc/default/keyboard
This results in a strange state and error message where first call to "localectl status" will first report as systemd-localed.service is activated, and the 2nd call to "localectl status" uses the cached values of the currently active systemd-localed.service so it doesn't report the permissions error and just dumps empty unset values.
root@testlocale-manticdaily:~# localectl status
Could not get properties: Access denied
root@testlocale-manticdaily:~# localectl status
System Locale: LANG=C.UTF-8
VC Keymap: (unset)
X11 Layout: (unset)
I think there are two issues here with localectl in Mantic, neither of which really seem critical from a functional standpoint, but from a usability standpoint they may warrant bugs of effort to improve understanding best practices and/or discovering errors in keymap setting:
1. localectl set-x11-keymap <keymap_layout> <model> could provide a pointer to manpage, breadcrumb or suggested best practice for writing /etc/default/keyboard directly instead of an unhelpful message:
Setting X11 and console keymaps is not supported in Debian.
2. localectl status could be more informative about permissions errors or formatting errors in /etc/default/keyboard and could probably announce what type of permissions errors it is hitting:
Could not get properties: Access denied to file /etc/default/keyboard
Again the 2nd case is really user/program-failure to do the right thing so not as likely a candidate to address.
Nick, thanks for the comment. I had a conspiracy theory that there was a race condition here in early boot during cloud-config. service when cloud-init tried writing /etc/default/ keyboard directly to write out before invoking systemctl restart console-setup. The conditions I was seeing was the error message:
Could not get properties: Access Denied
This generic message which lead me to believe something was interacting incorrectly with dbus during systemd-localed activation.
Turns, out this was a programming issue in the cloud-init PR we put up to address this. When cloud-init is trying to write /etc/default/ keyboard, the content is correct, but the file permissions were off.
The utility function we were using was trying to set perms on /etc/default/ keyboard to 644 providing a decimal value of 644 instead of an octal value of mode=0o644
```
util.write_ file(
filename= "/etc/default/ keyboard" ,
content= contents,
mode= 644,
omode= "w",
)
```
This resulted in setting permissions 1204 on /etc/default/ keyboard .... which is equivalent of:
chmod u=w,o=,g=r,+t /etc/default/ keyboard.
leaving us with a file with no read permissions for root and a sticky bit set:
root@testlocale -manticdaily: ~# ls -l /etc/default/ keyboard keyboard
-rw-r----T 1 root root 120 Aug 25 02:31 /etc/default/
This results in a strange state and error message where first call to "localectl status" will first report as systemd- localed. service is activated, and the 2nd call to "localectl status" uses the cached values of the currently active systemd- localed. service so it doesn't report the permissions error and just dumps empty unset values.
root@testlocale -manticdaily: ~# localectl status -manticdaily: ~# localectl status
Could not get properties: Access denied
root@testlocale
System Locale: LANG=C.UTF-8
VC Keymap: (unset)
X11 Layout: (unset)
I think there are two issues here with localectl in Mantic, neither of which really seem critical from a functional standpoint, but from a usability standpoint they may warrant bugs of effort to improve understanding best practices and/or discovering errors in keymap setting:
1. localectl set-x11-keymap <keymap_layout> <model> could provide a pointer to manpage, breadcrumb or suggested best practice for writing /etc/default/ keyboard directly instead of an unhelpful message:
Setting X11 and console keymaps is not supported in Debian.
2. localectl status could be more informative about permissions errors or formatting errors in /etc/default/ keyboard and could probably announce what type of permissions errors it is hitting: keyboard
Could not get properties: Access denied to file /etc/default/
Again the 2nd case is really user/program- failure to do the right thing so not as likely a candidate to address.