Beiträge von pschulze59

Zitat von LinuPia

Also schlimm kann's nich sein.
Läuft alles.

Ich habe kein Leap.
Stell mal bitte einen Screenshot der Firewall ein.
(Am besten mit "shutter" und das annotiert, wo du suchst, und was du versucht hast. )

Du solltest das einfach sehen.

Sorry, die screenshots stehen weiter oben und was ich gemacht habe ist, dass ich das Yast-Modul aufgerufen habe, um meine Netzwerkschnittstellen, die an genau dieser Stelle aufgelistet sein müssten, verschiedenen Zonen zuzuweisen, die je nach Zone, verschiedene Firewall-Rules zugewiesen bekommen sollen.
Was man halt so macht bei 'ner Firewallkonfiguration per Yast.
Also, nichts für ungut, Deine Aussage "scheint ja zu laufen" usw. bringt mich da nicht wirklich weiter ....

Zitat von LinuPia

Was zeigt:
systemctl status -l SuSEfirewall2

toshilappi:~ # systemctl status -l SuSEfirewall2
SuSEfirewall2.service - SuSEfirewall2 phase 2
Loaded: loaded (/usr/lib/systemd/system/SuSEfirewall2.service; enabled)
Active: active (exited) since Mon 2016-01-04 18:41:31 CET; 1h 28min ago
Process: 1117 ExecStart=/usr/sbin/SuSEfirewall2 boot_setup (code=exited, status=0/SUCCESS)
Main PID: 1117 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/SuSEfirewall2.service

Zitat von Sauerland

Upgrade von openSUSE 13.2 nach Leap?

Nee, absichtlich komplette jungfräuliche Neuinstallation!

Hier die Ausgabe von ifconfig (Adresswerte anonymisert):

toshilappi:~ # ifconfig -a
eth0      Link encap:Ethernet  HWaddr aa:bb:cc:dd:ee:ff  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:19 


lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:9 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1416 (1.3 Kb)  TX bytes:1416 (1.3 Kb)


wlan0     Link encap:Ethernet  HWaddr aa:bb:cc:dd:ee:ff  
          inet addr:192.168.xxx.yyy  Bcast:192.168.xxx.255 Mask:255.255.255.0
          inet6 addr: fe80::2ae3:47ff:fe08:abcd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2459 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1848 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2454317 (2.3 Mb)  TX bytes:251339 (245.4 Kb)

Also werden vom System die Schnittstellen erkannt und verwaltet.

Hier sind die screenshots

Bei einem Versuch, über Yast die Firewall meines Leap-Laptops zu konfigurieren, stellte ich fest, dass dort keine Schnittstellen (weder LAN noch WLAN) aufgelistet werden. Kennt jemand die Ursache und eventuell auch den Tipp, um das zu ändern, dafür? Es müsste ja - auch wenn ich den Networkmanager und WLAN verwende - wenigstens die WLAN-Schnittstelle administrierbar sein, oder?

Danke für den Tipp, aber eigentlich sollte Dolphin das bringen, was es vorher auch schon -problemlos- gebracht hat. (Übrigens haben auch andere Filemanager keine Probleme, z.B. "Files", resp. "Dateien")
Leap läuft bei mir deswegen noch auf keinem Produktiv-System, sondern gegenwärtig nur zum Kennenlernen und Ausprobieren. Ehrlich gesagt, hatte ich auch erwartet, dass Leap mit KDE5 Probleme macht - die Änderungen sind halt sehr umfangreich. Um so mehr ist feedback für die Entwickler nötig, damit die nächste Version so stabil wird, wie es einst 13.2 war.

Alles klar, da sich diese Fragen auf meinen Leap-Laptop bezogen, erklärt sich, dass "deadline" aktiv ist, da der Kernel die SSD-Erkennung mittlerweile leisten kann.
Insofern scheint ab Leap bezüglich spezieller SSD-Parameter tatsächlich nichts mehr notwendig zu sein.

Danke für die Beiträge.

Danke für die Antworten, aber ich bin "a little bit confused".

Ich versuche mal zu sortieren:
1.
fstab-Einträge discard, noatime, nodiratime haltet ihr für unnötig, da man "... ohnehin nicht die Lebensdauer einer SSD ausnutzt ..." (Zitat sinngemäß)

Der von Sauerland gepostete Artikel sagt dazu was anderes.

Aber egal, ob diese Parameter nun Sinn machen oder nicht (sie schaden jedenfalls nicht), bleibt für mich noch eine Frage offen: Das Standardsystem richtet eine Unmenge an Subvolumes ein. Sollte man dann konsequenterweise diese Parameter auch für jedes der Subvolumes angeben (sofern man sie angeben will)? Meiner Meinung nach gibt es da je einige, bei denen viele Schreib- und Löschvorgänge laufen, also gerade discard Sinn machen würde.

2.
Ihr haltet den GRUB-Parameter elevator=deadline für " ...auf jeden Fall sinnvoll... ". Mal davon abgesehen, dass ich dessen Sinn nicht wirklich verstanden habe, ist mir noch unklar, was die eckigen Klammern bedeuten, wenn ich mir mit "cat /sys/block/sda/queue/scheduler" den Status anzeigen lasse. Bei mir liefert die Anzeige nämlich ein deadline in eckigen Klammern. Ist der Parameter damit nun gesetzt oder noch nicht?
Falls ja, warum enthält meine /etc/default/grub dann keinen Parameter "deadline"?

Vielleicht kann mir jemand noch diese zwei Fragen beantworten.

Danke!

Ich habe bisher immer beim mounten von SSDs fstab-Einträge trim, noatime, nodiratime angegeben. Ist das bei Leap eigentlich noch nötig? Wenn ja, warum erkennt Leap nicht eine SSD und setzt diese Parameter nicht automatisch? Oder sie sind nicht mehr nötig, kann ja sein. Oder benötigt das Dateisystem BTRFS diese Parameter nicht? Dennoch müsste ich meine "alte" EXT4-home-Partition dann wenigstens mi diesen Parametern einhängen, oder?