[gentoo-amd64] system broken?

[gentoo-amd64] system broken?

[Martin Herrman]

All,

I did:
1. emerge --syn
2. emerge --update --deep --newuse world

glibc was updated:

=============================================================

<snip>
<<<          obj /lib32/libnsl-2.8.so
--- replaced obj /lib32/libmemusage.so
--- replaced sym /lib32/libm.so.6
<<<          obj /lib32/libm-2.8.so
--- replaced sym /lib32/libdl.so.2
<<<          obj /lib32/libdl-2.8.so
--- replaced sym /lib32/libcrypt.so.1
<<<          obj /lib32/libcrypt-2.8.so
--- replaced sym /lib32/libcidn.so.1
<<<          obj /lib32/libcidn-2.8.so
--- replaced sym /lib32/libc.so.6
<<<          obj /lib32/libc-2.8.so
--- replaced sym /lib32/libanl.so.1
<<<          obj /lib32/libanl-2.8.so
--- replaced obj /lib32/libSegFault.so
--- replaced sym /lib32/libBrokenLocale.so.1
<<<          obj /lib32/libBrokenLocale-2.8.so
--- replaced sym /lib32/ld-linux.so.2
<<<          obj /lib32/ld-2.8.so
--- replaced dir /lib32
--- replaced sym /lib
--- replaced obj /etc/rpc
--- replaced obj /etc/nsswitch.conf
--- replaced obj /etc/nscd.conf
--- replaced obj /etc/init.d/nscd
--- replaced dir /etc/init.d
--- replaced obj /etc/host.conf
--- replaced obj /etc/gai.conf
--- replaced dir /etc
<<<          dir /usr/share/doc/glibc-2.8_p20080602
>>> Regenerating /etc/ld.so.cache...

>>> Emerging (4 of 4) www-client/mozilla-firefox-3.0.4-r2 to /
 * mozilla-firefox-3.0.1-patches-0.3.tar.bz2 RMD160 SHA1 SHA256 size
;-) ...
                                                           [ ok ]
 * mozilla-firefox-3.0.4.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...

                                                         [ ok ]
 * checking ebuild checksums ;-) ...

                                                         [ ok ]
 * checking auxfile checksums ;-) ...

                                                         [ ok ]
 * checking miscfile checksums ;-) ...

                                                         [ ok ]
 * checking mozilla-firefox-3.0.4.tar.bz2 ;-) ...

                                                         [ ok ]
 * checking mozilla-firefox-3.0.1-patches-0.3.tar.bz2 ;-) ...

                                                         [ ok ]
Traceback (most recent call last):
  File "/usr/lib64/portage/bin/portageq", line 461, in <module>
    main()
  File "/usr/lib64/portage/bin/portageq", line 431, in main
    import portage
  File "/usr/lib64/portage/pym/portage.py", line 98, in <module>
    from portage_data import ostype, lchown, userland, secpass, uid, wheelgid, \
  File "/usr/lib64/portage/pym/portage_data.py", line 106, in <module>
    mystatus, myoutput = getstatusoutput("id -G portage")
  File "/usr/lib64/python2.5/commands.py", line 53, in getstatusoutput
    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
OSError: [Errno 38] Function not implemented
 *
 * ERROR: www-client/mozilla-firefox-3.0.4-r2 failed.
 * Call stack:
 *                         ebuild.sh, line   49:  Called pkg_setup
 *   mozilla-firefox-3.0.4-r2.ebuild, line   97:  Called
built_with_use 'pkg_setup' 'pkg_setup'
 *                     eutils.eclass, line 1709:  Called die
 * The specific snippet of code:
 *      [[ -z ${PKG} ]] && die "Unable to resolve $1 to an installed package"
 *  The die message:
 *   Unable to resolve x11-libs/cairo to an installed package
 *
 * If you need support, post the topmost build error, and the call
stack if relevant.
 * A complete build log is located at
'/var/tmp/portage/www-client/mozilla-firefox-3.0.4-r2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/www-client/mozilla-firefox-3.0.4-r2/temp/die.env'.
 *

 * Messages for package dev-java/java-config-1.3.7-r1:

 * The way Java is handled on Gentoo has been recently updated.
 * If you have not done so already, you should follow the
 * instructions available at:
 *      http://www.gentoo.org/proj/en/java/java-upgrade.xml
 *
 * While we are moving towards t<<<          obj /lib32/libnsl-2.8.so
--- replaced obj /lib32/libmemusage.so
--- replaced sym /lib32/libm.so.6
<<<          obj /lib32/libm-2.8.so
--- replaced sym /lib32/libdl.so.2
<<<          obj /lib32/libdl-2.8.so
--- replaced sym /lib32/libcrypt.so.1
<<<          obj /lib32/libcrypt-2.8.so
--- replaced sym /lib32/libcidn.so.1
<<<          obj /lib32/libcidn-2.8.so
--- replaced sym /lib32/libc.so.6
<<<          obj /lib32/libc-2.8.so
--- replaced sym /lib32/libanl.so.1
<<<          obj /lib32/libanl-2.8.so
--- replaced obj /lib32/libSegFault.so
--- replaced sym /lib32/libBrokenLocale.so.1
<<<          obj /lib32/libBrokenLocale-2.8.so
--- replaced sym /lib32/ld-linux.so.2
<<<          obj /lib32/ld-2.8.so
--- replaced dir /lib32
--- replaced sym /lib
--- replaced obj /etc/rpc
--- replaced obj /etc/nsswitch.conf
--- replaced obj /etc/nscd.conf
--- replaced obj /etc/init.d/nscd
--- replaced dir /etc/init.d
--- replaced obj /etc/host.conf
--- replaced obj /etc/gai.conf
--- replaced dir /etc
<<<          dir /usr/share/doc/glibc-2.8_p20080602
>>> Regenerating /etc/ld.so.cache...

>>> Emerging (4 of 4) www-client/mozilla-firefox-3.0.4-r2 to /
 * mozilla-firefox-3.0.1-patches-0.3.tar.bz2 RMD160 SHA1 SHA256 size
;-) ...
                                                           [ ok ]
 * mozilla-firefox-3.0.4.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...

                                                         [ ok ]
 * checking ebuild checksums ;-) ...

                                                         [ ok ]
 * checking auxfile checksums ;-) ...

                                                         [ ok ]
 * checking miscfile checksums ;-) ...

                                                         [ ok ]
 * checking mozilla-firefox-3.0.4.tar.bz2 ;-) ...

                                                         [ ok ]
 * checking mozilla-firefox-3.0.1-patches-0.3.tar.bz2 ;-) ...

                                                         [ ok ]
Traceback (most recent call last):
  File "/usr/lib64/portage/bin/portageq", line 461, in <module>
    main()
  File "/usr/lib64/portage/bin/portageq", line 431, in main
    import portage
  File "/usr/lib64/portage/pym/portage.py", line 98, in <module>
    from portage_data import ostype, lchown, userland, secpass, uid, wheelgid, \
  File "/usr/lib64/portage/pym/portage_data.py", line 106, in <module>
    mystatus, myoutput = getstatusoutput("id -G portage")
  File "/usr/lib64/python2.5/commands.py", line 53, in getstatusoutput
    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
OSError: [Errno 38] Function not implemented
 *
 * ERROR: www-client/mozilla-firefox-3.0.4-r2 failed.
 * Call stack:
 *                         ebuild.sh, line   49:  Called pkg_setup
 *   mozilla-firefox-3.0.4-r2.ebuild, line   97:  Called
built_with_use 'pkg_setup' 'pkg_setup'
 *                     eutils.eclass, line 1709:  Called die
 * The specific snippet of code:
 *      [[ -z ${PKG} ]] && die "Unable to resolve $1 to an installed package"
 *  The die message:
 *   Unable to resolve x11-libs/cairo to an installed package
 *
 * If you need support, post the topmost build error, and the call
stack if relevant.
 * A complete build log is located at
'/var/tmp/portage/www-client/mozilla-firefox-3.0.4-r2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/www-client/mozilla-firefox-3.0.4-r2/temp/die.env'.
 *

 * Messages for package dev-java/java-config-1.3.7-r1:

 * The way Java is handled on Gentoo has been recently updated.
 * If you have not done so already, you should follow the
 * instructions available at:
 *      http://www.gentoo.org/proj/en/java/java-upgrade.xml
 *
 * While we are moving towards the new Java system, we only allow
 * 1.3 or 1.4 JDKs to be used with java-config-1 to ensure
 * backwards compatibility with the old system.
 * For more details about this, please see:
 *      http://www.gentoo.org/proj/en/java/why-we-need-java-14.xml

 * Messages for package www-client/mozilla-firefox-3.0.4-r2:

 *
 * ERROR: www-client/mozilla-firefox-3.0.4-r2 failed.
 * Call stack:
 *                         ebuild.sh, line   49:  Called pkg_setup
 *   mozilla-firefox-3.0.4-r2.ebuild, line   97:  Called
built_with_use 'pkg_setup' 'pkg_setup'
 *                     eutils.eclass, line 1709:  Called die
 * The specific snippet of code:
 *      [[ -z ${PKG} ]] && die "Unable to resolve $1 to an installed package"
 *  The die message:
 *   Unable to resolve x11-libs/cairo to an installed package
 *
 * If you need support, post the topmost build error, and the call
stack if relevant.
 * A complete build log is located at
'/var/tmp/portage/www-client/mozilla-firefox-3.0.4-r2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/www-client/mozilla-firefox-3.0.4-r2/temp/die.env'.
 *
 * Regenerating GNU info directory index...
 * Processed 119 info files.
 * IMPORTANT: 1 config files in '/etc' need updating.
 * See the CONFIGURATION FILES section of the emerge
 * man page to learn how to update config files.
martindesktop ~ # emerge cairo
Traceback (most recent call last):
  File "/usr/bin/emerge", line 27, in <module>
    import portage
  File "/usr/lib64/portage/pym/portage.py", line 98, in <module>
    from portage_data import ostype, lchown, userland, secpass, uid, wheelgid, \
  File "/usr/lib64/portage/pym/portage_data.py", line 106, in <module>
    mystatus, myoutput = getstatusoutput("id -G portage")
  File "/usr/lib64/python2.5/commands.py", line 53, in getstatusoutput
    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
OSError: [Errno 38] Function not implemented
he new Java system, we only allow
 * 1.3 or 1.4 JDKs to be used with java-config-1 to ensure
 * backwards compatibility with the old system.
 * For more details about this, please see:
 *      http://www.gentoo.org/proj/en/java/why-we-need-java-14.xml

 * Messages for package www-client/mozilla-firefox-3.0.4-r2:

 *
 * ERROR: www-client/mozilla-firefox-3.0.4-r2 failed.
 * Call stack:
 *                         ebuild.sh, line   49:  Called pkg_setup
 *   mozilla-firefox-3.0.4-r2.ebuild, line   97:  Called
built_with_use 'pkg_setup' 'pkg_setup'
 *                     eutils.eclass, line 1709:  Called die
 * The specific snippet of code:
 *      [[ -z ${PKG} ]] && die "Unable to resolve $1 to an installed package"
 *  The die message:
 *   Unable to resolve x11-libs/cairo to an installed package
 *
 * If you need support, post the topmost build error, and the call
stack if relevant.
 * A complete build log is located at
'/var/tmp/portage/www-client/mozilla-firefox-3.0.4-r2/temp/build.log'.
 * The ebuild environment file is located at
'/var/tmp/portage/www-client/mozilla-firefox-3.0.4-r2/temp/die.env'.
 *
 * Regenerating GNU info directory index...
 * Processed 119 info files.
 * IMPORTANT: 1 config files in '/etc' need updating.
 * See the CONFIGURATION FILES section of the emerge
 * man page to learn how to update config files.
martindesktop ~ # emerge cairo
Traceback (most recent call last):
  File "/usr/bin/emerge", line 27, in <module>
    import portage
  File "/usr/lib64/portage/pym/portage.py", line 98, in <module>
    from portage_data import ostype, lchown, userland, secpass, uid, wheelgid, \
  File "/usr/lib64/portage/pym/portage_data.py", line 106, in <module>
    mystatus, myoutput = getstatusoutput("id -G portage")
  File "/usr/lib64/python2.5/commands.py", line 53, in getstatusoutput
    pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')
OSError: [Errno 38] Function not implemented

=============================================================

What has happened? What to do next?

Thanks..

Martin

[gentoo-amd64] Re: system broken?

[Duncan]

"Martin Herrman" <martin@herrman.nl> posted
40bb8d3b0812090605r624530efhddc8eaec105ed3bd@mail.gmail.com, excerpted
below, on  Tue, 09 Dec 2008 15:05:36 +0100:

> What has happened? What to do next?

Most of those errors seem to be portage itself choking.  I just did an 
update here and had a python remerge due to new USE flag (2.5.2-r8, I'm 
on ~amd64).  If you had a python update or remerge too, that could be 
it.  Check and see if your python has the expat use flag and whether it's 
on or not.  If you do and it's off, that /may/ be the problem, as I left 
mine on.

Whether it's python or portage (I suspect one of the two, if it was glibc 
you'd almost certainly have far bigger problems), you'll likely not be 
able to remerge a good package to fix it, since portage keeps crashing.  
If you've been using FEATURES=buildpkg, you should be able to untar an 
older package version over top of your system, using basically the below 
procedure but using your own package rather than the tarball from the 
URL.  If not, then use the tarball from the URL listed in the following 
document:

Manually fixing broken portage installations
http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml

That's for portage itself.  If that's not it, try python.  If you've been 
using FEATURES=buildpkg you should have an older package to use.  If not, 
the bash part of portage should at least work, so you should be able to 
use ebuild.sh to step-by-step thru emerging python, or you can download a 
stage tarball, unpack it somewhere, chroot into it, quickpkg python, then 
untar that package over your main system using a procedure like that for 
portage, above.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: system broken?

[Martin Herrman]

On Tue, Dec 9, 2008 at 5:47 PM, Duncan <1i5t5.duncan@cox.net> wrote:

> Most of those errors seem to be portage itself choking.  I just did an
> update here and had a python remerge due to new USE flag (2.5.2-r8, I'm
> on ~amd64).  If you had a python update or remerge too, that could be
> it.  Check and see if your python has the expat use flag and whether it's
> on or not.  If you do and it's off, that /may/ be the problem, as I left
> mine on.
>
> Whether it's python or portage (I suspect one of the two, if it was glibc
> you'd almost certainly have far bigger problems), you'll likely not be
> able to remerge a good package to fix it, since portage keeps crashing.
> If you've been using FEATURES=buildpkg, you should be able to untar an
> older package version over top of your system, using basically the below
> procedure but using your own package rather than the tarball from the
> URL.  If not, then use the tarball from the URL listed in the following
> document:
>
> Manually fixing broken portage installations
> http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml
>
> That's for portage itself.  If that's not it, try python.  If you've been
> using FEATURES=buildpkg you should have an older package to use.  If not,
> the bash part of portage should at least work, so you should be able to
> use ebuild.sh to step-by-step thru emerging python, or you can download a
> stage tarball, unpack it somewhere, chroot into it, quickpkg python, then
> untar that package over your main system using a procedure like that for
> portage, above.
>

Hi Duncan,

thanks a lot for this reply!

Of course (using Gentoo now for a month or so), I don't have buildpkg
in my config. So I used the manual on the URL you provided. It says
that one should emerge portage first to get a correct system first.
But when I do that, I get an error:

martindesktop ~ # emerge portage
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) sys-apps/portage-2.1.4.5
 * portage-2.1.4.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...

                                                        [ ok ]
 * portage-2.1.4.5.patch.bz2 RMD160 SHA1 SHA256 size ;-) ...

                                                        [ ok ]
 * checking ebuild checksums ;-) ...

                                                        [ ok ]
 * checking auxfile checksums ;-) ...

                                                        [ ok ]
 * checking miscfile checksums ;-) ...

                                                        [ ok ]
>>> Unpacking source...
>>> Unpacking portage-2.1.4.tar.bz2 to /var/tmp/portage/sys-apps/portage-2.1.4.5/work
>>> Unpacking portage-2.1.4.5.patch.bz2 to /var/tmp/portage/sys-apps/portage-2.1.4.5/work
 * Applying portage-2.1.4.5.patch ...

                                                         [ ok ]
 * Setting portage.VERSION to 2.1.4.5 ...

                                                         [ ok ]
>>> Source unpacked.
>>> Compiling source in /var/tmp/portage/sys-apps/portage-2.1.4.5/work/portage-2.1.4 ...
>>> Source compiled.
>>> Test phase [not enabled]: sys-apps/portage-2.1.4.5

>>> Install portage-2.1.4.5 into /var/tmp/portage/sys-apps/portage-2.1.4.5/image/ category sys-apps
patching file make.conf
>>> Completed installing portage-2.1.4.5 into /var/tmp/portage/sys-apps/portage-2.1.4.5/image/

strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment
   usr/lib64/portage/bin/tbz2tool
ecompressdir: bzip2 -9 /usr/share/man

>>> Installing sys-apps/portage-2.1.4.5
 * If you have an overlay then you should remove **/files/digest-* files
 * (Manifest1) because they are no longer supported. If earlier versions
 * of portage will be used to generate manifests for your overlay then you
 * should add a file named manifest1_obsolete to the root of the repository
 * in order to disable generation of the Manifest1 digest files.
 *
 * For help with using portage please consult the Gentoo Handbook
 * at http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3
 *
!!! can't process invalid log file:
/var/tmp/portage/sys-apps/portage-2.1.4.5/temp/logging/postinst.LOG
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.

 * GNU info directory index is up-to-date.
martindesktop ~ #

Next, the same issues appear again. So I follow the manual again and
instead of 'emerge portage' I first emerged glibc and next python.
Both went well. Next I did a full upgrade:

- emerge --syn
- emerge --update --deep --newuse world
- find /etc -iname '._cfg????_*'
- emerge --depclean
- revdep-rebuild

which also went well. Next I emerged portage again.. problem is back again..

martindesktop portage # emerge ktorrent
Calculating dependencies \Traceback (most recent call last):
  File "/usr/bin/emerge", line 6979, in <module>
    retval = emerge_main()
  File "/usr/bin/emerge", line 6973, in emerge_main
    myopts, myaction, myfiles, spinner)
  File "/usr/bin/emerge", line 6240, in action_build
    retval, favorites = mydepgraph.select_files(myfiles)
  File "/usr/bin/emerge", line 2120, in select_files
    if not self.validate_blockers():
  File "/usr/bin/emerge", line 2571, in validate_blockers
    blocker_cache.flush()
  File "/usr/bin/emerge", line 1335, in flush
    cPickle.dump(self._cache_data, f, -1)
cPickle.PicklingError: Can't pickle <type 'method-wrapper'>: attribute
lookup __builtin__.method-wrapper failed

is this a portage issue? Or is there something wrong it depends on?

Thanks in advance!

Martin

Re: [gentoo-amd64] Re: system broken?

[Richard Freeman]

Martin Herrman wrote:
> Of course (using Gentoo now for a month or so), I don't have buildpkg
> in my config. So I used the manual on the URL you provided. It says
> that one should emerge portage first to get a correct system first.
> But when I do that, I get an error:
> 

Yeah - once you break it you get stuck with the pieces.  Somebody might 
have a clever solution for you - if not your best best might be to find 
a stage3 tarball off the distribution site and unpack it somewhere.  In 
there you'll find good (but stale) copies of anything you need.

If nothing else you can install the stage3 to a directory, then set up 
your environment per the install guide and chroot to it.  Then type 
"quickpkg portage" to generate a binary package in /var/packages (within 
the chroot).  You can then use that binary package to reinstall portage. 
  Best way to do that is with emerge -k, but if that doesn't work you 
can always just expand the tarball into your root.  I'd re-emerge 
portage just to clean up after doing that.

It could be something other than portage that is broken.  If you're 
still able to boot and generally function, it can't be anything too 
critical (like glibc).

I wouldn't jump the gun on my stage3 idea - somebody else might have a 
more clever and clean solution.  However, I've cleaned up after a few 
disasters via partial manual reinstalls.  And if you just quickpkg 
specific packages from your chroot you won't be overwriting files 
en-masse.  You could also update your chroot (emerge -uD system) and 
then you wouldn't need to worry too much about copying over files left 
and right.  Just be careful not to wipe out your /etc files (fstab and 
passwd come to mind) by copying them from the stage3.

[gentoo-amd64] Re: system broken?

[Duncan]

"Martin Herrman" <martin@herrman.nl> posted
40bb8d3b0812091105q2cc4d77ar8953e56baba1f1a@mail.gmail.com, excerpted
below, on  Tue, 09 Dec 2008 20:05:00 +0100:

[snipped]

OK, I just checked bugzilla and I bet it's this bug:

http://bugs.gentoo.org/show_bug.cgi?id=250342

It's a problem that seems specific to the new ~arch glibc-2.9* version 
and the stable portage-2.1.4* series.  With either ~arch portage (2.1.6 
series) or masked portage (2.2_rcs), or with stable glibc-2.6* or ~arch 
glibc-2.8 (so previous to the latest 2.9 version), nobody has yet 
reported a problem, so repeating the above, it seems to require BOTH the 
~arch 2.9 glibc AND the stable 2.1.4* portage.

Thus, three options:

1) Upgrade portage to the 2.1.6 ~arch series
2) Downgrade glibc back to the 2.8 series or stable
3) There are code-hack workarounds reported on the bug.

Note that there are a few other obscure bugs already reported on the new 
glibc, as well, including remote-X problems.  So unless you have some 
burning need to run glibc 2.9, I'd choose to revert it.  The bugs will be 
fixed in time, but it often takes awhile to track them all down and 
figure out and fix the problems.  Try it again in three months or 
whatever.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: system broken?

[Martin Herrman]

On 12/10/08, Duncan <1i5t5.duncan@cox.net> wrote:

> OK, I just checked bugzilla and I bet it's this bug:
>
> http://bugs.gentoo.org/show_bug.cgi?id=250342
>
> It's a problem that seems specific to the new ~arch glibc-2.9* version
> and the stable portage-2.1.4* series.  With either ~arch portage (2.1.6
> series) or masked portage (2.2_rcs), or with stable glibc-2.6* or ~arch
> glibc-2.8 (so previous to the latest 2.9 version), nobody has yet
> reported a problem, so repeating the above, it seems to require BOTH the
> ~arch 2.9 glibc AND the stable 2.1.4* portage.
>
> Thus, three options:
>
> 1) Upgrade portage to the 2.1.6 ~arch series
> 2) Downgrade glibc back to the 2.8 series or stable
> 3) There are code-hack workarounds reported on the bug.
>
> Note that there are a few other obscure bugs already reported on the new
> glibc, as well, including remote-X problems.  So unless you have some
> burning need to run glibc 2.9, I'd choose to revert it.  The bugs will be
> fixed in time, but it often takes awhile to track them all down and
> figure out and fix the problems.  Try it again in three months or
> whatever.

Hi Duncan,

thanks a lot for this link! This seems to be exactly the issue I have
(and also caused by the wish to have GCC 4.3). I will downgrade glibc
(and gcc) to have a stable system again.

Currently I'm at work, but will get back to you asap and inform you on
the result.

Regards,

Martin

Re: [gentoo-amd64] Re: system broken?

[Ben de Groot]

[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

Martin Herrman wrote:
> thanks a lot for this link! This seems to be exactly the issue I have
> (and also caused by the wish to have GCC 4.3). I will downgrade glibc
> (and gcc) to have a stable system again.

Except you can't downgrade glibc. It won't work. So your best bet is to
get a tarball of portage-2.1.6 (or 2.2_rc17) from someone with a
functioning ~amd64 system. (I myself am stuck on ~x86 for the moment.)

-- 
Ben de Groot
Gentoo Linux developer (lxde, media, desktop-misc)
Gentoo Linux Release Engineering PR liaison
__________________________________________________

yngwin@gentoo.org
http://ben.liveforge.org/
irc://chat.freenode.net/#gentoo-media
irc://irc.oftc.net/#lxde
__________________________________________________



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

[gentoo-amd64] Re: system broken?

[Duncan]

Ben de Groot <yngwin@gentoo.org> posted 493FB175.3050204@gentoo.org,
excerpted below, on  Wed, 10 Dec 2008 13:09:25 +0100:

> Martin Herrman wrote:
>> thanks a lot for this link! This seems to be exactly the issue I have
>> (and also caused by the wish to have GCC 4.3). I will downgrade glibc
>> (and gcc) to have a stable system again.
> 
> Except you can't downgrade glibc. It won't work. So your best bet is to
> get a tarball of portage-2.1.6 (or 2.2_rc17) from someone with a
> functioning ~amd64 system. (I myself am stuck on ~x86 for the moment.)

Well, you can, but not directly.

Surely you have an emergency boot method, either (like me) a backup root 
partition that you snapshot from your working one periodically when you 
know the system's working pretty smoothly (which means you've rebooted 
since your last merges so you know you can), or a LiveCD of some sort, 
maybe a Gentoo LiveCD, maybe something else, that you can boot to and 
mount your broken system partitions from?  That's the basis from which to 
start.  If you don't have such an emergency boot solution, how do you 
expect to recover in the event you have a broken boot?

When I had a problem with glibc and needed to downgrade, I simply stuck 
the appropriate root=/dev/whatever on the kernel command line from grub, 
and booted to my backup root partition.  The way I'm setup, that gives me 
the exact working system I had at that point, and can mount either my 
normal or backup /home and other data partitions, so I'm still fully 
operational.  I was able to mount my my normal root from the backup, 
along with my packages partition, then set ROOT= to point to the normal 
working partition, and emerge -K an appropriate binpkged glibc over top 
of the broken one.  I must admit I was a bit apprehensive about it as I'd 
never used portage's ROOT= setting before, and after all this is glibc 
we're talking about, but it worked fine, and I was then able to reboot 
back into my normal root again.

Another alternative as long as glibc isn't so broken you can't run 
anything, is to hand-edit the ebuild to kill the downgrade blocker bit of 
the script.

Finally, as posted elsewhere, it's also possible to start with a stage 
tarball once again as a known good starting point, then emerge --
emptytree @system to get back to a current system.  This is sort of the 
equivalent of an OS reinstall on other OSs/distributions and it works 
quite well.  Of course, it helps if you make a backup of your /etc before 
you do it, so you can quickly recover overwritten config files.

So there's ways to downgrade glibc.  You just have to be smarter than the 
child-safety-locks portage has in place to prevent you from doing it 
inadvertently and breaking a system further, as doing so after remerging 
a bunch of packages thus linking them to the new glibc might do.  But if 
you have a backup to operate from if necessary, you don't have to worry 
so much about breaking a system which is probably already partially 
broken or you'd not be having to worry about downgrading glibc.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: system broken?

[Martin Herrman]

On Wed, Dec 10, 2008 at 2:45 PM, Duncan <1i5t5.duncan@cox.net> wrote:

> Well, you can, but not directly.
>
> Surely you have an emergency boot method, either (like me) a backup root
> partition that you snapshot from your working one periodically when you
> know the system's working pretty smoothly (which means you've rebooted
> since your last merges so you know you can), or a LiveCD of some sort,
> maybe a Gentoo LiveCD, maybe something else, that you can boot to and
> mount your broken system partitions from?  That's the basis from which to
> start.  If you don't have such an emergency boot solution, how do you
> expect to recover in the event you have a broken boot?
>
> When I had a problem with glibc and needed to downgrade, I simply stuck
> the appropriate root=/dev/whatever on the kernel command line from grub,
> and booted to my backup root partition.  The way I'm setup, that gives me
> the exact working system I had at that point, and can mount either my
> normal or backup /home and other data partitions, so I'm still fully
> operational.  I was able to mount my my normal root from the backup,
> along with my packages partition, then set ROOT= to point to the normal
> working partition, and emerge -K an appropriate binpkged glibc over top
> of the broken one.  I must admit I was a bit apprehensive about it as I'd
> never used portage's ROOT= setting before, and after all this is glibc
> we're talking about, but it worked fine, and I was then able to reboot
> back into my normal root again.
>
> Another alternative as long as glibc isn't so broken you can't run
> anything, is to hand-edit the ebuild to kill the downgrade blocker bit of
> the script.
>
> Finally, as posted elsewhere, it's also possible to start with a stage
> tarball once again as a known good starting point, then emerge --
> emptytree @system to get back to a current system.  This is sort of the
> equivalent of an OS reinstall on other OSs/distributions and it works
> quite well.  Of course, it helps if you make a backup of your /etc before
> you do it, so you can quickly recover overwritten config files.
>
> So there's ways to downgrade glibc.  You just have to be smarter than the
> child-safety-locks portage has in place to prevent you from doing it
> inadvertently and breaking a system further, as doing so after remerging
> a bunch of packages thus linking them to the new glibc might do.  But if
> you have a backup to operate from if necessary, you don't have to worry
> so much about breaking a system which is probably already partially
> broken or you'd not be having to worry about downgrading glibc.

Well, this is why I actually love Linux: you still have control over
your system, no matter what happened. But.. the downside is that you
need to know how things work :-) For the moment, I have chosen the
most easiest way:

sys-apps/portage
app-admin/eselect-news
app-admin/eselect

added to package.keywords. That went smooth and everything seems to
work again (altough it adds the number of masked packages, which is a
risk). But.. I should now keep an eye on the development of glibc and
portage (etc.) packages so I can get back to the stable tree again?
Can it take months before gcc 4.3 and glibc 2.8 are stable?

Martin

[gentoo-amd64] Re: system broken?

[Duncan]

"Martin Herrman" <martin@herrman.nl> posted
40bb8d3b0812101053u74e0bda7q887e375eb2fcd78c@mail.gmail.com, excerpted
below, on  Wed, 10 Dec 2008 19:53:01 +0100:

> For the moment, I have chosen the most easiest way:
> 
> sys-apps/portage
> app-admin/eselect-news
> app-admin/eselect
> 
> added to package.keywords.

Note that you may wish to use a complete package atom, including version, 
~cat-egory/package-0.1.2 for instance, to include all -r revisions but no 
other versions, when you keyword, or =cat-egory/package-0.1*, to incluse 
0.1.1, 0.1.2, etc, but not 0.2.0.  That way portage won't try to 
automatically upgrade you to ~arch forever, only for that version.

> That went smooth and everything seems to work
> again (altough it adds the number of masked packages, which is a risk).
> But.. I should now keep an eye on the development of glibc and portage
> (etc.) packages so I can get back to the stable tree again? Can it take
> months before gcc 4.3 and glibc 2.8 are stable?

You'd have to ask toolchain or keep watch on the related bugs to see 
their comments, but in general, such toolchain packages can't stabilize 
until everything can either compile with them (ebuilds apply patches so 
it works), or in some cases, has other ebuild workarounds (in the worst 
cases, the ebuild may test for a version of gcc and die, telling the user 
it can't use that version, but that's for instance for cruft that won't 
compile with any gcc4 version at all, say).  Then all those working 
ebuilds must themselves go stable, which is a minimum 30 day process in 
most cases.  So indeed, it can takes months to stabilize such things.

That said, I've had no problems with gcc-4.3.2 for some time now, tho 
part of that may be patches that are bugged but that I'm carrying locally 
-- they haven't been applied to the ebuilds yet, and where they are, 
those ebuilds may not be stable themselves yet, since I run all ~arch.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman