Beiträge von Vienna

    Anschließende Größenmanipulation von xfs über gparted ist eingeschränkt. - man sollte bei ext4 bleiben.

    Eingeschränkt ja, sofern man xfs-Partitionen nachträglich verkleinern möchte. Vergrößern einer Partition ist überhaupt kein Problem und das dürfte mit einiger Sicherheit der häufigere Anwendungsfall sein...

    Eine eigene Partition für home wäre sicher nicht verkehrt. ;)
    Ext4, Btrfs und xfs wären sicher geeignete Dateisysteme, ich für meinen Teil setze seit geraumer Zeit auf xfs.


    Bezugnehmend auf den Artikel würde ich von der Discard-option in der fstab eher Abstand nehmen, das kommt mit einigen Nachteilen des Weges. "Noatime" hingegen halte ich persönlich für eine gute Idee. Die Auslagerung von /tmp in den Arbeitsspeicher macht ebenfalls Sinn. Arbeitsspeicher steht auf moderneren Systemen meist mehr als ausreichend zur Verfügung und damit lassen sich die Schreibzugriffe auf die SDD erheblich verringern. Mittlerweile bietet auch systemd ein Modul das sich um SSD's kümmert:


    Code
    ● fstrim.timer - Discard unused blocks once a week   Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)   Active: active (waiting) since Sam 2016-12-17 08:55:12 CET; 1h 16min ago     Docs: man:fstrim

    Dies wird einmal in der Woche automatisch aktiv ohne dass sich der Anwender um etwas kümmern muss. Einfach mit "systemctl enable fstrim.timer" aktivieren.

    So, nach einigen Wochen bin ich in dieser Angelegenheit ein wenig schlauer geworden...


    Die mehrfach gestarteten Conky-Instanzen unter Xfce kommen dadurch zustande wenn man beim Herunterfahren beim Xfce-Logout "Sitzung für weitere Anmeldungen speichern" aktiviert. Einmaliges aktivieren reicht (um zm Beispiel Thunar automatisch nach dem Einloggen geöffnet zu haben oder was auch immer sonst). Dabei wird eine session-datei unter /home/user/.cache/xfce4/ angelegt. Das scheint soweit kein Problem zu sein, aus irgendeinem Grund (eventuell bug) bringt es aber Conky aus dem Tritt und es werden danach mind. 2 oder auch mehrere Instanzen gleichzeitig gestartet.


    Abhilfe: Die angelegt Datei unter .cache/xfce4 löschen und dann startet Conky verlässlich reproduzierbar immer nur eine Instanz. In Verbindung mit Conky also am besten die Sitzung speichern-Option nicht verwenden, da beißt sich was ;)


    Vielleicht ist ja jemandem eine Hilfe - Problem gelöst!

    Hallo,


    habe nochmals etwas genauer hingesehen und bei mir ist Leap 42.1 installiert. Der richtige Ort für den Logitech-Treiber sollte /lib/modules/4.1.27-27-default/kernel/drivers/hid/ sein. Der Kernel ist bei der Rolling release-Variante natürlich um einiges aktueller. Aber selbst unter 42.1 finden sich bereits folgende Logitech-Module ohne weiteres zutun bei mir im entsprechenden Verzeichnis:



    hid-logitech-dj.ko
    hid-logitech-hidpp.ko
    hid-logitech.ko


    Den Treiber manuell zu installieren bringt also nichts, der ist ohnehin schon im System vorhanden. Hätte da genauer nachsehen sollen, sorry für die unnötigen Umstände. Das mit der sich ändernden Tastenbelegung klingt seltsam, aber ich kann mich dunkel daran erinnern als ich noch die 705 von Logitech hatte (kein Ruhmesblatt für den Hersteller sofern sich dieser noch Qualität auf die Fahnen schreibt), da gab es eine spezielle Windows-Software dazu mit der man das Timing der Tasten usw. ganz präzise anpassen und einstellen konnte. Vermute mal das da Rückmeldungen der Maus unter Linux vielleicht "zweideutig" oder ähnlich interpretiert werden. Da wird wohl nur schwer Abhilfe zu schaffen sein, die Maus scheint zwar mittlerweile mit den wichtigsten Funktionen unter Linux zu funkionieren, aber eben leider nicht vollends zufriedenstellend. Von Logitech selbst wird in Bezug auf Linux in diesem Falle wahrscheinlich nicht viel zu erwarten sein...


    Wenn die "Bastelei" mit der xbindkeys-config ein besseres Ergebnis als die bereits bestehenden ergeben sollte, so wäre es sehr nett wenn die xbindkeysrc hier zur Verfügung gestellt werden könnte. Das kann anderen und zukünftigen Besitzern dieser Hardware eine große Hilfe sein, denn eine einfach umsetzbare Lösung die ohne Einschränkungen gut funktioniert scheint es bislang leider noch nicht zu geben.

    Kein Problem, fragen kost ja nichts ;)


    Kurios, nachdem diese spezielle und auf Win8 zugeschnittene Maus schon bei der 13.2 out of the box funktioniert hat sollte es unter dem Rolling-Release erst recht kein Problem darstellen. Laut dem Wiki für Archlinux ist das entsprechende Kernelmodul seit Kernel 4.2 offizieller bestandteil des Kernels.


    Ja, die xbindkeysrc ist für jeden Nutzer anzulegen, eine globale Konfiguration ist meines bescheidenen Wissens nach nicht möglich. Der Aufbau der Datei ist eigentlich recht simpel. Zum Beispiel:

    Code
    "chromium" 
      Super + c


    startet die Tastenkombinaton der Win-Taste auf der linken Seite (Super) und die gleichzeitige Betätigung von "c" den Chromium-Browser. Die erste Zeile enthält den auszuführenden Befehl, dieser ist in Anführungszeichen zu setzen. Die zweite Zeile legt die Tastenkombination fest. Bei den größeren/komfortableren Desktopumgebungen gibt es natürlich bequemere Wege Tastenkürzel für Anwendungen zu definieren. Bei einfacheren Windowmanagern aber kommt man auch heute um xbindkeys nicht herum. Bei der problematischen Maus ist die Vorgehensweise diesselbe:


    1. auszuführende Aktion
    2. zugewiesene Maustaste


    Ein "xev | grep" sollte bei einem darauffolgenden Klick mit der entsprechenden Maustaste den zugewiesenen Button ausweisen. "Button 4" kommt dann z.B. als b:4 in die zweite Zeile. Das ist die leichtere Übung, in der Zeile 1 ist nun die auszuführende Aktion nach dem Mausklick zu definieren und das ist der etwas mühsamere Teil. Mangels Hardware kann ich es nicht testen, aber im deutschen Arch-Forum hat ein User dankenswerterweise eine xbindkeysrc-konfiguration zur Verfügung gestellt:




    https://bbs.archlinux.de/viewtopic.php?id=29262


    Damit würde ich den Anfang machen, das sollte den Einstieg erleichtern und die alles wie gewünscht funktioniert xbindkeys noch in den Autostart und der Fall ist abgeschlossen.


    Hier gibt es auch noch einen Beta-Treiber für die M56: https://github.com/kreijack/logitech-m560


    Zip runterladen und enpacken oder git + GCC bei Bedarf installieren und dann


    1. git clone GitHub - kreijack/logitech-m560
    2. in den logitech-m560 ordner wechseln und dort ein Terminal öffnen
    3. make ausführen (dauert nur wenige Sekunden)
    4.mit "sudo rmmod hid_logitech_hidpp" bestehendes Modul entladn
    5 mit "sudo insmod hid-logitech-hidpp.ko" neues Modul laden


    Insgesamt kann ich mich aber des Eindrucks nicht erwehren das es einen "weniger steinigen Weg" geben muss, zumal die Maus ja ohne weiteres Zutun bereits unter 13.2 korrekt gearbeitet hat. Ist vielleicht nur eine Kleinigkeit warum es unter Tumbleweed hakt. Ich würde es zuerst mal mit dem Betatreiber probieren und erneut testen ob sich die Maus dann schon ohne weitere Konfiguration brauchbar verwenden. Falls nicht bleibt dann immer noch die Option mit xbindkeys...


    Wie auch immer - ich wünsche viel Erfolg und beim nächsten Hardwarekauf immer darauf achten das diese auch mit dem Pinguin spielen mag ;)
    Wobei eine Maus die unter Linux herumzickt ist mir seit vielen, vielen Jahren nicht mehr untergekommen...

    Zitat

    Device Boot Start End Sectors Size Id Type
    /dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
    /dev/sda2 206848 175652711 175445864 83.7G 7 HPFS/NTFS/exFAT
    /dev/sda3 175652864 312498175 136845312 65.3G f W95 Ext'd (LBA)


    Ein wenig kurios denn im Normalfall werden bestehende Windows-Installation seit Jahren verlässlich gefunden und ins grub2-Bootmenü eingebunden. Falls das warum auch immer nicht klappen sollte, so besteht natürlich nach wie vor die Möglichkeit Einträge manuell hinzuzufügen. Abgesehen davon Clonezilla im Bootmenü zu haben und direkt von einer Partition auf der Festplatte starten zu lassen habe ich das allerdings mangels Notwendigkeit seit Jahren nicht mehr gemacht. Die Vorgehensweise:


    Die Datei /etc/grub.d/40_custom (die ist für eigene Einträge da) mit beliebigem Texteditor als root öffnen und "manuell" einen Eintrag für das gewünschte Windows 7 hinzufügen:


    Code
    menuentry "Windows 7" {
    insmod part_msdos
    insmod ntfs
    set root='(hd0,msdos1)'
    chainloader +1
    }

    Je nachdem wo Windows seinen egenen Bootloader untergebracht ist unter Umständen das hd0 in Zeile 4 anzupassen. hd0 bedeutet erste Festplatte = /dev/sda, hd1 zweite Festplatte /dev/sdb usw. Imho ist die Grub-Syntax hier etwas umständlich, aber so ist es eben. Falls der Windows-Bootloader in einer eigenen Partition installiert ist (sofern das möglich ist), so ist auch diese anzugeben. Hier wird ohne Umwege hochgezählt: 1 Partition ist 1, 2=2 usw. also hd0,2 würde dann bedeuten die zweite Partition der ersten Festplatte. Diese Angabe muss zwingend korrekt sein damit der Win-bootloader gefunden wird und startet. Danach ein "sudo grub2-mkconfig -o /boot/grub2/grub.cfg" und Windows sollte wieder im Bootmenü auftauchen und dann hoffentlich korrekt starten.


    Falls dann zukünftig irgendwann mal vielleicht zwei Windows-Einträge im Bootmenü auftauchen, dann den obig manuell hinzugefügten wieder entfernen und ein grub2-update durchführen.

    Hallo,


    zumindest bei ersterem sollte hier eine der möglichen Lösungen zu finden sein:


    Customize Logitech M560 on Linux

    Code
    zypper install xbindkeys xautomation

    Danach den Ausführungen unter "Configurate xbindkeys" folgen. Mittels "xev | grep button" herausfinden welche Button-Nummer den Vor und Zurück-Knöpfen auf der linken Seite der Maus zugewiesen sind. Dies dann der .xbindkeysrc wie unter Punkt drei beschrieben hinzufügen. Gleiches gilt für die mittlere Maustaste (welche Logitech leider neuerdings durch eine extra-Taste hinter dem Mausrad realisiert). Herausfinden welche Nummer zugewiesen ist, dies samt der gewünschten Aktion in die .xbindkeysrc. Gut möglich das hier etwas experimentieren und herumspielen nötig sind bis alles wie gewünscht funktioniert (Bezugnehmend auf einige Einträge im Fedora-Bugzilla könnte sich aber die Emulation der mittleren Maustaste als eher problematisch gestalten).Wenn alles soweit als möglich passt noch eine autostart-datei wie im Blog beschrieben anlegen damit man xbindkeys nicht nach jedem Neustart manuell starten muss. Das scrollen mit dem Mausrad sollte jedoch ohne weiteres zutun funktionieren, seltsam wenn dem nicht so wäre, aber diese Maus scheint leider eher ein Sonderfall zu sein...



    Anstelle von der Konfiguration mit xbindkeys gibt es auch Lösung mittels einer udev-rule:


    Quelle: Bug 1035668 – Problematic support for Logitech M560 mouse


    (Sollte über kurz oder lang den Weg in alle Distributionen finden, so dass die M560 dann "out of the box" funktioniert - zumindest weitestgehend)


    Ansonsten könnte eventuell auch ein kleiner Hinweis in Form einer kurzen Mail an Logitech nicht schaden, in der diese darauf hingewiesen werden das es bei Betriebssystemen auch mehr als nur Windows ,7,8 und 10 gibt. ;)

    Hallo zusammen,


    nach einigen Monaten mit Leap 42.1 muss ich sagen das ich bisher sehr angetan davon bin. Eine sehr solide Distribution, alles läuft soweit brav und sehr stabil, die Aktualisierungen sind problemlos und mittlerweile habe ich mir das System auch perfekt auf meine Vorstellungen hin eingerichtet. Die einzige kleine Baustelle die ich nicht aussortieren konnte ist Conky. Aus irgendeinem mir nicht nachvollziehbaren Grund werden häufig mehrere Instanzen davon gleichzeitig gestartet. Direkt nach der Installation von openSUSE anfangs nur vereinzelt/gelegentlich, aber mittlerweile passiert das nach fast jedem Neustart. Nicht immer, aber immer öfter sozusagen ;)


    Der verwendete Desktop ist Xfce und wie in all den Jahren zuvor starte ich Conky mittels einer desktop-datei in /home/user/.config/autostart:


    Code: conky.desktop
    [Desktop Entry]
    Encoding=UTF-8
    Version=1.0
    Type=Application
    Name=Conky
    Comment=Systemmonitor
    Exec=conky -d -p 12
    OnlyShowIn=XFCE;
    StartupNotify=false

    Das häufig mehrere Instanzen von Conky laufen passiert direkt nach dem Login. Mit verschiedenen Optionen wie Conky zeitverzögert starten zu lassen usw. habe ich auch schon herumgespielt, das hat leider keine Änderung bewirkt. Der Effekt wenn Conky sozusagen "mehrmals läuft" ist sofort ersichtlich, es führt zu einer unschönen Darstellung, da sich die Ausgaben überlappen/überschreiben. Zur Veranschaulichung habe ich einen Teil aus Conky ausgeschnitten um das Problem besser darzustellen. In der Htop-Ausgabe ist mit den PIDs 1572, 1565, 1573 das mehrmalige/gleichzeitige Starten mehrerer Instanzen des Systemmonitors erkennbar:


    [Blockierte Grafik: https://abload.de/thumb/conky_002o9x2b.png] [Blockierte Grafik: https://abload.de/thumb/htop_001qva4n.png]


    Hier noch die conkyrc: Pastebin
    Für den Fall das der Fehler in der Syntax verursacht wird. Verwende diese Konfigurationsdatei allerdings in dieser Form nahezu unverändert seit Jahren ohne das sich dabei Probleme ergeben hätten.


    Falls jemandem dazu etwas einfällt - ich nehme jeden Vorschlag/Idee sehr gerne entgegen und bedanke mich gleich im Voraus dafür! Ist zwar vorwiegend ein eher "kosmetisches Problem" ohne andere Auswirkungen, aber wenn ich nicht immer wieder unnötig laufende Instanzen von Conky zu schließen hätte, würde ich das auch nicht unbedingt als Nachteil betrachten. ;)


    Falls weitere Informationen gewünscht sind liefere ich diese natürlich umgehend nach! Herzlichen Dank für Eure Zeit!

    Hallo zusammen,


    lang, lang ist es her seit ich openSUSE auf einem meiner Rechner installiert hatte. War noch vor der Verfügbarkeit von zypper, dürfte wahrscheinlich die 10.2 gewesen. Nervige, zeitaufwändige Basteleien an Rolling-Release-Distributionen haben mich nach einiger Zeit den Blick auf etwas solideres werfen. Der neue Ansatz mit dem SLES-Unterbau scheint mir sehr vielversprechend und die Software aus dem Multimediabereich ist auch wie gehabt sehr aktuell. Zur Abwechslung mal openSUSE mit dem Xfce-Desktop und nicht KDE:


    [Blockierte Grafik: http://abload.de/thumb/001nfk7k.png] [Blockierte Grafik: http://abload.de/thumb/002e0jgy.png]
    (für größere Darstellung bitte einfach auf das Bild klicken!)