# unemerged python-exec jetzt ist emerge broken.. [solved]

## ChrisJumper

Wie der Titel schon sagt. Ich habe einen sehr dummen Fehler begangen.

```
[?] dev-lang/python-exec

     Available versions:  (2) 2.0.1-r1 **2.9999

       {PYTHON_TARGETS="jython2_5 jython2_7 pypy pypy3 python2_7 python3_3 python3_4"}

     Installed versions:  0.3.1-r1(11:56:58 12.03.2014)(PYTHON_TARGETS="jython2_5 jython2_7 pypy2_0 python2_6 python2_7 python3_2 python3_3 -python3_4") 2.0.1-r1(2)(11:56:28 12.03.2014)(PYTHON_TARGETS="jython2_5 jython2_7 pypy2_0 python2_6 python2_7 python3_2 python3_3 -python3_4")

     Homepage:            https://bitbucket.org/mgorny/python-exec/

     Description:         Python script wrapper
```

Das verleitete mich dazu das Parket mit -C zu entfernen. Wie ich jetzt weiß sollte man lieber -c nehmen.

Mein Problem ist aber das ich jetzt ein zerbrochenes emerge habe.

Hier hatte jemand das Problem. Aber mit dem Tipp python neu zu bauen hat es nicht funktioniert.

Dann habe ich auch noch diese Fixin broken portage Anleitung in der falschen Teminal ausgeführt und... jetzt habe ich zwei Systeme die mehr oder weniger kaputt sind.

Auf System 1, wo nur diese Anleitung befolgt wurde. Ich nehme an das

```
rm -rf /usr/lib/portage/*
```

kam da nicht so gut an, bekomme ich folgende Fehlermeldung:

```
emerge -1 portage

Calculating dependencies... done!

Traceback (most recent call last):

  File "/usr/lib/python-exec/python2.7/emerge", line 50, in <module>

    retval = emerge_main()

  File "/usr/lib/python2.7/site-packages/_emerge/main.py", line 1070, in emerge_main

    return run_action(emerge_config)

  File "/usr/lib/python2.7/site-packages/_emerge/actions.py", line 4082, in run_action

    emerge_config.args, spinner)

  File "/usr/lib/python2.7/site-packages/_emerge/actions.py", line 454, in action_build

    retval = mergetask.merge()

  File "/usr/lib/python2.7/site-packages/_emerge/Scheduler.py", line 949, in merge

    rval = self._handle_self_update()

  File "/usr/lib/python2.7/site-packages/_emerge/Scheduler.py", line 318, in _handle_self_update

    _prepare_self_update(self.settings)

  File "/usr/lib/python2.7/site-packages/portage/package/ebuild/doebuild.py", line 2326, in _prepare_self_update

    shutil.copytree(orig_bin_path, portage._bin_path, symlinks=True)

  File "/usr/lib/python2.7/site-packages/portage/__init__.py", line 259, in __call__

    rval = self._func(*wrapped_args, **wrapped_kwargs)

  File "/usr/lib/python2.7/shutil.py", line 171, in copytree

    names = os.listdir(src)

OSError: [Errno 2] Datei oder Verzeichnis nicht gefunden: '/usr/lib/portage/python2.7'
```

Kann es auch sein das /usr/lib64 und /usr/lib32 bei den Pfadangaben eine Rolle spielen wo, das portage-2.2.18/portage/bin hinkopiert werden muss?

Noch mal zu System 2. Dort habe ich sowohl portage installiert als auch python, von Hand und python-exec. Beides bringt mich zu der Fehlermeldung:

```
# emerge -1 portage

Could not find platform independent libraries <prefix>

Could not find platform dependent libraries <exec_prefix>

Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]

Fatal Python error: Py_Initialize: Unable to get the locale encoding

ImportError: No module named 'encodings'

Abgebrochen
```

Ja ich bin Müde und es war spät. Somit habe dann auch noch python statt python-exe auf dem System erneuert. Anschließend weitere Probleme, wenn ich jedenfalls

mittels "eselect python set" zu einer Version wechsel die ich nicht überschrieben habe bekomme ich folgenden Fehler:

```
# emerge -1 =dev-lang/python-3.3.5-r1

Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-lang/python-3.3.5-r1::gentoo

[dev-lang/python-3.3.5-r1] bash: /usr/lib/portage/python2.7/ebuild.sh: No such file or directory

 * The ebuild phase 'die_hooks' has been aborted since PORTAGE_BUILDDIR

 * does not exist: '/var/tmp/portage/dev-lang/python-3.3.5-r1'

>>> Failed to emerge dev-lang/python-3.3.5-r1

 * Messages for package dev-lang/python-3.3.5-r1:

```

Kann ich nicht auf beiden Systemen ein stage3 entpacken und das System neu bauen? Oder sollte es noch anders funktionieren?Last edited by ChrisJumper on Thu Mar 19, 2015 7:18 pm; edited 1 time in total

----------

## ChrisJumper

-_-

Kein guter Tag. Heute habe ich natürlich Fehler Nummer 3 begangen und ein stage3 Tar entpackt. Was mir jetzt alle Konfiguratoinsdateien überschrieben hat. Von Group bis /etc/fstab bis /etc/sshd und /etc/hosts

Ja manch mal werden schlechte Tage noch schlechter. Nein Portage geht da immer noch nicht ;D

Edit Ich bin weiter, Portage geht wieder auf dem worst case System da ich einen Symlink von /usr/lib64/portage/python2.7 nach /usr/lib/portage/pthon2.7/ gelegt habe. Dann wird das mit dem rest wohl auch wieder, aber wie komme ich an die ganzen Nutzer Verzeichnisse wieder ran für die anderen? Einfach alles neu bauen oder?

Edit: Also die flasche Portage Version Installieren, dann noch das stage3 Tarbell drübe welches mir die ganzen Config-Dateien überschrieben hat, das war schon heftig. Jetzt habe ich mit Hilfe der Binärpakete tinderbox.dev.gentoo.org/default-linux/amd64 aber zumindest wieder ein funktionierenden Compiler und emerge. Ich werde dann heute mal das System neu bauen und die Konfigurations-Dateien finde ich auch noch. Dann wird gleich morgen ein besseres Backupsystem installiert.

Aber immer wieder schön zu sehen wie SEHR man selbst ein zerschlagenes python, emerge, portage und gcc, wieder reparieren kann. Und das auch noch heute wo die große openssl-lücke gefixt wird.

----------

## Yamakuzure

Ehrlich gesgt war mein erster Gedanke: "Ach du heilige Sch**e!!!"

Und ich muss ehrlich gestehen, dass das mit dem stage3 tarball auch meine Idee wäre, allerdings würde ich das dann nicht nach /usr entpacken, sondern /tmp und dann nur das (von Hand, ja) rauskopieren, was fehlt.

An die tinderbox hatte ich garnicht mehr gedacht. Schon mal gut, dass das funktioniert hat.

----------

## py-ro

Die richtige Lösung wäre

```
/usr/lib/python-exec/python2.7/emerge
```

zu nutzen gewesen.

Jetzt ist dein System ziemlich im Eimer...

Bye

Py

----------

## Josef.95

Ach schade, mit dem nun drüber kopierten stage3 ist das System nun leider hin :(

(Nutze am besten das letzte funktionierende Backup, oder installiere neu)

Bezüglich dem versehentlich deinstallierten dev-lang/python-exec hätte der Tipp aus https://forums.gentoo.org/viewtopic-p-7648990.html#7648990 helfen sollen. 

```
# /usr/lib/python-exec/python2.7/emerge -1 dev-lang/python-exec
```

/edit

Oh, da war py-ro schneller :)

----------

## ChrisJumper

Also aktuell habe ich nur auf dem System wo ich aus versehen portage falsch "gefixt" hatte, noch das problem das emerge eben nicht geht. Aber Das system selbe scheint stabil zu laufen.

dort habe in de tat auch ein /usr/lib/python-exec/python2.7/emerge

Doch mit einem Symlink:

```
# ls -lah /usr/bin/emerge

lrwxrwxrwx 1 root root 37 19. Mär 20:16 /usr/bin/emerge -> /usr/lib/python-exec/python2.7/emerge
```

Funktioniert das immer noch nicht es bleibt bei:

```
[dev-lang/python-2.7.9-r1] bash: /usr/lib/portage/python2.7/ebuild.sh: Datei oder Verzeichnis nicht gefunden

 * The ebuild phase 'die_hooks' has been aborted since PORTAGE_BUILDDIR

 * does not exist: '/var/tmp/portage/dev-lang/python-2.7.9-r1'

>>> Failed to emerge dev-lang/python-2.7.9-r1
```

Ich denke ja das der Fehler darin leigt das ich KEINEN Symlink bei /usr/lib auf /usr/lib64 habe. Fragt mich nicht wieso! Bei dem anderen worst case System, dem es mittlerweile schon besser geht (stage3 hat nicht sehr viele wichtige Config-Dateien erwischt), die ich jetzt wieder nachreiche.

Kann ich mich auf dem System hier aus der Affaire ziehen wenn ich die paar Dateien unter /usr/lib nach /usr/lib64 kopiere und anschließend /usr/lib als Symlink auf /usr/lib64 verknüpfe.

Doch bevor ich das probiere mach ich erst mal das andere System wieder Fit. Der Vorteil dort ist aktuell das es läuft. Das ich denke wenn ich alle Pakete (auch die die einen Benutzer angelegt haben) neue emerge kommt wieder alles in Ordnung, denn der stage3-Fehler hat eben nur die meisten Konfigurationsdateien überschrieben die ich auch noch grob kannte. Alles wichtige der Programme die jetzt eigentlich Fehler produzieren sollten liegt noch in weiteren Configdateien.

Es ist schon erstaunlich wie Robust so ein system noch unter solchen perversen Bedingungen ist. Doch bin mir sicher das ich nicht hätte booten können und hätte ich zum falschen Zeitpunkt die Shell zugemacht und nicht neue Benutzer angelegt/passwörter vergeben, eben wie nach einer neuen Installation. Dann hätte ich mich nicht nur böse ausgesperrt sondern erst recht ein System gehabt das nicht mehr hochgefahren wäre.

----------

## py-ro

Klingt danach, dass du den falsche Stage Tarball entpackt hast.

----------

## ChrisJumper

Also den Symlink habe ich auf dem System wohl...

```
# ls -lah /usr/lib

lrwxrwxrwx 1 root root 5 27. Okt 2010  /usr/lib -> lib64
```

```
# equery b /usr/lib/portage/python2.7

 * Searching for /usr/lib/portage/python2.7 ...

sys-apps/portage-2.2.14 (/usr/lib/portage/python2.7)
```

Das macht bei mir den Eindruck als sollte in dieser

```
wget http://distfiles.gentoo.org/distfiles/portage-2.2.14.tar.bz2
```

Datei eigentlich ein Notfall-python2.7 dabei sein. In der anderen Installation hatte ich einfach glück (?) das dort unter /usr/lib64/portage die python Version lag. Vielleicht war es aber auch weil ich nach dem Stage3-Vorfall auch tinderbox nutzte.

Die Tinderbox nutze ich späte auf dem System aktuell habe ich erst mal die Nase voll :)

Der Aufwand beim anderen System kam allerdings einer neu Installation gleich.

----------

## ChrisJumper

Kann es sein!?

Das wenn ich ein tar-file von tinderbox entpacke, das den Link unter /usr/lib auf /usr/lib64 überschreibt?

```
# ls -lah /usr/lib

insgesamt 12K

drwxr-xr-x  3 root root 4,0K 23. Nov 21:25 .

drwxr-xr-x 19 root root 4,0K 23. Nov 21:25 ..

drwxr-xr-x  2 root root 4,0K 23. Nov 21:25 python-exec
```

/usr/lib/portage/python2.7 habe ich immer noch nicht gefunden.

----------

## Klaus Meier

Damit mir so etwas nicht mehr passiert, bin ich auf btrfs umgestiegen. Jeden Morgen, wenn ich meine Kiste anwerfe, mache ich als erstes einen Snapshot. Geht etwas schief, dann kann ich den wieder herstellen.

----------

## ChrisJumper

Ja das ist die einzige richtige Lösung.

Ich habe natürlich auf dem einen System mit dem ehemals entpackten stage3 *das war so eine dumme Idee!*, alles neu installieren und einrichten müssen und vor allem weil nach der Installation diverse Nutzerrechte anders waren musste ich die Verzeichnisse/Logdateien/Datenbanken noch entsprechend anpassen, damit diese mit den NEU angelegten Benutzern übereinstimmen, weil die Reihenfolge anders war waren natürlich UID und GID vertauscht. aber danach und nachdem ich alles neu gebaut hatte. Schnurrt das System wieder wie ein Kätzchen.

Das selbe natürlich auch auf dem System hier, ein mal python und die Verzeichnisse wieder in Ordnung gebracht, einfach die modifizierten Pakete neu installiert und es war wieder alles gut. Aber jetzt habe ich erst mal die Nase voll, der Rest folgt morgen/nächste Woche.

Dann überlege ich mir auch ein 2 System Backup, das verschlüsselt auch von beiden Systemen auf unterschiedliche Festplatten macht. Da werde ich noch mal Geld investieren damit es eine ordentliche Lösung wird. Das blöde ist ja auch bei den Terrabyte Monstern das die Verführug da ist das auf eine Platte zu machen.

----------

## Klaus Meier

Ein Backup ist aber etwas anderes als ein Snapshot. Wenn du kein btrfs verwendest, kann du kein bootfähiges Backup von einem laufenden System erstellen. Du musst dazu von einem Rettungsmedium booten um das Backup zu erstellen. Daten kannst du direkt sichern, das System nicht. Mit btrfs geht das auch im laufenden Betrieb. Snapshot erstellen und das sichern.

Des weiteren, du weißt ja gar nicht, ob du das Backup brauchst. Das Snapshot belegt erst mal keinen Platz und dauert nur Sekunden. Was natürlich nicht heißt, dass du kein Backup machen solltest. Aber das dann auf eine andere Platte. Und du kannst jederzeit einfach mal so ein Snapshot anlegen, wenn du etwas machst, was vielleicht in die Hose geht. Die Hemmschwelle ist Null, es kostet weder Platz noch Zeit.

Und sage mir keiner btrfs ist noch nicht so weit. Hatte Stress mit meinem Lüfter, da hat sich die Kiste beim Kompilieren permanent wegen Überhitzung abgeschaltet. Mir ist da wegen COW nicht eine Datei kaputt gegangen. Das System war dann halt im Zustand von vor 5 Minuten, aber niemals war eine Datei kaputt. Der Schaden, der durch Fehlbedienung entsteht, weil man keinen Snaphot hat, der ist deutlich größer als das, was btrfs so anrichten kann.

P.S.: Habe die Lüftung jetzt freigeräumt, CPU ist 20 Grad kühler...

----------

## Yamakuzure

 *Klaus Meier wrote:*   

> Mit btrfs geht das auch im laufenden Betrieb. Snapshot erstellen und das sichern.

 Oder mit ZFS.  :Wink:  (Kleine Gegenüberstellung)

----------

## ChrisJumper

 *py-ro wrote:*   

> Die richtige Lösung wäre
> 
> ```
> /usr/lib/python-exec/python2.7/emerge
> ```
> ...

 

An dieser Stelle noch mal super vielen dank Py-ro für diesen Tipp. Denn lustiger Weise hatte ich genau diesen Fall wieder. Google brachte mich auf einen Thread. Auch ein anderer Post hier im Forum hatten wohl empfohlen das man einfach die Pakete entfernen soll... Was hasse ich Python Updates, da wünsche ich mir langsam ein alles um Fassendes-Pakete wo alle Pakete enthalten sind. Gibt es dafür noch keinen meta-Befehl?

Python-Updater habe ich schon versucht, der lief ja in das Problem. Zudem war das System hier noch auf Python 2.7 und dann kam die News das jetzt Python 3.4 Standard ist, aber ein direkter Sprung ist auch quark, und geht nicht, daher laufe ich jetzt noch den Umweg über Python 3.3.

----------

## py-ro

Mittlerweile sollte einfaches emerge alles erledigen, perl-cleaner, python-updater und revdep-rebuild sind nicht mehr nötig.

Bye

Py

----------

## Josef.95

 *py-ro wrote:*   

> Mittlerweile sollte einfaches emerge alles erledigen, perl-cleaner, python-updater und revdep-rebuild sind nicht mehr nötig.
> 
> ..

 

Sorry, dem kann ich nicht ganz zustimmen :)

python-updater <-- Ja ok, der ist i.d.R. wohl wirklich kaum mehr nötig

perl-cleaner <-- Sollte man nach einem perl Upgrade auf jeden Fall nutzen (so wie in den postinstall-messages von perl auch empfohlen)

revdep-rebuild <-- Sollte man nach einem System-Update idR auch noch nutzen

Aktuelles Beispiel nach einem binutlils Update: 

```
[ 29% ]  *   broken /usr/lib/cairo/libcairo-trace.so.0.0.0 (requires libbfd-2.25.so)
```

 Da hilft bisher auch kein preserve-libs Feature, (und Subslot "zwangs-rebuild" gibt es hier noch nicht).

Sprich ein gelegentliches prüfen via revdep-rebuild -i sollte nicht schaden.

----------

## Josef.95

 *ChrisJumper wrote:*   

> Python-Updater habe ich schon versucht, der lief ja in das Problem. Zudem war das System hier noch auf Python 2.7 und dann kam die News das jetzt Python 3.4 Standard ist, aber ein direkter Sprung ist auch quark, und geht nicht, daher laufe ich jetzt noch den Umweg über Python 3.3.

 

Bitte nicht falsch verstehen - die aktuelle default Änderung im Profil betrifft nur python3 (von 3.3 auf 3.4)

Den Main-Active-Python-Interpreter würde ich noch auf python2.7 lassen.

Hier schauts aktuell so aus: 

```
# eselect python show

python2.7

# eselect python show --python3

python3.4
```

----------

## Josef.95

Und noch ein Nachschlag  :Wink: 

Ich würde das so machen wie in der News empfohlen - das sollte idR funktionieren:  *News - 2015-07-25  Python 3.4 enabled by default wrote:*   

> 
> 
> 2015-07-25-python-targets
> 
>   Title                     Python 3.4 enabled by default
> ...

 

Nach dem Vorgeschlagenen

eselect python set --python3 python3.4

emerge -uDv --changed-use @world

sollte es mit python-updater normal kaum noch was zu tun geben.

----------

## ChrisJumper

 *Josef.95 wrote:*   

>  *ChrisJumper wrote:*   Python-Updater habe ich schon versucht, der lief ja in das Problem. Zudem war das System hier noch auf Python 2.7 und dann kam die News das jetzt Python 3.4 Standard ist, aber ein direkter Sprung ist auch quark, und geht nicht, daher laufe ich jetzt noch den Umweg über Python 3.3. 
> 
> Bitte nicht falsch verstehen - die aktuelle default Änderung im Profil betrifft nur python3 (von 3.3 auf 3.4)
> 
> Den Main-Active-Python-Interpreter würde ich noch auf python2.7 lassen.
> ...

 

Ah das ja... die Hitze. Ich hab jetzt python 3.3, den Absatz mit Python_Singel_Target ist natürlich noch auf 2.7. Bisher hatte ich keine Probleme. Ich denk aber noch mal dran das wieder auf 2.7 zu setzten vor dem nächsten World Update, danke für den Hinweis.

Sehr schön zu lesen das sich die Situation dort verbessert! @py-ro

----------

