opensuse15 Leap unter VirtualBox - nix geht mehr

Hinweis: In dem Thema opensuse15 Leap unter VirtualBox - nix geht mehr gibt es 20 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Ist BTRFS das richtige Filesystem für Heimanwender?


    eigentlich könnte ich einen neuen Thread dazu aufmachen, führe mal diesen hier fort.


    hab unter Btrfs-Mountoptionen › Wiki › ubuntuusers.de folgende Warnung gefunden:
    "Die nachfolgende Beschreibung basiert auf einer Kernelversion ab 3.0.0-xx, mit älteren Kernelversionen führen einige Mountoptionen zu Fehlern bis hin zum Einfrieren des Systems!"


    Meiner Meinung nach ist dies immer noch aktuell, was Leap15 betrifft und Kubuntu-18.04 was ich inzwischen auch installiert habe und von beiden versuche meine Daten von der 42er (mit btrfs) rüberzukopieren.

    • sobald ich die 42er Partition versuche zu mounten geht auf beiden Installationen Leap15, Kubuntu18.04 mehr oder weniger sofort die CPU Last auf 100%
    • ein btrfs check -p <partition> zuvor hat jeweils keine Fehler auf dieser angezeigt, somit sollte die ok sein
    • unter Kubuntu konnte ich noch auf die gemountete Partiton zugreifen, aber /home war leer, was ich gelernt habe, ich muss evtl erst die Subvolumes ermitteln um dieser direkt zu mounten
    • beim Versuch diese anzeigen zu lassen, was nur bei gemounteter Partition funktioniert habe ich wieder das Lastproblem und letztendlich input/output errors - nix geht mehr.
    • Alles noch eine Stufe komplizierter durch subvolumes unter btrfs als es bei einem Direktzugriff einer ext4 Partition möglich wäre

    Das Ganze tritt natürlich immer erst im Fehlerfall auf. Trotzdem bleibt für mich die Frage ob btrfs für einen Heimanwender so einen Gewinn darstellt.
    Kubuntu wählt defaultmäßig noch ext4. btrfs-tools müssen erst nachinstalliert werden.

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 121165 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • Du kannst deine Beobachtungen aber nicht mit einer realen Installation vergleichen......


    Denn dort wird auf die Hardware zugegriffen.......

    Für den Inhalt des Beitrages 121167 haftet ausdrücklich der jeweilige Autor: Sauerland

  • nein, nicht unbedingt, was das hochschnellen der CPU Last betrifft.


    Dass die Partitionen nicht mehr direkt mountbar/zugreifbar sondern nur über die subvolumes die man erst mal kennen/ermitteln muss sofern man nicht selbst dafür verantwortlich war besteht aber auch unter realer Hardware. Was es für einen Großteil der Heimanwender (unnötigerweise) verkomplizieren dürfte.

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 121169 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • Dass die Partitionen nicht mehr direkt mountbar/zugreifbar sondern nur über die subvolumes die man erst mal kennen/ermitteln muss sofern man nicht selbst dafür verantwortlich war besteht aber auch unter realer Hardware.

    Bei mir nicht......

    Für den Inhalt des Beitrages 121170 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Bei mir nicht......

    dann möchte ich mal vermuten bzw. präzisieren

    • du hast /home separat angelegt. Dann sollte Suse für / btrfs und für /home ext4 per default verwenden. Somit bestünde das Poblem für /home nicht
    • ich bin dazu übergegangen bei kleinen Platten und insb. dyn. wachsenden virtuellen Disks alles auf einer Partition anlegen zu lassen. Dann sollte alles btrfs sein, und /home scheinbar als subvolume angelegt sein, sonst wäre es jetzt nicht leer.
    • Leap15 sollte ich ähnlich eingerichtet haben, sofern das Vorgehen nicht geändert wurde könnte ich mich daran orientieren (?)

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 121172 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • 1. du hast /home separat angelegt. Dann sollte Suse für / btrfs und für /home ext4 per default verwenden. Somit bestünde das Poblem für /home nicht

    Normale und sinnvolle Vorgehensweise. Default ist allerdings für /home nicht ext4, sondern XFS.



    2. ich bin dazu übergegangen bei kleinen Platten und insb. dyn. wachsenden virtuellen Disks alles auf einer Partition anlegen zu lassen. Dann sollte alles btrfs sein, und /home scheinbar als subvolume angelegt sein, sonst wäre es jetzt nicht leer.

    Der erste Teil deiner Aussage: Warum auch nicht, ist ja sinnvoll.
    Den zweiten Teil ab "Dann sollte alles btrfs......" verstehe ich nicht.

    Für den Inhalt des Beitrages 121183 haftet ausdrücklich der jeweilige Autor: ThomasS

  • das ist ja mein Punkt, ich habe auf meinem Mac VirtualBox aktuell Version 5.2.12 am laufen (und damit seit kurzem Probleme)
    Ansonsten läuft VirtualBox schon seit Version4 o.früher auf diesem Rechner problemlos.

    um mal dein Problem von einer anderen Seite einzukreisen - vielleicht hat dein VB irgendwelche Installationsprobleme ..
    Hast du schon mal fertige VMs getestet?


    openSUSE images for VMware and VirtualBox

    There's no place like 127.0.0.1

    Für den Inhalt des Beitrages 121186 haftet ausdrücklich der jeweilige Autor: wurzel99

  • Hast du schon mal fertige VMs getestet?

    Hallo @wurzel99,


    mir fehlt etwas die Muse und Zeit dies auch noch durchzuführen.
    An sich würde ich alles bei mir als uneingeschränkt funktionsfähig beschreiben. Das war seit Jahren ohne Probleme der Fall.
    Die 13er läuft immer noch ohne Macken.
    Die 42er bootet seit Einspielen von patches nicht mehr, hängt ...
    (ältestes Filedatum im 42er VirtualBox-Verzeichnis ist von 19.Juni 2016, mind seit diesem Datum war die Installation ohne Probleme am Laufen)
    Die 15er läuft an sich auch problemlos, wesentlich träger als die anderen Releases, aber mit jedem Release ist ein Performanceverlust vebunden gewesen.
    von 13 -> 42 -> 15 jeweils höherer CPU Verbrauch und geringerer zur Verfügung stehende Leistung.
    Die Uuntu 18.04, wie Leap15 ...


    Leider, komischerweise verursacht erst das mounten der btrfs Partition einen CPU Anstieg auf 100% bei 15 und 18.04. siehe Beitrag 11 ff

    hab unter Btrfs-Mountoptionen › Wiki › ubuntuusers.de folgende Warnung gefunden:
    "Die nachfolgende Beschreibung basiert auf einer Kernelversion ab 3.0.0-xx, mit älteren Kernelversionen führen einige Mountoptionen zu Fehlern bis hin zum Einfrieren des Systems!"

    eine entsprechende Warnung gibt es für ältere Kernel. Trifft wohl aber exakt auch in meinem Fall zu.


    Ein einfacher btrfs fsck auf die nicht gemountete Partition läuft widerum problemlos und zeigt keine Fehler in dieser Partition an. Warum dann anschließend das mounten schief geht, wer weiß.
    m.Meinung nach müsste Linux/kernel/btrfs treiber noch gar nichts groß unternehmen solange ich nur mounte und noch nicht aktiv darauf zugreife. Aber wer weiß das schon in Zeiten von prediction und lookahead Funktionen ob hier nicht schon Vorauszugriffe stattfinden.


    Ich könnte jetzt fertige Suse, Ubuntu, Mint etc runterladen und durchtesten. Ich verspreche mir ehrlich gesagt dasselbe Verhalten die die letzten Versionen 15 und 18.04.


    ich suche eine andere Lösung / Idee. -->> 42er ans Laufen bekommen


    prinzipiell sind 15 und 18.04 nicht mehr interessant auf meiner Hardware und ich würde die auch sofort wieder Löschen wenn die 42er wieder am Laufen wäre X( . Sie dienen mir nur für einem Test, btrfs-fsck bzw. Zugriff auf meine Daten unter /home


    soweit.
    <X

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 121199 haftet ausdrücklich der jeweilige Autor: TuxSv748

  • Etwas totes ans laufen bringen.........

    prinzipiell ja, aber auch nein.


    btrfs check sagt: Partition ohne Fehler
    und es bootet bis ' a start job is running ...'
    und die Sekunden werden hochgezählt :P , von tot kann man da nicht sprechen ?(


    die Hoffnung stirbt zuletzt :smilie_pc_012: , solange ich noch nicht an meine /home Daten gekommen bin.

    honi soit qui mal y pense :: lärnt L.i.n.u.x zu buchstabieren

    Für den Inhalt des Beitrages 121201 haftet ausdrücklich der jeweilige Autor: TuxSv748