Beiträge von TuxSv748

hab ich da in der Vergangenheit was verpasst oder warum ignoriert chip.de openSuse so vollkommen - ist schon länger auffällig.
Kann mir nicht vorstellen das 10 z.T. Randdistributionen beliebter als openSuse sind.

Microsoft kauft GitHub für 7,5 Milliarden US-Dollar |
heise online

Zitat von Sauerland

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 , von tot kann man da nicht sprechen

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

Zitat von 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

Zitat von TuxSv748

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 . Sie dienen mir nur für einem Test, btrfs-fsck bzw. Zugriff auf meine Daten unter /home

soweit.

ich bevorzuge, wenn verfügbar, immer die Variante per USB-A Adapter -> SATA /M.2 o.ä
prinzipiell sollte es auch mit einem normalen Datenkabel funktionieren, wenn dieses dann an ein USB Ladegerät statt eines PCs angeschlossen wird (?)

Dürfte einerseits schwierig sein,da Datenkabel für SATA oder M2 fertig konfektioniert, abgeschirmt sind. Mir ist da jetzt nichts bekannt um eine SSD nur mit Strom zu versorgen. Ausser bei Handys, wo sich die Hersteller die Datenkabel gespart haben.

btw. fällt mir ein damit "PortaPow" könnte es funktionieren via USB. Wird gerne eingesetzt um Smartphones am FimenPC aufzuladen ohne dass der PC eine Datenverbindung aufbaut, weil diese durch den Adapter getrennt wird.

wird noch ähnliche andere Hersteller geben

Zitat von 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 (?)

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.

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.

Zitat von Sauerland

Tut mir leid, aber bei Mac und Virtualbox bin ich raus.

denke auch dass ich damit etwas einsam bin.

Da alles Andere ohne Proleme lief und läuft, OSX und VirtualBox nicht geupdated wurden und nur unter 42 ein 'zypper patch' durchgeführt wurde bevor die Probleme auftraten gehe ich zunächst von einem Einfluß davon aus.
Leap15 ist neu - neuer Code neue Probleme - vielleicht?

werd jetzt mit Ubuntu testen wie sich das verhält.

btw:
hab gerade mein Ubuntu auf dem Rechner gebootet, ist ubuntu 12 und ich musste erst mal die VBoxGuest von 4.2.6 auf 5.2.12 updaten.
das zeigt:
- schon lange nichts mehr mit ubuntu gemacht und
- schon lange mit VirtualBox am werkeln.