[gentoo-user] glibc-2.17 fails and warning: setlocale: LC_ALL error

[Dale]

Howdy,

I'm reinstalling Gentoo on my OLD rig. It's x86. I have two issues
which will be seen in the error below. Sort of hard to miss. Anyway, I
started with the latest stage3 tarball. I've got it to where it boots
up and all and am in the process of trying to do a emerge -e system
which will also update everything as well. My problem is glibc and the
locale settings. May be a separate issue or related. Here is the boo
boo.

localhost linux # emerge -v glibc
sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)

* IMPORTANT: 5 news items need reading for repository 'gentoo'.
* Use eselect news to read news items.


These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] sys-libs/glibc-2.17:2.2 USE="-debug -gd (-hardened)
(-multilib) -nscd -profile (-selinux) -suid -systemtap -vanilla" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-libs/glibc-2.17
>>> Failed to emerge sys-libs/glibc-2.17, Log file:
>>> '/var/tmp/portage/sys-libs/glibc-2.17/temp/build.log'
>>> Jobs: 0 of 1 complete, 1 failed Load avg: 0.16,
0.39, 1.44
* Package: sys-libs/glibc-2.17
* Repository: gentoo
* Maintainer: tool...@gentoo.org
* USE: abi_x86_32 elibc_glibc kernel_linux userland_GNU x86
* FEATURES: preserve-libs sandbox
[sys-libs/glibc-2.17] bash: warning: setlocale: LC_ALL: cannot change
locale (en_US.UTF8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF8) <<-- This error right here. :-(
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
make -j3 -s glibc-test
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
make -j3 -s glibc-test
* Your old kernel is broken. You need to update it to
* a newer version as syscall(<bignum>) will break.
* http://bugs.gentoo.org/279260
* ERROR: sys-libs/glibc-2.17::gentoo failed (setup phase):
* keeping your system alive, say thank you
*
* Call stack:
* ebuild.sh, line 93: Called pkg_setup
* glibc-2.17.ebuild, line 151: Called eblit-run 'pkg_setup'
* glibc-2.17.ebuild, line 137: Called eblit-glibc-pkg_setup
* pkg_setup.eblit, line 75: Called die
* The specific snippet of code:
* die "keeping your system alive, say thank you"
*
* If you need support, post the output of `emerge --info
'=sys-libs/glibc-2.17::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=sys-libs/glibc-2.17::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/sys-libs/glibc-2.17/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/sys-libs/glibc-2.17/temp/die.env'.
* Working directory: '/usr/lib/portage/pym'
* S: '/var/tmp/portage/sys-libs/glibc-2.17/work/glibc-2.17'
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
/bin/bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
*
* The following package has failed to build or install:
*
* (sys-libs/glibc-2.17::gentoo, ebuild scheduled for merge), Log file:
* '/var/tmp/portage/sys-libs/glibc-2.17/temp/build.log'
*
localhost linux #


One reason I want to re-emerge glibc, I'm HOPING it will fix the other
LC_ALL error. I'm pretty sure glibc takes care of that but not 100%
sure. I checked my main rig for differences in USE flags, multilib is
the only one I see. It is set on my main rig and doesn't seem to be
available on x86 for obvious reasons.

If this is not enough info, let me know what you need. I don't want to
flood with tons of unneeded info when usually that above gives enough of
a hint. ;-)

Thanks.

Dale

:-) :-)

[Hinnerk van Bruinehsen]

On Mon, Jul 14, 2014 at 08:50:58PM -0500, Dale wrote:
> Howdy,
>
> I'm reinstalling Gentoo on my OLD rig. It's x86. I have two issues
> which will be seen in the error below. Sort of hard to miss. Anyway, I
> started with the latest stage3 tarball. I've got it to where it boots
> up and all and am in the process of trying to do a emerge -e system
> which will also update everything as well. My problem is glibc and the
> locale settings. May be a separate issue or related. Here is the boo
> boo.
>

<SNIP>

> * Package: sys-libs/glibc-2.17
> * Repository: gentoo
> * Maintainer: tool...@gentoo.org
> * USE: abi_x86_32 elibc_glibc kernel_linux userland_GNU x86
> * FEATURES: preserve-libs sandbox
> [sys-libs/glibc-2.17] bash: warning: setlocale: LC_ALL: cannot change
> locale (en_US.UTF8)
> /bin/bash: warning: setlocale: LC_ALL: cannot change locale
> (en_US.UTF8) <<-- This error right here. :-(

<SNIP> <error1 above>

> * Your old kernel is broken. You need to update it to
> * a newer version as syscall(<bignum>) will break.

<SNIP> <error 2 above>

>
> One reason I want to re-emerge glibc, I'm HOPING it will fix the other
> LC_ALL error. I'm pretty sure glibc takes care of that but not 100%
> sure. I checked my main rig for differences in USE flags, multilib is
> the only one I see. It is set on my main rig and doesn't seem to be
> available on x86 for obvious reasons.
>
> If this is not enough info, let me know what you need. I don't want to
> flood with tons of unneeded info when usually that above gives enough of
> a hint. ;-)
>

Hi Dale,

first you should check if you have this line in your /etc/locale.gen:
en_US.UTF-8 UTF-8

If you do, run locale-gen to create the locale. This should in theory fix the
LC_<foo> errors (Note: there are some LC_ settings best left undisturbed,
especially setting LC_ALL to something other than "C" tends to break stuff).

The other error you get (glibc failing to install) seem to be caused by an old
kernel version that wouldn't be compatible with the newer glibc. So I'd
recommend that you try to update your kernel first.

WKR
Hinnerk

[Dale]

Hinnerk van Bruinehsen wrote:
>
>
> Hi Dale,
>
> first you should check if you have this line in your /etc/locale.gen:
> en_US.UTF-8 UTF-8
>
> If you do, run locale-gen to create the locale. This should in theory fix the
> LC_<foo> errors (Note: there are some LC_ settings best left undisturbed,
> especially setting LC_ALL to something other than "C" tends  to break stuff).

Howdy,

I looked at that file.  On both my systems, it is not a text file.  When I look at it in a file manager, Konqueror via fish, it shows up as "GENESIS rom" for type.  Since it is not text on either of my machines, I'm nervous about editing that thing.  Are we certain it is safe to mess with???   O_O

>
>
> The other error you get (glibc failing to install) seem to be caused by an old
> kernel version that wouldn't be compatible with the newer glibc. So I'd
> recommend that you try to update your kernel first.
>
> WKR
> Hinnerk

This is interesting.  I'm using this version:  3.15.5-gentoo According to equery, that's as new as it gets.  I thought about going back to a older version but that seemed odd given the error.  I been dealing with this for about two days now.  My 3 lb mini sledge is starting to look interesting.  @_@

Thoughts?

Dale

:-)  :-)

[Hinnerk van Bruinehsen]

On Mon, Jul 14, 2014 at 09:19:27PM -0500, Dale wrote:
> Hinnerk van Bruinehsen wrote:
> >
>
> >
>
> > Hi Dale,
>
> >
>
> > first you should check if you have this line in your
> /etc/locale.gen:
>
> > en_US.UTF-8 UTF-8
>
> >
>
> > If you do, run locale-gen to create the locale. This should
> in theory fix the
>
> > LC_<foo> errors (Note: there are some LC_ settings best
> left undisturbed,
>
> > especially setting LC_ALL to something other than "C" tends 
> to break stuff).
>
> Howdy,
>
> I looked at that file.  On both my systems, it is not a text file.  When I
> look at it in a file manager, Konqueror via fish, it shows up as "GENESIS
> rom" for type.  Since it is not text on either of my machines, I'm nervous
> about editing that thing.  Are we certain it is safe to mess with???   O_O

Here's the contents of mine:

==============BEGIN====================
# /etc/locale.gen: list all of the locales you want to have on your system
#
# The format of each line:
# <locale> <charmap>
#
# Where <locale> is a locale located in /usr/share/i18n/locales/ and
# where <charmap> is a charmap located in /usr/share/i18n/charmaps/.
#
# All blank lines and lines starting with # are ignored.
#
# For the default list of supported combinations, see the file:
# /usr/share/i18n/SUPPORTED
#
# Whenever glibc is emerged, the locales listed here will be automatically
# rebuilt for you. After updating this file, you can simply run `locale-gen`
# yourself instead of re-emerging glibc.

#en_US ISO-8859-1
en_GB.UTF-8 UTF-8
en_US.UTF-8 UTF-8
de_DE.UTF-8 UTF-8
#ja_JP.EUC-JP EUC-JP
#ja_JP.UTF-8 UTF-8
#ja_JP EUC-JP
#en_HK ISO-8859-1
#en_PH ISO-8859-1
#de_DE ISO-8859-1
#de_DE@euro ISO-8859-15
#es_MX ISO-8859-1
#fa_IR UTF-8
#fr_FR ISO-8859-1
#fr_FR@euro ISO-8859-15
#it_IT ISO-8859-1

=================END=================
Note that I also enable 2 other (en_GB and de_DE) that you probably don't
need.

>
> >
>
> >
>
> > The other error you get (glibc failing to install) seem to be
> caused by an old
>
> > kernel version that wouldn't be compatible with the newer
> glibc. So I'd
>
> > recommend that you try to update your kernel first.
>
> >
>
> > WKR
>
> > Hinnerk
>
> This is interesting.  I'm using this version:  3.15.5-gentoo According to
> equery, that's as new as it gets.  I thought about going back to a older
> version but that seemed odd given the error.  I been dealing with this for
> about two days now.  My 3 lb mini sledge is starting to look interesting. 
> @_@
>
> Thoughts?

That's interesting: maybe that kernel is too new. Which version of glibc is
installed right now (It may be helpful to make a guess which kernel version
should work). Otherwise according to the Changelogs of gentoo-sources and glic
the kernel version was something around 3.6.x when glibc-2.17 was added to the
tree.

WKR
Hinnerk

[Dale]

I thought that should be a text file. I know I had to edit mine on the
new rig a long time ago but was to chicken to try it. I opened a weird
file once and made a mess so I didn't want to try that again. I wonder,
that likely came from the stage3 tarball that way. Bug maybe?? Some
files I just copied over but some I can't since one is 64 bit and one 32
bit. Example, parts of make.conf was a serious no on that.

I'll test this on the old rig first. ;-) May even just rename it and
start fresh, just in case.

>> This is interesting. I'm using this version: 3.15.5-gentoo According to
>> equery, that's as new as it gets. I thought about going back to a older
>> version but that seemed odd given the error. I been dealing with this for
>> about two days now. My 3 lb mini sledge is starting to look interesting.
>> @_@
>>
>> Thoughts?
> That's interesting: maybe that kernel is too new. Which version of glibc is
> installed right now (It may be helpful to make a guess which kernel version
> should work). Otherwise according to the Changelogs of gentoo-sources and glic
> the kernel version was something around 3.6.x when glibc-2.17 was added to the
> tree.
>
> WKR
> Hinnerk

That's why I decided to just ask. The version is 2.17. We have storms
close by so I shutdown the rig but pretty sure it was just a recompile
of the same version. Once this storm passes, I'll try a newer version.

Thanks. Maybe this will get things moving again.

Dale

:-) :-)

[Dale]

UPDATE: Thanks to Hinnerk, the locale error is fixed. I am still
looking for ideas on the glibc error tho. Since this original post, I
have tried the following versions of glibc with the same result.

sys-libs/glibc-2.18-r1
sys-libs/glibc-2.19-r1

So, it seems something else is wrong here. I have googled and most
things I find are with older kernels and I'm using the newest kernel I
can find in the tree. 3.15.5-gentoo

Ideas? Fixes? Bug that needs Raid?

Dale

:-) :-)

[Hinnerk van Bruinehsen]

On Tue, Jul 15, 2014 at 12:33:57AM -0500, Dale wrote:
<SNIP>

> > make -j3 -s glibc-test
> > * Your old kernel is broken. You need to update it to
> > * a newer version as syscall(<bignum>) will break.
> > * http://bugs.gentoo.org/279260
> > * ERROR: sys-libs/glibc-2.17::gentoo failed (setup phase):
> > * keeping your system alive, say thank you
> > *
> > * Call stack:

<SNIP>

> UPDATE: Thanks to Hinnerk, the locale error is fixed. I am still
> looking for ideas on the glibc error tho. Since this original post, I
> have tried the following versions of glibc with the same result.
>
> sys-libs/glibc-2.18-r1
> sys-libs/glibc-2.19-r1
>
> So, it seems something else is wrong here. I have googled and most
> things I find are with older kernels and I'm using the newest kernel I
> can find in the tree. 3.15.5-gentoo
>
> Ideas? Fixes? Bug that needs Raid?

I've taken a look at the bug that is mentioned in the error and there were
several things mentioned that are supposed to fix this:

1. disable auditd (if you have it running) - this was the newest (from '14)
So if you have it installed run /etc/init.d/auditd stop
2. reemerge several packages because python may have issues:
- sync your tree
- emerge portage (which will likely pull in some python stuff if the box
wasn't updated for some time)
(- optional: run eselect python and select a sane version and run python
updater - this wasn't mentioned but may make sense nonetheless)
- emerge linux-headers
- emerge glibc (hopefully with success this time)

WKR
Hinnerk

[Dale]

Hinnerk van Bruinehsen wrote:
> I've taken a look at the bug that is mentioned in the error and there were
> several things mentioned that are supposed to fix this:
>
> 1. disable auditd (if you have it running) - this was the newest (from '14)
> So if you have it installed run /etc/init.d/auditd stop
> 2. reemerge several packages because python may have issues:
> - sync your tree
> - emerge portage (which will likely pull in some python stuff if the box
> wasn't updated for some time)
> (- optional: run eselect python and select a sane version and run python
> updater - this wasn't mentioned but may make sense nonetheless)
> - emerge linux-headers
> - emerge glibc (hopefully with success this time)
>
> WKR
> Hinnerk

I didn't have the audit stuff installed BUT it was turned on in the
kernel. I kicked that out and also got rid of all that cgroup stuff I
don't have any need for. Rebooted then tried your list. Audit stuff,
gone. Sync is maybe a couple days old so should be OK. Portage is up to
date. Python as follows:

dev-lang/python-2.7.6
dev-lang/python-3.3.3

localhost ~ # eselect python list
Available Python interpreters:
[1] python2.7 *
[2] python3.3
localhost ~ #

Updated linux-headers. It was a little out of sync with kernel
version. After all that, I get this:

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] sys-libs/glibc-2.17:2.2 USE="-debug -gd (-hardened)
(-multilib) -nscd -profile (-selinux) -suid -systemtap -vanilla" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

>>> Verifying ebuild manifests
>>> Emerging (1 of 1) sys-libs/glibc-2.17
>>> Failed to emerge sys-libs/glibc-2.17, Log file:
>>> '/var/tmp/portage/sys-libs/glibc-2.17/temp/build.log'

>>> Jobs: 0 of 1 complete, 1 failed Load avg: 0.27,
0.59, 0.43

* Package: sys-libs/glibc-2.17
* Repository: gentoo
* Maintainer: tool...@gentoo.org
* USE: abi_x86_32 elibc_glibc kernel_linux userland_GNU x86
* FEATURES: preserve-libs sandbox

make -j3 -s glibc-test

make -j3 -s glibc-test
* Your old kernel is broken. You need to update it to
* a newer version as syscall(<bignum>) will break.
* http://bugs.gentoo.org/279260
* ERROR: sys-libs/glibc-2.17::gentoo failed (setup phase):
* keeping your system alive, say thank you
*
* Call stack:

* ebuild.sh, line 93: Called pkg_setup
* glibc-2.17.ebuild, line 151: Called eblit-run 'pkg_setup'
* glibc-2.17.ebuild, line 137: Called eblit-glibc-pkg_setup
* pkg_setup.eblit, line 75: Called die
* The specific snippet of code:

* die "keeping your system alive, say thank you"
*

* If you need support, post the output of `emerge --info
'=sys-libs/glibc-2.17::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=sys-libs/glibc-2.17::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/sys-libs/glibc-2.17/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/sys-libs/glibc-2.17/temp/die.env'.
* Working directory: '/usr/lib/portage/pym'
* S: '/var/tmp/portage/sys-libs/glibc-2.17/work/glibc-2.17'

*
* The following package has failed to build or install:
*
* (sys-libs/glibc-2.17::gentoo, ebuild scheduled for merge), Log file:
* '/var/tmp/portage/sys-libs/glibc-2.17/temp/build.log'
*

localhost ~ #

So, the locale junk is gone but glibc is still not liking something.
Where did I put that hammer the last time I used it?? ;-)

Ideas? I'm pretty much out of them right now. My idea is the hammer.
lol

Dale

:-) :-)

[Hinnerk van Bruinehsen]

<SNIP>

>
> So, the locale junk is gone but glibc is still not liking something.
> Where did I put that hammer the last time I used it?? ;-)
>
> Ideas? I'm pretty much out of them right now. My idea is the hammer.
> lol

Generally hammers tend to make things worse... ;-)

Can you run;

printf "#include <unistd.h>\n#include <sys/syscall.h>\nint main(){return \
syscall(1000)!=-1;}\n" > syscall.c && make syscall && ./syscall && echo $?

(It should be all one line).
It will compile the test that seems to fail on your system and runs it,
expected output would be:

cc syscall.c -o syscall

0

The "0" says that all went well, if it reports something else then it's not
just the buildsystem...

If it's the system you'll have to reinstall glibc (no kidding, as it provides
the used headers (though they should be somewhat dependent on linux-headers)).

You could do the following to break out of this chicken-and-egg-problem:
you can download an appropriate stage3-tarball (x86 or amd64) and extract it to
some arbitrary location. Then you essentially do the same as if you would
install gentoo from scratch (bind mount dev and sys and mount proc) and chroot
into it.
Inside the chroot you sync your tree (you could also bind-mount it from the
default location) and emerge glibc again but this time with the --build-pkg
flag set (emerge --buildpkg glibc). As long as you kernel is new enough (which
3.15.5 definitely is) the build should succeed and leave you with a nice binpkg
of glibc sitting in <path-to-chroot>/usr/portage/packages (in case of the
bind mount it should also be there inside your real system). If needed copy
it to /usr/portage/packages and run emerge -K glibc (this will force portage
to use the binpkg).

I hope that this es enough to circumvent the check (if not you could also try
to boot your rig from usb and copy the contents of the binpkg manually).

If the build breaks even inside the chroot run uname -a and take a look if the
kernel you're running acutally reports to be a 3.15.5 one.

Good luck,
Hinnerk

[Hinnerk van Bruinehsen]

On a side note:

You can also boot into a chroot, move your /etc and /var directories elsewhere
(e.g. etc_old and var_old) (do the same for other directories where you
yourself made changes), extract a stage 3 tarball on top of your normal
/ directory (overwriting potentially broken stuff), move etc_old and var_old
back to their old locations/names, chroot into it (like during install) and
emerge @system @world -evDNa (to rebuild everything from the known-good start
that the stage3 provides).

[Dale]

It's getting close to nap time here. Also, more stormy stuff could pop
up at any time. I shut the old rig back down again. It doesn't have a
UPS or anything on it. Anyway, I suspect strongly that the error is on
the stage3 tarball. I got it installed but I have not been able to get
a clean emerge -e system as of yet. I generally unpack, get things to
where I can emerge and then do a emerge -e system as soon as I can.
That way anything else I build is built on top of updated packages. I
have installed Gentoo so many times it is pitiful.

What I may do, unpack the stage3 somewhere, recompile glibc to create a
binary and then install that package. I'm not going to be to shocked if
it fails to build straight out of the stage3 tarball tho.

I'm going to work on this some more when I get both eyes open.

Dale

:-) :-)

[Douglas J Hunley]

On Tue, Jul 15, 2014 at 2:25 AM, Dale <rdale...@gmail.com> wrote:

Anyway, I suspect strongly that the error is on
the stage3 tarball.  I got it installed but I have not been able to get
a clean emerge -e system as of yet.

I know you say you have the latest kernel installed, Dale, but are you certain it's the running kernel? uname -r to confirm :)

--

Douglas J Hunley (doug....@gmail.com)
Twitter: @hunleyd                                               Web: about.me/douglas_hunley
G+: http://google.com/+DouglasHunley

[Dale]

Yep.  I posted that somewhere in this thread.  Usually when I first install a kernel, I do a uname -r just to be certain.  Even tho that was a fresh install, I checked it anyway.  Sounds silly since it was the only kernel there but it's a habit now.  lol  I do that on my main rig too. 

Sometimes it is those simple things that bite us tho.  It's always worth a mention.  < thumbs up > 

Dale

:-)  :-) 

[Dale]

I tried this. I unpacked the stage3 tarball just like I would for a new
install, in /mnt/gentoo of course. I set it up just enough to where I
could try and emerge glibc and just see if it would complete or if it
would fail. It failed. It seems to me that while it may be complaining
about the kernel version, something else is really the issue. I'm using
the latest kernel so it can't be that. I also installed linux-headers
and tried again, still failed.

I also checked on the locale,gen file. It is the wrong file type within
the tarball. It shows up as GENESIS rom there as well instead of a
plain text file.

It seems to me that the stage3 tarball is broke. I'm not sure what else
to try at this point. When the source is broke, it's sort of hard to
fix the rest.

Where to go from here?

Dale

:-) :-)

[Helmut Jarausch]

On 07/16/2014 09:32:31 AM, Dale wrote:
> I tried this. I unpacked the stage3 tarball just like I would for a
> new
> install, in /mnt/gentoo of course. I set it up just enough to where I
> could try and emerge glibc and just see if it would complete or if it
> would fail. It failed. It seems to me that while it may be
> complaining
> about the kernel version, something else is really the issue. I'm
> using
> the latest kernel so it can't be that. I also installed linux-headers
> and tried again, still failed.

What kernel version are you using?
On one machine I have strange effects with kernel 3.15.x (including
3.15.5)
Portage hangs. Attaching gdb to it one can see that hangs in the glibc
call
__epoll_wait_nocancel
called from pyepoll_poll from PyRun_FileExFlags

Just stepping back to 3.14.12 solves the problem.
(I do have linux-headers-3.15 installed here)

Helmut

[Dale]

3.15.5-gentoo

I got a different tarball, going to test that. If it fails, may step
back a kernel version and see if that helps. It's faster than
re-installing from scratch again. ;-)

Dale

:-) :-)

[Dale]

UPDATE: I downloaded a different stage3 tarball and I think I see
progress. It has a couple errors that I had to fix, had to run
gcc-config for one, but it looks like glibc is running longer than
before. It seems to be compiling now. So, it seems that other tarball
has some issues and needs a hammer.

Now to figure out if I want to try and use the binary from this new
tarball on the current install OR just install Gentoo again from scratch.

Dale

:-) :-)

[J. Roeleveld]

I would start from scratch. Who knows what else is broken?

--
Joost
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Dark Templar]

16.07.2014 14:33, J. Roeleveld пишет:

When I reinstalled gcc and glibc, migrating from non-multilib amd64 arch
to multilib one, I just unpacked gentoo stage3 into temporary directory,
chrooted there, made binary packages out of installed ones (quickpkg
<name>), copied resulted binary packages and their metadata to host
system (i.e. moved $chroot/usr/portage/packages into
/usr/portage/packages) and installed those binary packages replacing
current ones. It's fast (you don't have to build packages from scratch),
and it didn't fail me even once, although I heard playing with glibc
such way may be dangerous (particularly, downgrading it). I guess it
works for other purposes too.

I don't like installing from scratch if there is a way to fix it. I
don't like that approach 'unpack stage on top of your system', because
it will lead to system pollution: a lot of files might be no longer
tracked by package manager after that.

But that's just my experience and opinion. I hope it can help you.

[Dale]

Dark Templar wrote:
> When I reinstalled gcc and glibc, migrating from non-multilib amd64 arch
> to multilib one, I just unpacked gentoo stage3 into temporary directory,
> chrooted there, made binary packages out of installed ones (quickpkg
> <name>), copied resulted binary packages and their metadata to host
> system (i.e. moved $chroot/usr/portage/packages into
> /usr/portage/packages) and installed those binary packages replacing
> current ones. It's fast (you don't have to build packages from scratch),
> and it didn't fail me even once, although I heard playing with glibc
> such way may be dangerous (particularly, downgrading it). I guess it
> works for other purposes too.
>
> I don't like installing from scratch if there is a way to fix it. I
> don't like that approach 'unpack stage on top of your system', because
> it will lead to system pollution: a lot of files might be no longer
> tracked by package manager after that.
>
> But that's just my experience and opinion. I hope it can help you.
>
>

If I can install something as a binary and then get a clean emerge -e
system/world out of it, I think it would be OK. Thing is, I'm concerned
something is amiss with the stage3 tarball. If that is the case, I want
to inform the person that overseas that so it can be fixed. Installing
Gentoo is hard enough for someone seasoned but would be a nightmare for
someone new to Gentoo.

Now to figure out what is the root problem on this thing.

Dale

:-) :-)

[Dale]

And then I went back to add the -B option and it failed. So, it built
the first time but fails the 2nd time. I'm beginning to wonder about
those stage3 tarballs for x86. Do they test those from time to time to
make sure they work or do they just autobuild them and upload them? I'm
following the install guide so I'm pretty sure I'm not doing anything
wrong but at the same time, I don't want to file a bug when it is just me.

I may play with this some more. It is starting to get old tho. What
concerns me is if it has the same issue for someone new to Gentoo. At
least I been around the block a few times. A noobie is going to pull
all their hair out thinking they are not doing something right.

Dale

:-) :-)

[Mick]

I believe that you used MAKEOPTS="-j3", can you try with "-j1"? I seem to
recall some random glibc failure which for me was fixed with -j1, but I can't
recall anything about not liking the kernel when it was doing its checks.
That's a few years back now.

--
Regards,
Mick

[Dale]

Heck, I'll give that a shot. It's not like it is going to blow smoke or
anything. Heck, maybe it will work. ;-)

Dale

:-) :-)

[walt]

On 07/16/2014 10:21 AM, Dale wrote:
> I'm beginning to wonder about
> those stage3 tarballs for x86. Do they test those from time to time to
> make sure they work or do they just autobuild them and upload them? I'm
> following the install guide so I'm pretty sure I'm not doing anything
> wrong but at the same time, I don't want to file a bug when it is just me.

Over the years I remember maybe three times I've had to untar a stage3 on
top of a "working" system, and IIRC the catastrophic problem was glibc each
time :/

Anyway, the first time I tried it I learned that the stage3 overwrites the
existing /etc directory. (That was so painful I remembered to move /etc out
of the way the next two times it did it :)

I mention all this because /etc/locale.conf may not be the file you expect,
based on how your compile environment and chroot stuff is configured, etc.

I been there/done that :)

[Dale]

I haven't done this on top of a working system tho. The first tarball
was a fresh install. The Gentoo that was there hadn't been updated in
like 3 years or so. I wasn't about to jump in and try to update all
that. The 2nd time, I just unpacked the tarball in /mnt/gentoo just
like I would a fresh install just that it was in the first install.

The locale.gen file was untouched from the tarball so it was the wrong
file type when I downloaded it. No clue on that yet.

Dale

:-) :-)

[J. Roeleveld]

Dale.

I will try to use the x86 stage3 on a VM today. Will let you know how far I get.

[J. Roeleveld]

Update:

Using a 32bit VM with current x86 stage3 file, glibc builds succesfully. (On first run)

 

Will do a second " emerge -ve @system " when this one is finished.

 

I used the following stage file:

stage3-i686-20140708.tar.bz2

 

I have not change anything in /etc/portage

 

--

Joost

[Dale]

J. Roeleveld wrote:

Update:

Using a 32bit VM with current x86 stage3 file, glibc builds succesfully. (On first run)

�

Will do a second " emerge -ve @system " when this one is finished.

�

I used the following stage file:

stage3-i686-20140708.tar.bz2

�

I have not change anything in /etc/portage

�

--

Joost

Sounds good.� I'm downloading that one and will try to install it next.� Let's hope it was a one time event.

Thanks for testing it.�

Dale

:-)� :-)�

[J. Roeleveld]

2nd run active, doing it with @world now instead of @system.

211 packages.

Only change done to /etc/portage/make.conf:

 

Added " FEATURES="buildpkg" "

 

Will let you know when this run has finished.

I should also be able to provide the package-dir to you if needed.

Am using the latest stable gentoo-sources (3.12.21-r1) using the default config:

# make mrproper

# make distclean

# make menuconfig

(Only unset the 64bit kernel option)

 

# make

# make modules_install

 

(This actually worked ;) )

--

Joost

 

[Peter Humphrey]

On Thursday 17 July 2014 04:03:34 Dale wrote:

--->8

> Sounds good. I'm downloading that one and will try to install it next.
> Let's hope it was a one time event.
>
> Thanks for testing it.

I've just started installing a 64-bit chroot to do the emerge work for my
laptop and I fell into the same error as you, Dale. Well, I haven't checked
all the details but it seems similar.

The odd thing is that I used a not-very-recent stage-3 that I'd already used
to install from - without problems that time. So I emerged glib and glibc in
the new, raw system and ran 'emerge --config sys-libs/timezone-data' again
with no problem. I had copied in a /etc/locale.gen and /etc/timezone from
another system first.

I don't know whether I needed to emerge glib, or just glibc. I'm going to have
to emerge glib again after I've emerged and set up gentoo-sources.

--
Regards
Peter

[J. Roeleveld]

Update:

No issues with glibc.

I am not doing any parallel builds (eg. default of -j 1 is used)

 

Let me know if you want any files for comparison.

 

--

Joost

[Peter Humphrey]

On Thursday 17 July 2014 10:20:59 I wrote:
> On Thursday 17 July 2014 04:03:34 Dale wrote:
>
> --->8
>
> > Sounds good. I'm downloading that one and will try to install it next.
> > Let's hope it was a one time event.
> >
> > Thanks for testing it.
>
> I've just started installing a 64-bit chroot to do the emerge work for my
> laptop and I fell into the same error as you, Dale. Well, I haven't checked
> all the details but it seems similar.
>
> The odd thing is that I used a not-very-recent stage-3 that I'd already used
> to install from - without problems that time. So I emerged glib and glibc
> in the new, raw system and ran 'emerge --config sys-libs/timezone-data'
> again with no problem. I had copied in a /etc/locale.gen and /etc/timezone
> from another system first.

Some other things were going wrong with the new installation, so I downloaded
the latest amd64 stage-3, installed afresh using that and all is going
swimmingly. Emerge -e world is in progress now.

HTH. HaND.

--
Regards
Peter

[Dale]

Howdy, different rig but similar issue. This is on my main rig now. It
is AMD64 multilib. I am doing a emerge -e world, which I do from time
to time. After that got to the point where it is almost done, I started
getting this:

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = "en_US.UTF8",
LANG = "en_US.UTF8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)

and like this:

/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)
>>> Regenerating /etc/ld.so.cache...
sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF8)

The error seems to vary depending on command run. This is my locale.gen
file:

LANG="en_US.UTF8"
LC_CTYPE="en_US.UTF8"
LC_NUMERIC="en_US.UTF8"
LC_TIME="en_US.UTF8"
LC_COLLATE="en_US.UTF8"
LC_MONETARY="en_US.UTF8"
LC_MESSAGES="en_US.UTF8"
LC_PAPER="en_US.UTF8"
LC_NAME="en_US.UTF8"
LC_ADDRESS="en_US.UTF8"
LC_TELEPHONE="en_US.UTF8"
LC_MEASUREMENT="en_US.UTF8"

I'm on sys-libs/glibc-2.17 right now.

Now riddle me this, why is this popping up all of a sudden? Did
something change and I missed it? When I google, I find folks with
settings like mine and it works. Is this something new that just hasn't
hit everyone yet?

Confused.

Dale

:-) :-)

[Mick]

/etc/locale.gen ought to show something like:

en_US.UTF-8 UTF-8

rather than what you show in your message. /etc/env.d/02locale can show what
you have in your message above, but typically only this is necessary:

LANG="en_US.UTF-8"

(In mine I also have: LC_TIME="POSIX" and LC_COLLATE="C", but most users
wouldn't).

--
Regards,
Mick

[Peter Humphrey]

On Thursday 17 July 2014 16:41:45 Dale wrote:

> This is my locale.gen file:
>
> LANG="en_US.UTF8"
> LC_CTYPE="en_US.UTF8"
> LC_NUMERIC="en_US.UTF8"
> LC_TIME="en_US.UTF8"
> LC_COLLATE="en_US.UTF8"
> LC_MONETARY="en_US.UTF8"
> LC_MESSAGES="en_US.UTF8"
> LC_PAPER="en_US.UTF8"
> LC_NAME="en_US.UTF8"
> LC_ADDRESS="en_US.UTF8"
> LC_TELEPHONE="en_US.UTF8"
> LC_MEASUREMENT="en_US.UTF8"

Dale, why are you setting all those values yourself? As far as I know, the
only one you need to set is the first one: LANG. The rest of them should all
be taken care of by portage - unless you have very particular (i.e. special)
requirements. I don't have any of those values set anywhere; look:

$ grep -r LC_ /etc
/etc/init.d/hwclock: if LC_ALL=C hwclock --help 2>&1 | grep -q
"\-\-noadjfile"; then
/etc/portage/savedconfig/sys-apps/busybox-1.21.0:# CONFIG_FEATURE_IPCALC_FANCY
is not set
/etc/portage/savedconfig/sys-apps/busybox-1.21.0:#
CONFIG_FEATURE_IPCALC_LONG_OPTIONS is not set
/etc/ssh/ssh_config:SendEnv LANG LC_*

This is my /etc/locale.gen:

en_GB.UTF-8 UTF-8
en_GB ISO-8859-1
en_GB.ISO-8859-15 ISO-8859-15

I don't remember why I still have those last two entries; I expect they date
from before Gentoo adopted UTF-8. Maybe I'll remove them and see what happens.

It's an easy trap to fall into: over-specifying details just because Gentoo
lets you do so, in contrast to other distros.

KISS :)

--
Regards
Peter

[Dale]

I got that off a howto somewhere. I think it is a Gentoo one. Anyway,
commented all that out and left the one line, ran locale-gen and it
seems to have fixed it. Keep in mind, it's been that way for quite a
long time. No clue why it decides to moan about it now.

Thanks.

Dale

:-) :-)

[Jc García]

2014-07-17 21:55 GMT-06:00 Dale <rdale...@gmail.com>:

> I got that off a howto somewhere. I think it is a Gentoo one. Anyway,
> commented all that out and left the one line, ran locale-gen and it
> seems to have fixed it. Keep in mind, it's been that way for quite a
> long time. No clue why it decides to moan about it now.
>

Well that is suprising, since the contents you have on that file are
totally wrong, locale.gen(5) manpage explicitly states the syntax for
that file is:
<locale> <charset>
example:
en_US.UTF-8 UTF-8
The man page also points you to the directories in /usr/share/i18n/
wich are locales/ and charmaps/ with the list of the ones available
for Gentoo, and also a convenient file named 'SUPPORTED' which tells
itself a list of what it has inside.
Also a the file alredy in the /etc/locale.gen in the stage3, has some
examples, since en_US.UTF-8 is the second example (and that's your
locale) you just need to uncomment that and run locale-gen.
Also LANG is an environment variable it has nothing to do in there.
PD: the manpages have the best supported answers, look at it before
going to random howtos online, its already at your installation
anyway.

> Thanks.
>
> Dale
>
> :-) :-)
>

[Mick]

On Thursday 17 Jul 2014 23:48:51 Peter Humphrey wrote:
> This is my /etc/locale.gen:
>
> en_GB.UTF-8 UTF-8
> en_GB ISO-8859-1
> en_GB.ISO-8859-15 ISO-8859-15
>
> I don't remember why I still have those last two entries; I expect they
> date from before Gentoo adopted UTF-8. Maybe I'll remove them and see
> what happens.

The last line is for Western European ASCII character encodings, just like
en_GB ISO-8859-1, but with the Euro symbol and some other accented characters
missing from the latter.

Nothing will happen if you remove the last two entries, because (I think) that
the UTF-8 character encodings cover all these.

--
Regards,
Mick

[Peter Humphrey]

On Friday 18 July 2014 06:54:32 Mick wrote:
> On Thursday 17 Jul 2014 23:48:51 Peter Humphrey wrote:
> > This is my /etc/locale.gen:
> >
> > en_GB.UTF-8 UTF-8
> > en_GB ISO-8859-1
> > en_GB.ISO-8859-15 ISO-8859-15
> >
> > I don't remember why I still have those last two entries; I expect they
> > date from before Gentoo adopted UTF-8. Maybe I'll remove them and see
> > what happens.
>
> The last line is for Western European ASCII character encodings, just like
> en_GB ISO-8859-1, but with the Euro symbol and some other accented
> characters missing from the latter.

Yes, I remember that, just not why I haven't ditched them since UTF-8 took
over the world.

> Nothing will happen if you remove the last two entries, because (I think)
> that the UTF-8 character encodings cover all these.

That's my uncertainty too.

--
Regards
Peter

[Dale]

J. Roeleveld wrote:

Update:

No issues with glibc.

I am not doing any parallel builds (eg. default of -j 1 is used)

�

Let me know if you want any files for comparison.

�

--

Joost

I tried the same tarball you are using and it still failed.� Basically, I unpacked the thing, copied over the portage tree and distfiles and tried to emerge glibc and it failed.�� It has to be something wrong on my end here.� Heck, this last time, I didn't even touch make.conf.� I looked to make sure it was set to something sane but didn't need to change anything.� I don't need sync servers or mirror servers either since I copy that over.�

This is weird.�

Dale

:-)� :-)�

[J. Roeleveld]

I did do a new sync and downloaded the distfiles from the net.
Eg. Didn't copy anything from.an existing environment.

[Jc García]

2014-07-18 3:18 GMT-06:00 Dale <rdale...@gmail.com>:

>
>
> I tried the same tarball you are using and it still failed. Basically, I
> unpacked the thing, copied over the portage tree and distfiles and tried to
> emerge glibc and it failed. It has to be something wrong on my end here.
> Heck, this last time, I didn't even touch make.conf. I looked to make sure
> it was set to something sane but didn't need to change anything. I don't
> need sync servers or mirror servers either since I copy that over.
>

Did you updated the locales? in the other thread about this I pointed
some things you should check, also take a look at this guide[1],
mostly unrelated but there's one step which might be in your
insterest:
" 9. Edit your locales and run locale-gen – sooner or later you’re
going to have to update glibc so no sense taking all day to do it."
[1] http://rich0gentoo.wordpress.com/2010/04/02/gentoo-on-ec2-from-scratch/