Bug 1221878

Summary: kiwi: should strip the extension from the keytable when calling systemd-firstboot
Product: [openSUSE] PUBLIC SUSE Linux Enterprise Server 15 SP6 Reporter: Eugenio Paolantonio <eugenio.paolantonio>
Component: Kiwi Next Generation (KIWI NG)Assignee: SUSE Public Cloud Maintainer <public-cloud-maintainers>
Status: RESOLVED INVALID QA Contact:
Severity: Normal    
Priority: P2 - High CC: marcus.schaefer
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Eugenio Paolantonio 2024-03-22 16:40:17 UTC 
Hi,

The keytable preference might specify the file extension (like
us.map.gz), while systemd-firstboot actually expects only the
keymap name [0].

Until recently [1], systemd-firstboot would not validate the
supplied keymap, so /etc/vconsole.conf was always updated even
if the keymap is wrong.

After the recent change, kiwi would fail with this error message
when using the full file name as a keytable:

[   91s] [ INFO    ]: 11:04:56 | Setting up keytable: us.map.gz
[   91s] [ DEBUG   ]: 11:04:56 | EXEC: [chroot /usr/src/packages/KIWI-vmx/build/image-root systemd-firstboot --help]
[   91s] [ DEBUG   ]: 11:04:56 | EXEC: [chroot /usr/src/packages/KIWI-vmx/build/image-root systemd-firstboot --keymap=us.map.gz]
[   91s] [ DEBUG   ]: 11:04:56 | EXEC: Failed with stderr: Keymap us.map.gz is not installed.
[   91s] , stdout: (no output on stdout)
[   91s] [ ERROR   ]: 11:04:56 | KiwiCommandError: chroot: stderr: Keymap us.map.gz is not installed.
[   91s] , stdout: (no output on stdout)

[0] https://man7.org/linux/man-pages/man1/systemd-firstboot.1.html
[1] https://github.com/systemd/systemd/commit/321a8c595e3470a0fe9002014656eee6a50b9553
Comment 1 Eugenio Paolantonio 2024-03-22 16:44:10 UTC 
My tentative fix: https://github.com/OSInside/kiwi/pull/2515
Comment 2 Eugenio Paolantonio 2024-04-17 15:39:39 UTC 
After discussion in the mentioned Pull Request, it has been decided that the best way to go is to amend the documentation. I'm closing this bug.