Bug 2015972
Summary: | systemd-vconsole-setup.service fails on an arabic system | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||||
Component: | kbd | Assignee: | Vitezslav Crhonek <vcrhonek> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | unspecified | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 35 | CC: | awilliam, bcotton, fedoraproject, filbranden, flepied, lnykryn, mfabian, msekleta, robatino, ryncsn, ssahani, s, systemd-maint, vcrhonek, yuwatana, zbyszek | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | AcceptedBlocker | ||||||||
Fixed In Version: | kbd-2.4.0-8.fc35 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2021-10-28 18:27:49 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1891955 | ||||||||
Attachments: |
|
Description
Kamil Páral
2021-10-20 14:18:45 UTC
Created attachment 1835128 [details]
journal
Created attachment 1835129 [details]
rpm -qa
Proposing for a blocker discussion. There's this criterion: "All system services present after installation with one of the release-blocking package sets must start properly, unless they require hardware which is not present. " https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#System_services I haven't seen any negative effects from the failed service (the system seems to work), but perhaps there are some? Still, the service *is* clearly failed. I don't *think* this is new. I checked back to F28 - https://koji.fedoraproject.org/koji/buildinfo?buildID=1030966 - and there's no 'ara' console layout in kbd-misc or kbd-legacy that I can see. The association has been in langtable since 0.0.15 in 2013, though I'm not sure where Mark got it? I also have obviously been in this area before, though I don't entirely recall the context and I didn't provide many references (bad me): https://github.com/legionus/kbd/issues/14 . From that issue, it looks like Debian ships an 'ar' and an 'fa' map. The 'fa' map was added to kbd as a result of that issue. There is a keyboard layout called 'ara', but it's only in xkb: /usr/share/X11/xkb/symbols/ara . We do not ship the kbd conversion of that layout in kbd-misc because it cannot input ASCII characters. [time passes] OK, so...in anaconda we expect that whatever 'native' layout name langtable gives us will exist as a kbd (console) layout. For Arabic, this just isn't true. As noted above, potentially valid console layout names are 'ar' and 'fa', but the xkb layout is called 'ara' and that's what langtable returns. The practical upshot of this is that the console layout used for Arabic installs will be 'us'. Ideally we would probably use 'fa'. However, implementing this is slightly tricky - we either have to special-case it in anaconda, extend langtable to somehow support the concept of different keymap names for xkb and kbd, or just symlink 'fa.map.gz' to 'ara.map.gz' in kbd-legacy - and I don't think it's new. I would expect the result to be the same on all past Fedora releases at least as long as langtable and vconsole have been around (and we probably had the same problem before that even). In today's Go/No-Go meeting, we agreed: This is clear violation of the "If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in at a console" criterion https://meetbot.fedoraproject.org/fedora-meeting/2021-10-21/f35-final-go_no_go-meeting.2021-10-21-17.00.log.html#l-451 This definitely isn't a systemd bug, btw. It's either in anaconda...or kbd...or langtable...but definitely not systemd. :D I'm re-assigning to kbd for now as the easiest quick fix I can think of is in kbd. I'll try that out later today. FEDORA-2021-c2c76d4847 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-c2c76d4847 FEDORA-2021-c2c76d4847 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c2c76d4847` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c2c76d4847 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. (In reply to Fedora Update System from comment #7) > FEDORA-2021-c2c76d4847 has been submitted as an update to Fedora 35. > https://bodhi.fedoraproject.org/updates/FEDORA-2021-c2c76d4847 I installed Workstation RC1 using Arabic, and then updated kbd to kbd-2.4.0-8.fc35 in /mnt/sysroot before rebooting. After booting the installed system, I no longer see any failed services in "systemctl --failed", and systemd-vconsole-setup.service is running OK without any errors in the log. I don't know how to check the current console layout in VT, whether it is "fa" or not. But I see this output: $ localectl System Locale: LANG=ar_EG.UTF-8 VC Keymap: ara X11 Layout: us,ara X11 Variant: , X11 Options: grp:alt_shift_toggle You can test just by hitting alt+shift and then typing some stuff :) Most keys are bound to different characters, in fa. Some will be visible as Arabic characters, some will just be squares, because the console font doesn't have enough space to show them all. FEDORA-2021-c2c76d4847 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. |