Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[gelöst] emerge kaputt nach Kernel-upgrade
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German)
View previous topic :: View next topic  
Author Message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Sun Aug 14, 2022 5:04 pm    Post subject: [gelöst] emerge kaputt nach Kernel-upgrade Reply with quote

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>>)
handle: <Handle AsynchronousTask._exit_listener_cb(<bound method...7ffb259eef80>>)>
Traceback (most recent call last):
File "/usr/lib/python3.10/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/lib/python3.10/site-packages/_emerge/AsynchronousTask.py", line 210, in _exit_listener_cb
listener(self)
File "/usr/lib/python3.10/site-packages/_emerge/EbuildPhase.py", line 206, in _async_start_exit
self._start_lock()
File "/usr/lib/python3.10/site-packages/_emerge/EbuildPhase.py", line 229, in _start_lock
self._start_ebuild()
File "/usr/lib/python3.10/site-packages/_emerge/EbuildPhase.py", line 286, in _start_ebuild
self._start_task(ebuild_process, self._ebuild_exit)
File "/usr/lib/python3.10/site-packages/_emerge/CompositeTask.py", line 112, in _start_task
task.start()
File "/usr/lib/python3.10/site-packages/_emerge/AsynchronousTask.py", line 34, in start
self._start()
File "/usr/lib/python3.10/site-packages/_emerge/AbstractEbuildProcess.py", line 212, in _start
self._start_post_builddir_lock(start_ipc_daemon=start_ipc_daemon)
File "/usr/lib/python3.10/site-packages/_emerge/AbstractEbuildProcess.py", line 245, in _start_post_builddir_lock
SpawnProcess._start(self)
File "/usr/lib/python3.10/site-packages/_emerge/SpawnProcess.py", line 155, in _start
build_logger.start()
File "/usr/lib/python3.10/site-packages/_emerge/AsynchronousTask.py", line 34, in start
self._start()
File "/usr/lib/python3.10/site-packages/portage/util/_async/BuildLogger.py", line 88, in _start
pipe_logger.start()
File "/usr/lib/python3.10/site-packages/_emerge/AsynchronousTask.py", line 34, in start
self._start()
File "/usr/lib/python3.10/site-packages/portage/util/_async/PipeLogger.py", line 42, in _start
self._log_file = open(
PermissionError: [Errno 13] Keine Berechtigung: b'/tmp/sys-apps:portage-3.0.34:20220814-153557.log'
Beendet


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)
=================================================================
System uname: Linux-5.16.2-gentoo-x86_64-Intel-R-_Core-TM-2_CPU_6600_@_2.40GHz-with-glibc2.35
KiB Mem: 8152948 total, 4644112 free
KiB Swap: 15174996 total, 15174996 free
Timestamp of repository gentoo: Sun, 14 Aug 2022 14:30:01 +0000
Head commit of repository gentoo: c1b056f635bfb1c58720a8b1dd6a343a2c98b3b7
sh bash 5.1_p16-r1
ld GNU ld (Gentoo 2.38 p4) 2.38
app-misc/pax-utils: 1.3.4::gentoo
app-shells/bash: 5.1_p16-r1::gentoo
dev-lang/perl: 5.34.1-r3::gentoo
dev-lang/python: 2.7.18_p15::gentoo, 3.9.13::gentoo, 3.10.5::gentoo
dev-lang/rust-bin: 1.62.1::gentoo
dev-util/cmake: 3.22.4::gentoo
dev-util/meson: 0.62.2::gentoo
sys-apps/baselayout: 2.8::gentoo
sys-apps/openrc: 0.44.10::gentoo
sys-apps/sandbox: 2.29::gentoo
sys-devel/autoconf: 2.13-r2::gentoo, 2.71-r1::gentoo
sys-devel/automake: 1.16.5::gentoo
sys-devel/binutils: 2.38-r2::gentoo
sys-devel/binutils-config: 5.4.1::gentoo
sys-devel/clang: 14.0.6-r1::gentoo
sys-devel/gcc: 10.4.0::gentoo
sys-devel/gcc-config: 2.5-r1::gentoo
sys-devel/libtool: 2.4.7::gentoo
sys-devel/llvm: 14.0.6-r1::gentoo
sys-devel/make: 4.3::gentoo
sys-kernel/linux-headers: 5.15-r3::gentoo (virtual/os-headers)
sys-libs/glibc: 2.35-r8::gentoo
Repositories:

gentoo
location: /var/portage
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-extra-opts:
sync-rsync-verify-metamanifest: yes
sync-rsync-verify-jobs: 1
sync-rsync-verify-max-age: 24

local_portage
location: /var/local_portage
masters: gentoo
priority: 0

torbrowser
location: /var/lib/layman/torbrowser
masters: gentoo
priority: 50

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/X11/xkb /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -fasynchronous-unwind-tables -fpermissive"
DISTDIR="/usr/portage/distfiles"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="de_DE.utf8"
LC_ALL="de_DE.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LINGUAS="de en"
MAKEOPTS="-j3"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
SHELL="/bin/bash"
USE="X acl acpi alsa amd64 apng bzip2 cdparanoia chromium cjk crypt dnssec elogind evdev ffmpeg gdbm gif gmp hwaccel iconv idn imlib ipv6 jpeg libglvnd libtirpc minizip mng mp3 ncurses nftables nls nptl opencl opengl openmp pam pcre pdf png policykit postscript ppds pulseaudio qt5 readline savedconfig sdl seccomp split-usr ssl svg system-ffmpeg system-icu system-libvpx threads tiff truetype tty-helpers unicode usb v4l2 vaapi vdpau virtfs x264 x265 xattr zlib" ABI_X86="64" ADA_TARGET="gnat_2020" ALSA_CARDS="hda-intel" CAMERAS="ptp2" CPU_FLAGS_X86="mmx mmxext sse sse2 sse3 ssse3" ELIBC="glibc" FFTOOLS="aviocat" INPUT_DEVICES="evdev" KERNEL="linux" L10N="de en" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4 php8-0" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_10" PYTHON_TARGETS="python3_10" QEMU_SOFTMMU_TARGETS="i386" RUBY_TARGETS="ruby27" SANE_BACKENDS="plustek" USERLAND="GNU" VIDEO_CARDS="nvidia"
Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LD, LEX, LFLAGS, LIBTOOL, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS


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,
Thomas


Last edited by Bartkauz on Tue Aug 16, 2022 3:05 pm; edited 1 time in total
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3940
Location: Bavaria

PostPosted: Sun Aug 14, 2022 5:14 pm    Post subject: Reply with quote

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 ?
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Sun Aug 14, 2022 5:57 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Sun Aug 14, 2022 6:11 pm    Post subject: Reply with quote

Ungewöhnlich an der "emerge --info"- Ausgabe ist:
Code:
gentoo
    location: /var/portage
    ...

local_portage
    location: /var/local_portage
    ...

Hier sollte eigentlich stehen:
Code:
gentoo
    location: /var/db/repos/portage
    ....

local_portage
    location: /var/db/repos/local_portage
    ...

Die Fehlermeldung ist interessant:
Code:
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?
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Sun Aug 14, 2022 7:20 pm    Post subject: Reply with quote

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:
Code:

/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...
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Sun Aug 14, 2022 7:32 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3940
Location: Bavaria

PostPosted: Sun Aug 14, 2022 7:51 pm    Post subject: Reply with quote

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/
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 4509
Location: Germany

PostPosted: Sun Aug 14, 2022 8:49 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Mon Aug 15, 2022 12:17 pm    Post subject: Reply with quote

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:
Code:

 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 :(

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:
Code:

                 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...
Back to top
View user's profile Send private message
pietinger
Moderator
Moderator


Joined: 17 Oct 2006
Posts: 3940
Location: Bavaria

PostPosted: Mon Aug 15, 2022 12:48 pm    Post subject: Reply with quote

Probier' mal:
Code:
# 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)
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Mon Aug 15, 2022 12:58 pm    Post subject: Reply with quote

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:
  1. Die Ausgabe von dmesg
  2. 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:
  1. Die Ausgabe von dmesg
  2. 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
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Mon Aug 15, 2022 1:11 pm    Post subject: Reply with quote

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):
Code:

 /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?
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Mon Aug 15, 2022 1:22 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Mon Aug 15, 2022 1:52 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Mon Aug 15, 2022 2:19 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Mon Aug 15, 2022 2:24 pm    Post subject: Reply with quote

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!
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Mon Aug 15, 2022 2:37 pm    Post subject: Reply with quote

Ich habe die 5.16.2 Dateien mit den 5.19.2 Dateien verglichen. Der Hauptunterschied ist folgender Kernel Command Line Parameter:
Code:
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?
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Mon Aug 15, 2022 3:14 pm    Post subject: Reply with quote

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...
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Mon Aug 15, 2022 3:32 pm    Post subject: Reply with quote

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

In den dmesg Ausgaben ist mir noch aufgefallen:
Code:
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.
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Mon Aug 15, 2022 5:38 pm    Post subject: Reply with quote

@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:

Code:

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
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Mon Aug 15, 2022 6:24 pm    Post subject: Reply with quote

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
Code:
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?
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Tue Aug 16, 2022 10:05 am    Post subject: Reply with quote

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):
Code:

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

Code:

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:
Code:

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:
Code:

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
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Tue Aug 16, 2022 11:19 am    Post subject: Reply with quote

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
Code:
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.
Back to top
View user's profile Send private message
Bartkauz
n00b
n00b


Joined: 14 Aug 2022
Posts: 23

PostPosted: Tue Aug 16, 2022 1:06 pm    Post subject: Reply with quote

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:

Code:

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:

Code:

  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?
Back to top
View user's profile Send private message
Josef.95
Advocate
Advocate


Joined: 03 Sep 2007
Posts: 4509
Location: Germany

PostPosted: Tue Aug 16, 2022 1:49 pm    Post subject: Reply with quote

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).
Code:
emerge --info -v | grep LOGDIR
sollte (sofern gesetzt) dazu was ausspucken .
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
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