Beiträge von Antarctris

    Ich lege dafür nicht meine Hand ins Feuer, da ich es selbst noch nicht testen konnte. In den meisten Foren und ihren Threads ist zu lesen, dass man mit Xonar-Karten am besten fährt. Ich hab selbst vor mich bald (nach viel zu langer Zeit..) von meinem Onboard-Sound zu verabschieden, deshalb habe ich in den letzten Wochen schon des öfteren mal nach geeigneten Kandidaten geschaut. Bei mir wird es definitiv eine Xonar.


    Wo die Meinungen halt stark auseinander gehen ist die Soundqualität der einzelnen Karten im Vergleich. Also wie gut die Xonar DGX im Vergleich zu deiner SoundblasterZ sein wird, kann dir wahrscheinlich keiner sagen. Wir hoffen mal das beste.

    Ich habe meine eigene Cloud auf nem Raspberry. Da habe ich mehr vertrauen als bei öffnetlichen Cloud Diensten.


    Da das hier aber ein wenig viel Aufwand wäre, schließe ich mich der ssh/scp-Empfehlung an.
    Für den Fall dass die Verbindung instabil sein sollte und möglicherweise abbricht bin ich allerdings mehr Freund von rsync.

    Update:


    Ein Kommilitone hat mich eben in der Uni darauf hingewiesen, dass LC_IDENTIFICATION=en_GB.UTF-8,LANG=en_GB.UTF-8 so nicht gesetzt sein darf. Ich habe auch keine Ahnung woher das kommt. Weiterhin ist es möglich, dass bei LANG und LC_CTYPE versteckte Leerzeichen oder ähnliches am Ende stehen, da dort keine Anführungszeichen zu finden sind. In meinem Fall war es aber nur LC_IDENTIFICATION


    Ein einfacher Test mit export auf en_GB.UTF-8 gesetzt habe, hat das ganze bestätigt.


    Somit bleibt jetzt noch die Frage, wo der seltsame Wert LC_IDENTIFICATION=en_GB.UTF-8,LANG=en_GB.UTF-8 hergekommen ist. Über die Konsole habe ich ihn jedenfalls nicht eingegeben und schätze, dass er aus einem der grafischen Tools, bzw. deren Backends kommen muss.

    Hey Leute,


    mein System hat sich an verschiedensten Stellen beschwert, dass die Spracheinstellungen nicht richtig sind. An und für sich funktioniert meistens alles, Ausnahmen sind z.B. Amarok, aber das hatten wir in einem anderen Thema ist hier nicht von Belang. Im Folgenden habe ich eine kleine Testreihe mit export-Befehlen gemacht, um euch zu zeigen, was ich herausfinden konnte. Wir alle wissen, dass diese Änderungen also nicht permanent sind, wir wissen genauso gut, dass wir die Änderungen mit z.B. localectl permanent machen könnten. Aber darum geht es mir hier nicht, wie ihr sehen werdet.
    Ich teile die Testreihe in 3 Abschnitte ein. Ich rufe beispielhaft immer Firefox und Man auf, da ich von diesen sicher weiß, dass sie sich beschweren, wenn die Spracheinstellungen nicht richtig erkannt werden.


    1. Default, so wie das System installiert wurde (en_GB bei Installation ausgewählt und gewünscht), hier führe ich auch einmalig locale -a aus mit Filter für die englischen Auswahlmöglichkeiten.


    2. Nachdem ich LC_ALL mit derselben Lokale "en_GB.UTF-8" überschreibe, die für alle anderen gesetzt war:

    Wie zu sehen ist beschweren sich plötzlich weder Firefox noch Man, allerdings kann LC_ALL wohl kaum die richtige Lösung des Problems sein, da es individuelle Konfigurationen von allen anderen LC_*-Variablen zunichte macht.



    3. Mir viel auf, dass in der Ausgabe von locale -a alle UTF-Endungen klein geschrieben waren und nicht groß, wie in den LC_*-Variablen und LANG. Also habe ich das ganze mal mit kleinem utf-8 probiert:

    Und wie man sieht: Firefox und Man finden die Spracheinstellungen.


    Nach unset LC_ALL habe ich übrigens nochmal überprüft: Es hat alle anderen Variablen wieder zurückgesetzt, so wie sie in (1) waren.


    Also mit LC_ALL ist es wohl in Ordnung, wenn das UTF-8 groß geschrieben ist. Andernfalls muss ich die Endungen klein schreiben, damit alles ohne Fehlermeldungen funktioniert. Ich hab zwischendurch noch ein wenig Belesung im opensuse.org Forum betrieben, in diesem Thread war es scheinbar egal, ob die Endungen für UTF-8 in den Variablen groß geschrieben waren. Auch dort waren die Endungen der locale -a-Ausgabe klein. Das widerspricht der Beobachtung auf meinem System und führt mich zur Frage:


    Gibt es irgendwo eine Konfiguration, die das ganze auf "Ignore-Case" setzt, habe ich hier einen Bug gefunden oder ist dieses Verhalten gewollt? Linux ist ja im großen und ganzen Case-Sensitiv...


    Auch wenn es wohl offensichtlich ist, möchte ich es nochmal erwähnen: Das Verhalten ist auf meinem System jederzeit 100% reproduzierbar.


    Falls es ein Bug ist, würde mich auch interessieren an wen der adressiert werden sollte, da ich mir nicht sicher bin ob das z.B. ein openSUSE-spezifisches oder eher ein glibc-locale Problem ist, damit ich ihn an die richtige Stelle melden kann.


    lg.
    Antarctris

    Bevor ich zu dem rm-Befehl gegriffen habe, habe ich mit Hilfe von snapper gelöscht. Der snapshot 18 konnte aber nicht von snapper gelöscht werden, weswegen ich dann zu drastischen Maßnahmen gegriffen habe...


    Die man-Pages von snapper beantworten meine Frage quasi mit Ja. Also dass die Snapshots einfach nur verlinkt werden. Dass solch ein Snapshot nicht gelöscht werden kann, wird nicht erwähnt, aber davon sollte man dann wohl implizit ausgehen. In den man-Pages von btrfs-subvolume konnte ich das bestätigt finden, wobei man auch hier selbst drauf kommen muss, dass man ein entsprechendes Default-Subvolume nicht löschen kann.


    Ich werde mich nochmal mehr in die Manuals einlesen. Falls ich dazu weiter nichts finde, werde ich mich an die Entwickler wenden und vorschlagen, das explizit im Manual zu erwähnen.


    Danke soweit, ich wäre dann hier fertig :whistling:

    Noch kann man das auch mit der SuseFirewall in Yast machen, bei Tumbleweed funktioniert es mit Yast (momentan glaub ich) nicht, dort ist von SuseFirewall auf firewalld umgestellt worden.

    Ich hab hier eine nette Mail gefunden, die den Zustand beschreibt:
    https://lists.opensuse.org/ope…ory/2018-01/msg00464.html


    Und aktuell sind Suse-Firewall und firewalld nebeneinander installiert. Die Suse-Firewall bleibt allerdings aktiv, solange man nicht mit systemctl manuell auf firewalld umstellt. Yast ruft jedefalls schon firewall-config X auf, weswegen man die Suse-Firewall nicht mehr mit Yast konfigurieren kann (In Tumbleweed).

    Ich werde nicht versuchen den Fehler mit dem neu aufgesetzten System zu rekonstruieren, Für eine weitere Neuinstallation habe ich keine Zeit.


    Was ich aber sagen kann: Der Snapshot, der sich nicht löschen ließ hatte die Nummer 18. Und ich hab mit folgendem Befehl versucht ihn manuell zu löschen:


    rm -rf /.snapshots/18


    Da aber btrfs scheinbar durch den rollback "/" auf "/.snapshots/18" verlinkt hatte habe ich damit quasi rm -rf / ausgeführt. Es blieben nur ein paar wenige Dateien übrig, die in Verwendung waren.


    Damit hatte ich nicht gerechnet, ich hätte eher gedacht, dass die Änderungen eines Rollbacks direkt in "/" geschrieben werden und nicht, dass btrfs das nur intern verlinkt.
    Meine Frage dazu ist, ob das wirklich so gewollt ist, da man nach einem Rollback dann einen Snapshot hat, den man nicht löschen kann. Und was passiert dabei mit dem Original-"/"-Volume? Ist das dann nur noch ein Link?

    Hello again,


    Als ich heute updaten wollte, sagte mir zypper, dass ich keinen Speicherplatz mehr in / habe. Da es nu 50GB hat, kann das mit btfs und snapshots durchaus mal vorkommen. Also fange ich an und lösche einige subvolumes. Bis mir eines begegnet, dass sich nicht löschen lässt. Als root mit dem Gedanken "Nicht mit mir" renne ich in ./snapshots und lasse rm -rf über den snapshot laufen um im nächsten Moment festzustellen, dass beinahe mein komplettes System gelöscht habe. Ich gebe zu - Like a DAU.


    Zu diesem Snapshot habe ich vor 4 Wochen einen Rollback gemacht, nachdem ich am nvidia-Grafiktreiber gescheitert bin, einen komplett schwarzen Bildschirm hatte und meine Tastaturbeleuchtung passend dazu energisch blinkte. (Danach habe ich es mit Hilfe von, BIOS, iGPU und Monitor umstecken geschafft den Treiber doch zu installieren und danach lief er super.)


    Nach notwendiger kompletter Neuinstallation habe ich rausgefunden, was da los ist: System Recovery and Snapshotmanagement with Snapper
    Also nach dem Rollback wird das Snapshot zum neuen default-Subvolume von btrfs Gemacht. Ok, das wusste ich nicht.


    Aber heißt das, dass sobald man ein Rollback macht, es immer einen Snapshot geben wird, der sich nicht löschen lässt und zwecks "Alterung" immer größer wird? :huh:


    Ich hatte mir meinen Sonntag echt etwas anders vorgestellt :pinch: