Description of problem:
Probably due to the changes in locales in Fedora the g-i-s crashes when I choose language. The language I chose is selected after restart.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install system from livecd (I installed it in Czech language) and don't create an user in anaconda
2. Boot the installed system to gnome-initial-setup
3. Choose some language
language changed and g-i-s still works
I propose this as an alpha blocker as it violates the criterion: "A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
The g-i-s works when user doesn't change language. User can even change the keyboard without crashig g-i-s.
Created attachment 1137347 [details]
output of journalctl -f during the crash
Discussed at 2016-03-17 Go/No-Go meeting, acting as a blocker review meeting: https://meetbot.fedoraproject.org/fedora-meeting/2016-03-17/f24-alpha-go_no_go-meeting.2016-03-17-17.00.html . Rejected as an Alpha blocker; we agreed this is a conditional violation of the criteria but too narrow to qualify as an Alpha blocker, it requires you to both not create a user in anaconda *and* change the language in g-i-s, we thought for an Alpha, that's too narrow.
By an oversight we didn't consider it for FE status, but I'm nominating it for that now. It could also be re-proposed as a blocker for a later milestone if a fix doesn't show up soon.
Could someone post a backtrace please?
Hum, I tried to reproduce this as described, but could not...sorry. Maybe Petr can.
(In reply to Adam Williamson from comment #4)
> Hum, I tried to reproduce this as described, but could not...sorry. Maybe
> Petr can.
I could not reproduce it either.
I used Fedora-Workstation-Live-x86_64-24_Alpha-5.iso, installed
in Japanese, did *not* create a user in Anaconda (I entered the root
password in Anaconda), and then selected German in gnome-initial-setup.
It is strange that
glibc-langpack-en-2.23.1-5.fc24.x86_64 *and* glibc-all-langpacks-2.23.1-5.fc24.x86_64
are installed. If glibc-all-langpacks is installed, then glibc-langpack-en
is redundant. And why glibc-langpack-en, why not glibc-langpack-ja if
the installation was done in Japanese?
Probably because we added something somewhere to make sure glibc-langpack-en is pulled in for anaconda, I'm guessing.
Using NEEDINFO to request a backtrace (you might need to use 'sudo abrt-cli' to get it)
Discussed at today's blocker review meeting . Voted as AcceptedFreezeException (Alpha) - though this one seems a bit vague at present, there's certainly a potential serious issue here, so we accept it as FE and if a clearly reproducible case is found and fixed, we will look at taking the fix
I reproduced this with final release. I clicked on few languages in g-i-s and it crashed. I tried to reproduce after restart and it happened again (spanish -> german -> english -> crash)
I reported this with abrt-cli - bug 1350873
*** This bug has been marked as a duplicate of bug 1350873 ***