Beiträge von Suelkun

    ok,


    systemctl status firewalld.service
    ● firewalld.service - firewalld - dynamic firewall daemon
    Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: disabled)
    Active: inactive (dead)
    Docs: man:firewalld(1)


    SuseFirewall2 nun gelöscht.


    Danach gleiches Verhalten von KMail wie zuvor.



    Code
    zypper se -si | grep -Ei 'systemp|system-p|system_p|system pa'

    siehe angehängte Datei



    Mal ~/.config/kmail2rc umbenannt?.

    nein, nichts dergleichen.

    Also: Unter einem anderen Benutzer startet Kmail.



    Code
    akonadictl status
    Akonadi Control: running
    Akonadi Server: running
    Akonadi Server Search Support: available (Remote Search, Akonadi Search Plugin)
    Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_ews_resource, akonadi_ewsmta_resource, akonadi_facebook_resource, akonadi_followupreminder_agent, akonadi_googlecalendar_resource, akonadi_googlecontacts_resource, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_indexing_agent, akonadi_invitations_agent, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_knut_resource, akonadi_kolab_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_newmailnotifier_agent, akonadi_notes_agent, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_tomboynotes_resource, akonadi_unifiedmailbox_agent, akonadi_vcard_resource, akonadi_vcarddir_resource




    Code
    zypper ve
    Repository-Daten werden geladen...
    Installierte Pakete werden gelesen...
    
    
    Die Abhängigkeiten aller installierten Pakete sind berücksichtigt.

    Die Firewall ist bei mir aber abgeschaltet. Ich habe eine Hardware-Firewall



    Zusatzinformationen:
    Ich benutze Kmail Version 18.12.3-lp151.3.7.1 und
    den Kernel 4.12.14-lp151.28.10.


    Der Kernel kam lt. Zeitstempel am Montag, 15.7.2019. Ich habe vom vergangenen Montag bis jetzt mit Sicherheit KMail benutzt.


    Update von Kmail ändert nichts am beschriebenen Verhalten.

    Hallo,


    ich benutze seit einiger Zeit Leap 15.1, zuvor habe ich Leap 42.3 benutzt. Leap 15.1 entstand durch update der Verein 42.3.
    Das laufende Leap 15.1 hat seit diesem update aus 42.3 keinerlei ernsthafte Probleme bereitet, bis heute nachmittag.


    Ich habe das automatischen Updater eingeschaltet und gegen Ende vergangener Woche kam darüber eine neue Kernelversion. Die Aktialisierung selbst verlief völlig problemlos.


    Zur Mail-Kommunikation verwende ich seit Jahren Kmail und auch für dieses gab es bisher keinerlei Probleme.


    Heute wollte ich nun Kmail starten und stelle fest, daß es nicht mehr hochkommt. Wenn ich Kmail aus einer Konsole starte, dann erhalte ich folgende Nachricht:



    Hat jemand eine Idee, an welcher Stellschraube ich drehen kann, um diesen Fehler zu vermeiden?

    Der Start per UEFI setze ja eine kleinere Partition voraus, die per FAT formattiert ist. Diese wird (bei der Installation von Linux) unter /boot/efi gemountet. Unter /boot/efi liegt dann das Verzeichnis EFI, unter EFI das Verzeichnis opensuse. Im Verzeichnis opensuse liegt dann der bootloader (z.B. grubx64.efi, aber auch andere).


    Das Aussehen der Auswahlscreen (wie bei dir) hängt natürlich vom Bios (d.h. Motherboard) ab , bei mir sieht diese Auswahlscreen völlig anders aus. Dein Bios zeigt scheinbar diesen Ordnernamen an.


    Ich würde erst einmal eines der Linuxe starten (geht natürlich auch mit dem Rettungssystem, wäre aber vermutlich komplizierter). .Dann würde ich (als Root) aus dem laufenden System heraus in den Ordner /boot/efi/EFI wechseln und den Ordner opensuse in den gewünschten Namen umändern.


    Um efibootmgr kommst Du wahrscheinlich dennoch nicht herum: Du mußt den aktuellen boot-Eintrag (wie oben beschrieben) weglöschen und (mit voller Syntax jetzt) im NVRAM eintragen, wo der Bootmanager jetzt gefunden werden kann. Ich könnte mir vorstellen, daß das betreffende Linux nicht mehr hochkommt, wenn man diesen letzten Schritt unterläßt (läßt sich aber mit dem Rettungssystem immer reparieren).

    zu Deinen Fragen:


    a) ja, mit efibootmgr werden Änderungen im NVRAM durchgeführt. Die Bezüge zu den Disks bleiben dennoch erhalten.
    Ich habe es noch nicht probiert, aber ich vermute, daß , wenn Du eine Platte ausbaust, der betreffende Eintrag einfach fehlt.
    Die Platte wird nicht über den SATA-Anschluß identifiziert, sondern über den eindeutigen Identifier der Disk. D.h. der Eintrag sollte dann auch erhalten bleiben.


    b) Die Einträge werden beim BIOS möglicherweise öfters neu zusammengestellt, aber Deine Einträge sollten das überleben. Der Eintrag für Windows überlebt das doch auch!


    c) nein, mit <efibootmgr -c -L"Name"> aus dem laufenden System heraus ist nichts weiter nötig. Das System weiß ja, von welcher Platte es heraus gebootet wurde. Du kannst natürlich mit komplexerer Syntax auch Einträge für andere (aktuell nicht laufende) Systeme erstellen. In diesem Fall bleibt nichts anderes übrig, als die Syntax der efibootmgr-Befehle zu googeln. Ich benutze efibootmgr zu selten, um mir die Syntax über längere Zeiten zu merken.


    d) Im Gegensatz zu dir kann ich mir sehr wohl vorstellen, daß die Installation von openSUSE efibootmgr benutzt.


    Nochmal: Den Eintrag für Windows würde ich nicht antasten.

    Wenn ich es richtig verstehe, dann bekommst Du alle 3 Betriebssysteme hoch, also auch das "defekte" Linux.
    Ich habe eine ähnliche Konfiguration (4 Platten, 4 unterschiedliche Versionen des Betriebssystems), mit dem Unterschied daß ich Windows nicht dabei habe und kein defektes Linux.


    Ich gehe im weiteren davon aus, daß du ein Linux anstarten kannst. Möglicherweise reicht da auch das "defekte".
    Unter Linux gibt es das Komandozeilen-Tool efibootmgr. Wenn es bei Dir nicht installiert sein sollte dann läßt es sich über Yast nachinstallieren. efibootmgr braucht Root-Rechte.


    Der Aufruf von efibootmgr selbst listet die vorhandenen Boot-Einträge, bei Dir müßte 2x ein Booteintrag mit dem Namen opensuse genannt werden. Verschiedene Boot-Einträge haben verschiedene Boot-Nummern.
    Der Eintrag mit der Bezeichnung BootCurrent: nennt die Nummer des aktuell gestarteten Eintrags. Wenn das die Nummer 000x (x ist eine Hex-Zahl) ist, dann kannst Du mit dem Kommando


    efibootmgr -b 000x -B


    diesen Eintrag weglöschen. (Leider scheint efibootmgr einen bestehenden Eintrag nicht umbenennen zu können. Der Eintrag muß deshalb erst weggelöscht und dann neu angelegt werden.)
    Aus dem laufenden System heraus den Eintrag dann mit


    efibootmgr -c -L "Name"


    neu anlegen, Name steht für den Namen, den Du dem laufenden System geben willst. Damit solltest Du die Linux-Systeme unterscheiden können.


    Bitte trotzdem Vorsicht: Ich weiß nicht, wie fit Du bist. Immerhin veränderst Du etwas am Bootvorgang. Ich würde auch den Booteintrag für Windows nicht anfassen.
    .

    danke sterun, ich kann über das Netzwerk scannen.


    Woran es jetzt wirklich lag, weiß ich nicht genau. Ich habe nämlich an 2 Stellschrauben gedreht (ja, ich weiß: sollte man niemals tun).


    1. In der Datei /etc/saned/saned.conf habe ich neben dem eigenen Netzwerk .192.168.0.0/24 auch noch localhost zugelassen.


    2.beim Durchlesen von
    SDB:Configuring Scanners - openSUSE


    steht auch was über Scannen übers Netzwerk und Einrichten über Yast. Das habe ich gemacht und damit funktionierte der Scan sofort.

    ...habe die beiden Links mal durchgelesen:


    am (nicht vorhandenen o. falschen) Driver liegt mein Problem vermutlich nicht, denn ich kann ja scannen. Davon abgesehen wird der Scanner in der Datei /etc/saned/genesys.conf mit der richtigen Vendor:Device-ID gelistet.


    Der Ouput von scanimage -L liefert:

    Code
    scanimage -L
    device `genesys:libusb:004:002' is a Canon LiDE 35/40/50 flatbed scanner
    device `net:localhost:genesys:libusb:004:002' is a Canon LiDE 35/40/50 flatbed scanner


    Der Output von


    Code
    scanimage -d genesys:libusb:004:002 >/tmp/image.pnm

    scanned korrekt, während der Output von

    Code
    scanimage -d net:localhost:genesys:libusb:004:002 >/tmp/image.pnm
    scanimage: sane_start: Error during device I/O

    eben einen Fehler liefert.

    Hallo,


    ich benutze Leap 42.3.


    An dem System habe ich einen älteren USB-Flachbettscanner (Canon Lide 35), der auch funktioniert. Ich scanne darauf mittels xsane, der dabei benutzte Treiber ist genesys.
    Ich würde jetzt gerne auch vom Netzwerk aus über diesen Scanner scannen. Dabei stoße ich allerdings auf Schwierigkeiten.


    Nach Änderung der Dateien /etc/saned/dll.conf, /etc/saned/net.conf und /etc/saned/saned.conf (und einem vielleicht unnötigen Neustart des Rechners) bietet mir der lokale Aufruf von XSane nun 2 Scanner als Auswahl an.Einmal den bisher schon vorhandenen Scanner (über den ich nach wie vor Scannen kann) und dann noch einen zweiten Scanner, bei dessen Auswahl ich über dann über das Netzwerk scanne, wenn ich das richtig verstehe.


    Bei (lokaler) Auswahl dieses 2. Scanners und nachfolgender Anforderung eines Scans erhalte ich die Fehlermeldung: "Konnte Scanner nicht starten. Fehler während Geräte I/O".
    Ich vermute, daß ich den Scanserver erst einmal lokal richtig am Laufen haben muß, bevor ich ihn dann wirklich versuchen kann, ihn übers Netzwerk anzusprechen.


    Ein wenig irritiert mich auch, daß ich nirgends einen Service finde, mit dem systemd z.b. saned starten könnte. Kann natürlich auch sein, daß Leap 42.3 saned noch nicht als service implementiert hat.


    Ich bräuchte ein paar Tips, wie ich weiterkommen kann.