staging.inyokaproject.org

Hallo,

ich wollte einen Rechner, der noch auf Ubuntu 20.04.6LTS läuft, auf eine neuere Version upgraden. Er weigert sich leider. Hier sie Ausgabe von apt update und apt upgrade:

~$ sudo apt update

OK:1 https://linux.teamviewer.com/deb stable InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu focal InRelease
OK:3 http://de.archive.ubuntu.com/ubuntu focal-updates InRelease
OK:4 http://de.archive.ubuntu.com/ubuntu focal-backports InRelease
OK:5 http://security.ubuntu.com/ubuntu focal-security InRelease
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Aktualisierung für 19 Pakete verfügbar. Führen Sie »apt list --upgradable« aus, um sie anzuzeigen.

:~$ sudo apt upgrade

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Paketaktualisierung (Upgrade) wird berechnet... Fertig
The following security updates require Ubuntu Pro with 'esm-infra' enabled:
  libsoup-gnome2.4-1 linux-headers-generic-hwe-20.04 poppler-utils
  linux-libc-dev xserver-common gir1.2-soup-2.4 libblockdev-swap2
  xserver-xorg-core gir1.2-gdkpixbuf-2.0 libnvidia-compute-535
  libnvidia-compute-535 libgdk-pixbuf2.0-0 libssh-4 libpython3.8-minimal
  git-man libnvidia-encode-535 libnvidia-encode-535 libsystemd0
  nvidia-kernel-common-535 gcc-10-base gcc-10-base libgs9
  xserver-xorg-video-nvidia-535 libnvidia-gl-535 libnvidia-gl-535 libsqlite3-0
  python3-protobuf python3-urllib3 libnvidia-fbc1-535 libnvidia-fbc1-535
  libitm1 libnvidia-decode-535 libnvidia-decode-535 sudo libpython3.8
  python3.8 xserver-xorg-legacy git libblockdev-crypto2 udev
  libnvidia-cfg1-535 libblockdev-loop2 libquadmath0 libblockdev-fs2
  linux-image-generic-hwe-20.04 libblockdev-part2 nvidia-utils-535
  python3-requests libudev1 libsoup2.4-1 systemd-timesyncd
  linux-generic-hwe-20.04 nvidia-dkms-535 xserver-xephyr libtiff5 udisks2
  libtsan0 libubsan1 libprotobuf-lite17 python3.8-minimal systemd-sysv
  libblockdev2 nvidia-compute-utils-535 gir1.2-udisks-2.0 libpam-systemd
  xwayland ghostscript liblsan0 systemd libgomp1 libgdk-pixbuf2.0-bin
  nvidia-driver-535 libssh-gcrypt-4 libblockdev-utils2 ghostscript-x
  libgdk-pixbuf2.0-common libgdk-pixbuf2.0-dev libnss-systemd libgs9-common
  libblockdev-part-err2 libgcc-s1 libgcc-s1 libxml2 libpython3.8-stdlib
  libudisks2-0 libatomic1 libatomic1 libpoppler-cpp0v5 libnvidia-common-535
  libcc1-0 libprotobuf17 libpoppler-glib8 libstdc++6 libstdc++6 libpoppler97
  libnvidia-extra-535 libxslt1.1 nvidia-kernel-source-535
Learn more about Ubuntu Pro at https://ubuntu.com/pro
Die folgenden Pakete sind zurückgehalten worden:
  libnvidia-cfg1-535 libnvidia-compute-535 libnvidia-compute-535:i386 libnvidia-decode-535
  libnvidia-decode-535:i386 libnvidia-encode-535 libnvidia-encode-535:i386 libnvidia-extra-535
  libnvidia-fbc1-535 libnvidia-fbc1-535:i386 libnvidia-gl-535 nvidia-compute-utils-535
  nvidia-dkms-535 nvidia-driver-535 nvidia-kernel-common-535 nvidia-kernel-source-535
  nvidia-utils-535 xserver-xorg-video-nvidia-535
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 18 nicht aktualisiert.

–> das habe ich direkt ausgeführt: ~$ apt list --upgradable

Auflistung... Fertig
libnvidia-cfg1-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-compute-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-compute-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 i386 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-decode-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-decode-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 i386 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-encode-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-encode-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 i386 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-extra-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-fbc1-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-fbc1-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 i386 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-gl-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
libnvidia-gl-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 i386 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
nvidia-compute-utils-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
nvidia-dkms-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
nvidia-driver-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
nvidia-kernel-common-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
nvidia-kernel-source-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
nvidia-utils-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]
xserver-xorg-video-nvidia-535/focal-updates,focal-security 535.230.02-0ubuntu0.20.04.1 amd64 [aktualisierbar von: 535.183.01-0ubuntu0.20.04.1]

Kann es sein, dass der Nvidia-Treiber das Problem ist? Ich habe schon versucht, in "Anwendungen & Aktualisierungen" den Treiber von 535 auf 570 umzuschalten, aber nach dem nötigen Neustart ist weiterhin 535 aktiv. Wenn ich dieser Seite hier glaube: https://wiki.ubuntuusers.de/Grafikkarten/Nvidia/nvidia/ dann ist 535 zumindest für Ubuntu 22.04LTS noch nutzbar. Allerdings ist die neueste Version auf nvidia.com 535.261.03 und ich scheine noch 535.183.01 zu haben.

Irgendwelche Vorschläge, was ich noch tun kann? Mir fällt jetzt nur noch ein, den Nvidia-Treiber komplett zu entfernen und hoffentlich auch alle Reste loszuwerden, dann das upgrade durchführen und danach erst wieder den Treiber zu installieren.

Die grafische Aktualisierungsverwaltung meint: siehe Anhang. https://media-cdn.ubuntu-de.org/forum/attachments/temp/4ce1e63f8bb3cab5067669d7a89a2e56

Falls es noch relevant sein sollte:

System:    Host: 3950-3070 Kernel: 5.15.0-139-generic x86_64 bits: 64 Desktop: Gnome 3.36.9 
           Distro: Ubuntu 20.04.6 LTS (Focal Fossa) 
Machine:   Type: Desktop Mobo: ASUSTeK model: TUF X470-PLUS GAMING v: Rev X.0x 
           serial: <superuser/root required> BIOS: American Megatrends v: 6042 date: 04/28/2022 
CPU:       Topology: 16-Core (2-Die) model: AMD Ryzen 9 3950X bits: 64 type: MT MCP MCM 
           L2 cache: 8192 KiB 
           Speed: 2200 MHz min/max: 2200/3500 MHz Core speeds (MHz): 1: 2191 2: 1965 3: 2197 
           4: 2200 5: 2201 6: 2200 7: 2200 8: 2200 9: 2200 10: 2195 11: 2281 12: 2199 13: 2201 
           14: 2201 15: 2203 16: 2197 17: 2200 18: 2200 19: 2200 20: 2200 21: 2202 22: 2199 
           23: 2199 24: 2200 25: 2198 26: 2200 27: 2200 28: 2200 29: 2200 30: 2198 31: 2483 
           32: 2197 
Graphics:  Device-1: NVIDIA driver: nvidia v: 535.183.01 
           Display: x11 server: X.Org 1.20.13 driver: nvidia 
           resolution: 3840x2160~60Hz, 3840x2160~60Hz 
           OpenGL: renderer: NVIDIA GeForce RTX 3070/PCIe/SSE2 v: 4.6.0 NVIDIA 535.183.01 
Audio:     Device-1: NVIDIA driver: snd_hda_intel 
           Device-2: AMD Starship/Matisse HD Audio driver: snd_hda_intel 
           Sound Server: ALSA v: k5.15.0-139-generic 
Network:   Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 
           IF: enp3s0 state: up speed: 1000 Mbps duplex: full mac: 4c:ed:fb:68:be:fd 
Drives:    Local Storage: total: 489.06 GiB used: 57.94 GiB (11.8%) 
           ID-1: /dev/sda vendor: Samsung model: SSD 860 EVO 250GB size: 232.89 GiB 
           ID-2: /dev/sdb vendor: Crucial model: CT275MX300SSD4 size: 256.17 GiB 
Partition: ID-1: / size: 250.60 GiB used: 57.94 GiB (23.1%) fs: ext4 dev: /dev/sdb5 
Sensors:   Message: No sensors data was found. Is sensors configured? 
Info:      Processes: 467 Uptime: 6m Memory: 31.25 GiB used: 2.12 GiB (6.8%) Shell: bash 
           inxi: 3.0.38 

Lesestoff: Focal Fossa

20.04 ist seit 31. Mai 2025 EndOfLife. Damit geht nichts mehr. Für ein Upgrade bist du viel zu spät. Dein System hat nun bereits eine Supportlücke von über 4 Monaten und muss somit als potenziell kompromitiert angesehen werden.

Da bleibt nur ein aktuelles System komplett sauber und neu installieren.

Das ist irrelevant. EndOfLife ist es trotzdem.

Dass es EOL ist, weiß ich, darum möchte ich es ja upgraden.

EoL heisst es geht nicht mehr. Du bist zu spät.

Man upgradet nicht, wenn es längst zu spät ist. Saubere Neuinstallation einer aktuellen Linux-Distributionsversion ohne Wenn und Aber!

magiceye04 schrieb:

Kann eine Kompromittierung wirklich sofort nach dem heutigen Booten erfolgt sein?

Selbstverständlich. Davon abgesehen ist "LTS" Selbstbetrug. Du scheinst Dich noch nie mit der Leichenhalle universe befaßt zu haben.

schwarzheit schrieb:

EoL heisst es geht nicht mehr. Du bist zu spät.

Ich hab jetzt auf den Nouveau-Treiber umgestellt und danach ging das upgrade. Es geht also doch.

@von.wert

Dann wäre das System ja auch kompromittiert, wenn ich nach 6 Monaten Pause ein System mit einer damals aktuellen und heute noch nicht EOL-Version gebootet hätte.

Das ändert immernoch nichts daran das du nun ein unsicheres System hast.

Ein EOL System upgradet man nicht. Fertig.

von.wert schrieb:

Du scheinst Dich noch nie mit der Leichenhalle universe befaßt zu haben.

Das ist korrekt, davon habe ich heute zum ersten Mal gehört und Google spuckt mir dazu auch nicht viel aus.

Auf dem Rechner läuft genau ein Programm (boinc) und das ist anscheinend im universe Paket. Also kann ich vermutlich auch nicht auf universe verzichten.

magiceye04 Um Verwirrungen zu vermeiden: Keiner behauptet, dass dein System kompromittiert ist. Die Wahrscheinlichkeit, dass es das ist, ist nicht hoch.

Dennoch gilt in der IT-Sicherheit der Grundsatz: Ein System mit Supportlücke gilt als kompromittiert. Denn eine Behebung dieses Zustandes durch Rollback oder Neuinstallation ist, zumindest bei guter Vorbereitung, i.d.R. weniger Aufwand als eine genaue Prüfung auf Malware, und darüber hinaus sicherer.

Und ja, das gilt auch für den von dir konstruierten Fall, dass ein System zwar noch nicht EOL, aber monatelang nicht gelaufen ist und deshalb keine Updates bekommen hat. Ein solches System würde ich als erstes updaten und bis dahin, wenn überhaupt (lokale Paketquellen bevorzugen), nur mit spitzen Fingern ans Netz hängen. Denn ob die Supportlücke auf EOL basiert oder auf sonstwas, macht fürs System keinen Unterschied – wenns auf dem Stand von vor 6 Monaten ist, ist es unsicher.

Jetzt stellt sich die Frage, ab welcher Wartezeit von Supportlücke zu sprechen ist ☺ Ich würde wenige Tage ansetzen. Ein sicherheitsrelevantes oder produktives System gehört jedenfalls mehrmals täglich upgedatet.

Für LTS gilt generell: main und restricted bekommen ihn. universe und multiverse nicht. Wer auf universe bzw. multiverse angewiesen ist, sollte vom LTS-Zyklus Abstand halten. Ja, das sagt einem keiner. Finde ich auch doof, hab ich aber nicht so eingerichtet und kann ich auch nicht ändern.

schwarzheit Es sind nur über 3 Monate seit Ende Mai, nicht über 4 ☺ aber das macht natürlich nichts besser.

--ks

magiceye4

Die Ausgabe von deinem obigen

:~$ sudo apt upgrade

zeigt zu dem sehr gut, welche Sicherheits-Updates das 20.04 nicht erhalten hat, weil es aus dem Support ist und Ubuntu Pro nicht aktiviert ist. Wie kritisch die fehlenden Aktualisierungen sind prüft man mit OpenSCAP.

Kreuzschnabel schrieb:

Und ja, das gilt auch für den von dir konstruierten Fall, dass ein System zwar noch nicht EOL, aber monatelang nicht gelaufen ist und deshalb keine Updates bekommen hat. Ein solches System würde ich als erstes updaten und bis dahin, wenn überhaupt (lokale Paketquellen bevorzugen), nur mit spitzen Fingern ans Netz hängen.

So konstruiert ist der Fall nicht. Ich nutze den PC mit zum Heizen des Arbeitszimmers und das brauche ich im Sommer ja nicht. Somit läuft der auch fast immer den kompletten Sommer nicht.

Nur wie lässt man einen PC "mit spitzen Fingern" ins Netz? Was lässt der Router denn real durch, was direkt Schaden anrichten kann? Das Szenario erscheint mir viel eher "konstruiert". Klar, wenn ich mit dem Browser aktiv ins Netz gehe, sehe ich ein, dass kompromittierte Seiten Schadcode einschleusen können, googles Werbemüll enthält vermutlich viel davon.

magiceye04 schrieb:

Ich nutze den PC mit zum Heizen des Arbeitszimmers

Erinnert mich an Win95 auf einem Pentium II. Die CPU musste auch idle gut gekühlt werden, so dass man damit wirklich den Raum heizen konnte.

und das brauche ich im Sommer ja nicht. Somit läuft der auch fast immer den kompletten Sommer nicht.

Da würde ich folgendes machen:

• Kleines Updatescript schreiben mit mutigem -y

• am Ende des Skripts ein sync && systemctl poweroff einsetzen

• Dieses Skript beim Systemstart automatisch starten lassen.

Dann kostet es dich jeweils exakt einen Knopfdruck (einschalten), den einmal die Woche zu upgraden.

Nur wie lässt man einen PC "mit spitzen Fingern" ins Netz?

Switch mit gutem Paketfilter dazwischen. Restriktive Firewall. IPv6 abschalten und nur über NAT zugreifen lassen. So was.

--ks