| View previous topic :: View next topic |
| Author |
Message |
IsmoHaa
n00b
Joined: 25 Jun 2005
Posts: 61
|
 Posted: Sat Aug 26, 2006 7:01 am Post subject: [SOLVED]System borked after "emerge -e system" |
 |
|
I recently decided to upgrade to gcc 3.4, because there are already packages that won't compile with 3.3. I used gcc-config to set the compiler to 3.4.6, then I did an "emerge --sync" and an "emerge -e system". During this phase, somewhere between installing bash and zlib all hell broke loose. Nothing - and I mean NOTHING would emerge any more. Emerge consistently bails with an error message like this:
| Code: | Calculating dependencies... done!
>>> Emerging (1 of 1) app-shells/bash-3.1_p16 to /
/usr/lib/portage/bin/ebuild.sh: line 1200: : File or folder does not exist
!!! ERROR: app-shells/bash-3.1_p16 failed.
Call stack:
ebuild.sh, line 1447: Called source '/usr/portage/app-shells/bash/bash-3.1_p16.ebuild'
bash-3.1_p16.ebuild, line 5: Called inherit 'eutils' 'flag-o-matic' 'toolchain-funcs'
ebuild.sh, line 1200: Called die
!!! died sourcing in inherit()
!!! If you need support, post the topmost build error, and the call stack if relevant.
|
That happened yesterday, and at the end of the day I still hadn't managed to solve the problem. (To be honest I don't even know where to begin troubleshooting this one.) As if that wasn't enough - to add injury to insult (sic) when I turned on the computer this morning I couldn't log in. Not into KDE, and not into the terminal. Not as an ordinary user and not as root. It would accept the password - and then present me with a new login screen. Fscking piece of @#%!! 
I've got a 10GB partition with a 64-bit gentoo installation that I can boot into, and from which I can chroot into the borked 32-bit installation (that I normally use). But from the chrooted environment I still can't emerge anything. Same error message. Does anyone have a clue as to what went wrong or (even better) how to fix this mess?
BTW: Someone asked whether the directory /usr/portage/eclass exists, since that's (apparently) where the files that emerge complains about should reside. The directory does exist, and it contains 202 .eclass files. (I have no idea how many it should contain, but I do know that if there are files missing, they weren't removed by me.)
Last edited by IsmoHaa on Mon Aug 28, 2006 5:30 am; edited 1 time in total |
|
| Back to top |
|
 |
sfragis
Tux's lil' helper
Joined: 24 Mar 2005
Posts: 95
Location: RE < IT < Europe
|
| Posted: Sat Aug 26, 2006 3:24 pm Post subject: |
|
|
First of all, beware the 'emerge -e world', you shouldn't need it most of the cases! To update all of the packages use 'emerge -Davu world'.
Answering your question: try to enable debug messages in order to see what's missing.
| Code: |
$ ECLASS_DEBUG_OUTPUT=on emerge -av =app-shells/bash-3.1_p16
|
The eclasses the bash ebuild inherits are eutils, flag-o-matic and toolchain-funcs. For each of these, you should have the relative .eclass file in /usr/portage/eclass (unless you've changed PORTDIR var in /etc/make.conf).
Have you tried to 'emerge --synch' again?
_________________
Regards
Fabio Strozzi |
|
| Back to top |
|
|
jamapii
l33t
Joined: 16 Sep 2004
Posts: 637
|
| Posted: Sat Aug 26, 2006 5:16 pm Post subject: |
|
|
I think you can continue the update if you boot into a Gentoo Live CD (or equivalent).
Then mount your hard disk partitions under /mnt/somewhere, then do the necessary emerges with
ROOT=/mnt/somewhere emerge ... |
|
| Back to top |
|
|
IsmoHaa
n00b
Joined: 25 Jun 2005
Posts: 61
|
| Posted: Sat Aug 26, 2006 7:31 pm Post subject: |
|
|
Thanks for the responses. I tried out the suggestions, but unfortunately didn't make much progress...
-Emerging stuff with ECLASS_DEBUG_OUTPUT=on has no effect. The error message is exactly the same.
-My PORTDIR=/usr/portage and all the appropriate .eclass files exist in /usr/portage/eclass.
-emerge --sync doesn't change the situation at all.
-Booting from a live-CD: This one I haven't tried yet, because my network card doesn't work with the kernel provided with the live-CD. I suppose I could try to emerge something that's already downloaded, and if that works maybe first download everything from my 64-bit installation, and then build it from the live-CD... I'll post an update when I know how that goes.
[Edit]: No luck with the live-CD. The live-CD doesn't come with its own version of portage, so the only way to do an emerge is to chroot into the installation, which (not surprisingly) works just as badly as chrooting from the 64-bit installation. 
Still I haven't got any clue as to why I can't log in anymore (which really is the more acute problem). Does anyone have an answer to that? |
|
| Back to top |
|
|
hielvc
Advocate
Joined: 19 Apr 2002
Posts: 2805
Location: Oceanside, Ca
|
|
| Back to top |
|
|
IsmoHaa
n00b
Joined: 25 Jun 2005
Posts: 61
|
| Posted: Sun Aug 27, 2006 4:36 am Post subject: |
|
|
Sorry. That didn't help either.
I really need to get this system back on its feet. What would happen if I just installed a "stage-3" tarball onto it and re-emerged everything? Would that break things badly? (I can certainly see that it has the potential of screwing things up, which is why I've been reluctant to do so.) |
|
| Back to top |
|
|
IsmoHaa
n00b
Joined: 25 Jun 2005
Posts: 61
|
| Posted: Sun Aug 27, 2006 7:10 am Post subject: |
|
|
Ooookay. Since it seemed that it's /usr/lib/portage/bin/ebuild.sh which is the script that throws all the errors, I decided to do some hacking on it (after backing it up - I'm not completely insane yet.)
Since the error got thrown at line 1200 tha seemed to be a good place to start:
| Code: | <SNIP about 1180 lines>
debug-print "inherit: $1 -> $location"
[ ! -e "$location" ] && die "${1}.eclass could not be found by inherit()"
#We need to back up the value of DEPEND and RDEPEND to B_DEPEND and B_RDEPEND
#(if set).. and then restore them after the inherit call.
#turn off glob expansion
set -f
# Retain the old data and restore it later.
unset B_IUSE B_DEPEND B_RDEPEND B_PDEPEND
[ "${IUSE-unset}" != "unset" ] && B_IUSE="${IUSE}"
[ "${DEPEND-unset}" != "unset" ] && B_DEPEND="${DEPEND}"
[ "${RDEPEND-unset}" != "unset" ] && B_RDEPEND="${RDEPEND}"
[ "${PDEPEND-unset}" != "unset" ] && B_PDEPEND="${PDEPEND}"
unset IUSE DEPEND RDEPEND PDEPEND
#turn on glob expansion
set +f
source "$location" || die "died sourcing $location in inherit()" # <- Line 1200, which is where it dies
#turn off glob expansion
set -f
<SNIP>
|
Judging from the error message, the problem was obviously that $location was set to NULL, when it should have been set to something meaningful by the time the script got to line 1200. I looked around the script, and did some checking by inserting "echo" commands here and there, to see if $location was correctly assigned. It turned out that everything was okay, just until about line 1200 when $location for some obscure reason lost its value. Changing the script like this, would make it go further:
| Code: | debug-print "inherit: $1 -> $location"
[ ! -e "$location" ] && die "${1}.eclass could not be found by inherit()"
uglyhack=$location # <-- Change number 1
#We need to back up the value of DEPEND and RDEPEND to B_DEPEND and B_RDEPEND
#(if set).. and then restore them after the inherit call.
#turn off glob expansion
set -f
# Retain the old data and restore it later.
unset B_IUSE B_DEPEND B_RDEPEND B_PDEPEND
[ "${IUSE-unset}" != "unset" ] && B_IUSE="${IUSE}"
[ "${DEPEND-unset}" != "unset" ] && B_DEPEND="${DEPEND}"
[ "${RDEPEND-unset}" != "unset" ] && B_RDEPEND="${RDEPEND}"
[ "${PDEPEND-unset}" != "unset" ] && B_PDEPEND="${PDEPEND}"
unset IUSE DEPEND RDEPEND PDEPEND
#turn on glob expansion
set +f
location=$uglyhack # <-- Change number 2
source "$location" || die "died sourcing $location in inherit()"
#turn off glob expansion
set -f
|
Notice that I said "go further", not "run". Now I got another error. After doing some initial checks that end with the "winky smiley" to indicate success. The script told me to "Please specify a valid command" and then proceeded to output a lengthy instruction set for "ebuild". I located the offending error message to almost the very end of the script, and again I started troubleshooting by inserting "echo" commands to get a closer look at what it was doing. The code looked like this:
| Code: |
for myarg in $*; do
case $myarg in
nofetch)
<SNIP>
prerm|postrm|postinst|config)
<SNIP>
unpack|compile|test|clean|install)
if [ "${SANDBOX_DISABLED="0"}" == "0" ]; then
export SANDBOX_ON="1"
else
export SANDBOX_ON="0"
fi
if [ "$PORTAGE_DEBUG" != "1" ]; then
dyn_${myarg}
#Allow non-zero return codes since they can be caused b$
else
set -x
dyn_${myarg}
#Allow non-zero return codes since they can be caused b$
set +x
fi
export SANDBOX_ON="0"
;;
help|setup|preinst)
<SNIP>
depend)
<SNIP>
*)
export SANDBOX_ON="1"
echo "Please specify a valid command."
echo
dyn_help
exit 1
;;
esac
|
The whole error was really weird. It would seem that everything in this function went just fine, until the script called it with the "unpack" parameter. (Cleaning for instance worked perfectly.) Then for some bizarre reason it wouldn't recognize the parameter, and default to the "Please specify a valid command" error. I added the following "echo" line in order to see if the values were preserved:
| Code: |
for myarg in $*; do
echo "crap: "$* $myarg
case $myarg in
|
AND THE SCRIPT FLIPPIN' RAN!!!  I added NOTHING but a line to print some crap to the screen, and that was the difference between the script recognizing the parameter, and not! If I posted this during the same quarter as april fools day, noone would believe me.
I still haven't tried to actually log in, because I'm rather doubtful as to whether it would work. I can't really see any parallells between hacking an ebuild script and logging on to the system... but then again I don't see why these stupid workarounds of mine should affect the script either. I suppose that in order to log in I'll have to smear myself in chicken blood and run naked 7 times around my house clockwise, at midnight during a full moon while screaming "IA, IA, CTHULHU FHTAGHN!" |
|
| Back to top |
|
|
Dralnu
Veteran
Joined: 24 May 2006
Posts: 1919
|
| Posted: Sun Aug 27, 2006 9:26 am Post subject: |
|
|
I had/have (need to bugreport it. Hrm..) an issue with portmon and the new baselayout. Problem with a command.
Changed it from error to echo, and it didn't complain...
_________________
The day Microsoft makes a product that doesn't suck, is the day they make a vacuum cleaner. |
|
| Back to top |
|
|
IsmoHaa
n00b
Joined: 25 Jun 2005
Posts: 61
|
| Posted: Mon Aug 28, 2006 5:29 am Post subject: |
|
|
| Ok. The problem (whatever the heck it was) has been solved. The silly hacks I did to the script allowed me to chroot into the system and perform the "emerge -e system". After that I managed to boot and log in (yay!) Only problem was that KDE wouldn't start because the nvidia-module refused to load. That turned out to be because of the kernel (which was still the version compiled with the 3.3 compiler). After re-compliling and rebooting, I finally had a working system, and a better understanding of vood^H^H^H^Hcomputers. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
