# [gelöst] emerge kaputt nach Kernel-upgrade

## Bartkauz

Guten Tag zusammen,

ich habe vor kurzem versucht, von Kernel 5.16.2 auf 5.16.20 zu upgraden. Nach neuem Booten scheint erst mal alles zu funktionieren - bis ich versuche, irgendeinen ebuild neu zu emergen. Dann passiert folgendes (zum Beispiel bei 'emerge portage'):

 *Quote:*   

> 
> 
> >>> Running pre-merge checks for sys-apps/portage-3.0.34
> 
> Exception in callback AsynchronousTask._exit_listener_cb(<bound method...7ffb259eef80>>)
> ...

 

Gleiches beim Versuch mit einem noch neueren Kernel (5.18.9). Sowie ich wieder den 5.16.2 - Kernel boote (den ich noch als .old im /boot Verzeichnis habe), funktioniert das emergen wieder.

hier mein emerge --info:

 *Quote:*   

> 
> 
> Portage 3.0.34 (python 3.10.5-final-0, default/linux/amd64/17.1, gcc-10.4.0, glibc-2.35-r8, 5.16.2-gentoo x86_64)
> 
> =================================================================
> ...

 

Hat jemand eine Idee, woran das liegen könnte?? Bei einer Änderung von Kernel 5.16.x nach 5.18.y könnte ich verstehen, dass nicht alles auf Anhieb klappt, aber von 5.16.x nach 5.16.y ??

Gruss und Dank,

ThomasLast edited by Bartkauz on Tue Aug 16, 2022 3:05 pm; edited 1 time in total

----------

## pietinger

Willkommen bei Gentoo, Bartkauz !

Spontan fallen mir drei Fragen ein:

1. Wie bist Du beim Update vorgegangen ? (Hoffentlich mit "make oldconfig"; Wie hast Du die Fragen beantwortet ?)

2. WIESO 5.16.20 und 5.18.9 ? Beide sind schon ziemlich alt =>

3. Was passiert wenn Du auf die aktuellen 5.18.17 oder 5.19.1 updatest ?

----------

## Bartkauz

Vielen Dank für die schnelle Antwort!

1.: ja, mit make oldconfig. Die Fragen nach bestem Wissen und Gewissen beantwortet (Hardware, die ich sowieso nicht habe: nein, sonst meist ja bzw. als Modul). Von 5.16 2 auf 5.16.20 waren aber nur 2 oder 3  Fragen)

2.: 5.16.20, weil ich ihn schon mal runtergeladen hatte, und ich dachte, je kleiner die Versionsnummer - Differenz, desto eher könnte es klappen.

Ich musste weiteres Probieren dann aus Zeitgründen aufschieben, bis 5.18.9 aktuell war. Jetzt habe ich wieder etwas Luft und will die Geschichte nicht weiter aufschieben.

3.: 5.19.1. kompiliere ich über Nacht. Bin gespannt auf morgen...

Gruss und Dank,

Thomas

----------

## mike155

Ungewöhnlich an der "emerge --info"- Ausgabe ist:

```
gentoo

    location: /var/portage

    ...

local_portage

    location: /var/local_portage

    ...

```

Hier sollte eigentlich stehen:

```
gentoo

    location: /var/db/repos/portage

    ....

local_portage

    location: /var/db/repos/local_portage

    ...

```

Die Fehlermeldung ist interessant:

```
PermissionError: [Errno 13] Keine Berechtigung: b'/tmp/sys-apps:portage-3.0.34:20220814-153557.log'

```

Könnte es einen Grund dafür geben? Sind /tmp, /var/tmp oder /var/tmp/portage beispielsweise ein tmpfs bei den Kernels, bei denen es funktioniert? Und ein Verzeichnis in der root-Partition bei den Kernels, bei denen es nicht funktioniert?

----------

## Bartkauz

Hallo mike155,

die locations sind historisch gewachsen. Ich erinnere mich dunkel, daß es da mal vor vielen Jahren einen vernünftigen Grund dafür gab.

Die Fehlermeldung hat mich auch schon beschäftigt. Zunächst: /tmp ist bei mir immer ein tmpfs, /var/tmp eine Partition mit jfs drauf, und /var/tmp/portage ein Directory in derselbigen:

Hier die betreffen Zeilen aus dem output von mount:

```

/dev/sdb5 on /var/tmp type jfs (rw,nosuid,nodev,relatime,lazytime)

none on /tmp type tmpfs (rw,nosuid,nodev,noexec,noatime,lazytime,size=3145728k)

```

Das Logfile, dessen Name in der Fehlermeldung angegeben ist, existiert auch (ist aber hier unergiebig). Aber da ist noch so ein vagabundierendes 'b' vor dem Namen, das kann ich gar nicht einordnen...

----------

## Bartkauz

So, jetzt bin ich auf Kernel Version 5.19.1 .

Gleiches Problem, ich habe die Verzeichnisse /tmp und /var/tmp händisch überprüft, sie sind eingehängt wie immer; insbesondere genau wie in dem funktionierenden Fall mit Kernel 5.16.2 .

Rechte sind ebenfalls gleich.

----------

## pietinger

Hmm ... 5.16.2 ist ja schon ziemlich alt. Weiß noch jemand WANN wir die Änderung im Kernel hatten bezüglich der Zugriffsrechte bei tmp-files ? Möglicherweise war das erst nach 5.16.2 ?

Falls es das ist, dann dürfte die Ursache sein, dass Deine Berechtigungen falsch sind. Möglicherweise fehlt Dir das Sticky-Bit auf /var/tmp/portage

Man kann das über sysctl auch wieder ausschalten (habe aber leider vergessen was das war; und mir damals nicht notiert).

P.S: Habs wieder gefunden: https://sysctl-explorer.net/fs/protected_symlinks/

----------

## Josef.95

Hm, könnte eventuell auch ein =sys-apps/portage-3.0.34 Bug sein -> Bug 864160 tönt verdächtig.

Teste bitte mal mit stable =sys-apps/portage-3.0.30-r3

----------

## Bartkauz

Leider bisher kein Erfolg. Ich habe auf portage 3.0.30-r3 (mit dem 'alten' Kernel 5.16.2) gedowngraded, dann wieder 5.19.1 gebootet und das sticky bit auf /var/tmp/portage erstmal manuell gesetzt, so daß jetzt:

```

 ls -dl /var/tmp/portage

drwxrwxr-t 3 portage portage 24 15. Aug 13:58 /var/tmp/portage

```

ist.

Genau der gleiche Fehler wie zuvor   :Sad: 

Er meckert über File "/usr/lib/python3.10/site-packages/portage/util/_async/PipeLogger.py", line 42.

Ich hab da mal reingeschaut; da wird wohl ein Logfile zu öffnen versucht:

```

                 self._log_file = open(

                     _unicode_encode(

                         log_file_path, encoding=_encodings["fs"], errors="strict"

                     ),

                     mode="ab",

                 )

```

 Leider gehen meine Python-Kenntnisse gegen Null, sonst würde ich als Provisorium das Logfile hard-coded irgendwohin schreiben...

----------

## pietinger

Probier' mal:

```
# echo 0 > /proc/sys/fs/protected_symlinks
```

Wenn danach immer noch der Fehler beim emerge kommt, dann war es das nicht und wir müssen woanders suchen.

Falls es danach geht, fehlt vermutlich einem anderem tmp-Verzeichnis das sticky-bit. (Bin leider auch kein python-Mensch)

----------

## mike155

Falls der Vorschlag von @pietinger nicht funktionieren sollte, mache bitte Folgendes:

Boote Kernel 5.16.2 (bei dem es funktioniert) und poste dann mit wgetpaste:

Die Ausgabe von dmesg

Die Datei /proc/config.gz (vor dem Posten auspacken). Bitte nimm wirklich diese Datei - und nicht ein .config, das bei den Kernel-Quellen steht.

Boote dann 5.16.20 (bei dem es nicht funktioniert) und poste auch dort mit wgetpaste:

Die Ausgabe von dmesg

Die Datei /proc/config.gz (vor dem Posten auspacken). Bitte nimm wirklich diese Datei - und nicht ein .config, das bei den Kernel-Quellen steht.

Du kannst auch schon mal mit "diff" oder einem Diff-Tool wie "diffuse" schauen, ob Du nennenswerte Unterschiede findest.Last edited by mike155 on Mon Aug 15, 2022 1:23 pm; edited 1 time in total

----------

## Bartkauz

Nein, das tut leider auch nicht.

Mich irritiert immer noch das herrenlose 'b'  in der letzten Zeile der Fehlermeldung. Das Logfile dahinter (/tmp/..... .log) existiert, ist aber (mir) inhaltlich keine Hilfe. Ich poste es trotzdem mal (hier zur Abwechslung mal beim Versuch, sudo neu zu emergen):

```

 /var/tmp # more /tmp/app-admin:sudo-1.9.10-r1:20220815-125857.log

 * Package:    app-admin/sudo-1.9.10-r1

 * Repository: gentoo

 * Maintainer: base-system@gentoo.org

 * USE:        abi_x86_64 amd64 elibc_glibc kernel_linux nls pam secure-path sendmail ssl userland_GNU

 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox

```

Die FEATURES-Zeile sagt mir nichts (warwohlschonimmerso...). Vielleicht weiss ein Kundiger, ob da irgendwas schräg ist?

----------

## mike155

Das b ist nicht herrenlos. Es definiert, dass ein "binary string" folgt. Bei Dateinamen ist das notwendig, weil Dateinamen (leider) auch Nicht-UTF-8-Format haben können. Deshalb sollte man da nicht mit UTF-8 Strings arbeiten.

----------

## Bartkauz

Sorry mike155, da gab es eine Überschneidung. Aber danke für die Erklärung zum 'b'.

/proc/config.gz gibt's bei mir nicht. Vielleicht habe ich es beim Kernel-konfigurieren irgendwann mal abgeschaltet. Kann man es (z.B. per sysctl) irgendwie nachträglich bekommen? Ansonsten müsste ich beide Kernel erst neu kompilieren.

Übrigens: wgetpaste "dmesg.gehtnicht" ist vom Kernel 5.19.1; pietinger hatte gestern empfohlen, auf diesen upzugraden und ich habe danach 5.16.20 und 5.18.9 gelöscht.

wgetpaste (für dmesg) benutze ich zum ersten Mal. Beim Überfliegen von dmesg ist mir nichts Besonderes aufgefallen, ich muss aber zugeben, daß ich weite Teile davon nicht verstehe.

 *Quote:*   

> 
> 
>  wgetpaste dmesg.geht
> 
> Your paste can be seen here: http://dpaste.com/68RADVEBG
> ...

 

 *Quote:*   

> 
> 
>  wgetpaste dmesg.gehtnicht
> 
> Your paste can be seen here: http://dpaste.com/DNXMD2ZHW
> ...

 

----------

## Bartkauz

Hier jetzt nochmal mit den config.gz's:

avalon-rw ~ # wgetpaste dmesg.geht

Your paste can be seen here: http://dpaste.com/5K9YJCN8W

avalon-rw ~ # wgetpaste dmesg.gehtnicht

Your paste can be seen here: http://dpaste.com/4RZXSQ4KV

avalon-rw ~ # wgetpaste config.geht

Your paste can be seen here: http://dpaste.com/DB79E4XSD

avalon-rw ~ # wgetpaste config.gehtnicht

Your paste can be seen here: http://dpaste.com/52PE3ZJAK

----------

## mike155

Danke für die Daten.

Aber so geht es nicht. Sorry!

Ich hatte absichtlich nach den Daten von 5.16.2 und 5.16.20 gebeten, weil ich dort nur geringe Unterscheide in der .config und in der dmesg-Ausgabe erwarte. 

Ein unabsichtlicher Unterschied würde dort sofort auffallen.

Zwischen 5.16 und 5.19 hat sich einiges geändert. Bei einem diff sieht man also viele Unterschiede - und dann ist die Suche nach interessanten Unterschieden wie die Suche nach der Nadel im Heuhaufen.

Könntest Du also bitte noch die Daten von "5.16.20 (geht nicht)" posten? Das würde es deutlich einfacher machen!

----------

## mike155

Ich habe die 5.16.2 Dateien mit den 5.19.2 Dateien verglichen. Der Hauptunterschied ist folgender Kernel Command Line Parameter:

```
systemd.unified_cgroup_hierarchy=1
```

Der ist beim Booten mit Kernel 5.19 vorhanden - und beim Booten mit Kernel 1.16.2 nicht.

Könnte es daran liegen?

----------

## Bartkauz

Danke für Deine Mühe, mike155!

Der command line Parameter macht keinen Unterschied (gerade ausprobiert). und die 5.16.* Kernels sind nicht mehr im Portage tree. Ich muss also mein letztes Backup vorholen; das dauert eine Weile...

----------

## mike155

Lass mal vorerst die Backpus. Ich habe die Dateien ja verglichen.

In den dmesg Ausgaben ist mir noch aufgefallen:

```
ext2 filesystem being mounted at /var/tmp
```

Was hat das zu bedeuten? Das ist doch wohl nicht richtig, oder?

Außerdem sehe ich, das Du BTRFS verwendest. Das könnte (!) auch ein Grund für Probleme sein.

Ich kann mir aber auch gut vorstellen, dass es ein ganz anderes Problem ist, das nichts - oder nur indirekt - mit den Kernel-Versionen zu tun hat.

----------

## Bartkauz

@mike155:

Hmmm...als ich Dein letztes Posting gelesen habe, war 5.16.20 schon am kompilieren, sodaß alles, was Du angefordert hattest, jetzt eh schon fertig ist:

```

avalon-rw ~ # wgetpaste d*20

Your paste can be seen here: http://dpaste.com/BLFCGXDLN

avalon-rw ~ # wgetpaste c*20

Your paste can be seen here: http://dpaste.com/8REBZF8XS

```

emerge unter diesem Kernel geht nach wie vor nicht.

/var/tmp ist tatsächlich eine eigene Partition - eigentlich mit jfs, testweise auch mal mit ext2 formatiert. War ein Schuss ins Blaue. BTRFS insgesamt rauszuschmeissen würde mir weh tun; ich liebe die Snapshots. Eher würde ich den Kernel 5.16.2 aufheben und

----------

## mike155

Deine Kernel configs 5.16.2 und 5.16.20 sind fast gleich. Es gibt nur zwei kleine Unterschiede, die aber das Problem nicht erklären können.

Auch die Ausgaben von dmesg sind fast gleich. Der Hauptunterschied ist systemd.unified_cgroup_hierarchy=1 - aber Du hast ja schon geprüft, dass das keinen Unterschied macht.

Wir können also aufhören, am Kernel zu suchen. Daran liegt es nicht.

Was passiert, wenn Du /var/tmp nicht mehr mit ext2 formatierst, sondern mit ext4?

Was passiert, wenn Du alternativ gar keine Partition nach /var/tmp mountest - und stattdessen ein tmpfs mountest?

Was BTRFS angeht: ich meinte nicht, dass Du BTRFS ersetzen sollst. BTRFS macht nur hin und wieder Probleme - deswegen bin ich da vorsichtig. Lösche doch mal ein paar alte Snapshots und lass ein btrfs-check über die Partition laufen.

Du schreibst, dass Du die Datei /tmp/sys-apps:portage-3.0.34:20220814-153557.log im Dateissystem sehen kannst? Bitte poste die Ausgabe von

```
ls -la /tmp/sys-apps:portage-3.0.34:20220814-153557.log
```

Vielleicht hilft uns das weiter. Warum sollte es ein "permission" Problem beim Zugriff auf diese Datei geben?

----------

## Bartkauz

Alle Variationen mit /var/tmp habe ich schon ausprobiert: jfs, ext2/4, tmpfs, garnichts (d.h. /var/tmp liegt auf der Partition, wo /var auch ist).

btrfs check (von einem Notfallsystem auf sda2 aus, mein Livesystem ist auf sdb1):

```

avalon-rw /mnt # more sda2/junk.txt

[1/7] checking root items

[2/7] checking extents

[3/7] checking free space tree

[4/7] checking fs roots

[5/7] checking only csums items (without verifying data)

[6/7] checking root refs

[7/7] checking quota groups skipped (not enabled on this FS)

Opening filesystem to check...

Checking filesystem on /dev/sdb1

UUID: 54d840b7-9a26-4d63-86b5-4f8899e1eeb8

found 20380450816 bytes used, no error found

total csum bytes: 19156928

total tree bytes: 763756544

total fs tree bytes: 707051520

total extent tree bytes: 33685504

btree space waste bytes: 132964738

file data blocks allocated: 19616694272

 referenced 19615662080

avalon-rw /mnt # 

```

Alte Snapshots hab ich alle gelöscht; allerdings habe ich das ganze System in einem Subvolume namens "live", d.h. in meiner grub.cfg steht

```

menuentry 'Livesystem      [sdb1]' {

  root=(hd1,1)

  linux /live/boot/vmlinuz rootflags=subvol=live root=/dev/sdb1 vga=775 systemd.unified_cgroup_hierarchy=1

}

```

Das /tmp/..... .log sieht so aus:

```

avalon-rw /home/tlz # more /tmp/sys-apps:portage-3.0.30-r3:20220816-094300.log

 * Package:    sys-apps/portage-3.0.30-r3

 * Repository: gentoo

 * Maintainer: dev-portage@gentoo.org

 * Upstream:   dev-portage@gentoo.org

 * USE:        abi_x86_64 amd64 elibc_glibc ipc kernel_linux native-extensions python_targets_python3_10 rsync-verify userland_GNU

 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox

avalon-rw /home/tlz # 

```

Er meckert also über fehlende permissions, *nachdem* er soeben das Logfile geschrieben hat !?

Ach so, das ls -la noch:

```

avalon-rw /home/tlz # ls -la /tmp/sys-apps:portage-3.0.30-r3:20220816-094300.log

-rw-rw---- 1 portage portage 441 16. Aug 11:43 /tmp/sys-apps:portage-3.0.30-r3:20220816-094300.log

```

----------

## mike155

Die Frage ist, warum die gezeigten Daten überhaupt in /tmp/sys-apps:portage-3.0.30-r3:20220816-094300.log stehen.

Bei mir stehen diese Daten in /var/tmp/portage/sys-apps/portage-3.0.30-r3/temp/build.log

Vermutung: es gibt irgendeinen ganz anderen Fehler. Portage kann nicht nach "/var/tmp/portage/sys-apps/portage-3.0.30-r3/temp/build.log" schreiben und schreibt deshalb nach /tmp/sys-apps:portage-3.0.30-r3:20220816-094300.log. Aus irgendeinem Grund gibt es dann einen weiteren Fehler, der zu dem "Keine Berechtigung" Fehler führt.

Mein Vorschlag: starte mit Kernel 6.16.2. Update dann erst einmal Dein System, damit Du auf den aktuellen Stand kommst. Falls der Fehler dann noch auftreten sollte, poste bitte die Ausgabe von

```
emerge -1 portage >/tmp/emerge.log 2>&1
```

(also die Datei emerge.log). Vielleicht sehen wir dort etwas.

Im Kernel fehlt übrigens die Option CONFIG_FANOTIFY. Ich würde CONFIG_DNOTIFY auch gleich mit einschalten. Bei EXT4 würde ich CONFIG_EXT4_FS_POSIX_ACL und CONFIG_EXT4_FS_SECURITY aktivieren.

Ich glaube aber NICHT, dass das emerge-Problem mit diesen Kernel-Optionen zusammenhängt.

----------

## Bartkauz

Also, so lange ich mich erinnern kann, stehen bei mir die build-logs in /tmp.

Nun denn: ich habe emerge --sync, emerge -NaDuv world, emerge --depclean und revdep-rebuild laufen lassen. Es war kaum etwas zu tun, was m.E. mit dem  Problem zusammenhängen könnte.

Aaaber:

Ich habe nach dem (erneut fehlgeschlagenen) "emerge portage" mal in /var/tmp/portage/sys-apps/portage-3.0.30-r3/temp geschaut und folgendes gefunden:

```

avalon-rw /var/tmp/portage/sys-apps/portage-3.0.30-r3/temp # ls -l

insgesamt 176

lrwxrwxrwx 1 root    root        51 16. Aug 14:42 build.log -> /tmp/sys-apps:portage-3.0.30-r3:20220816-124205.log

-rw-rw-r-- 1 root    portage   4336 16. Aug 14:42 eclass-debug.log

-rw-rw-r-- 1 root    portage 164017 16. Aug 14:42 environment

drwxr-xr-x 2 portage portage   4096 16. Aug 14:42 logging

avalon-rw /var/tmp/portage/sys-apps/portage-3.0.30-r3/temp # 

```

Das build.log ist also ein Link zum Gleichnamigen in /tmp. Interessanter finde ich aber eclass-debug.log, welches lautet wie folgt:

```

  eclass exists: /var/portage/eclass/distutils-r1.eclass

inherit: distutils-r1 -> /var/portage/eclass/distutils-r1.eclass

*** Multiple Inheritence (Level: 2)

  eclass exists: /var/portage/eclass/multibuild.eclass

inherit: multibuild -> /var/portage/eclass/multibuild.eclass

  eclass exists: /var/portage/eclass/multiprocessing.eclass

inherit: multiprocessing -> /var/portage/eclass/multiprocessing.eclass

  eclass exists: /var/portage/eclass/toolchain-funcs.eclass

inherit: toolchain-funcs -> /var/portage/eclass/toolchain-funcs.eclass

*** Multiple Inheritence (Level: 3)

  eclass exists: /var/portage/eclass/multilib.eclass

inherit: multilib -> /var/portage/eclass/multilib.eclass

*** Multiple Inheritence (Level: 4)

  eclass exists: /var/portage/eclass/toolchain-funcs.eclass

inherit: toolchain-funcs -> /var/portage/eclass/toolchain-funcs.eclass

*** Multiple Inheritence (Level: 2)

  eclass exists: /var/portage/eclass/python-r1.eclass

inherit: python-r1 -> /var/portage/eclass/python-r1.eclass

*** Multiple Inheritence (Level: 3)

  eclass exists: /var/portage/eclass/multibuild.eclass

inherit: multibuild -> /var/portage/eclass/multibuild.eclass

  eclass exists: /var/portage/eclass/python-utils-r1.eclass

inherit: python-utils-r1 -> /var/portage/eclass/python-utils-r1.eclass

*** Multiple Inheritence (Level: 4)

  eclass exists: /var/portage/eclass/eapi8-dosym.eclass

inherit: eapi8-dosym -> /var/portage/eclass/eapi8-dosym.eclass

*** Multiple Inheritence (Level: 4)

  eclass exists: /var/portage/eclass/multiprocessing.eclass

inherit: multiprocessing -> /var/portage/eclass/multiprocessing.eclass

  eclass exists: /var/portage/eclass/toolchain-funcs.eclass

inherit: toolchain-funcs -> /var/portage/eclass/toolchain-funcs.eclass

_python_export: entering function, parameters: pypy3 PYTHON_PKG_DEP

_python_export: implementation: pypy3

_python_export: PYTHON_PKG_DEP = >=dev-python/pypy3-7.3.9_p1:0=[bzip2(+),threads(+)]

_python_export: entering function, parameters: python3_8 PYTHON_PKG_DEP

_python_export: implementation: python3.8

_python_export: PYTHON_PKG_DEP = >=dev-lang/python-3.8.13:3.8[bzip2(+),threads(+)]

_python_export: entering function, parameters: python3_9 PYTHON_PKG_DEP

_python_export: implementation: python3.9

_python_export: PYTHON_PKG_DEP = >=dev-lang/python-3.9.12:3.9[bzip2(+),threads(+)]

_python_export: entering function, parameters: python3_10 PYTHON_PKG_DEP

_python_export: implementation: python3.10

_python_export: PYTHON_PKG_DEP = >=dev-lang/python-3.10.4:3.10[bzip2(+),threads(+)]

EXPORT_FUNCTIONS: src_prepare -> distutils-r1_src_prepare

EXPORT_FUNCTIONS: src_configure -> distutils-r1_src_configure

EXPORT_FUNCTIONS: src_compile -> distutils-r1_src_compile

EXPORT_FUNCTIONS: src_test -> distutils-r1_src_test

EXPORT_FUNCTIONS: src_install -> distutils-r1_src_install

  eclass exists: /var/portage/eclass/linux-info.eclass

inherit: linux-info -> /var/portage/eclass/linux-info.eclass

*** Multiple Inheritence (Level: 2)

  eclass exists: /var/portage/eclass/toolchain-funcs.eclass

inherit: toolchain-funcs -> /var/portage/eclass/toolchain-funcs.eclass

EXPORT_FUNCTIONS: pkg_setup -> linux-info_pkg_setup

  eclass exists: /var/portage/eclass/toolchain-funcs.eclass

inherit: toolchain-funcs -> /var/portage/eclass/toolchain-funcs.eclass

  eclass exists: /var/portage/eclass/tmpfiles.eclass

inherit: tmpfiles -> /var/portage/eclass/tmpfiles.eclass

  eclass exists: /var/portage/eclass/prefix.eclass

inherit: prefix -> /var/portage/eclass/prefix.eclass

python_gen_impl_dep: entering function, parameters: ssl(+)

_python_verify_patterns: entering function, parameters: 

_python_export: entering function, parameters: pypy3 PYTHON_PKG_DEP

_python_export: implementation: pypy3

_python_export: PYTHON_PKG_DEP = >=dev-python/pypy3-7.3.9_p1:0=[ssl(+)]

_python_export: entering function, parameters: python3_8 PYTHON_PKG_DEP

_python_export: implementation: python3.8

_python_export: PYTHON_PKG_DEP = >=dev-lang/python-3.8.13:3.8[ssl(+)]

_python_export: entering function, parameters: python3_9 PYTHON_PKG_DEP

_python_export: implementation: python3.9

_python_export: PYTHON_PKG_DEP = >=dev-lang/python-3.9.12:3.9[ssl(+)]

_python_export: entering function, parameters: python3_10 PYTHON_PKG_DEP

_python_export: implementation: python3.10

_python_export: PYTHON_PKG_DEP = >=dev-lang/python-3.10.4:3.10[ssl(+)]

```

Das sieht nach einem python-problem aus, oder? "Multiple inheritance" erinnert mich an C++, aber in python scheint das was Verbotenes zu sein (?)

Es ist noch nicht lange her, daß ich mein gesamtes System auf python 3.10 aktualisiert habe. Alte pythons habe ich gewissenhaft unmerged. Das war, als Kernel 5.15.* noch aktuell war, also vor der jetzigen Misere.

Wie gesagt, python kenne ich kaum, und was es mit den eclass'es auf sich hat, weiß ich auch nicht. Kannst Du (oder ein anderer python-Kundiger) etwas damit anfangen?

----------

## Josef.95

 *mike155 wrote:*   

> Die Frage ist, warum die gezeigten Daten überhaupt in /tmp/sys-apps:portage-3.0.30-r3:20220816-094300.log stehen.

 

Das sind gespeicherte Logs (die man auch beim erfolgreichen Build für eine gewisse Zeit speichern möchte) wenn PORTAGE_LOGDIR="/path/to/irgendwo" in make.conf gesetzt ist.

@Bartkauz

Schau mal in deiner make.conf nach PORTAGE_LOGDIR (oder früher nannte es sich auch PORT_LOGDIR).

```
emerge --info -v | grep LOGDIR
```

 sollte (sofern gesetzt) dazu was ausspucken .

----------

## Bartkauz

Das war die Lösung!!

Ich hatte irgendwann mal in /etc/make.conf  PORTAGE_LOGDIR="/tmp" und  PORT_LOGDIR="/tmp" gesetzt. Dies habe ich jetzt wieder rückgängig gemacht, und prompt läuft emerge wieder, sowohl mit Kernel 5.16.20 als auch 5.19.1 .

Daß die Logs jetzt wieder da sind, wo sie ganz ursprünglich mal waren, damit kann ich leben... Ich glaube, ich war es damals nur leid, mich immer durch /var/tmp/portage/* zu hangeln, um sie zu finden.

Offenbar verträgt es portage nicht, wenn die LOGDIR's irgendwo anders sind.

Herzlichen Dank für Eure Hilfe!

----------

## pietinger

Ich glaube ich kann auch sagen warum es mit dem alten Kernel funzte ...

erstmal: mea culpa ... mea maxima culpa (ich schiebe  es auf mein Alter wenn ich was durcheinander bringe oder vergesse):

Vermutlich hätte das geholfen:

```
# echo 0 > /proc/sys/fs/protected_regular
```

Hier der entsprechende Thread (ich war sogar involviert    :Embarassed:   )

https://forums.gentoo.org/viewtopic-p-8699243.html

----------

## mike155

Eines verstehe ich nicht: warum sieht man PORTAGE_LOGDIR="/tmp" und PORT_LOGDIR="/tmp" nicht in der Ausgabe von "emerge --info" im ersten Post?

----------

## pietinger

 *mike155 wrote:*   

> Eines verstehe ich nicht: warum sieht man PORTAGE_LOGDIR="/tmp" und PORT_LOGDIR="/tmp" nicht in der Ausgabe von "emerge --info" im ersten Post?

 

So wie es aussieht gibt der "emerge --info" das nicht raus (habe es soeben selbst ausprobiert) ... müsste wohl an die Entwickler gemeldet werden ... (Dein Englisch ist besser als meines  :Wink:  )

----------

## Josef.95

 *mike155 wrote:*   

> Eines verstehe ich nicht: warum sieht man PORTAGE_LOGDIR="/tmp" und PORT_LOGDIR="/tmp" nicht in der Ausgabe von "emerge --info" im ersten Post?

 

Mike, diese Variablen sieht man nur mit --verbose

emerge --info --verbose

----------

## mike155

@pietinger, @Josef.95: Danke für Eure Antworten. Ich bin es so gewohnt, dass "emerge --info" alles Notwendige ausgibt, dass es mich wirklich überrascht hat, dass die geänderten Log-Verzeichnisse nicht dabei waren. Aber Ihr habt natürlich Recht, dass "emerge --info" nicht alle Variablen ausgibt, sondern dass man dazu "emerge --info -v" braucht.

Ich bin jedenfalls sehr froh, dass Ihr den Grund für das Problem erkannt habt. Ich wäre nicht so schnell darauf gekommen - und hätte wohl noch lange Zeit weitergesucht.

Ist die fehlende Ausgabe der Log-Verzeichnisse bei "emerge --info" nun ein Bug, den wir melden sollten - oder nicht? Ich vermute eher nicht, da "emerge --info " ja absichtlich kürzer ist als "emerge --info -v". Es wäre gut, wenn "emerge --info" alle Werte ausgeben würde, die gegenüber den Default-Werten geändert wurden. Aber da es keine wirklichen "Default-Werte" gibt ("Default-Werte" sind vom Profil abhängig und ändert sich im Laufe der Zeit), dürfte das schwierig zu implementieren sein. Ich würde also eher keinen Bug aufmachen.

@pietinger: was das Englisch angeht: ich glaube, da bist Du besser.  :Smile: 

----------

## pietinger

@Josef.95: Auch von mir vielen Dank für die Info über "--verbose" ! Jetzt nutze ich Gentoo seit über 16 Jahren und wusste nicht mal dass es den für "emerge --info" überhaupt gibt ...  :Embarassed: 

 *mike155 wrote:*   

> Ist die fehlende Ausgabe der Log-Verzeichnisse bei "emerge --info" nun ein Bug, den wir melden sollten - oder nicht? [...]  Ich würde also eher keinen Bug aufmachen.

 

Ja, sehe ich genauso.

 *mike155 wrote:*   

> @pietinger: was das Englisch angeht: ich glaube, da bist Du besser. 

 

 :Laughing:  Ganz sicher nicht ... frage nicht wie oft ich bei leo.org bin   :Razz: 

----------

## Bartkauz

Das mit dem

```

# echo 0 > /proc/sys/fs/protected_regular

```

ist ja noch geiler! Jetzt kann ich wieder PORTAGE_LOGDIR auf "/tmp" setzen und habe meine Logfiles wieder da, wo ich sie schon immer hin haben wollte (gerade ausprobiert).

Nochmals vielen Dank an alle!

----------

## pietinger

Bartkauz,

nur fürs Protokoll ...  :Wink:  Ich empfehle das nicht, weil es (eigentlich) eine Sicherheitslücke darstellt (musste ich jetzt sagen als alter Paranoiker)   :Cool: 

----------

