Bug 1312607 - anaconda fails to start up since glibc locale split ('locale.Error: unsupported locale setting')
anaconda fails to start up since glibc locale split ('locale.Error: unsupport...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: lorax (Show other bugs)
24
All All
unspecified Severity urgent
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
AcceptedBlocker
:
Depends On:
Blocks: F24AlphaBlocker
  Show dependency treegraph
 
Reported: 2016-02-27 15:39 EST by Adam Williamson
Modified: 2016-03-08 14:05 EST (History)
11 users (show)

See Also:
Fixed In Version: lorax-24.14-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-03-08 14:05:46 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Adam Williamson 2016-02-27 15:39:02 EST
In recent Rawhide and F24 nightlies, anaconda fails to start up at all, with a traceback ending in 'locale.Error: unsupported locale setting'. e.g. https://openqa.fedoraproject.org/tests/6228/modules/_boot_to_anaconda/steps/7 . dgilmore believes this is due to the glibc locale split, and suggests adding Requires: glibc-all-langpacks to anaconda's deps for F24+.

This is an automatic F24 Alpha blocker, under both "Complete failure of any release-blocking TC/RC image to boot at all under any circumstance - "DOA" image (conditional failure is not an automatic blocker)" (as the installer images do not boot to anything useful) and "Bugs which entirely prevent the composition of one or more of the release-blocking images required to be built for a currently-pending (pre-)release" (because this breaks building, I believe, lives and Cloud images).
Comment 1 Adam Williamson 2016-02-29 10:26:47 EST
As is currently being discussed in #anaconda, changing lorax may not be entirely sufficient. Live media creation will probably still fail as it does not use the lorax-generated environment.

I guess I'll file a new bug for that.
Comment 2 Adam Williamson 2016-02-29 10:35:57 EST
Filed https://bugzilla.redhat.com/show_bug.cgi?id=1312951 for the live media case.
Comment 3 Carlos O'Donell 2016-02-29 11:05:55 EST
The glibc team is working to put out an ASAP update that would use a slightly tweaked set of rpm dependencies to ensure glibc-all-lanpacks is pulled in by default in more cases.
Comment 4 Carlos O'Donell 2016-02-29 11:07:42 EST
Does Anaconda actually need *all* the locales?
Comment 5 David Shea 2016-02-29 11:27:36 EST
https://github.com/rhinstaller/anaconda/pull/531 should make things behave a bit better on the anaconda side.

(In reply to Carlos O'Donell from comment #4)
> Does Anaconda actually need *all* the locales?

Are you saying we should pick and choose which locale data and languages we actually need? That sounds super annoying.

This isn't just about language. The locale chosen by the user affects the behavior of several aspects of the install, like text direction and time display, so yeah, it'd be nice to have all of them.
Comment 6 Adam Williamson 2016-02-29 12:27:36 EST
I'm guessing that in theory anaconda only needs the locales relevant to the languages it offers. However, as David says, I think trying to make the dependency that specific would be difficult in practice (the anaconda language support list, IIRC, is actually dynamically generated based on the translation status in Zanata).

If there's going to be some sort of 'all the remotely sane langpacks' virtual package or something, that would probably work for anaconda in practice? But it's hard to be sure how to answer your question.
Comment 7 Carlos O'Donell 2016-03-01 03:29:23 EST
(In reply to Adam Williamson from comment #6)
> I'm guessing that in theory anaconda only needs the locales relevant to the
> languages it offers. However, as David says, I think trying to make the
> dependency that specific would be difficult in practice (the anaconda
> language support list, IIRC, is actually dynamically generated based on the
> translation status in Zanata).
> 
> If there's going to be some sort of 'all the remotely sane langpacks'
> virtual package or something, that would probably work for anaconda in
> practice? But it's hard to be sure how to answer your question.

You answered my question. The `glibc-all-langpacks` is the virtual "provide everything and the kitchen sink", and that's what Anaconda should use. It provides all the locales in a minimized form.
Comment 8 Carlos O'Donell 2016-03-01 03:32:46 EST
With glibc-2.23.90-3.fc25 and glibc-2.23.1-5.fc24 we have now fixed
the issue in several important ways.

See:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WXOOUGA3YCB2O4O77JGLSJZ25BS4RFK5/

You should now always get glibc-all-langpacks by default.
Comment 9 stalinswag1 2016-03-01 10:14:10 EST
(In reply to Carlos O'Donell from comment #8)
> With glibc-2.23.90-3.fc25 and glibc-2.23.1-5.fc24 we have now fixed
> the issue in several important ways.
> 
> See:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
> message/WXOOUGA3YCB2O4O77JGLSJZ25BS4RFK5/
> 
> You should now always get glibc-all-langpacks by default.

When this bugfix be applied for Rawhide ISO image?
Comment 10 Adam Williamson 2016-03-01 10:51:17 EST
Bodhi is not enabled for F24 ATM, so the next F24 and Rawhide composes that happen should include it (in fact they may have happened since Carlos posted his comment)...
Comment 11 Adam Williamson 2016-03-02 04:10:23 EST
current Rawhide and Branched nightlies are still hitting this, so I don't think the changes to the glibc package help the anaconda environment case. bcl, could you please do F24 and Rawhide builds of lorax so we can get past this bug? until this is fixed we really can't tell what all else is still broken in F24/Rawhide with the compose process changes and so on, because all our tests blow up right away. thanks!
Comment 12 Carlos O'Donell 2016-03-02 07:08:35 EST
(In reply to Adam Williamson from comment #11)
> current Rawhide and Branched nightlies are still hitting this, so I don't
> think the changes to the glibc package help the anaconda environment case.
> bcl, could you please do F24 and Rawhide builds of lorax so we can get past
> this bug? until this is fixed we really can't tell what all else is still
> broken in F24/Rawhide with the compose process changes and so on, because
> all our tests blow up right away. thanks!

The changes to f24 and f25 make it a requirement to install glibc with a langpack. The default langpack the dependency solver will use is glibc-all-langpacks because of the suggestion in glibc package.

Could you please verify you actually have glibc-2.23.90-3.fc25 or glibc-2.23.1-5.fc24? Until those two packages enter your builds you'll have problems.

Is there any way I reproduce this on my end to make sure we didn't miss anything?
Comment 13 Brian Lane 2016-03-02 11:04:11 EST
I built lorax with the glibc-all-langpacks fix last night. So depending on timing of compose vs. build it may have used the old lorax. Check the compose logs to see if the new package was included.
Comment 14 Adam Williamson 2016-03-02 11:29:17 EST
MMMMMMMMM THIS HUMBLE PIE IS DELICIOUS

that'll teach me not to click on thumbnails. turns out the openQA tests for 2016-03-02 weren't failing on the anaconda bug, they were failing because they couldn't find the ISO, and they couldn't find the ISO because some idiot monkey forgot to restart the scheduler after changing the ISO download code...

excuse me while I put some salt on my hat to go with this pie!

now I fixed the scheduler, we have a Rawhide test actually running anaconda:

https://openqa.fedoraproject.org/tests/7016

so it does indeed look like one change or the other fixed this.

I'll just confirm that Branched works too, but this looks good.
Comment 15 Adam Williamson 2016-03-02 11:32:55 EST
For the record, the last tests that actually failed in anaconda were Fedora-24-20160301.n.0:

https://openqa.fedoraproject.org/tests/6634

that tree has lorax-24.13-1.fc25.x86_64.rpm and glibc-2.23.90-2.fc25.i686.rpm , so we can't tell for sure whether glibc change alone would've fixed this from that. If bcl wants to know if he could drop the lorax change, I'll download some ISOs from the composes in the middle if I can find one with the glibc change but not the lorax change and check manually.
Comment 16 Adam Williamson 2016-03-02 11:33:58 EST
damnit, looked at the wrong tree, but same info - it has glibc-2.23.1-4.fc24.x86_64.rpm and lorax-24.13-1.fc24.x86_64.rpm , i.e. the non-fixed package in both cases.
Comment 17 Carlos O'Donell 2016-03-02 11:40:04 EST
(In reply to Adam Williamson from comment #16)
> damnit, looked at the wrong tree, but same info - it has
> glibc-2.23.1-4.fc24.x86_64.rpm and lorax-24.13-1.fc24.x86_64.rpm , i.e. the
> non-fixed package in both cases.

Right, those are the old glibc packages with the upgrade issues.

F24 compose includes the fixed version as of yesterday:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/AKFL6K2HNWBY6W535OVQW3QIHC2OV2YN/

F25 compose includes the fixed version as of today:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/SFVADLBHDFSXPV3UCQTEHDCTGUMLXEX3/

So you'd have to use the latest composes to get the fix.
Comment 18 Adam Williamson 2016-03-02 11:46:29 EST
right, I've already said the latest trees are fixed. But what I'm trying to determine now is whether the glibc fix was sufficient or if the lorax fix was still needed.
Comment 19 Carlos O'Donell 2016-03-02 11:48:29 EST
(In reply to Adam Williamson from comment #18)
> right, I've already said the latest trees are fixed. But what I'm trying to
> determine now is whether the glibc fix was sufficient or if the lorax fix
> was still needed.

OK, the glibc fix is sufficient to fix the locale.Error, if it isn't, then I'd like to know and dig deeper. Other issues I can't comment on.
Comment 20 Adam Williamson 2016-03-08 14:05:46 EST
Welp, I've got a ton of stuff on my plate and this is definitely fixed one way or the other, so let's just close it for now.

Note You need to log in before you can comment on or make changes to this bug.