I did some digging into this, explained in the bug report, and I don't believe it's a new problem. The practical result is not ideal but also not disastrous (you get US layout at the console in an Arabic install, rather than 'fa' which would allow input of Arabic characters). As well as the service failing, we have an explicit criterion that covers this:

https://fedoraproject.org/wiki/Fedora_35_Final_Release_Criteria#Keyboard_layout_configuration

"If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in at a console"

and this seems like a fairly straightforward violation of that. It is also a conditional violation of the "services must start" criterion. Given that, I think I have to vote:

FinalBlocker +1

But I will also vote to waive this, if we get to that point, on the basis that it was discovered extremely late, it is not a new bug (this has likely been the case in every Fedora release at least since langtable/vconsole have existed, and probably before that), and the impact is not really super bad.

FinalBlocker +1

I agree with everything Adam said.

Ditto

FinalBlocker +1

(and +1 to waive if thats the last blocker tomorrow)

FinalBlocker +1
(and +1 waive)

Thanks for summing this up @adamwill

FinalBlocker -1

We seem to all be in agreement that, despite it failing to meet the letter of the criterion, it would be waived anyway. That says to me that it's not a blocker and is instead an insufficient criterion.

Put another way: I'd still vote not to block on this for Fedora 36 Final. That is pretty much the definition of "not a blocker" to me.

I agree with Stephen. If we are willing to waive it, then we do not need to make it a blocker, especially when the system works (as described in the bug)

FinalBlocker -1

despite it failing to meet the letter of the criterion

I don't understand this, it seems to violate the "services must not fail" criterion to the letter. (I'm not arguing against your stance).

"If a particular keyboard layout has been configured for the system, that keyboard layout must be used: ... When logging in at a console"

Adam, I'm not sure why you mentioned this one. When I chose Arabic as the language, it provided me with two keyboard layouts, us as the default one, and ara as the secondary one. Following the testcase, I encrypted the disk with the default us keymap, and that's also what's used during decryption. So it seems to be working according to requirements, or doesn't it?

FinalBlocker +1
FinalFE +1

@kparal for me, it's only a conditional violation of the services criterion, the condition being "you have to install in Arabic", which is going to be a fairly low proportion of users most likely. The other criterion I feel is stronger because it's specifically about i18n.

For your second question, the answer is a bit technical, but the summary is "no, it's not working according to requirements". What we should use at the console is 'fa', which is a switchable layout which types Latin characters by default but can be switched to input Arabic ones. That would be the correct console counterpart to the xkb configuration of "us,ara". Instead we are just using the 'us' layout, which can only type Latin characters, it cannot type Arabic at all.

Release F35 is no longer tracked by BlockerBugs, closing this ticket.