Description of problem:
This is a crash from openQA testing of Fedora-Server-dvd-x86_64-Rawhide-20160307.n.0.iso. It crashes immediately upon boot. Note the netinst does not crash in the same way.
Version-Release number of selected component:
The following was filed automatically by anaconda:
anaconda 25.0-1 exception report
Traceback (most recent call first):
File "/usr/lib64/python3.5/site-packages/pyanaconda/ui/gui/spokes/lib/lang_locale_handler.py", line 142, in _select_locale
locale_itr = set_treeview_selection(self._localeView, locales, col=1)
File "/usr/lib64/python3.5/site-packages/pyanaconda/ui/gui/spokes/welcome.py", line 205, in initialize
lang_itr, _locale_itr = self._select_locale(self.data.lang.lang)
File "/usr/lib64/python3.5/site-packages/pyanaconda/ui/gui/__init__.py", line 827, in run
File "/sbin/anaconda", line 1196, in <module>
IndexError: list index out of range
cmdline: /usr/bin/python3 /sbin/anaconda
cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-rawh quiet
dnf.rpm.log: Mar 07 22:27:21 INFO --- logging initialized ---
release: Cannot get release name.
Created attachment 1133919 [details]
Created attachment 1133920 [details]
Created attachment 1133921 [details]
Created attachment 1133922 [details]
Created attachment 1133923 [details]
Created attachment 1133924 [details]
Created attachment 1133925 [details]
Created attachment 1133926 [details]
Created attachment 1133927 [details]
Created attachment 1133928 [details]
Created attachment 1133929 [details]
Created attachment 1133930 [details]
I'm guessing it's crashing on `locales` here. Interestingly this doesn't seem to happen for me locally - note I'm in Canada, openQA is running in the US.
note from anaconda.log: "22:27:25,492 DEBUG anaconda: setting locale to: C.UTF-8"
An easy way to reproduce is to turn off networking. That way geolocation doesn't fix the locale to one that langtable et al can do something with.
FWIW the "note the netinst does not crash the same way" from the OP was incorrect. in openQA, both DVD and netinst crash this way. For me running locally, neither do (though the locale is still set to C.UTF-8).
Turns out that it's kind of hard to deal with locale data not actually telling us anything useful! This is going to become an issue in F24, since 5af1a3d9649c1f86a7dbc93a7844842f89c03e5d is on f24-branch as part of the fix for 1312607. However, after the change in lorax to install all glibc langpacks, and the change in glibc to ensure that at least one and most likely all langpacks get installed, anaconda can continue to use en_US.UTF-8 as the default. I'd like to revert that commit on F24 and deal with the more complicated task of handling crazy partially-available locale data on rawhide.
Proposed as a Blocker for 24-alpha by Fedora user dshea using the blocker tracking app because:
This is going to become an issue on alpha any time a user runs in an environment where geolocation data is not available. This causes a crash on the welcome screen, fitting the criterion of "The installer must run when launched normally from the release-blocking images. "
The solution is to revert a commit as outlined in the bug.
This crash hasn't actually been happening on F24, so far as I can tell.
It will once there's a new build for F24, though.
Ah...well, sbueno did build anaconda-24.13.1-1.fc24 today. So should we hold off on doing any composes with that, and wait for a new build with the patch reverted?
Discussed at today's blocker review meeting . Voted as punt (delay decision) - this isn't a regular "need more info" punt, but the status is that the current stable anaconda does not have this bug so it is not technically a blocker, but if we need a new anaconda package for any other blocker fix, this becomes a blocker and must be fixed.
Still happening in Fedora-Rawhide-20160315.n.0. Doesn't happen in F24.
Let's move this to the Beta blocker list, now Alpha was signed off with an earlier anaconda build that did not have the bug.
Is there any doable workaround available? I tend to say this bug should better be proposed as freeze exception, except we do not know how to fix (yet). Can anaconda work with a native code page? Sorry if I did not read all the comments carefully.
(In reply to David Shea from comment #24)
Okay, this means we could propose as freeze exception (see comment #26), when that upstream patch is not applied before beta freeze.
There's basically zero chance that Beta would not have a newer Anaconda build, so I'm +1 beta blocker for this.
Discussed at today's blocker review meeting . Voted as AcceptedBlocker (Beta) - this clearly violates the criteria (installer fails to run at all) and it's unlikely we can make the Beta release with the same anaconda build we used for Alpha (which did not suffer from the bug)
This is now a live issue for F24: anaconda-24.13.1-1.fc24 got pushed stable (autopush due to karma, probably granted by testers who tested by updating live images, which may bypass this bug) and anaconda now fails to run on all F24 images. See all the fails for today's F24 compose:
could we get a new F24 anaconda build with the fix for this ASAP? Thanks!
anaconda-24.13.2-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-ed73149773
*** Bug 1323489 has been marked as a duplicate of this bug. ***
Tried on a Thinkpad X220 bare metal, anaconda-24.13.2-1.fc24 works for me.
anaconda-24.13.3-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-cd26edfec7
anaconda-24.13.3-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-cd26edfec7
anaconda-24.13.3-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.