Beiträge von letsfindaway

    ok, und da finde ich u.a.:

    Code
    Mon 2018-06-25 00:00:00 CEST  6 days left         Mon 2018-06-18 07:24:02 CEST  13h ago            btrfs-balance.timer          btrfs-balance.service
    Mon 2018-06-25 00:00:00 CEST  6 days left         Mon 2018-06-18 07:24:02 CEST  13h ago            btrfs-trim.timer             btrfs-trim.service
    Mon 2018-06-25 00:00:00 CEST  6 days left         Mon 2018-06-18 07:24:02 CEST  13h ago            fstrim.timer                 fstrim.service

    d.h. in einer Woche erwartet mich - was? Wieder eine knappe halbe Stunde? Das wäre echt der Killer für btrfs, denn das ist in der Praxis für mich untragbar. Wie sind eure Erfahrungen mit dem Balancing?

    Hallo,


    heute nach dem Booten war der Rechner nahezu unbrauchbar. Ich habe es immerhin noch geschafft, eine Konsole aufzumachen und top zeigte abwechselnd btrfs-balance und btrfs-transaction mit 100% CPU Last. Das ging etwa 20 Minuten so. Dann hat sich alles wieder beruhigt und nun startet das System wieder wie zuvor.


    Ich habe ein Leap 15.0 installiert, das per Upgrade von 42.3 entstanden ist. Bisher habe ich sowas noch nicht beobachtet.


    Muss ich das mit btrfs öfters erwarten oder ist das ein einmaliger Ausrutscher? Was macht denn btrfs-balance und wann wird es warum gestartet?


    Und um schon mal weiterzudenken: Macht es Sinn, einen Umstieg auf ein anderes Filesystem in Betracht zu ziehen?


    Danke!

    Noch ein Hinweis: Für die Installation würde ich in der Tat auf PlayOnLinux zurückgreifen, wie das wurzel99 auch schon vorgeschlagen hatte. Ich hab das mit Office 2010 erfolgreich hinbekommen. Ein Fallstrick lauert dann hinterher: die Aktivierung. Schau dir mal diesen Post an, wo dann auf diese Microsoft-Seite verwiesen wird. Dort wird erläutert, wie man eine telefonische Aktivierung für so alte Produkte hinbekommt. Für Office 2010 hat es so geklappt!


    Und: PlayOnLinux bietet beim Installieren die Auswahl: CD Verzeichnis angeben oder Pfad zur setup.exe. Bei mir hat nur das zweite funktioniert, also die setup.exe.



    Viel Erfolg!

    und noch eine Ergänzung: Heute war plymouth einfach wieder da, und damit auch der Hänger. Wahrscheinlich durch ein Update installiert, ich weiß es nicht.


    Ich habe jetzt nicht nur plymouth und das davon abhängende plymouth-dracut deinstalliert, sondern auch noch blog-plymout installiert, das wohl als "Ersatz" dient und Logmeldungen erfasst, und außerdem mit plymouth selbst in Konflikt steht. Damit hoffe ich, dass mir kein Update mehr ungefragt wieder plymouth auf meinem System installiert.

    Ich habe heute die Zeit genutzt und weiter recherchiert. Hier drei Links zu der Thematik:


    https://bugs.archlinux.org/task/48069
    https://bbs.archlinux.org/viewtopic.php?id=208514
    https://bugzilla.opensuse.org/show_bug.cgi?id=968930


    Für den der das nicht lesen will und weil ich die Story so nett finde, hier eine Erklärung der einfachen Art.


    Nicht nur ich, auch andere hatten diese "Erscheinung". Eine Anfrage bei den Entwicklern der Geräteverwaltung ergab: "Liegt nicht an uns, wir kriegen die Info so von udev".


    udev ist u.a. für die Erkennung von neu angesteckten Geräten zuständig. Und udev meldet die Platte als "removable". Eine Anfrage bei den Entwicklern auch hier: "Liegt nicht an uns, wie kriegen die Info so vom Kernel".


    Und in der Tat, das Problem trat wohl erst mit Kernel Version 4.4.1 auf. Also Fehlermeldung an die Kernelentwickler. Doch da hieß es: "Kein Bug, ein Feature! Endlich reichen wir die Info vom BIOS weiter, dass es sich um ein HotPlug Gerät handelt"


    So, jetzt sind wir ganz unten angelangt. Es gibt BIOSse, da kann man die HotPlug Funktionalität eines SATA Anschlusses ein- und ausschalten, bei meinem nicht.


    Aber man kann auch auf der udev-Ebene eingreifen: Dazu verweise ich aber wieder auf https://bbs.archlinux.org/viewtopic.php?id=208514. Dort den untersten Beitrag anschauen. Gemäß dieses Tipps habe ich bei mir auch eine neue Datei

    Code: /etc/udev/rules.d/62-internal-disk.rules
    KERNEL=="sde*",ENV{UDISKS_IGNORE}="1"


    angelegt. Und voila! Die Einträge sind weg! Die Partitionen werden jetzt auch nicht mehr als extra Geräte in Dolphin gelistet, was auch Unsinn war, weil sie ja / und /home entsprechen.


    Quintessenz: Das Problem liegt nicht immer da, wo es aufscheint. Und man löst es nicht immer dort, wo es herkommt.

    Hallo zusammen,


    ich habe mein System auf einer SSD installiert. Wie bei der Installation vorgeschlagen ist diese in zwei Partitionen aufgeteilt, die mit btrfs bzw. xfs fromatiert sind. Beide Partitionen werden mir auf der KDE Oberfläche als Wechseldatenträger angezeigt - inklusive der Option diese auszuwerfen. Das möchte ich in beiden Fällen definitiv nicht tun! Hier ein Screenshot dazu:

    Auch Dolphin zeigt diese Laufwerke als Wechselmedium an.


    Ich empfinde das zumindest als verwirrend und besonders wenn ich wirklich mal einen angesteckten USB Stick auswerfen will habe ich immer die Befürchtung, versehentlich auf den falschen Knopf zu drücken. Keine Ahnung was passiert, ich habs noch nicht probiert. Aber unabhängig davon hätte ich diese beiden Partitionen gerne nicht hier aufgeführt.


    Kann man dem System irgendwo sagen, dass ich dieses Laufwerk mit vier Schrauben fest verankert habe und es nicht so einfach wechseln möchte?


    Danke für Tipps!

    Ergänzung 2:


    Das wichtigste Tool, um die Ursache für das langsame Booten zu finden, war folgendes Kommando:

    Bash
    sudo systemd-analyze plot > startup.svg

    Die Ausgabedatei dann z.B. von Dolphin auf den geöffneten Firefox schieben. Die angezeigte Grafik zeigt ganz genau, wie der Boot-Vorgang abläuft und wer wofür wie viel Zeit braucht. Da war sowohl plymouth als auch wicked.service zu finden. Und zusammen mit den Tipps von Sauerland und dem Link aus meinem oben stehenden Beitrag waren die Probleme dann zu beheben.


    Ich bin noch systemd-Neuling und habe bisher nur mit inid System gearbeitet, aber so langsam weiß ich die Tools von systemd zu schätzen. Man muss sie nur finden!

    Ergänzung:


    ich hab IPv6 nun doch disabled, das macht das Booten noch mal deutlich schneller. Das Verhalten meines Rechners ist da wie in https://github.com/openSUSE/wicked/issues/681 beschrieben. Ich hänge über einen Switch an einer FritzBox. Also in Summe nun zwei Maßnahmen:


    • Plymouth deinstallieren, da es hängengeblieben ist
    • IPv6 disablen, weil wicked vermutlich auf eine IPv6 Adresse wartet und da erst mal der Timeout ablaufen muss