Login
Newsletter
Werbung

Thema: Dateisystemkorruption in ext4 in Linux 4.19

44 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von glasen am Do, 29. November 2018 um 15:03 #

Sowohl auf meinen Thinkpad T460, als auch auf meinem Desktop-Rechner mit Ryzen 2600-CPU. Beide Rechner haben eine SSD, wobei es laut Nutzeraussagen auch HDD-Systeme betrifft.

  • 1
    Von James Kirk am Do, 29. November 2018 um 15:23 #

    Ich hatte den Fehler ebenfalls auf einem Laptop mit SSD. Seit 4.19.3 gibt es jedoch keine Probleme mehr.

    • 1
      Von glasen am Do, 29. November 2018 um 15:38 #

      Hatte ihn auch noch mit 4.19.3.

      • 1
        Von peterle am Do, 29. November 2018 um 16:23 #

        interessant, aber wie genau bemerkt man das (so schnell)? andauernd partitionen prüfen?

        • 1
          Von glasen am Do, 29. November 2018 um 16:42 #

          Bei mir funktionierte auf einmal "VisualVM" nicht mehr. Es kam immer eine Fehlermeldung. Also habe ich versucht das Programm zu löschen (Liegt bei mir einfach unter "~/tools" und frisch zu installieren. Das funktionierte nicht, da das Verzeichnis beschädigt war.

          1
          Von James Kirk am Do, 29. November 2018 um 16:54 #

          Bei mir war die root Partition (vielleicht auch nur bestimmte Verzeichnisse) nur noch read only. Nach einem Neustart behob der fsck das Problem zunächst. Nach ein paar Stunden trat das Phänomen wieder auf.

          • 1
            Von peterle am Do, 29. November 2018 um 17:50 #

            ok, verstehe. sollten also meine favoriten tools streiken, ist das ein indiz.

            sehr viel schlimmer stell ich mir das bei audio und video dateien vor. und die ev noch unbemerkt spiegeln :shock:

2
Von irgendwer am Do, 29. November 2018 um 16:59 #

Ts'o sagt ja mehrmals und wird damit auch hier zitiert, dass es schon mehrfach aufgetreten ist, dass Dateisystemfehler letztendlich nicht auf eine Änderung am Dateisystemcode, sondern auf auf Änderungen an ganz anderen Stellen des Linux-Kernels zurückzuführen waren. Das berühmte NVidia-Beispiel der wildlaufendenden Pointer ist ja nur ein Beispiel unter anderen.

Da kann ich mir einen Kommentar nicht verkneifen: Mit einem Mikrokernel wäre das nicht passiert!

  • 4
    Von Ti Sento am Do, 29. November 2018 um 17:45 #

    Stimmt, den die haben schon per Definition keine Fehler, schon gar keine unbeabsihtigtenunbeabsichigten.

    0
    Von schmidicom am Fr, 30. November 2018 um 08:16 #

    Wie soll ein Microkernel den solche Wild Pointer verhindern?

    • 2
      Von irgendwer am Fr, 30. November 2018 um 09:34 #

      Erstens kann das von dir verlinkte sowieso nicht mehr so einfach funktionieren, da durch heutige Sicherheitsbestimmungen und Möglichkeiten des Virtuellen Speichers allgemein real auch bei malloc (und nicht nur calloc) kein uninitialisierer, alter Speicher übergeben wird. Entweder die wahre Alloziierung erfolgt sowieso erst beim ersten Schreibzugriff (vorher werden Nullen aus dem Nichts geliefert) oder es wird aus Sicherheitsgründen zu Null initialisiert. Dem entsprechend gibt es in den Beispielen einfach nur eine Null-Pointer-Exception, die sich recht einfach abfangen lässt und im System heutzutage nichts mehr kaputt macht. Man muss sich da schon durch gut gedachte aber falsch umgesetzte Pointer-Magie verrechnen und so bewusst auf Speicherbereiche zugreifen, die man so nicht adressieren wollte.

      Und da kommt dann der Vorteil des Microkernels zur Geltung: Beim Microkernel sind alles bis auf einen sehr kleinen Kernel, also insbesondere auch Dateisystem- und Harwaretreiber Userland-Prozesse. Ein Wild Pointer in einem Treiber kann somit genauso wenig ein wildes Schreiben in den Speicherbereich des Kernels oder eines anderen Treibers auslösen wie bei dir der Firefox in den Speicherbereich des Chrome schreiben kann! Die CPU unterbindet das und springt in eine Exception-Routine des Kernels. Der Kernel wiederum kann in dem Fall den kompletten (virtuellen) Speicherbereich des Treiber-Prozesses entladen und den Treiber reinitialisieren.

      Das sieht bei einem Monolithen extrem anders aus. Wenn da ein Treibermodul wild im Kernelspace rumfurwerkt hat, führt an einem klassischen Neustart des gesamtem Kernelspaces nichts vorbei.

      DAS ist der Punkt, an dem Microkernel klar im Vorteil sind und der sie überhaupt ausmacht: Bei Monolithen wie Linux gibt es harte Policies für Code beitragende, an die sich Programmierer halten müssen, damit Code aufgenommen wird. Mit viel Sorgfalt muss man Programmierfehlern vorbeugen. Und dennoch können diese passieren und haben dann fatale Folgen. Bei Microkerneln sind diese viel weniger tragisch, betreffen nur das lokale Subsystem und diese können auch nach bösesten Fehlern einfach neu gestartet werden (es sind ja gekapselte Prozesse).

      Das hat natürlich auch Nachteile, weil zum Datenaustausch zwischen Kernel und Treiber halt bewusst Shared Memory initialisiert werden muss, mehr Kontextwechsel stattfinden, etc. und der direkte Hardwarezugriff für solche Userlandprozesse die Hardwaretreiber darstellen geregelt werden muss, etc.

      Es ist aufwändiger, aber dank moderner Techniken wie Zero-Copying heute nicht mehr so sehr im Nachteil wie früher, als Microkernel für "wesentlich langsamer" standen.

      Das ist auch der Grund, weshalb sich auch bei generell auf Microkerneln basierenden Systemen ala Windows NT durchaus das ein oder andere monolithische Konzept durchgesetzt hat. Wenn performancekritisches wie Grafikkartentreiber im Kernel ein paar Prozent schneller sind, sind sie da halt ein paar Prozent schneller. Dennoch ist allen bewusst, dass man sich das mit Nachteilen erkauft, weshalb gerade unter Windows eine Abkehr davon stattfindet. Nicht umsonst kann man da mittlerweile das Grafiksubsystem bei Fehlern neu starten, während ein fataler Fehler im GPU-Stack von Linux oftmals nur mit einem Neustart des ganzen Systems zu beheben ist (dank KMS und Kerneltreibern im Gegensatz zu früher, wo ein X-Neustart durchaus reichte, als der GPU-Treiber noch im Userland war).

      Des Weiteren kann man klar festhalten: Nur weil sich Monolithen durchaus durchsetzen, heißt das nicht, dass diese die besseren Kerne sind. Sie sind besser für einen bestimmten Zweck: Erst einmal einfacher und mit weniger Mitteln schneller. Dennoch würde auf Dauer der Microkernel das bessere Konzept sein. Es setzt sich aber halt nicht immer das bessere durch. Warum ist Windows mit der 9x-Serie groß geworden und nicht mit NT? NT war _klar_ besser. Aber halt nicht in allen Punkten. Warum nutzen wir heute alle Android mit all seinen Sicherheitsproblemen und nicht iOS oder Windows Mobile, die haben durchaus ihre Vorteile...

      Für all das gibt es Gründe.

      • 0
        Von glasen am So, 2. Dezember 2018 um 01:06 #

        Dennoch würde auf Dauer der Microkernel das bessere Konzept sein.
        Mag sein, aber die Diskussion ist rein akademischer Natur. Microkernel mögen stabiler und sicherer sein, in der freien Wildbahn haben sich aber Makrokernel durchgesetzt, weil deren Stabilität und Sicherheit eben nicht so viel schlechter sind.

        Warum ist Windows mit der 9x-Serie groß geworden und nicht mit NT? NT war _klar_ besser.
        Das lag einzig und allein daran, dass die 9x-Serie wesentlich weniger RAM benötigt hat als NT. NT 3.1 benötigte damals mindestens 8MB RAM, damit man mit dem System überhaupt arbeiten konnte. Das war 1994, als gerade 4MB zum Standard wurden.

        • 0
          Von irgendwer am So, 2. Dezember 2018 um 09:55 #

          Mag sein, aber die Diskussion ist rein akademischer Natur. Microkernel mögen stabiler und sicherer sein, in der freien Wildbahn haben sich aber Makrokernel durchgesetzt, weil deren Stabilität und Sicherheit eben nicht so viel schlechter sind.
          Das Fazit stimmt, aber die Herleitung überhaupt nicht. Es gibt in der Praxis relevante Microkernel-Systeme, wie QNX. Wenn es wirklich auf Stabilität ankommt, werden sie durchaus gerne verwendet (z.B. Firmware für Steuergeräte, Automobile, Raumfahrt, etc.).

          Wie auch immer, die Diskussion ist eh mühsam, denn reine Vertreter sind sowieso eher selten. Insbesondere die bekannten Server- und Desktop-Vertreter Windows und Macos nutzen als Beispiel hybride Kernel und damit die Vorteile aus beiden Welten: Apple konnte so u.a. die POSIX-API und den Netzwerkstack aus FreeBSD übernehmen, ohne alles selber neu erfinden zu müssen. Für Apple wie auch Windows gilt dabei – wie üblich: "Many drivers can be written to run from user space, which further enhances the stability of the system. If a user-space driver crashes, it will not crash the kernel. However, if a kernel-space driver crashes it will crash the kernel." - https://en.wikipedia.org/wiki/XNU

          Aber auch Linux ist längst kein reiner Monolith. Viel Funktionalität wird in die kworker-Threads ausgelagert, die einen Großteil der Arbeit übernehmen. (Sie tauchen als Userspace-Prozesse in ps/top auf, inklusive PID.) Darüber hinaus gibt es ... userspace I/O system (UIO), FUSE, usw...

          Nicht ohne Grund. Die Entwickler aller Systeme sind sich der Vorteil beider Welten bewusst.

          Userspace-Treiber habe nicht nur den Vorteil bei Fehlern weniger Schaden anrichten zu können, man kann hier auch andere Bibliotheken nutzen, eben Userspace-Bibliotheken von der libc bis zu komplexen Runtime-Environments. Die Treiberentwicklung ist somit auch einfacher.

          Das lag einzig und allein daran, dass die 9x-Serie wesentlich weniger RAM benötigt hat als NT. NT 3.1 benötigte damals mindestens 8MB RAM, damit man mit dem System überhaupt arbeiten konnte. Das war 1994, als gerade 4MB zum Standard wurden.

          Ich bin mal alte Vobis Denkzettel (weil man die recht einfach im Netz findet) durchgegangen. 8 MB waren wohl schon 94 üblich.

          Windows 9x wurde jedoch erst mit 95 groß, welches – oh Wunder – erst 1995 auf den Markt kam. Da waren 8 MB und mehr üblich. Es fand erst später mit 98 wirklich Verbreitung, da waren schon 32 MB und mehr nicht unüblich.

          Es hat sich durchgesetzt, weil es billiger als NT und für die Masse ausreichend war. Und vor allem: besser kompatibel mit alten DOS-Anwendungen – insbesondere denen, die direkt auf die Hardware zugreifen wollten wie Spiele. NT war der deutlich schlechter Gameloader. Ein Grund, der auch heute noch für vieles spricht, an altem hängen zu bleiben: Spiele. Das erklärt prima, weshalb Windows trotz aller aktuellen Umstände so deutlich klar beliebter ist als Linux oder andere Alternativen: Windows ist mit Abstand der beste PC-Gameloader.

          Wie schon gesagt: Es gibt nicht _das_ Beste, so lang es verschiedene Kriterien und Gewichtungen dieser gibt.

          • 0
            Von glasen am So, 2. Dezember 2018 um 11:54 #

            Ich bin mal alte Vobis Denkzettel (weil man die recht einfach im Netz findet) durchgegangen. 8 MB waren wohl schon 94 üblich.
            Bei neuen Rechnern und dann auch nur in den Preisklassen weit über 3000DM. Die "Brot-und-Butter-PCs" bis maximal 2000DM waren immer noch alle mit 4MB ausgestattet:

            https://katzentier.de/_misc/Vobis/

            Windows 9x wurde jedoch erst mit 95 groß, welches – oh Wunder – erst 1995 auf den Markt kam. Da waren 8 MB und mehr üblich. Es fand erst später mit 98 wirklich Verbreitung, da waren schon 32 MB und mehr nicht unüblich.
            Erst 1996 wurden 8MB RAM zum Standard in der BuB-Klasse. Und als Windows 98 auf den Markt kam, waren 16MB RAM der Standard. 32MB halt nur in Rechnern über 2000DM.

            Es hat sich durchgesetzt, weil es billiger als NT und für die Masse ausreichend war. [..]
            Da stimme ich dir zu. Nur hatte sich das MS damals anders gedacht. NT sollte damals MS-DOS vollständig ablösen, nur eben war der RAM zu teuer.

            • 0
              Von irgendwer am So, 2. Dezember 2018 um 15:29 #

              Ich weiß ja nicht wo du guckst. Sobald in den Blättchen Windows 95 als OS auftaucht, sind 8-16 MB üblich. Schon beim 1999 DM Frontcover von 1996. Im Februar 1995 gab es halt noch kein Windows 95 – obwohl auch dennoch dort im Blättchen 8 MB nicht unüblich sind. Schon im 1997er Blättchen sind dann mehr mit 32 als 16 MB, wie soll dann 1998 und später noch 16 MB Standard gewesen sein?

              Man hätte also durchaus NT bei Neu-PC mit Win95 liefern können. Hat man aber nicht.

              Ach und 2000 DM waren da halt eher die absolute Einstiegsgrenze als eine Obergrenze. Es ist in den Blättchen dieser Zeit der Einstieg, fast alles andere ist teurer. Das also als Obermaß zu nehmen ist schon irgendwie daneben.

              Bei Alt-PC stimme ich dir zu, auf 486ern mit 4MB, wie es vielleicht noch 92 üblich war, ist NT Fehl am Platze. Jedoch auch Win95, da ist DOS zweckmäßiger. Dann fallen Spiele aber ebenfalls durchaus eher raus. Nicht weil sie unter DOS nicht liefen, nein, DOS ist da noch immer Spieleplattform. Viel mehr weil man Alt-PC schon für die Anforderungen der Spiele selbst aufrüsten müsste. Für Highlights des Jahres ala Warcraft 2 benötigt man durchaus mal 16 MB und aufwärts. Also ja, NT benötigt mehr RAM als Win95 und wäre von daher ein guter Grund zum Aufrüsten gewesen – aber den gab es somit sowieso auch aus anderen Gründen.

              NT hat sich vielleicht auch nicht durchgesetzt, weil man mehr RAM brauchte oder 95 bei Neu-PC billiger mit anbieten konnte, aber insbesondere weil NT halt zum Spielen nicht so gut geeignet war. Bzw. wohl möglich Win95 sogar gerade wegen seiner DOS-Basis. Bei Win9x funktionierten all die tollen Tipps und Tricks aus der DOS-Zeit in config.sys und autoexec.bat größtenteils einfach weiter; notfalls indem man den Bootvorgang mit DOS abbrach um all zu sehr tricksende DOS-Spiele noch nutzen zu können – unter NT mit seiner Speicherverwaltung und seinem emulierten DOS machte das _deutlich_ mehr Probleme; DOS-Spiele mit eigener VMM-Verwaltung (wohl möglich sogar mit eigener Real/Protected-Mode Verwaltung) sogar unmöglich. NT war stabiler, aber eben auch ein völlig anderes Konzept und Altlasten nicht nur der Nutzer, sondern auch Programmiergewohnheiten der DOS-Entwickler funktionierten so einfach nicht.

              Apropos, da sehe ich noch einen Haupt-Grund: die Experten, die einem zeigen wo's lang geht. Der DOS/Win3.1-Crack war meist kein NT-Crack. Was empfiehlt dieser "Fachmann" im Bekanntenkreis also?

              Schon alternative DOS ala Novell-DOS hatten schlechte Chancen. Nicht weil damit weniger möglich war – ganz im Gegenteil – es war dem "Fachmann" von Nebenan einfach fremd. (Ich hab lange Zeit Novell DOS genutzt, das lief viel besser als MS-DOS und brachte sogar einen Netzwerkstack schon mit. Lief alles super, von den Typischen Cracks im Nachbarumfeld hab ich dabei ständig gehört, dass das doch nichts tauge, weil damit nichts läuft. Ja, ich kenne die Vorurteile.)

              Apropos RAM, da hast du durchaus auch Recht, aber etwas anders als gedacht: Fehlendes RAM war in dem Fall ein sehr entscheidender Grund. Aber nicht, weil bei den 8 oder 16 MB Systemram zu wenig für das Spiel bleibt, sondern weil das alte DOS-Spiel von den 640 kB Low-Mem bei NT nicht mehr die gewohnten 600 kB ala DOS, sondern vielleicht noch 500 kB oder noch weniger abbekam. DAS war oftmals fatal. Und auch 1995 kamen noch Spiele auf den Markt, die noch immer von möglichst viel Low-Mem dieser Art abhängig waren. Oder von High-Mamory-Managern, die unter NT nicht wollten, etc. Ich kann mich noch gut daran erinnern, das letzte Quäntchen Low-Mem heraus kitzeln zu müssen, damit die Lieblingsspiele liefen und war auch zu Windows-Zeiten noch mit einer stark angepassten config.sys/autoexec.bat unterwegs.

              Apropos Gewohnheit und Altlasten (aka Liebgewonnenes): Einer DER Gründe auch heute noch, der gegen einen Umstieg vom mittlerweile gewohnten Windows auf etwas anderes spricht. Gewohnheit ist halt ein _sehr_ starker Grund.

              Was damals jedoch sicher kein Grund war: Der Preis der Software. In einer Zeit, in der Software bei Aufrüstungen im Privaten zum absolut überwiegenden Teil eh kostenlos war... ;-) ... ich mein ja nur...

    1
    Von Antiquities am Fr, 30. November 2018 um 08:39 #

    was hat denn ein Microkernel damit zu tun?
    30 Jahre alter Hype als irrationaler Glaubensartikel?
    Aus fast allen Microkernels sind Hybrids geworden. Nicht Zufall!

1
Von Scipio am Do, 29. November 2018 um 18:01 #

Also vor dem Update eine Konvertierung auf BTRFS durchführen wäre ein möglicher Workaround ????

https://wiki.ubuntuusers.de/Konvertierung_nach_Btrfs/
https://www.tobias-bauer.de/konvertierung-ext4-zu-btrfs.html

  • 1
    Von Nicht unbedingt am Do, 29. November 2018 um 18:25 #

    Mir hat es vor kurzem mein Btrfs zerlegt.
    könnte von der Zeit her mit 4.19 passen.

    1
    Von Falk am Do, 29. November 2018 um 23:55 #

    Naja ...


    checking extents
    bad block 6012928
    Errors found in extent allocation tree or chunk allocation
    checking free space cache
    checking fs roots
    root 257 root dir 256 error
    root 257 inode 256 errors 200, dir isize wrong
    root 257 inode 623493 errors 2001, no inode item, link count wrong
    unresolved ref dir 623147 index 0 namelen 13 name l7x-lmri8.tfm filetype 1 errors 6, no dir index, no inode ref
    root 257 inode 623494 errors 2001, no inode item, link count wrong
    unresolved ref dir 623147 index 0 namelen 20 name texnansi-lmsso10.tfm filetype 1 errors 6, no dir index, no inode ref

    ... ca. 57000 Zeilen später ...

    Checking filesystem on /dev/nvme0n1p5
    UUID: ...
    cache and super generation don't match, space cache will be invalidated
    found 11782381568 bytes used err is 1
    total csum bytes: 0
    total tree bytes: 19611648
    total fs tree bytes: 16384
    total extent tree bytes: 19529728
    btree space waste bytes: 3839309
    file data blocks allocated: 6553600
    referenced 6553600


    ... hatte übrigens nichts für die 60GB-Partition fürs Betriebssystem genützt, die Partition wurde mit XFS formatiert (Edit2: natürlich danach) und das Logfile ist zugegebenermaßen schon etwa ca. 1,5 Jahre (Edit: nein - definitiv 18.3.2018) alt. Ich habe dazu übrigens auch noch einen schönen Screenshot. Erstellt mit der Kamera meines Tablets (Edit: da habe ich gerade nachgeschaut und die Timestamps stimmen überein. Mein Lenovo-Laptop sorgte jedoch vor dem Bios-Update auch für Probleme).

    Die Hardware läuft übrigens immer noch unverändert. Toitoitoi.

    Deshalb habe ich folgendes in meiner fstab stehen:
    UUID=... / xfs defaults 0 0
    UUID=... /home xfs defaults 0 0

    Zumindest bei der Home-Partition wäre ich vorsichtig.

    Dieser Beitrag wurde 4 mal editiert. Zuletzt am 30. Nov 2018 um 00:08.
    • 1
      Von klopskind am Fr, 30. November 2018 um 09:21 #

      Danke für den Einblick!

      Ein Frage hätt' ich dann noch:
      Wenn die Protokolleinträge vom 18.3.2018 stammen: Welche Version(en) von Kernel und btrfs-progs kamen zum Einsatz?

      4.19 kann es ja nicht sein, denn der wurde erst am 22.10. veröffentlicht bzw. am 26.08. gab's den ersten RC.

      • 1
        Von Falk am Fr, 30. November 2018 um 18:37 #

        ...
        BTRFS critical ... corrupt node, bad key order: ...
        BTRFS critical ... corrupt node, bad key order: ...
        BTRFS critical ... corrupt node, bad key order: ...
        BTRFS critical ... corrupt node, bad key order: ...
        ...
        Kernel panic - not syncing: Attempted to kill init! exitcode=0x00007f00.1: invalid ELF header

        CPU: 1 PID: 1 Comm: init Tainted: P DE 4.13.0-37-generic #42-Ubuntu
        Hardware name: LENOVO 20ES0004UK/20ES0004UK, BIOS N1DET90W (2.16) 07/12/2017
        ...

        ------
        Also Kernel 4.13.0-37-generic von Ubuntu

        Zu den btrfs-progs kann ich nichts mehr sagen. Sicher nicht die von Ubuntu. Steht komischerweise nicht in der Log-Datei. Normalerweise sollten solche Tools selbst mitteilen, ob sie kompatibel sind und Kerneltreiber ganz genauso, ob sie das Filesystem ansteuern können.

        Sorry - habe leider keinen Bugreport geschrieben (keine Zeit). Der Fehler kann bei mir auch daran gelegen haben, dass ich verschiedene Linux-Distributionen getestet habe.

1
Von ext4-Arschkartenbesitzer am Do, 29. November 2018 um 20:02 #

Kurz bevor das bei mir immer auftrat hagelte es im Log Meldungen dass SATA Kommandos fehl schlugen. Danach meckern dann immer mehr Layer die davon betroffen sind am Ende eben das ext4fs und es kracht.

Der Bug ist äussert nervig da er sich nicht reproduzieren lässt, der taucht wochenlang gar nicht auf, dann wieder alle paar Stunden hintereinander.

  • 1
    Von ext4-Arschkartenbesitzer am Do, 29. November 2018 um 20:06 #

    Achja und kein 4.19 sonderne ein 4.15er Kernel, wenn ich mich recht erinnere hatte ich diese Fehler auch schon mit älteren Kerneln nur damals ist das nicht so oft aufgetaucht und dachte es läge an defekter Hardware.

    Betroffen ist bei mir auch immer nur das bootlaufwerk und die systempartition die ext4 ist.
    Gebootet wird von einer ext2 partiton auf diesem Laufwerk die macht keine Probleme, andere Discs mit ext4 sind nicht betroffen.

    Andere glauben es läge an der swappartiton auf einer SSD, habe ich auch aber ob das Grund ist, keine Ahnung.

1
Von Janko Weber am Do, 29. November 2018 um 21:45 #

Der beliebteste Kernel ist 4.9 :oP


MfG Janko Weber

2
Von Anonymous am Do, 29. November 2018 um 21:48 #

Sorry; der musste einfach raus ;)

1
Von Falk am Fr, 30. November 2018 um 00:04 #

Gut zu wissen.

1
Von Ralph Miguel Fröhlich am Fr, 30. November 2018 um 05:23 #

Danke für die Nachricht/Warnung!

1
Von AlBert am Fr, 30. November 2018 um 08:12 #

schon längst zu spät für mich, ich habe Sparky Linux 4.19.5 drauf. allerdings habe ich auch keine wichtigen Daten auf dem System :)

1
Von Potz Blitz am Fr, 30. November 2018 um 09:20 #

Ich habe es zwar schon anderswo gelesen, aber nach dem Eindruck hier im Forum, ist es KEIN vernachlässigbares Problem. Hoffen wir, dass der Fehler schnell gefunden wird.

1
Von goowoo am Fr, 30. November 2018 um 10:06 #

Letzte Woche auf 4.19.2 geupdated, weil der 4.18 ein kaputtes DVB-Subsystem hatte. Jetzt lese ich diese Meldung und stelle fest das der Server sein Filesystem nur noch RO gemounted hat :?

Dieser Beitrag wurde 1 mal editiert. Zuletzt am 30. Nov 2018 um 10:09.
1
Von Richy's Bluescafr am Fr, 30. November 2018 um 11:56 #

Leider hat mich das Problem auch erwischt. In meinem Fall läßt sich der Fehler aber auch nicht mit der Rückkehr zum 18 beheben. . Keiner der installieren recoverie Kernel bis 15 behebt das Problem.

1
Von Katzennascher am Fr, 30. November 2018 um 12:23 #

Falls jemand mal fragt warum Leute "Stable" benutzen...

  • 1
    Von Manrek am Fr, 30. November 2018 um 13:23 #

    Ist 4.19 nicht sogar nur stable sondern auch LTS? ;)

    • 1
      Von Mantek am Fr, 30. November 2018 um 13:24 #

      Nachtrag: Hoffe natürlich, dass der Fehler (oder die Fehler) schnell gefunden werden und gefixt.
      Schätze alles über 4.19 (also 4.20 +) wird wohl auch dann irgendwie betroffen sein werden.

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung