[20.04] Keyboard layout not enabled immediately during installation when typing username/password

Bug #1875062 reported by Dag Bjerkeli on 2020-04-25
74
This bug affects 13 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
High
Łukasz Zemczak
Focal
High
Unassigned
Hirsute
High
Łukasz Zemczak

Bug Description

During a fresh install of Ubuntu 20.04, selecting Norwegian keyboard is provided and keys are responding correctly at that stage. But later when entering user information the keyboard setting is wrong.

It looks like it have fallen back to English keyboard-layout.
I failed to log in after my first install, so a new attempt I tried to write some special letters in the name field, and noticed that I got the wrong characters for the key.

The install is done i VMware workstation 15.

In the attached screendump, the characters (';[":{) after my name should have been (æøåÆØÅ) that is norwegian characters.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ubiquity (not installed)
ProcVersionSignature: Ubuntu 5.4.0-26.30-generic 5.4.30
Uname: Linux 5.4.0-26-generic x86_64
ApportVersion: 2.20.11-0ubuntu27
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sat Apr 25 19:27:41 2020
InstallCmdLine: file=/cdrom/preseed/ubuntu.seed initrd=/casper/initrd quiet splash --- maybe-ubiquity
InstallationDate: Installed on 2020-04-25 (0 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: ubiquity
Symptom: installer
UpgradeStatus: No upgrade log present (probably fresh install)

Dag Bjerkeli (dag-e) wrote :
Changed in ubiquity (Ubuntu):
importance: Undecided → High
status: New → Confirmed
tags: added: rls-ff-incoming
Jean-Do Veuve (jeando) wrote :

I installed a fresh Ubuntu 20.04 LTS on an Oracle VM. During the installation, I choosed “french language” and “Belgian keyboard”. Later, the installer asked me to type my name and password and THERE the keyboard is in Qwerty with no support of the numeric pad (Qwerty 88)

I checked it with two different install to be sure of the bug. And with a German keyboard, same problem.

After reboot, it returns back in Keyb BE as defined.

Potential login problem :

If your name doesn’t contain any letter as “z-q-a-w or m” nor a numeric AND neither does your password, you are fine. But if only your password does, you’re fried because you cannot detect the problem during the install and at the next restart : bam ! “your password is invalid”.

The work around is to type the password with the “Qwerty 88” design in your head, a design easy to find on internet.

Simos Xenitellis  (simosx) wrote :

I suggest to change the title of this report to something like
"[20.04] Keyboard layout not enabled immediately during installation when typing username/password".

It looks like an issue of not activating the selected keyboard layout during the installation, in order to type your username/password/computer name.

I have not tested for this and I do not recall an issue, probably because I use the English US layout as the primary layout.

Dag Bjerkeli (dag-e) on 2020-04-27
summary: - Incorrect keyboard layout for selecting username and password during
- install of 20.04
+ [20.04] Keyboard layout not enabled immediately during installation when
+ typing username/password
Adolfo Jayme (fitojb) on 2020-05-13
Changed in ubiquity (Ubuntu):
status: Confirmed → Triaged
Coeur Noir (coeur-noir) wrote :

I faced the same problem while installing Ubuntu 18.04 and 20.04.

No VM here. And French for locale.

It's OK if I first « try without installing » in my language, then later launch the installer.
In this scenario, no problem with keyboard at the username/password stage, it remains french/azerty.

It's not OK when I go straight to « install ». Ubiquity stops using french/azerty keyboard at username/password stage.
And once there, there is no way to go back or abort safely.

By chance rough power off had no dramatic consequence.

Reproducible any time. And also with UbuntuBudgie ( and I guess any flavor using Ubiquity ).

Dimitri John Ledkov (xnox) wrote :

Did you try groovy, and is this issue fixed there for you? We have recently had keyboard improvement there.

Groovy images are available from http://cdimage.ubuntu.com/daily-live/pending/

Jean-Do Veuve (jeando) wrote :

I checked the Groovy version proposed by @Dimitri John Ledkov (xnox) ab

NO progress: still a US in place of the chosen localized keyboard at the introduction of the name+password.

Progress: 102 touch in place of 88 touch keyboard (numeric keyboard worked) at that moment

I checked the Groovy version proposed by @Dimitri John Ledkov with the same configuration : VM Oracle. I went directly to the minimal install, without trying the OS before as described by @coeur-noir, and the "AZERTY Belgian Keyb" configuration is recognize as such but at the moment of the introduction of name+password. There, it is still a 102 US Keyboard.

Jean-Do Veuve (jeando) wrote :

Another problem appears while installing Groovy as of now, FR speaking version, on an Oracle VM machine, the installer cannot install the bootloader (FR: "chargeur d'amorçage") with the following message (in french) "Désolé, une erreur s'est produite. Il n'a pas été possible d'installer le chargeur d'amorçage à l'emplacement indiqué." and propose to install it on another media.

I tried it twice on 2 different virtual disks but on the same physical Solid-State Disk

Jean-Do Veuve (jeando) wrote :

Worse : in an english speaking install with a AZERTY Belgian keyboard, we are back to the 88 touch US design (no numeric pad) at the same moment : introduction of name+password. I insist : 88 US Keyb. It is different in a french speaking install were the Keyboard is a 102 touch US Keyb (numeric pad work).

And for the third time, it still cannot install the boot loader.

Dimitri John Ledkov (xnox) wrote :

@jeando

The expectation is not that the keyboard is set to localised one.

But that the alternative layouts are available in the keyboard indicator in the top right, and one can switch to a localised layout. Or using Super+Space to change layouts.

Also this bug report is about norwegian language, which is very different to azerty keyboards.

Please open separate new bug report about french / french belgian / azerty keybaords. Please keep this bug report about nb_NO only.

For other bug reports about installation failures, please complete them in english and open separate bug reports.

It's not helpful to use one issue to report lots of different things.

Jean-Do Veuve (jeando) wrote :

@xnox

Okay, I double check on base of your remarks and I got deeper in the tests and eliminate the other bugs in this report. Thank you for helping to reformulate and motivate me to goes on :-)

I am more precise now and I think I may say it is exactly the same bug in all 3 languages I checked. The selected keyboard layout is NOT recognize at any point during the install process, period. I check 3 keyboards layout (and languages): Norwegian, French and Deutsch (aka German) on my VM.

In other words: at no point of the install but the moment of the selection itself, you get the keyboard layout you selected. You got a 82 US layout in the first version of 20.04, with "Groovie" it's a 102 US layout (with numeric keypad). A little progress, so.

The original bug description said: "During a fresh install of Ubuntu 20.04, selecting Norwegian keyboard is provided and keys are responding correctly at that stage. But later when entering user information the keyboard setting is wrong." Word for word, the same remark applies except, as I said before, that the problem appears sooner, too.

It may help to trace the bug that some problem exist in US layout too: the keyboard layout fall to 88 touch during the install process.

Jean-Do Veuve (jeando) wrote :

This bug is a regression: with older version of Ubuntu, such as 18.04 LTS, during the install process, you get your selected keyboard layout all along during the install process.

As I said before, this bug makes that, if you don't realize that the keyboard layout fell to US, it might happen that at the place where you choose your password, where the letters appears as "*", you use one or more characters where US and your selected keyboard layouts differs without realizing it. In that case, at the reboot (where your keyboard selection is correctly activated), you will receive the message "invalid password" on and on. If you don't realize where the bug is, it is possible that you choose to reinstall Ubuntu again and again until you choose a password where the 2 keyboard layout don't differ.

Yaron (sh-yaron) wrote :

I think that there should be a way to select layout during installation and even make a list of languages that should be optional after the installation.

In Hebrew we have a different problem where Hebrew layout is automatically selected and when we're trying to type the password for logging in after installation we're being kicked out because the layout defaults to Hebrew.

I think emphasizing the layout selection along this process will be more beneficial for users that need to switch to their layout or switch to English, maybe having some tooltip explaining how to switch keyboard layout or some accessible button at the bottom or top of the screen (just a suggestion, it's probably not that good).

Steve Langasek (vorlon) on 2020-06-25
Changed in ubiquity (Ubuntu Focal):
milestone: none → ubuntu-20.04.1
tags: removed: rls-ff-incoming
Brian Murray (brian-murray) wrote :

There is an updated version of ubiquity (20.04.15.1) in the -proposed pocket which may address this issue. Could you please test it?

Changed in ubiquity (Ubuntu Focal):
status: New → Triaged
importance: Undecided → High
status: Triaged → Incomplete
Gunnar Hjalmarsson (gunnarhj) wrote :

On 2020-06-25 18:24, Brian Murray wrote:
> There is an updated version of ubiquity (20.04.15.1) in the
> -proposed pocket which may address this issue. Could you please test
> it?

How would you go about doing that? Is there an ISO with that ubiquity version somewhere?

I would also need an ISO to start with.

Den 25.06.2020 18:55, skrev Gunnar Hjalmarsson:
> On 2020-06-25 18:24, Brian Murray wrote:
>> There is an updated version of ubiquity (20.04.15.1) in the
>> -proposed pocket which may address this issue. Could you please test
>> it?
> How would you go about doing that? Is there an ISO with that ubiquity
> version somewhere?
>

Jean-Do Veuve (jeando) wrote :

@gunnarhj @dag-e
@xnox gave the adress for ISO "Groovy images are available from http://cdimage.ubuntu.com/daily-live/pending/ "

Gunnar Hjalmarsson (gunnarhj) wrote :

That's groovy, and Brian talked about focal-proposed. But sure, if this bug is present also with the latest groovy daily build, I suppose we can conclude that the version in focal-proposed is not sufficient to fix this bug.

Jean-Do Veuve (jeando) wrote :

I checked with the last Groovy I found 45 minutes ago and the bug is still there in French-Belgian language/keyboard layout.

Jean-Do Veuve (jeando) wrote :

And still ther in German (Deutsch) also

Gunnar Hjalmarsson (gunnarhj) wrote :

I started an install using the 2020-06-25 groovy ISO, selected Swedish, but found that the effective keyboard layout in the window for entering name, password, etc. was English (US).

Changed in ubiquity (Ubuntu Focal):
status: Incomplete → Triaged
tags: added: id-5ef4c1e222b6324e1c59ad48
Steve Langasek (vorlon) wrote :

Gunnar, since there are multiple different code paths related to keyboard configuration, could you please clarify exactly which way you selected Swedish with the focal daily image?
- Did you boot under BIOS or UEFI?
- If BIOS, did you select the keyboard from the bootloader (purple screen)?
- Which boot option did you use?

Changed in ubiquity (Ubuntu Focal):
status: Triaged → Incomplete
Gunnar Hjalmarsson (gunnarhj) wrote :

On 2020-06-29 21:16, Steve Langasek wrote:
> Gunnar, since there are multiple different code paths related to
> keyboard configuration, could you please clarify exactly which way
> you selected Swedish with the focal daily image?

Please note that it was the groovy daily image (from 2020-06-25) I used.

> - Did you boot under BIOS or UEFI?

UEFI

> - Which boot option did you use?

Install Ubuntu (safe graphics)

But just now I tried again, and made an observation which may be important.

When achieving the result in comment #20 I did:

* Selected the Swedish language on the Welcome window

* When the window for keyboard layout selection showed up, the Swedish layout was pre-selected, so I just clicked "Continue".

* In the window for entering name, password etc. the English (US) layout was effective.

However - this is today's experiment:

* Selected the Swedish language on the Welcome window

* When the window for keyboard layout selection showed up, the Swedish layout was pre-selected. But I still changed to some other layout, and then changed back to the Swedish one before clicking "Continue".

* In the window for entering name, password etc. the Swedish layout was effective.

This indicates that the issue with English (US) always being effective when entering name, password etc. only happens if you accept the pre-selected layout without touching other layouts, and not when you explicitly select a layout of your choice.

Gunnar Hjalmarsson (gunnarhj) wrote :

I think I answered the questions Steve asked...

Changed in ubiquity (Ubuntu Focal):
status: Incomplete → Triaged
Dag Bjerkeli (dag-e) wrote :

I've tried groovy-desktop-amd64 downloaded yesterday (July 3rd).

Attempt 1
-----------------------------------------------------------------------
- Did you boot under BIOS or UEFI?
BIOS

- If BIOS, did you select the keyboard from the bootloader (purple screen)?
Not sure what screen this should be.

- Which boot option did you use?
Ubuntu

**Welcome**
   -> Selecting Norsk Bokmål (Norwegian)
   -> Installer Ubuntu (Install Ubuntu)

**Tastaturutforming** (Keyboard layout?)
Testing the keyboard in the input field -> OK Norwegian characters appears as they should.

Selecting defaults for remaining screens until **Hvem er du** (Who are you?)
Entering Norwegian keys in the name field gives wrong characters.

Attempt 2
-----------------------------------------------------------------------
Same as Attempt 1. But at the window **Tastaturutforming** I selected
US keyboard
Then Continue
Then Back from the Oppdateringer og annen programvare (Updates and other software?) window.
Selecting Norwegian as keyboard layout.

Selecting defaults for remaining screens until **Hvem er du** (Who are you?)
Entering Norwegian keys in the name field gives CORRECT characters.

so I can confirm Gunnar Hjalmarssons observations.

I've found how to overcome this bug.

I needed Belgian Azerty and made the selection Belgian - Belgian, and testing it always showed Azerty. Yet when I needed to fill in my username and password it always changed back to Qwerty..
I tried about 8 different combinations to try and get Azerty.. Yet always the same thing occured.

So now the solution;
When you want for example Belgian Azerty, then you have to select Belgian in the first option, then select Belgian in the second option AND then go back to the first option and double click your selection. It then goes to the next screen. You select back, and go to the previous screen. Now you see it has the selection Belgian - Belgian. If you then go to the user and password screen it gives Azerty like it should do.

If you select the first one, and then double click it (without selecting the second one, EVEN if it is already selected automaticly) then you'll see that when you return to the previous screen it jumped back to the automaticly selected first option (for me this was English) and that's why I always got Qwerty instead of Azerty.

Hope this helps. :)

Changed in ubiquity (Ubuntu):
assignee: nobody → Łukasz Zemczak (sil2100)
status: Triaged → In Progress
Łukasz Zemczak (sil2100) wrote :

Can anyone check if this is still happening on the daily groovy images?

http://cdimage.ubuntu.com/ubuntu/daily-live/current/groovy-desktop-amd64.iso

I have tried reproducing the issue on a VM with both the groovy and focal dailies with no success. That being said, as it was a quick VM check I did boot only via BIOS, but it at least feels that the boot method should not matter in this case (will double check later anyway). I tried various outlined combinations, both from #22 and #25.

I would appreciate if someone who was encountering it in the past could try reproducing it with current groovy images. Thank you!

Gunnar Hjalmarsson (gunnarhj) wrote :

Hi Łukasz!

Checked with today's daily image for groovy, and could no longer reproduce the issue. Tested both on a VM and by doing a complete install.

Tested with yesterday's daily image for focal too (only VM, though), and couldn't reproduce the issue with that either.

Jean-Do Veuve (jeando) wrote :

@sil2100

Problem solved :-)

I check the daily-live I download from the indicated address and made exactly the same install (Oracle VM running on a Ubuntu 18.04, vanilla config of the VM) that failed since 2020-04-27 and this time, at the moment of introducing the new login and password, the keyboard was in Azerty Belgian aka Belgian Keyboard as asked.

To be sure, I'll check with some other languages and if it failed, I'll write it here but I'm 99% confident that all will be OK.

You are welcome.

Jean-Do Veuve (jeando) wrote :

Hi Lukasz

I checked also in Dutch (Nederlands) and it is also solved.

Thanks

Dag Bjerkeli (dag-e) wrote :

I've checked with Norwegian keyboard and settings as I originally did. And I did not experience the problem described earlier.

I've tested both UTF-8 characters and keyboard layout.

So this appears to be solved.

Good woork!

/dag

Łukasz Zemczak (sil2100) wrote :

Thanks a lot everyone! Let's close off this bug in that case.

Changed in ubiquity (Ubuntu):
status: In Progress → Fix Released
Shlomi Shehebar (shlomzions) wrote :

After installing Ubuntu 20.04.1 LTS - Hebrew keyboard appeared to exist and super+space seems to switch between them however... no hebrew comes out...:(

Removing the keyboard from the Input Sources and immediately adding it back , solves the Issue ... however it returns after boot or after loading some browser or terminal...

ANNOYING!

Gunnar Hjalmarsson (gunnarhj) wrote :

@Shlomi: Your issue sounds more like bug #1890875.

Gunnar Hjalmarsson (gunnarhj) wrote :

Please disregard my latest comment; that bug is about bionic.

Gunnar Hjalmarsson (gunnarhj) wrote :

Unfortunately this bug seems to have resurrected in hirsute. It's actually even worse than before: When testing in a VM it uses *always* the English (US) keyboard layout in the window for entering name and password, irrespective of my previous choices of display language and keyboard layout.

Probably I should have submitted a new bug, but since a few users who were attentive to the issue previously are subscribed to this one, it would be great if others could test the latest hirsute build in this respect. Maybe it's just me...

Changed in ubiquity (Ubuntu):
status: Fix Released → Confirmed
Gunnar Hjalmarsson (gunnarhj) wrote :

Added the rls-hh-incoming tag. But the problem is still there in focal too, at least. <https://askubuntu.com/q/1308016> is a recent example.

Please give this the attention it deserves.

tags: added: rls-hh-incoming
Dag Bjerkeli (dag-e) wrote :

I've conducted a test for some ISO's that I've got:

* Groovy from 8th Oct 2020
* 20.04.01
* 20.10
* Hirsute from 17th Jan 2021

The last three were downloaded 17th Jan.

All versions had correct keyboard layout where one could test the keyboard.
Likewise all installs had correct layout after installation.

But 20.04.01 and Hirsute had incorrect keyboard-layout when username and password were to be chosen.

The keyboard layout that I tested was Norwegian.

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2021-01-18 20:49, Dag Bjerkeli wrote:
> But 20.04.01 and Hirsute had incorrect keyboard-layout when username
> and password were to be chosen.

Right, thanks for confirming. And that's what this bug is about.

tags: added: fr-1091
Changed in ubiquity (Ubuntu Focal):
milestone: ubuntu-20.04.1 → ubuntu-20.04.2
tags: removed: rls-hh-incoming
Michel-Ekimia (michel.ekimia) wrote :

We tested again on 20.04.2 :

- Exactly the same problem as described

- Also when you type your password for ciphered LUKS which is more difficult to fix ...

I think at least we should have the 'eye' to see what password is being typed ....

Changed in ubiquity (Ubuntu Focal):
milestone: ubuntu-20.04.2 → ubuntu-20.04.3
Changed in ubiquity (Ubuntu Hirsute):
milestone: none → ubuntu-21.04
Łukasz Zemczak (sil2100) wrote :

This is weird. I just tried reproducing this issue on both 20.04.2.0 release images and on the latest hirsute (21.04) dailies (Ubuntu Desktop) and failed. Steps I used to reproduce it:

1. Booted up the image on a VM
2. Ubiquity starts, on the left-hand side list I selected 'Norsk bokmål' and then the equivalent of 'Install Ubuntu'.
3. Moved through all the stages, installing the system on disk
4. On the username and password screen, I typed '[' on my keyboard and got 'å' on the input field instead - meaning the correct keyboard layout was used.

Am I doing something wrong? Can anyone tell me if I'm missing a step? Or is it no longer reproducible on both focal and hirsute *again*?

Cheers.

Changed in ubiquity (Ubuntu Hirsute):
status: Confirmed → Incomplete
Gunnar Hjalmarsson (gunnarhj) wrote :

Hi Łukasz!

I tested the latest (2021-03-11) hirsute daily build and the 20.04.2 ISO.

As regards hirsute, I can no longer reproduce the issue. If nobody has explicitly addressed this bug, the code seems to be very fragile. But let's hope that it will work now until the release. After all the installer is about to be replaced with new software, and it's more important to focus on the new installer and the coming 22.04 LTS.

As regards 20.04.2, the issue (i.e. getting [ on the username/password window instead of å when pressing the [ key) was still there for me as previously reported. It was there when I followed your steps exactly as well as when I accomplished a couple of other variants involving Swedish.

Closed the hirsute task. It would be great if you could try the 20.04.2 ISO again. Do we have an annoying "sometimes" bug?

Changed in ubiquity (Ubuntu Hirsute):
status: Incomplete → Fix Released
Dag Bjerkeli (dag-e) wrote :

I have just tested 20.10 and 20.04.02.
For 20.10 it's OK
For 20.04.02 the bug is still present.

These tests were done on both VMware 16.1 and VirtualBox 6.1 both of those on same Ubuntu 20.04.02 host.

Gunnar Hjalmarsson (gunnarhj) wrote :

Ehh.. Sorry Łukasz, but the issue was back in hirsute when I played with today's daily ISO in a VM. Fragile indeed. :(

Changed in ubiquity (Ubuntu Hirsute):
status: Fix Released → Confirmed
Gunnar Hjalmarsson (gunnarhj) wrote :

Additional observation as regards hirsute: Different behavior depending on from where the installation is started:

* The issue is present if I press "Install Ubuntu" from ubiquity's welcome screen, i.e. without trying Ubuntu.

* The issue is not present if I press "Try Ubuntu" and later start the installation via the desktop icon in the live session.

Changed in ubiquity (Ubuntu Focal):
assignee: nobody → Kadir Selçuk (turkdevops)
status: Triaged → Fix Committed
Changed in ubiquity (Ubuntu Hirsute):
status: Confirmed → Fix Released
Changed in ubiquity (Ubuntu Focal):
status: Fix Committed → Fix Released
Gunnar Hjalmarsson (gunnarhj) wrote :

Spam reversed.

Changed in ubiquity (Ubuntu Focal):
assignee: Kadir Selçuk (turkdevops) → nobody
status: Fix Released → Triaged
Changed in ubiquity (Ubuntu Hirsute):
status: Fix Released → Confirmed
Changed in ubiquity (Ubuntu Focal):
assignee: nobody → Kadir Selçuk (turkdevops)
status: Triaged → New
Gunnar Hjalmarsson (gunnarhj) wrote :

@Kadir: If you have found a solution to this bug, please show us. If not, stop changing the status and assignment of this bug!

Changed in ubiquity (Ubuntu Focal):
assignee: Kadir Selçuk (turkdevops) → nobody
status: New → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers