Siduction Forum
Siduction Forum => Software - Support => Topic started by: jure on 2019/07/03, 10:57:13
-
Hallo zusammen,
seit dem du von gestern abend startet mein tagesaktueller PC (KDE) nicht mehr, d.h. es kommt kein graphischer login mehr. Es kommen mehrere "failed to start xyz service" Meldungen, als erstes "failed to start wpa supplicant".
Das Netzwerk läuft nicht, div. Aktionen laufen extrem langsam.
Kernel 5.1.12-towo.1-siduction-amd64
Kernel 5.1.15-towo.1-siduction-amd64
Es wurden nur wenige Pakete upgedatet :
dkms
libpng16-16
libwebkit2-gtk
libjavascriptcoregtk
openjdk-11-jre
Ich bin "etwas" ratlos ...... :-[
und schreibe hier vom Tablett und kann Infos nicht vom PC senden, da kein Netzwerk.
Anfang der Ausgabe von journalctl -xb -p err, es folgen noch div. "failed to start...."
(https://de.share-your-photo.com/img/70beac7558.jpg)
-
Leider keine Hilfe für dich... :(
Ich habe eben mein System auf den neuesten Stand gebracht (wöchentlich mehrmals) und habe diesen Fehler nicht.
inxi -SGxxx
System: Host: sidukde Kernel: 5.1.15-towo.1-siduction-amd64 x86_64 bits: 64 compiler: gcc v: 8.3.0
Desktop: KDE Plasma 5.14.5 tk: Qt 5.11.3 wm: kwin_x11 dm: LightDM 1.26.0
Distro: siduction 16.1.0 Patience - kde - (201702251051) base: Debian GNU/Linux 10 (buster)
Graphics: Device-1: AMD Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] vendor: PC Partner Limited
driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:6779
Display: x11 server: X.Org 1.20.4 driver: ati,radeon unloaded: fbdev,modesetting,vesa
compositor: kwin_x11 resolution: 1920x1080~60Hz
OpenGL: renderer: AMD CAICOS (DRM 2.50.0 / 5.1.15-towo.1-siduction-amd64 LLVM 7.0.1)
v: 3.3 Mesa 18.3.6 compat-v: 3.1 direct render: Yes
ist ein Desktop-PC. Wenn es sich bei dir um sddm handelt, würde ich zuerst dort ansetzen. Alles Andere sind m.M. Folgefehler.
-
Danke für die Infos.
Ich behaupte ja nicht, dass das Problem durch das du verursacht wurde, es trat halt direkt beim booten danach auf.
Ich verwende lightdm 1.26.0-4
systemctl start lightdm.service bringt
(https://de.share-your-photo.com/img/09e8cd57ef.jpg)
(https://de.share-your-photo.com/img/85da23d01c.jpg)
bricht dann mit timeout ab
Via ceni (an dem ich aber lange nichts verstellt habe, wie auch sonst nichts verändert wurde) konnte ich eth0 wieder aktivieren, Netz läuft also zZ wieder.
(https://de.share-your-photo.com/img/c38b6092a7.jpg)
-
Bote mal mit selinux=0 als Kernelparameter.
-
Im grub menue kernel ausgewählt und über "e" die Parameter unten mit selinux=0 ergänzt und gebootet.
Es rauschen die Meldungen durch "ok started" dann bleibt er hängen und es kommen die Fehler failed bzgl login manager, modem manager etc - siehe Bilder.
Nach ein paar Minuten kommt der login auf der Konsole, bis das login dann durch ist dauert es auch wieder (unable to get valid context for root), dann bin ich eingeloggt - hmm
-
Es funktioniert nur die 1te Konsole.
Xorg.o.log endet mit
Fatal server error:
(EE) SELinux: Failed to open x_contexts mapping in policy
Es ist aber nix von selinux-* installiert...
Hier der lightdm log - welche logs / Infos können noch helfen ?
(https://de.share-your-photo.com/img/a4fb9d5659.jpg)
-
https://forum.siduction.org/index.php?topic=7674.msg62484#msg62484
Probiers mal damit - aus irgendwelchen Gründen wird selinux mitgeliefert, aber nich konfiguriert.
Edit: Das würde auf jeden Fall das SELINUX-Problem lösen - was Du mit dem bootparameter schon mal gemacht hattest. Zum Thema LightDM - genau aus diesen Gründen benutzen wir durchgängig SDDM, es hatte irgendwie keiner mehr Bock, sich mit den immer neuen Fehlern in LightDM auseinanderzusetzen.
-
EDIT !
in /etc/selinux/config "SELINUX=permissive" auf disabled zu setzen hat es gebracht, der PC bootet und läuft (scheinbar) wieder normal - und ich brauche den ...
Viiielen Dank für deinen Tip !!
Hi Melmarker
danke für den input, es reicht also "SELINUX=permissive" auf disabled zu setzen ?!
Aber als Bootparameter hat SElinux=0 nix gebracht.
Die Kiste braucht ca 10 min bis zum login auf der Konsole. Es wir versucht diverse Dienste zu starten, siehe Bilder oben, was aber letztendlich nicht funzt. Selbst das login braucht dann ca. 1,5 min
Was mich wundert wo der Fehler plötzlich herkommt, wo ich nichts verändert oder installiert habe, außer den wenigen updates der letzten Tage.
Zum Wechsel von lightdm auf sddm reicht ein apt purge lightdm-* und apt install sddm (gibt 9 Pakete) ?
dpkg -l lightdm-* zeigt nur lightdm-kde-greeter als installiert an.
-
ja aber ...
was nicht funktioniert, ist das mounten der NAS LW. Auch hier hatte ich nichts geändert, weder am NAS, noch am PC.
hier für "daten-nas, dto für die anderen mounts vom NAS auf den PC
journalctl -xb -p err
Jul 04 16:44:51 siductionbox NetworkManager[812]: ^[[0;1;39m<error> [1562251491.7890] session-monitor: failed to create systemd-logind monitor: -2
Jul 04 16:45:03 siductionbox sudo[1695]: ^[[0;1;39mpam_unix(sudo:auth): conversation failed
Jul 04 16:45:03 siductionbox sudo[1695]: ^[[0;1;39mpam_unix(sudo:auth): auth could not identify password for [juergen]
Jul 04 16:45:05 siductionbox systemd[1]: ^[[0;1;39mFailed to mount /media/daten-nas.
-- Subject: A start job for unit media-daten\x2dnas.mount has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit media-daten\x2dnas.mount has finished with a failure.
--
-- The job identifier is 1462 and the job result is failed.
Jul 04 16:45:06 siductionbox systemd[1]: ^[[0;1;39mFailed to mount /media/daten-nas.
-- Subject: A start job for unit media-daten\x2dnas.mount has failed
-- Defined-By: systemd
......
die seit langem bestehenden Einträge in fstab sehen so aus
192.168.2.60:/volume1/daten /media/daten-nas nfs4 noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0
-
auch merkwürdig
z.B.
root@siductionbox:/home/juergen# ifconfig
Command 'ifconfig' is available in '/sbin/ifconfig'
The command could not be located because '/sbin' is not included in the PATH environment variable.
This is most likely caused by the lack of administrative privileges associated with your user account.
ifconfig: command not found
-
nö - das ist das neues debian default - dooferweise musst Du die notwenigen Umstellungen auf das alte Verhalten selbst in die Defaults tippen - in den neuen Isos habe ich das mal ganz eigenmächtig gemacht, so gut es ging.
Als das eingeführt wurde, hatten wir glaube ich auch massig Anleitungen hier im Forum wie das ging. Ich habs mittlerweile verdrängt ;)
-
ok dann schaue ich mal bzgl der Rechte
aber das ist ja wohl nicht default, wie ich eins weiter oben schrieb
https://forum.siduction.org/index.php?topic=7697.msg62664#msg62664 (https://forum.siduction.org/index.php?topic=7697.msg62664#msg62664)
"..was nicht funktioniert, ist das mounten der NAS LW. Auch hier hatte ich nichts geändert, weder am NAS, noch am PC.."
-
Zum Thema LightDM - genau aus diesen Gründen benutzen wir durchgängig SDDM, es hatte irgendwie keiner mehr Bock, sich mit den immer neuen Fehlern in LightDM auseinanderzusetzen.
Ist bei mir genau "anders herum". :D Keinesfalls möchte ich deine Kompetenz in Abrede stellen, im Gegenteil.
Weil mir die Fehler in sddm auf den Sack gingen, habe ich auf lightdm umgestellt. Ist schon länger her und seidem tun vier Siduction und zwei Arch klaglos ihren Dienst, dass ich schon das lightdm vergessen hatte. ;)
-
nö - das ist das neues debian default - dooferweise musst Du die notwenigen Umstellungen auf das alte Verhalten selbst in die Defaults tippen - in den neuen Isos habe ich das mal ganz eigenmächtig gemacht, so gut es ging.
Als das eingeführt wurde, hatten wir glaube ich auch massig Anleitungen hier im Forum wie das ging. Ich habs mittlerweile verdrängt
hast du dafür biite mal nen link auf einen alten Faden oder auch gerne EIN Beispiel was wo zu ändern ist. Mein nfs mount Problem https://forum.siduction.org/index.php?topic=7697.msg62664#msg62664 (https://forum.siduction.org/index.php?topic=7697.msg62664#msg62664) scheint ja auch irgendwie an den Rechten zu liegen
-
Kompetenz hin oder her - wenn lightdm mal funktioniert tut es eigentlich(tm) - leider habe ich in den letzten 10 Jahren zu oft erlebt, dass sich was geändert hat und es auf einmal auf bestehenden Systemen nicht mehr tat.
Zu sddm: Ja, es war mal richtig kacke und konnte nerven - und in großen LDAP-Umgebungen würde ich es heute noch nicht einsetzen wollen - aber an sonsten geht es ganz fein, ansonsten gibt es halt den kleinen Dienstweg zum Upstream.
-
es wäre wirklich seeehr nett, wenn einer der Wissenden zu meinem obigen NAS mount Problem noch eine Idee/Tipp hätte - ich brauch das Teil zum Arbeiten.
Ggf hängt das ja, wie schon geschrieben, auch irgendwie mit den Rechten zusammen ...
Gruss
Juergen
-
Ist bei mir genau "anders herum". :D
Ebenfalls. Ich nutze generell LightDM - seit Ewigkeiten unter jeder Distribution. Was immer da andere für Probleme haben w/sollen. Klar hat sich da anfangs, sorich vor Jahren, mal was geändert. Gerade vorhin das aktuelle (sprich das letzte) weekly build (das ist Absicht) von debian-live-testing-amd64-standard.iso installiert, lxqt-core und lightdm dazu.
-
Is Linux macht doch was ihr wollt - echt jetzt :D
Zwei Dinge bleiben:
* Siduction wird nie wieder offiziell LightDM unterstützen
* Wir werden unser Wohl und Wehe keiner Software anvertrauen, deren Upstream Canonical ist - zumindest nicht in der Distribution.
-
Is Linux macht doch was ihr wollt - echt jetzt (https://forum.siduction.org/Smileys/default/cheesy.gif)
Machen wir. Ich jedenfalls.
Siduction wird nie wieder offiziell LightDM unterstützen
Verlangt auch keiner. Ich jedenfalls nicht.
-
Es ist ja schön dass ihr euch über sddm und lightdm austauscht, das hilft mir aber nicht weiter....Also BITTE mal ein paar Tipps.
Sorry wenn ich nerve, aber für mich ist's wichtig.
-
@jure: da musste wohl ein wenig kreativ werden. Wenn ich davon ausgehe, dass die Einträge mal ne Chance hatten zu funktionieren:
Was sagt ein "mount -a" wenn das System fertig hat? Normal müsste dann ja gemounted werden, so denn die Netzwerkverbindung da ist.
-
mount -a "sagt" gar nix und die NAS Verzeichnisse werden nicht gemounted, was sonst seit Jahren kein Problem war.
journalctl -xb -p err bringt
Jul 04 16:44:51 siductionbox NetworkManager[812]: ^[[0;1;39m<error> [1562251491.7890] session-monitor: failed to create systemd-logind monitor: -2
Jul 04 16:45:03 siductionbox sudo[1695]: ^[[0;1;39mpam_unix(sudo:auth): conversation failed
Jul 04 16:45:03 siductionbox sudo[1695]: ^[[0;1;39mpam_unix(sudo:auth): auth could not identify password for [juergen]
Jul 04 16:45:05 siductionbox systemd[1]: ^[[0;1;39mFailed to mount /media/daten-nas.
-- Subject: A start job for unit media-daten\x2dnas.mount has failed
-- Defined-By: systemd
-
Jul 04 16:45:03 siductionbox sudo[1695]: ^[[0;1;39mpam_unix(sudo:auth): auth could not identify password for [juergen]
immerhin
-
immerhin was - auch das password wurde nicht geändert, warum könnte das password nicht mehr erkannt werden.
Da der pc ja wieder läuft kann ich alle log`s oder Abfragen posten, aber was hilft hier ?
-
Nu ja - da ich nicht weiss, wie oft Du d-u's machst - eventuell mal in die Liste des letzen d-u schauen und raussuchen, welche Pakete nen upgrade erhielten.
-
wie anfangs geschrieben ist der pc fast immer tagesaktuell
seit dem du von gestern abend 02.07.19 startet mein tagesaktueller PC (KDE) nicht mehr, d.h. es kommt kein graphischer login mehr.
am 2019-06-25 wurde sicher neu gebooted wegen dem neuen Kernel
Start-Date: 2019-06-25 17:35:08
Commandline: apt-get remove --purge --yes linux-headers-5.1.11-towo.2-siduction-amd64 linux-image-5.1.11-towo.2-siduction-amd64
Purge: linux-headers-5.1.11-towo.2-siduction-amd64:amd64 (5.1-11.1), linux-image-5.1.11-towo.2-siduction-amd64:amd64 (5.1-11.1)
End-Date: 2019-06-25 17:35:19
Start-Date: 2019-06-26 10:13:03
Commandline: apt dist-upgrade
Upgrade: debian-keyring:amd64 (2019.03.24, 2019.06.25), libpaper1:amd64 (1.1.27, 1.1.28), libpaper-utils:amd64 (1.1.27, 1.1.28), python3-sortedcontainers:amd64 (2.0.4-1, 2.1.0-1), python-sortedcontainers:amd64 (2.0.4-1, 2.1.0-1)
End-Date: 2019-06-26 10:13:10
Start-Date: 2019-06-27 09:00:39
Commandline: apt dist-upgrade
Upgrade: openjdk-11-jre-headless:amd64 (11.0.4+8-1, 11.0.4+9-1), openjdk-11-jre:amd64 (11.0.4+8-1, 11.0.4+9-1)
End-Date: 2019-06-27 09:00:47
Start-Date: 2019-06-29 08:18:11
Commandline: apt dist-upgrade
Upgrade: libgcc-7-dev:amd64 (7.4.0-9, 7.4.0-10), cpp-7:amd64 (7.4.0-9, 7.4.0-10), python3-reportlab-accel:amd64 (3.5.21-1, 3.5.23-1), gcc-7-base:amd64 (7.4.0-9, 7.4.0-10), libcilkrts5:amd64 (7.4.0-9, 7.4.0-10), libasan4:amd64 (7.4.0-9, 7.4.0-10), libubsan0:amd64 (7.4.0-9, 7.4.0-10), libgfortran4:amd64 (7.4.0-9, 7.4.0-10), gcc-7:amd64 (7.4.0-9, 7.4.0-10), python-pkg-resources:amd64 (40.8.0-1, 41.0.1-1), python-reportlab-accel:amd64 (3.5.21-1, 3.5.23-1), python3-pkg-resources:amd64 (40.8.0-1, 41.0.1-1), python-setuptools:amd64 (40.8.0-1, 41.0.1-1), python-reportlab:amd64 (3.5.21-1, 3.5.23-1), python-distlib:amd64 (0.2.8-1, 0.2.9.post0-1), python3-reportlab:amd64 (3.5.21-1, 3.5.23-1)
End-Date: 2019-06-29 08:18:20
Start-Date: 2019-06-30 09:38:25
Commandline: apt dist-upgrade
Upgrade: patch:amd64 (2.7.6-3, 2.7.6-4)
End-Date: 2019-06-30 09:38:27
Start-Date: 2019-06-30 17:08:34
Commandline: apt dist-upgrade
Upgrade: nano:amd64 (3.2-3, 4.3-1)
End-Date: 2019-06-30 17:08:37
Start-Date: 2019-07-02 23:07:10
Commandline: apt dist-upgrade
Upgrade: dkms:amd64 (2.6.1-4, 2.7.1-1), openjdk-11-jre-headless:amd64 (11.0.4+9-1, 11.0.4+10-1), openjdk-11-jre:amd64 (11.0.4+9-1, 11.0.4+10-1), libwebkit>
End-Date: 2019-07-02 23:07:22
-
Nur so als Idee wegen nfs4 in der fstab, guck mal da: https://forum.siduction.org/index.php?topic=7637.0 (auch wenn das ein anderes Fehlerbild ist).
Zu dem Pfad von ifconfig weiter oben, wirst du root mit "su" oder mit "su -" ? Letzteres wäre die korrekte Variante, sonst kriegt root nicht sein ganzes environment.
Das NAS ist grundsätzlich up und unter der IP aus der fstab erreichbar? Also nicht irgendwie die IP neu zugewiesen oder so was?
Ist das alles nur mit dem aktuellen Kernel so? Wie sieh es aus wenn Du mit dem letzten Kernel bootest?
-
danke für den input
mit "su -" funktioniert z.B. ifconfig, danke - war also eine andere Baustelle.
Das NAS ist im sleepmode (und fährt wenn angesprochen hoch) oder up und das mit fester ip. das ist schon lange so und hat immer funktioniert. Wie geschrieben ich habe nix geändert.
zu dem verlinkten Beitrag bzgl nfs4
mount -t nfs -o nfsvers=4 192.168.2.60:/volume1/daten /media/daten-nas
mount.nfs: access denied by server while mounting 192.168.2.60:/volume1/daten
ich hatte in einem der vorderen Beiträge geschrieben, welche Fehler ausgegeben werden https://forum.siduction.org/index.php?topic=7697.msg62664#msg62664 (https://forum.siduction.org/index.php?topic=7697.msg62664#msg62664)
ul 04 16:44:51 siductionbox NetworkManager[812]: ^[[0;1;39m<error> [1562251491.7890] session-monitor: failed to create systemd-logind monitor: -2
Jul 04 16:45:03 siductionbox sudo[1695]: ^[[0;1;39mpam_unix(sudo:auth): conversation failed
Jul 04 16:45:03 siductionbox sudo[1695]: ^[[0;1;39mpam_unix(sudo:auth): auth could not identify password for [juergen]
Jul 04 16:45:05 siductionbox systemd[1]: ^[[0;1;39mFailed to mount /media/daten-nas.
Das Problem besteht auch mit Kernel 5.1.15-towo.1-siduction-amd64.
-
ok - nu Butter bei die Fische:
das angesprochene 'su -' - Verhalten hat sich erledigt, netzwerken noch nicht. Geht das eventuell mit einem älteren Kernel? nfs ist ein Kernel inbuild afaik - wenn nicht, dann würde ich aufgrund der Fehlermeldungen eventuell pam zuordnen.
-
Netzwerk geht grundsätzlich, die NAS mounts aber nicht, weder beim booten noch beim Zugriff auf die Freigabe. Auch mount -a function nicht - siehe ein Post weiter oben.
Beide vorhanden Kernel verhalten sich gleich
5.1.15-towo.1-siduction-amd64.
5.1.16-towo.1-siduction-amd64.
Viel wurde per dist-upgrade in den letzten Tagen vor dem Problem ja nicht upgedatet - s.o.
-
<sarcasm> is doch wunderbar, dann liegts zumindestet nich am Kernel </sarcasm>
und das ist auch gut so - würde Wowereit sagen.
Nächster Versuch: kannst Du die Freigaben direkt mounten - also von der Kommandozeile?
-
wie schon geschrieben, mount -a *sagt nichts & funzt nicht und
mount -t nfs -o nfsvers=4 192.168.2.60:/volume1/daten /media/daten-nas
bringt
mount.nfs: access denied by server while mounting 192.168.2.60:/volume1/daten
in der fstab steht dazu (schon lange)
192.168.2.60:/volume1/daten /media/daten-nas nfs4 noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0
*edit: Vom tablet komme ich wie gehabt via Total Commander auf die NAS Freigabe, wie auch vom Notebook mit siduction (nicht aktuell,veraltet), die NAS Freigaben tun es also.
-
hier mal die Ausgabe von z.B.
systemctl status /media/daten-nas
media-daten\x2dnas.mount - /media/daten-nas
Loaded: loaded (/etc/fstab; generated)
Active: failed (Result: exit-code) since Sat 2019-07-06 18:07:54 CEST; 30min ago
Where: /media/daten-nas
What: 192.168.2.60:/volume1/daten
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Jul 06 18:07:54 siductionbox systemd[1]: ^[[0;1;39m^[[0;1;39mmedia-daten\x2dnas.mount: Failed with result 'exit-code'.
Jul 06 18:07:54 siductionbox systemd[1]: ^[[0;1;39mFailed to mount /media/daten-nas.
Jul 06 18:07:54 siductionbox systemd[1]: Mounting /media/daten-nas...
Jul 06 18:07:54 siductionbox mount[2129]: mount.nfs4: access denied by server while mounting 192.168.2.60:/volume1/daten
Jul 06 18:07:54 siductionbox systemd[1]: ^[[0;1;39m^[[0;1;39mmedia-daten\x2dnas.mount: Mount process exited, code=exited, status=32/n/a
Jul 06 18:07:54 siductionbox systemd[1]: ^[[0;1;39m^[[0;1;39mmedia-daten\x2dnas.mount: Failed with result 'exit-code'.
Jul 06 18:07:54 siductionbox systemd[1]: ^[[0;1;39mFailed to mount /media/daten-nas.
Jul 06 18:07:54 siductionbox systemd[1]: ^[[0;1;39m^[[0;1;39mmedia-daten\x2dnas.mount: Start request repeated too quickly.
Jul 06 18:07:54 siductionbox systemd[1]: ^[[0;1;39m^[[0;1;39mmedia-daten\x2dnas.mount: Failed with result 'exit-code'.
Jul 06 18:07:54 siductionbox systemd[1]: ^[[0;1;39mFailed to mount /media/daten-nas.
edit: in /run/systemd/generator steht dazu
# Automatically generated by systemd-fstab-generator
[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
[Mount]
Where=/media/daten-nas
What=192.168.2.60:/volume1/daten
Type=nfs4
Options=noauto,x-systemd.automount,timeo=14,x-systemd.idle-timeout=1min
der Eintag in fstab
192.168.2.60:/volume1/daten /media/daten-nas nfs4 noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0
-
So per Suchmaschine ist die Fehlermeldung "mount.nfs4: access denied by server while mounting" auch typisch für einen IP mismatch zischen Clientrechner und NAS-Server (bzw dessen /etc/exports). Hat dein Rechner vielleicht gerade keine gültige IP aus dem Heimnetz, irgendwas kaputt mit dhcp oder resolv? (/me vermut ins Blaue hinein...)
-
eigentlich alles i.O.
ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.42 netmask 255.255.255.0 broadcast 192.168.2.255
-
das mount Problem habe ich jetzt auch lösen können.
Ich habe die Freigaben auf dem NAS gecheckt und festgestellt, dass die ip des PC`s nicht in der Liste der Berechtigten war. Scheinbar wurde dem PC per dhcp (fritzbox) eine andere ip zugewiesen !?
Jedenfalls funzt der nfs Zugriff, das mounten wieder, nach dem ich die aktuelle und jetzt festgeschriebene PC ip im NAS nachgetragen habe.
Vielen Dank für eure Mühen und input !
-
jure, Du kannst die IP-Range für dhcp in der Fritzbox anpassen und dem Nas eine ip ausserhalb dieses Bereiches zuweisen - oder einfach die IP an der MAC-Adresse festmachen - funktioniert dann allerdings nur bis zum nächsten Kartenwechsel :)