Skip to content
linux-nerds.org

linux-nerds.org
  1. Übersicht
  2. Linux
  3. Fedora 40 - Updates

Fedora 40 - Updates

Linux
1 1 206
  • FrankMF

    Ich habe ja bei meinen Tests zu Fedora 40 KDE Plasma immer über dieses komische Update System rum genörgelt, was mich massiv an M$ erinnert. Wenn man das nicht wegbekäme, wäre das ein Blocker für mich. So was käme mir nicht auf die Platte. Aber, Linux ist ja sehr flexibel. Ich habe dann mal in den KDE Settings gesucht.

    setup_updates.png

    Da ist die Einstellung. Neustart erforderlich, erst dann wird es übernommen. Danach sieht das dann bei Updates gewohnt aus 🙂

    updates.png

    Nach der Aktualisierung, dann so wie immer.

    after_updates.png

    Yeah

    Für Menschen, die keine Nerds sind, ist die erste Methode vermutlich die bessere Option. Für mich steht sie leider ein wenig im Weg. Ich mag keine Reboots, die sind bei mir selten. Ja, wenn es einen neuen Kernel gibt wird auch mal durchgestartet, aber so gefällt es mir besser.

    Im Fediverse -> @FrankM@nrw.social

    1. NanoPi R5S
    2. Quartz64 Model B, 4GB RAM
    3. Quartz64 Model A, 4GB RAM
    4. RockPro64 v2.1
    0
Anmelden zum Antworten

  • FrankMF

    Vaultwarden bekommt Aufmerksamkeit vom BSI

    Vaultwarden vaultwarden linux bsi
    1
    0 Stimmen
    1 Beiträge
    219 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Manjaro Btrfs Snapshot auswählen

    Linux manjaro linux
    1
    2
    0 Stimmen
    1 Beiträge
    395 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    NodeBB - v3.7.0

    NodeBB nodebb linux
    1
    0 Stimmen
    1 Beiträge
    142 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Debian Bookworm 12.5 released

    Linux linux debian
    3
    0 Stimmen
    3 Beiträge
    228 Aufrufe
    FrankMF
    Und hier taucht es dann auf -> https://www.debian.org/News/2024/20240210
  • FrankMF

    Firefox - Dolphin Dateibrowser benutzen

    Linux firefox linux
    1
    1
    0 Stimmen
    1 Beiträge
    505 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Root-Rechte für Angreifer

    Linux linux debian
    1
    0 Stimmen
    1 Beiträge
    105 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    Pycharm & Docker

    Verschoben Linux pycharm docker linux
    1
    4
    0 Stimmen
    1 Beiträge
    311 Aufrufe
    Niemand hat geantwortet
  • FrankMF

    NanoPi R2S - Firewall mit VLan und DHCP-Server

    Verschoben NanoPi R2S nanopir2s linux
    2
    2
    0 Stimmen
    2 Beiträge
    840 Aufrufe
    FrankMF
    Nachdem ich die Tage feststellen musste, das irgendwas mit dem Gerät nicht stimmte, bekam keine DNS Auflösung über die Konsole, habe ich das heute mal eben neuinstalliert. Armbian ist ja immer was spezielles Hat sich bis heute nix dran geändert..... Ok, dann heute mal eben ein neues Image erstellt. Download Gewählt habe ich das Armbian Buster. Image auf die SD-Karte, eingeloggt. Alles wie oben erstellt und abgespeichert. Neustart, geht wieder alles. root@192.168.3.15's password: _ _ _ ____ ____ ____ | \ | | __ _ _ __ ___ _ __ (_) | _ \|___ \/ ___| | \| |/ _` | '_ \ / _ \| '_ \| | | |_) | __) \___ \ | |\ | (_| | | | | (_) | |_) | | | _ < / __/ ___) | |_| \_|\__,_|_| |_|\___/| .__/|_| |_| \_\_____|____/ |_| Welcome to Debian GNU/Linux 10 (buster) with Linux 5.9.11-rockchip64 System load: 2% Up time: 11 min Memory usage: 10% of 978M IP: 192.168.3.15 192.168.1.1 192.168.2.1 CPU temp: 61°C Usage of /: 5% of 29G Last login: Sun Dec 6 12:28:10 2020 from 192.168.3.213 Kernelversion root@nanopi-r2s:~# uname -a Linux nanopi-r2s 5.9.11-rockchip64 #20.11.1 SMP PREEMPT Fri Nov 27 21:59:08 CET 2020 aarch64 GNU/Linux ip a oot@nanopi-r2s:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether b2:b5:10:38:9e:76 brd ff:ff:ff:ff:ff:ff inet 192.168.3.15/24 brd 192.168.3.255 scope global dynamic eth0 valid_lft 6360sec preferred_lft 6360sec inet6 2a02:908:xxxxxx/64 scope global dynamic mngtmpaddr valid_lft 7196sec preferred_lft 596sec inet6 fe80::b0b5:10ff:fe38:9e76/64 scope link valid_lft forever preferred_lft forever 3: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff 4: lan0.100@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.1.1/24 brd 192.168.1.255 scope global lan0.100 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever 5: lan0.200@lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b2:b5:10:38:9e:96 brd ff:ff:ff:ff:ff:ff inet 192.168.2.1/24 brd 192.168.2.255 scope global lan0.200 valid_lft forever preferred_lft forever inet6 fe80::b0b5:10ff:fe38:9e96/64 scope link valid_lft forever preferred_lft forever Vom Notebook aus funktioniert auch alles. So weit bin ich zufrieden. Jetzt mal langsam anfangen, der Kiste IPv6 beizubringen. Oje, nicht gerade mein Lieblingsthema... Bis der NanoPi R4S hier ankommt und ein vernünftiges Image hat, vergeht ja noch was Zeit...