Beiträge von MustermannE

    Hier der aktuelle Geforce 440.40 von der Nvidia-Downlaod-Seite. Die Compilierung geht schon nicht, weil irgendwelche ~.h nicht vorhanden sind. Insgesamt ist gefühlt eine dreistellige Anzahl errors im Logfile.


    Frage: ist es sinnvoll, das zu diesem Zeitpunkt schon irgendwo zu melden (wenn ja wo?) oder wird sich da erfahrungsgemäß schon jemand drum kümmern?

    Und nochmal: Deine Software ist zu alt.
    Daraus zu folgern, dass openSUSE einen Bug habe,
    ist ähnlich sinnvoll, wie Mercedes anzuklagen, weil es beim Automatik Getriebe keinen Ganghebel gibt,
    wo doch der eigene Ford Model T einen hat.

    Nett, dass ihr mich auf meinen eigenen Bugreport aufmerksam macht ... :)
    Und zu alt ist eine eigenwillige Interpretation, ich sehe das anders.


    Einen Bug hatte ich doch nicht unterstellt, aber meine Vermutung, dass sich ab Leap 15 etwas änderte, hat sich doch vollumfänglich bestätigt:


    Ab Leap 15 wird ein ext4-fs vom Yast-Partinioner stets als 64-Bit-System angelegt.
    Bis Leap 42.3 geschah das nur, wenn es auch erforderlich war:


    /etc/mke2fs.conf in der ext4 subsection steht bei Leap 42.3 noch
    auto_64-bit_support = 1


    In Leap 15 steht da etwas mit ...,64bBit,...
    Das kann man mit ...,^64Bit,... abschalten. Das habe ich mal gemacht und den Yast-Partinioner erneut bemüht.
    Und es funktioniert, prompt hat Paragon-FM15 das Problem nicht mehr. Prompt ist meine Software nicht mehr zu alt.


    Und - btw - laut manpages zu mke2fs.conf kann man auch da mit # etwas auskommentieren ...


    Hier einfach "mit deine Software ist zu alt" alles abzubügeln, finde ich weder hilfreich, noch angemessen.
    So wie Felix Miata geholfen hat, so ist es hilfreich gewesen.
    Und - btw - ich fahre einen Mercedes mit Automatik-Getriebe und da hat es sogar mehrere Ganghebel :P drei um genau zu sein und die sind alle am Lenkrad.


    Die Vorgehensweise bis Leap 42.3 erscheint mir sinnvoller, wann sollte denn ein /-System in 64-Bit-Ausprägung je nötig sein oder Vorteile bringen?
    Wo sollen da je soviele Blöcke erforderlich werden?
    Zu unseren Lebzeiten wohl kaum. Für spezielle Datensysteme kann das zutreffen.
    Felix Miata sieht das ebenso: "For compatibility reasons, I have no / partitions using the 64bit option, and few others."


    Ich werde aber Paragon sicherheitshalber auf den Umstand 32-Bit/64-Bit bei ext4 hinweisen. Vielleicht bewirkt das ja etwas.
    Den Thread setze ich auf erledigt.

    Dann mach bei Paragon nen Bugreport auf.

    Ich denke aber, das Problem liegt bei openSUSE, nicht bei Paragon. Soeben habe ich GParted (0.31.0-lp150.1.2) aus dem Leap-Repository installiert und damit ein ext4-fs erzeugt. Und siehe da, das wird vom Paragon-Tool auch richtig erkannt. Zustand, Füllungsgrad, Partitionsgrenzen, alles i. O.


    Das Problem taucht ausschließlich im Umgang mit dem Leap15-Partitionierer auf. Da ist m. E. openSUSE als erster Ansprechpartner zuständig.

    Ich hatte schon mehrfach geschrieben: Ist deine Wahl.
    Dass ich den gnadenlosen Geschwindigkeitsvorteil weder glaube, noch für nötig halte, sei mir aber bitte doch auch unbenommen.


    Außerdem würde ich einer Backup/ISO - Restore Lösung, die keine normale Linux- Formatierung erkennt, niemals trauen.
    Für den Ernstfall schon gar nicht.

    Etwas nicht für nötig halten, ist eine Sache. Einem nicht zu glauben eine andere. Ich bin gerne bereit, es live zu demonstrieren ... eine Flasche Wein ist immer im Keller ... Den Ernstfall habe ich mehrfach erprobt und überwunden.


    Und bis vor 2 Wochen unter Leap 42.3 gab es dieses Problem nicht. Und bei allen anderen Vorgänger-Versionen bis zur 13.2 garantiert auch nicht. Es ist erst mit Leap 15 aufgetaucht. Mit dem 4.12er Kernel und bevor das jüngst in den Medien beschrieben ext4-Problem diskutiert wurde (ich habe eine Weile Leap 15 und Leap 42.3 parallel vorgrhalten). Mit den Patches dazu kann es also auch nicht zu tun haben.


    Ich gehe inzwischen davon aus, dass irgendein Verwaltungsbit/Statusbyte/bisher unbenutztes Bit/Byte einen Zustand bekommen hat, den es so bislang nicht gab oder so nicht benutzt wurde und deshalb zu einer falschen Interpretation führt. Sogar diesen Zustand kann ich sichern, ich muss in den Einstellungen dann vorgeben, jeden Sektor ins Image aufzunehmen. Ja, habe ich ausprobiert, klappt. Auch der Restore klappt. Dauert dann halt 5-6 Minuten.


    Am 3.7-Kernel des Bootsticks liegt es auch nicht, das habe ich inzwischen herausgefunden, in dem ich dafür den aktuellen 4.19er der openSUSE unterjubelte, was zu meiner Verblüffung sogar ganz gut klappte. Auch dann wird ein ext4-FS des Leap-15-Partionierer als unformatiert angesehen.

    Ich weiß nicht, was du da machst, aber 1,5 Minuten um eine ganze Partition zu klonen?
    Mag möglich sein, wenn die nicht größer als ein paar MB ist.

    Das ist kein klonen. es werden nur die belegten Sektoren im Imagefile hinterlegt. TrueImage, Paragon und alle anderen Anbieter von Idiesen Backup&Restore-Tools machen dasselbe.


    def -h
    liefert u. a. das hier:
    /dev/sda2 59G 11G 46G 19% /


    Das ist schon etwas mehr als ein paar MB. Quell- und Zielmedium sind zwei SSD.
    Und was die Ausführungs-Zeiten in beiden Richtungen angeht: btdtgt
    Ich kann nicht nachvollziehen, wieso meine Angaben hier derart angezweifelt werden, ich habe mir die nicht ausgedacht!


    Und da ich - wie beschrieben - damit offline sichere, ist da kein Hintergrund, in dem etwas läuft. Insofern ist Schnelligkeit durchaus ein Thema. Dafür kann ich einen Systemstand aber auch blitzschnell restaurieren. Ganz ohne überhaupt ein System zu haben, dass ich booten muss. Wie restaurierst du ein System, das irgendwie online gesichert wurde, das sich aber nicht mehr booten lässt? Dann musst du ein anderes System (ein Live-System?) booten und das Dateisystem wieder neu aufbauen. Sicher, kann man machen.


    Aber ein Image zu laden geht deutlich fixer, besonders, wenn an mal etwas ausprobieren will und das evtl. mehrmal tun muss. Und ich kann so ein Image-Archiv einfach zusätzlich auf externe Datenträger vervielfältigen (wo ich eine Kopie von /home habe), die ich bequem auswärts aufbewahren kann, z. N. im Bankschließfach oder der Zweitwohnung. Damit bin ich auch für den worst case ziemlich gut vorbereitet.


    In alten Windows-Tagen habe ich auch die Datenlaufwerke stets so in Images gesichert, da geht das ohnehin schon immer online und im Hintergrund. Seitdem ich so verfahre (15 Jahre?), hatte ich nie einen Datenverlust zu beklagen. Bei rdiff-backup hingegen kommt es gelegentlich schon zu Unpässlichkeiten, vielleicht weil der Rechner ausfiel während eines Sicherungslaufes. Darum mache ich das alle 20 Minuten auf je einer anderen Platte nebenbei. Hin und wieder zur Sicherheit als Image wieder offline mit dem FM15. Das läuft dann für


    /dev/sdc1 443G 229G 214G 52% /home


    in ca. 20 Minuten durch, da ist das Ziel dann keine SSD. Das Ergebnis davon könnte auch inkrementell ergänzt werden, aber das praktiziere ich derzeit nicht.