Mageia Forum

Hallo Leute,
bei mir ist wohl der Wurm drin. Nachdem ich jetzt einen gangbaren Weg gefunden habe über F9 und uefi in Mageia zu kommen, taucht jetzt plötzlich ein neues Problem auf.
Mitten im Sortieren meiner Fotos war Schluß und die Meldung mit dem rescue modus tauchte auf. Es wurden dann zwei Befehle angezeigt: systemctl reboot und systemctl default. Mit beiden hatte ich kein Erfolg. Ich hab dann die Installations DVD eigelegt und beide Möglichkeiten ausprobiert: Aktualisieren, Installation. Beim Hochfahren ist kurz vor dem Passwort-Fenster Schluß. Dann kommt die Meldung: You are in emergency mode. Das Journal auslesen kann ich nicht da fehlt mir das Wissen (jornalctl -xb).
Ich glaub ich brauche ein neues Laptop.
Grüße

Ich arbeite vorerst mit der Live CD. Ist aber keine Lösung. Vielleicht ist das wichtig: Wenn ich z.B. systemctl reeboot oder -default eingebe poppt kurz der Satz auf: Failed to connect to bus: Datei oder Verzeichnis nicht gefunden.
Grüße

Erklär doch bitte was genau passiert ist? Ist das Laptop abgestürzt oder eingefroren und jetzt bootet es in den Rescue Modus oder was ist passiert?

Bitte gib im emergency modus ein:

Code: Alles auswählen: # journalctl -ab --no-pager -p err

Das sollte eine übersichtliche Ausgabe liefern.

Die Meldung heißt "failed to connect to dbus" und bedeutet erstmal nur, das das System vor Neustart nicht aufgeräumt wird. Wenn du mit dem Livesystem arbeiten kannst, sollte die Hardware funktionieren.

AndieY hat geschrieben:Erklär doch bitte was genau passiert ist? Ist das Laptop abgestürzt oder eingefroren und jetzt bootet es in den Rescue Modus oder was ist passiert?

Hallo, ich habe Fotos auf div Dateien sortiert. Letztes Merkmal war, dass von einigen Fotos plötzlich die Vorschau nicht mehr angezeigt wurde. Dann schwarzer Bildschirm.
Beim Neustart bin ich bis zum Mageia-Symbol mit den Pünktchen gekommen. Dann kam der o.a. Text.
Auch arbeitet meine Mini-Windows-Partition einwandfrei. Ergo, liegt dann wohl nicht an meinem Laptop.
@Bequimao
Sorry. wo soll ich das eingeben? Wenn er beim Hochfahren die rescue-Meldung bringt?

Bequimao hat geschrieben:Bitte gib im emergency modus ein:
Code: Alles auswählen
# journalctl -ab --no-pager -p err

Das sollte eine übersichtliche Ausgabe liefern.

Die Meldung heißt "failed to connect to dbus" und bedeutet erstmal nur, das das System vor Neustart nicht aufgeräumt wird. Wenn du mit dem Livesystem arbeiten kannst, sollte die Hardware funktionieren.

Hallo, ich schreibe das Ergebnis mal ab:
..systemd-fsck[704]: fsck failed with exit status 4.
..systemd[1]: Failed to start systemd-fsck@dev-disk-by\x2duuid-c9bcb4c2\x2d7273\x2d482f\x2d9f36\x2d4a97b6b3a81b.service

Das heißt, dass das Dateisystem defekt ist.
Um zu wissen, welches Dateisystem vorliegt, brauchen wir die Ausgabe als root im Livesystem von

Code: Alles auswählen: blkid

Alternativ einfach Dateisystemcheck über alle Dateisysteme in der /etc/fstab laufen lassen, da wo es Fehler gibt werden die automatisch repariert

Code: Alles auswählen: fsck -Ay

Bequimao hat geschrieben:Das heißt, dass das Dateisystem defekt ist.
Um zu wissen, welches Dateisystem vorliegt, brauchen wir die Ausgabe als root im Livesystem von

Code: Alles auswählen
blkid

Sorry, ich war 3 Tage in Frankfurt.
Das wäre die Ausgabe mit Live-CD:

[live@localhost ~]$ su
[root@localhost live]# blkid
/dev/nvme0n1p9: UUID="c9bcb4c2-7273-482f-9f36-4a97b6b3a81b" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="48c6fe10-7c8a-47f7-8305-bfa9dc38823d"
/dev/nvme0n1p7: UUID="7847aa01-7bc3-4358-992f-7f9bae056480" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="dcae52e5-9717-408e-98a1-902f28831aab"
/dev/nvme0n1p5: BLOCK_SIZE="512" UUID="CCCA4474CA445D38" TYPE="ntfs" PARTUUID="c5b3ad76-d2f5-4526-9d10-2b48590dc807"
/dev/nvme0n1p1: BLOCK_SIZE="512" UUID="5CA84F4FA84F26BC" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="b8cc7a2d-961f-4e95-b26c-7f773a6f7334"
/dev/nvme0n1p8: UUID="008693ad-fdd8-48c8-bcbe-70c01aa9fa0b" TYPE="swap" PARTUUID="152213f7-28ec-4f6a-9361-e52dd8fe8bf7"
/dev/nvme0n1p6: BLOCK_SIZE="512" UUID="AC627B71627B3F60" TYPE="ntfs" PARTUUID="2b78fa16-bcee-49c5-9a9d-a4b88f24f486"
/dev/nvme0n1p4: BLOCK_SIZE="512" UUID="3638B67738B635A9" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="989ef4b9-5b4e-4044-8038-c1203fc0cb7b"
/dev/nvme0n1p2: UUID="549A-E59E" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="32c0408d-93b7-44ec-9aa8-7c9c0c52fa81"
/dev/sr0: BLOCK_SIZE="2048" UUID="2023-08-20-08-42-55-00" LABEL="Mageia-9-Live-Plasma-x86_64" TYPE="iso9660" PTTYPE="dos"
/dev/loop0: TYPE="squashfs"
/dev/nvme0n1p3: PARTLABEL="Microsoft reserved partition" PARTUUID="097f7b79-6648-49b8-8048-bde2de9ea706"

doktor5000 hat geschrieben:Alternativ einfach Dateisystemcheck über alle Dateisysteme in der /etc/fstab laufen lassen, da wo es Fehler gibt werden die automatisch repariert
Code: Alles auswählen
fsck -Ay

Hallo,
ich versuche mal ob ich das hin bekomme. Mir ist noch nicht ganz klar wie ich das machen soll (:
Vmtl. im rescue modus?

Ich hab mal versucht im rescue modus bis auf /etc/fstab mich einzuloggen. fstab mag er nicht. Ansonsten kommt die Meldung:
"fsck von util-linux 2.38.1
e2fsck 1.47.0 (5-Feb_2023)
/dev/nvme0n1p7 ist eingehängt.
e2fsck: Fortsetzung nich möglich"
Kannst Du mir bitte mal den kompletten Pfad angeben den ich unter dem rescue modus eingeben soll.

arthuro hat geschrieben:Ich hab mal versucht im rescue modus bis auf /etc/fstab mich einzuloggen. fstab mag er nicht.

Sorry ich weiß nicht was das bedeuten soll. Du solltest nur das eingeben was im Code-Block steht.
Für das bereits gemountete Dateisystem geht das natürlich nicht oder nur wenn du es vorher aushängst, das wird aber im Rescue-Modus nicht gehen.
Von der Live-CD aus sollte das aber kein Problem sein.

arthuro hat geschrieben:Kannst Du mir bitte mal den kompletten Pfad angeben den ich unter dem rescue modus eingeben soll.

Ich verstehe nicht was du mit kompletten Pfad meinst ?
Wenn du den vollen Befehl haben willst, für deine beiden ext4-Dateisysteme aus der Auflistung:

Code: Alles auswählen: fsck -y /dev/nvme0n1p9 fsck -y /dev/nvme0n1p7

Super!! Hat funktioniert. Mir fällt ein Stein vom Herzen.
Falls Interesse, ich habe den Text kopiert. Ich sehe nur dass es ein fehlerhaftes Dateiensystem gab.
Hab mal nachgesehen. Mein SW Foto Ordner ist jetzt leer. Vermutlich mochte er einige Fotodateien nicht.
Danke für die Hilfe.
Ernst

Hallo, leider muß ich noch einmal zurück kommen.
Ich hatte schon wieder einen rescue-Modus.
Wie das letzte Mal hab ich dann die beiden Befehle ausgeführt (Live CD) und Mageia lief dann wieder normal.
Ich gebe mal den ganzen Reparaturtext ein, vielleicht kann man daraus mein Problem ableiten und es kann dann gelingen das Problem dauerhaft zu lösen.

Code: Alles auswählen: [root@localhost live]# fsck -y /dev/nvme0n1p9 fsck von util-linux 2.38.1 e2fsck 1.47.0 (5-Feb-2023) /dev/nvme0n1p9 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen. Durchgang 1: Inodes, Blöcke und Größen werden geprüft Der Erweiterungsbaum von Inode 14977534 (auf Ebene 1) könnte kürzer sein. Optimize? ja Inodes wurden gefunden, die Teil einer defekten verketteten Liste von verwaisten Inodes waren. Reparieren? ja Inode 15036336 war Teil der Liste verwaister Inodes. REPARIERT. Inode 15037671 war Teil der Liste verwaister Inodes. REPARIERT. Inode 15037674 war Teil der Liste verwaister Inodes. REPARIERT. Inode 15037708 war Teil der Liste verwaister Inodes. REPARIERT. Inode 15037711 war Teil der Liste verwaister Inodes. REPARIERT. Inode 15037759 war Teil der Liste verwaister Inodes. REPARIERT. Der Erweiterungsbaum von Inode 15731186 (auf Ebene 1) könnte kürzer sein. Optimize? ja Der Erweiterungsbaum von Inode 15732163 (auf Ebene 1) könnte kürzer sein. Optimize? ja Durchgang 1E: Erweiterungsbäume werden optimiert Durchgang 2: Verzeichnisstruktur wird geprüft Durchgang 3: Verzeichnisverknüpfungen werden geprüft Durchgang 4: Referenzzähler werden überprüft Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft Unterschiede in der Block-Bitmap: -(3196768--3196784) -(50657803--50657817) -51091486 -(57591819--57591828) - (58013711--58013716) -(70742035--70742038) -(70742041--70742050) Reparieren? ja Die Anzahl freier Blöcke in Gruppe #97 ist falsch (5173, gezählt=5190). Reparieren? ja Die Anzahl freier Blöcke in Gruppe #1545 ist falsch (19173, gezählt=19188). Reparieren? ja Die Anzahl freier Blöcke in Gruppe #1559 ist falsch (17502, gezählt=17503). Reparieren? ja Die Anzahl freier Blöcke in Gruppe #1757 ist falsch (6467, gezählt=6477). Reparieren? ja Die Anzahl freier Blöcke in Gruppe #1770 ist falsch (7370, gezählt=7376). Reparieren? ja Die Anzahl freier Blöcke in Gruppe #2158 ist falsch (11133, gezählt=11147). Reparieren? ja Die Anzahl freier Blöcke ist falsch (37695325, gezählt=37695388). Reparieren? ja Unterschiede in der Inode-Bitmap: -14942630 -15036336 -15037671 -15037674 -15037708 -15037711 -15037759 Reparieren? ja Die Anzahl freier Inodes für Gruppe #1824 ist falsch (0, gezählt=1). Reparieren? ja Die Anzahl freier Inodes für Gruppe #1835 ist falsch (2752, gezählt=2758). Reparieren? ja Die Anzahl freier Inodes ist falsch (23691632, gezählt=23691639). Reparieren? ja /dev/nvme0n1p9: ***** DATEISYSTEM WURDE VERÄNDERT ***** /dev/nvme0n1p9: 171657/23863296 Dateien (4.6% nicht zusammenhängend), 57738677/95434065 Blöcke [root@localhost live]# fsck -y /dev/nvme0n1p7 fsck von util-linux 2.38.1 e2fsck 1.47.0 (5-Feb-2023) /dev/nvme0n1p7: Journal wird wiederhergestellt Die Anzahl der freien Inodes wird auf 3146819 gesetzt (war 3146820) Die Anzahl der freien Blöcke wird auf 11396192 gesetzt (war 11398242) /dev/nvme0n1p7: sauber, 154557/3301376 Dateien, 1787808/13184000 Blöcke

arthuro hat geschrieben:Ich gebe mal den ganzen Reparaturtext ein, vielleicht kann man daraus mein Problem ableiten und es kann dann gelingen das Problem dauerhaft zu lösen.

Ahoi, nein kann man nicht. Wenn du nicht dazu schreibst was zuvor passiert ist, kann man daraus gar nichts ableiten.

Für mich sieht das so aus wie ein Reboot im laufenden Betrieb als das Dateisystem noch eingehangen war als Ursache.

Schade. Ich hab gedacht, dass er vielleicht einige Dateien nicht mag ("/dev/nvme0n1p9 enthält ein fehlerhaftes Dateisystem").
Eigentlich läuft das immer nach dem gleichen Schema ab:
Irgendwann läßt sich eine Datei oder ein Foto mit der Maus nicht mehr öffnen. Die Maus bewegt sich noch aber man kann nichts mehr ausführen. Und dann verabschiedet sich, langsam nicht schlagartig, das Programm und es erscheint ein schwarzer Bildschirm. Wenn ich neu starte lande ich genau wieder auf der alten Oberfläche mit all den geöffneten Programmen usw. von vorher. Das geht manchmal, manchmal kommt dann schon vor dem Einloggen der rescue-Modus.

Das klingt eher nach einem Hardware-Problem mit der SSD, oder problematische Energiespareinstellungen für PCIex-Geräte ggf. in Kombination mit Unverträglichkeit mit dem Mainboard oder dem NVMe-Controller.

Zu einem der Boot-Vorgänge wo das aufgetreten ist wäre ein journal-Auszug hilfreich da lässt sich ggf. was herauslesen was mit der SSD oder dem NVMe-Controller passiert.
Als root

Code: Alles auswählen: journalctl -ab-1 | grep -i nvme

-b-1 ist dabei der vorherige Boot, -b-2 wäre der davor.

Und ein paar mehr Details zur Hardware, dazu steht hier und im anderen Thread zu grub nichts.

Hier die relevanten Tage:

Code: Alles auswählen: [root@localhost ernesto]# journalctl -ab-5 | grep -i nvme Aug 30 19:17:20 localhost kernel: nvme nvme0: pci function 0000:03:00.0 Aug 30 19:17:20 localhost kernel: nvme nvme0: 8/0/0 default/read/poll queues Aug 30 19:17:20 localhost kernel: nvme0n1: p1 p2 p3 p4 p5 p6 p7 p8 p9 Aug 30 19:17:20 localhost kernel: EXT4-fs (nvme0n1p7): mounted filesystem 7847aa01-7bc3-4358-992f-7f9bae056480 ro with ordered data mode. Quota mode: none. Aug 30 19:17:20 localhost kernel: EXT4-fs (nvme0n1p7): unmounting filesystem 7847aa01-7bc3-4358-992f-7f9bae056480. Aug 30 19:17:20 localhost kernel: EXT4-fs (nvme0n1p7): mounted filesystem 7847aa01-7bc3-4358-992f-7f9bae056480 ro with ordered data mode. Quota mode: none. Aug 30 19:17:20 localhost dracut: Mounted root filesystem /dev/nvme0n1p7 Aug 30 19:17:20 localhost kernel: EXT4-fs (nvme0n1p7): re-mounted 7847aa01-7bc3-4358-992f-7f9bae056480 r/w. Quota mode: none. Aug 30 19:17:20 localhost systemd-fsck[559]: /dev/nvme0n1p7: sauber, 164660/3301376 Dateien, 2056251/13184000 Blöcke Aug 30 19:17:20 localhost kernel: Adding 4194300k swap on /dev/nvme0n1p8. Priority:-2 extents:1 across:4194300k SS Aug 30 19:17:22 localhost kernel: FAT-fs (nvme0n1p2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 30 19:17:22 localhost ntfs-3g[722]: Mounted /dev/nvme0n1p4 (Read-Write, label "", NTFS 3.1) Aug 30 19:17:22 localhost ntfs-3g[722]: Mount options: allow_other,nonempty,relatime,rw,default_permissions,fsname=/dev/nvme0n1p4,blkdev,blksize=4096 Aug 30 19:17:22 localhost systemd-fsck[721]: /dev/nvme0n1p9 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen. Aug 30 19:17:22 localhost systemd-fsck[721]: /dev/nvme0n1p9: Inodes wurden gefunden, die Teil einer defekten verketteten Liste von Aug 30 19:17:22 localhost systemd-fsck[721]: /dev/nvme0n1p9: UNERWARTETE INKONSISTENZ; fsck MANUELL AUSFÜHREN Aug 30 19:18:35 localhost ntfs-3g[722]: Unmounting /dev/nvme0n1p4 () Aug 30 19:18:35 localhost systemd[1]: dev-disk-by\x2did-nvme\x2deui.0000000001000000e4d25c71895d5101\x2dpart8.swap: Deactivated successfully. Aug 30 19:18:35 localhost systemd[1]: Deactivated swap dev-disk-by\x2did-nvme\x2deui.0000000001000000e4d25c71895d5101\x2dpart8.swap. Aug 30 19:18:35 localhost systemd[1]: dev-disk-by\x2did-nvme\x2dINTEL_SSDPEKNW512G8H_BTNH9346056U512A\x2dpart8.swap: Deactivated successfully. Aug 30 19:18:35 localhost systemd[1]: Deactivated swap dev-disk-by\x2did-nvme\x2dINTEL_SSDPEKNW512G8H_BTNH9346056U512A\x2dpart8.swap. Aug 30 19:18:35 localhost systemd[1]: dev-disk-by\x2dpath-pci\x2d0000:03:00.0\x2dnvme\x2d1\x2dpart8.swap: Deactivated successfully. Aug 30 19:18:35 localhost systemd[1]: Deactivated swap dev-disk-by\x2dpath-pci\x2d0000:03:00.0\x2dnvme\x2d1\x2dpart8.swap. Aug 30 19:18:35 localhost systemd[1]: dev-disk-by\x2did-nvme\x2dINTEL_SSDPEKNW512G8H_BTNH9346056U512A_1\x2dpart8.swap: Deactivated successfully. Aug 30 19:18:35 localhost systemd[1]: Deactivated swap dev-disk-by\x2did-nvme\x2dINTEL_SSDPEKNW512G8H_BTNH9346056U512A_1\x2dpart8.swap. Aug 30 19:18:35 localhost systemd[1]: dev-nvme0n1p8.swap: Deactivated successfully. Aug 30 19:18:35 localhost systemd[1]: Deactivated swap dev-nvme0n1p8.swap. [root@localhost ernesto]# journalctl -ab-4 | grep -i nvme Aug 31 11:13:44 localhost kernel: nvme nvme0: pci function 0000:03:00.0 Aug 31 11:13:44 localhost kernel: nvme nvme0: 8/0/0 default/read/poll queues Aug 31 11:13:44 localhost kernel: nvme0n1: p1 p2 p3 p4 p5 p6 p7 p8 p9 Aug 31 11:13:44 localhost kernel: workqueue nvme-delete-wq: hash matches Aug 31 11:13:44 localhost kernel: EXT4-fs (nvme0n1p7): mounted filesystem 7847aa01-7bc3-4358-992f-7f9bae056480 ro with ordered data mode. Quota mode: none. Aug 31 11:13:44 localhost kernel: EXT4-fs (nvme0n1p7): unmounting filesystem 7847aa01-7bc3-4358-992f-7f9bae056480. Aug 31 11:13:44 localhost kernel: EXT4-fs (nvme0n1p7): mounted filesystem 7847aa01-7bc3-4358-992f-7f9bae056480 ro with ordered data mode. Quota mode: none. Aug 31 11:13:44 localhost dracut: Mounted root filesystem /dev/nvme0n1p7 Aug 31 11:13:44 localhost kernel: EXT4-fs (nvme0n1p7): re-mounted 7847aa01-7bc3-4358-992f-7f9bae056480 r/w. Quota mode: none. Aug 31 11:13:44 localhost systemd-fsck[558]: /dev/nvme0n1p7: sauber, 164660/3301376 Dateien, 2057148/13184000 Blöcke Aug 31 11:13:44 localhost kernel: Adding 4194300k swap on /dev/nvme0n1p8. Priority:-2 extents:1 across:4194300k SS Aug 31 11:13:46 localhost kernel: FAT-fs (nvme0n1p2): utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive! Aug 31 11:13:46 localhost ntfs-3g[720]: Mounted /dev/nvme0n1p4 (Read-Write, label "", NTFS 3.1) Aug 31 11:13:46 localhost ntfs-3g[720]: Mount options: allow_other,nonempty,relatime,rw,default_permissions,fsname=/dev/nvme0n1p4,blkdev,blksize=4096 Aug 31 11:13:46 localhost systemd-fsck[719]: /dev/nvme0n1p9 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen. Aug 31 11:13:47 localhost systemd-fsck[719]: /dev/nvme0n1p9: Inodes wurden gefunden, die Teil einer defekten verketteten Liste von Aug 31 11:13:47 localhost systemd-fsck[719]: /dev/nvme0n1p9: UNERWARTETE INKONSISTENZ; fsck MANUELL AUSFÜHREN Aug 31 11:14:18 localhost systemd-fsck[873]: /dev/nvme0n1p9 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen. Aug 31 11:14:18 localhost systemd-fsck[873]: /dev/nvme0n1p9: Inodes wurden gefunden, die Teil einer defekten verketteten Liste von Aug 31 11:14:18 localhost systemd-fsck[873]: /dev/nvme0n1p9: UNERWARTETE INKONSISTENZ; fsck MANUELL AUSFÜHREN Aug 31 11:14:42 localhost systemd-fsck[918]: /dev/nvme0n1p9 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen. Aug 31 11:14:42 localhost systemd-fsck[918]: /dev/nvme0n1p9: Inodes wurden gefunden, die Teil einer defekten verketteten Liste von Aug 31 11:14:42 localhost systemd-fsck[918]: /dev/nvme0n1p9: UNERWARTETE INKONSISTENZ; fsck MANUELL AUSFÜHREN

Laptop= HP 17-1307NG I5-8265U/8GB/512GB SS, 5Jahre alt.
Der Crash war am 31.8.
Meine letzte Tätigkeit am 30.8. war, die Gültigkeit der SIM-Karte vom kroatischen Smartphone meiner Frau über die Web-Seite zu verlängern.

Das geht leider nicht weit genug zurück, der erste Treffer für nvme0n1p9 ist schon für ein beschädigtes Dateisystem, es muss also schon beim Boot davor gewesen sein.

arthuro hat geschrieben:
Code: Alles auswählen
[root@localhost ernesto]# journalctl -ab-5 | grep -i nvme [...] Aug 30 19:17:22 localhost systemd-fsck[721]: /dev/nvme0n1p9 enthält ein fehlerhaftes Dateisystem, Prüfung erzwungen. Aug 30 19:17:22 localhost systemd-fsck[721]: /dev/nvme0n1p9: Inodes wurden gefunden, die Teil einer defekten verketteten Liste von Aug 30 19:17:22 localhost systemd-fsck[721]: /dev/nvme0n1p9: UNERWARTETE INKONSISTENZ; fsck MANUELL AUSFÜHREN

Sorry. Er geht nicht weiter zurück. Ich hab schon journalctl -ab-8 | grep -i nvme eingegeben aber es kommt immer wieder der 30.8. Wohl weil ich zwischendurch mal neu installiert habe.

Gestern hat sich beim Durchscrollen von Nachrichten mein Firefox verabschiedet. Ich hab dann schnell den Rechner heruntergefahren und neu gestartet.
Anschließend habe ich gleich ein Protokoll abgerufen (journalctl -ab-1 | grep -i nvme) und seitenlang immer die gleiche beunruhigende Meldung bekommen:
Auszug:

Code: Alles auswählen: Sep 04 18:59:01 localhost kernel: nvme 0000:03:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Sep 04 18:59:01 localhost kernel: nvme 0000:03:00.0: device [8086:f1a8] error status/mask=00000001/0000e000 Sep 04 18:59:01 localhost kernel: nvme 0000:03:00.0: [ 0] RxErr (First) Sep 04 18:59:01 localhost kernel: nvme 0000:03:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Sep 04 18:59:01 localhost kernel: nvme 0000:03:00.0: device [8086:f1a8] error status/mask=00000001/0000e000 Sep 04 18:59:01 localhost kernel: nvme 0000:03:00.0: [ 0] RxErr (First) Sep 04 18:59:54 localhost ntfs-3g[722]: Unmounting /dev/nvme0n1p4 () Sep 04 18:59:55 localhost systemd[1]: dev-disk-by\x2did-nvme\x2deui.0000000001000000e4d25c71895d5101\x2dpart8. swap: Deactivated successfully. Sep 04 18:59:55 localhost systemd[1]: Deactivated swap dev-disk-by\x2did-nvme\x2deui.0000000001000000e4d25c718 95d5101\x2dpart8.swap. Sep 04 18:59:55 localhost systemd[1]: dev-disk-by\x2did-nvme\x2dINTEL_SSDPEKNW512G8H_BTNH9346056U512A\x2dpart8 .swap: Deactivated successfully. Sep 04 18:59:55 localhost systemd[1]: Deactivated swap dev-disk-by\x2did-nvme\x2dINTEL_SSDPEKNW512G8H_BTNH9346 056U512A\x2dpart8.swap. Sep 04 18:59:55 localhost systemd[1]: dev-disk-by\x2did-nvme\x2dINTEL_SSDPEKNW512G8H_BTNH9346056U512A_1\x2dpar t8.swap: Deactivated successfully. Sep 04 18:59:55 localhost systemd[1]: Deactivated swap dev-disk-by\x2did-nvme\x2dINTEL_SSDPEKNW512G8H_BTNH9346 056U512A_1\x2dpart8.swap. Sep 04 18:59:55 localhost systemd[1]: dev-disk-by\x2dpath-pci\x2d0000:03:00.0\x2dnvme\x2d1\x2dpart8.swap: Deac tivated successfully. Sep 04 18:59:55 localhost systemd[1]: Deactivated swap dev-disk-by\x2dpath-pci\x2d0000:03:00.0\x2dnvme\x2d1\x2 dpart8.swap. Sep 04 18:59:55 localhost systemd[1]: dev-nvme0n1p8.swap: Deactivated successfully. Sep 04 18:59:55 localhost systemd[1]: Deactivated swap dev-nvme0n1p8.swap. Sep 04 18:59:55 localhost kernel: EXT4-fs (nvme0n1p9): unmounting filesystem c9bcb4c2-7273-482f-9f36-4a97b6b3a 81b.

Ich denke, ich warte jetzt mal ab bis er sich wieder komplett verabschiedet und mache dann ein Protokoll. Dann sehen wir hoffentlich genau das ganze Problem.
Grüße
Ernst

Naja wie ich schon geschrieben hatte, da brauchst du dich auch nicht zu wundern wenn das Dateisystem unsauber ist.
Dazu gibt es viele Treffer, siehe z.B.
https://www.thomas-krenn.com/en/wiki/PC ... s_00001100
https://forums.unraid.net/topic/118286- ... o-resolve/
https://askubuntu.com/questions/863150/ ... eceiver-id

Kandidaten für Boot-Optionen wären also:
pcie_aspm=off
pci=noaer
pci=nomsi
Siehe dazu auch https://wiki.mageia.org/en/Wie_man_Kern ... nstellt-de

Alternativ die SSD mal in einen anderen Steckplatz stöpseln.

Danke für die Info.

Mageia Forum

rescue Modus

rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: [gelöst] rescue Modus

Re: [gelöst] rescue Modus

Re: [gelöst] rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus

Re: rescue Modus