ubuntuusers.de

Hallo!

(Noch) benutze ich Ubuntu 20.04 und wollte 24.04.03 herunterladen, aber mit den Hash-Summen stimmt etwas nicht! Zunächst habe ich das Image von dem Hauptserver heruntergeladen und laut Info in der SH256SUM-Datei erwarte ich den Wert
faabcf33ae53976d2b8207a001ff32f4e5daae013505ac7188c9ea63988f8328

Leider erhalte ich einen anderen Wert:
$ sha256sum ubuntu-24.04.3-desktop-amd64.iso
f0633cbbb74cda2eb9cc6e823c16a455f44e8075621aefc24519d5eb03b2d51c

Nach und nach habe ich das Image jeweils von weiteren Servern (offiziellen Mirrors: RWTH Aachen, StudNet Bonn, Dogado GmbH sowie Macarne in den Niederlanden) geholt. Alle Dateien sind 6345887744 Byte lang, jedoch die Hash-Summen sind allesamt unterschiedlich.
$ sha256sum ubuntu-24.04.3-desktop-amd64-RWTH.iso
74d217cbec0b872a40ad0e3c2dd9dc6b32e9a391aabbd7410d0125f331b3a9d0 ubuntu-24.04.3-desktop-amd64-RWTH.iso

$ sha256sum ubuntu-24.04.3-desktop-amd64-StudNet-Bonn.iso
fc161be58326097d6285fc83dc247f1fa289a187bc25bea435b9a4bd16b7b966 ubuntu-24.04.3-desktop-amd64-StudNet-Bonn.iso

$ sha256sum ubuntu-24.04.3-desktop-amd64-dogado-GmbH.iso
a0de50270acf5e4563d37b83fc84339f5cb63e541de233064caa3f5e8b2bbe89 ubuntu-24.04.3-desktop-amd64-dogado-GmbH.iso

$ sha256sum ubuntu-24.04.3-desktop-amd64-NL-Macarne.iso
ab5bccdc6bd9b6ca7433e8b05ad195595db3bc7616f12d9e980bb08daf95525c ubuntu-24.04.3-desktop-amd64-NL-Macarne.iso

Ich kann mir nicht vorstellen, dass diese offiziellen Stellen irgendwie gehackte Versionen haben.
Stimmt etwas mit meinem sha256sum oder mache ich irgendetwas grundsätzlich falsch?

$ sha256sum --version
sha256sum (GNU coreutils) 8.30
...
Danke!

Kann ich hier nicht nachvollziehen.

[tomx3@tomtomtom ~]$ wget https://releases.ubuntu.com/24.04.3/ubuntu-24.04.3-desktop-amd64.iso
--2025-12-31 10:36:34--  https://releases.ubuntu.com/24.04.3/ubuntu-24.04.3-desktop-amd64.iso
CA-Zertifikat »/etc/ssl/certs/ca-certificates.crt« wurde geladen
Auflösen des Hostnamens releases.ubuntu.com (releases.ubuntu.com)… 91.189.91.109, 91.189.91.107, 185.125.190.37, ...
Verbindungsaufbau zu releases.ubuntu.com (releases.ubuntu.com)|91.189.91.109|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 6345887744 (5,9G) [application/x-iso9660-image]
Wird in ‘ubuntu-24.04.3-desktop-amd64.iso’ gespeichert.

ubuntu-24.04.3-desktop-amd6 100%[=========================================>]   5,91G  27,6MB/s    in 4m 40s  

2025-12-31 10:41:15 (21,6 MB/s) - ‘ubuntu-24.04.3-desktop-amd64.iso’ gespeichert [6345887744/6345887744]

[tomx3@tomtomtom ~]$ sha256sum ubuntu-24.04.3-desktop-amd64.iso 
faabcf33ae53976d2b8207a001ff32f4e5daae013505ac7188c9ea63988f8328  ubuntu-24.04.3-desktop-amd64.iso
[tomx3@tomtomtom ~]$ rm ubuntu-24.04.3-desktop-amd64.iso 
[tomx3@tomtomtom ~]$ wget https://ftp.halifax.rwth-aachen.de/ubuntu-releases/24.04.3/ubuntu-24.04.3-desktop-amd64.iso
--2025-12-31 10:43:44--  https://ftp.halifax.rwth-aachen.de/ubuntu-releases/24.04.3/ubuntu-24.04.3-desktop-amd64.iso
CA-Zertifikat »/etc/ssl/certs/ca-certificates.crt« wurde geladen
Auflösen des Hostnamens ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)… 137.226.34.46, 2a00:8a60:e012:a00::21
Verbindungsaufbau zu ftp.halifax.rwth-aachen.de (ftp.halifax.rwth-aachen.de)|137.226.34.46|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 6345887744 (5,9G) [application/octet-stream]
Wird in ‘ubuntu-24.04.3-desktop-amd64.iso’ gespeichert.

ubuntu-24.04.3-desktop-amd64.iso          100%[====================================================================================>]   5,91G  28,4MB/s    in 3m 39s  

2025-12-31 10:47:23 (27,7 MB/s) - ‘ubuntu-24.04.3-desktop-amd64.iso’ gespeichert [6345887744/6345887744]

[tomx3@tomtomtom ~]$ sha256sum ubuntu-24.04.3-desktop-amd64.iso 
faabcf33ae53976d2b8207a001ff32f4e5daae013505ac7188c9ea63988f8328  ubuntu-24.04.3-desktop-amd64.iso
[tomx3@tomtomtom ~]$ 

An den Servern liegt es also wohl eher nicht...

Dein System ist seit mehr als einem halben Jahr aus dem Support und hat seitdem keine Updates mehr erhalten und muss somit als potentiell kompromittiert angesehen werden. Vielleicht da mal ansetzen. 😈

Davon abgesehen, daß 20.04 seit 8 Monaten End of Service ist, Dein System ob der langen Aktualisierungslücke als kompromittiert anzusehen ist, Du darüberhinaus wissentlich falsch "Ubuntu-Version: Ubuntu 22.04 (Jammy Jellyfish)" angegeben hast - wie/womit ziehst Du ubuntu-24.04.3-desktop-amd64.iso? Vermutlich sind die Files nicht vollständig.

https://releases.ubuntu.com/24.04/

Linuxonly schrieb:

[…] Alle Dateien sind 6345887744 Byte lang, jedoch die Hash-Summen sind allesamt unterschiedlich.

Die wahrscheinlichste Erklärung für solche Effekte ist, dass das Programm, welches Du zum herunter laden verwendest, oder das Programm, mit dem Du die Prüfsumme ermittelst, oder die Software, die für die Ablage der Dateien auf der Platte zuständig ist, fehlerhaft arbeitet. Vielleicht ist mindestens eine dieser Komponenten mit Schadsoftware infiziert.

Gegenmaßnahmen:

• Rechner sofort vom Netzwerk trennen.

• Rechner ohne Netzwerk von einem schreibgeschützten Medium booten.

• Alle angeschlossenen magnetischen Festplatten vollständig mit Nullen überschreiben oder – sofern möglich – secure erase verwenden.

• Alle angeschlossenen SSDs mit secure erase löschen.

• Neu installieren.

Danke für die schnellen Antworten!
Sämtliche Dateien, nichts Böses ahnend, habe ich habe ich vom Browser (Brave) aus heruntergeladen. Um die "trust issues" dem Browser gegenüber auszuschließen, habe ich soeben mit "wget https://releases.ubuntu.com/24.04.3/ubuntu-24.04.3-desktop-amd64.iso" auch eine Datei geholt, die zwar wieder die gleiche Länge (6.345.887.744 Byte) hat, aber die Prüfsumme ist schon wieder eine andere ☹ Also wird es an sha256sum und höchstwahrscheinlich auch sonstigen Komponenten des Systems liegen... Genau deswegen wollte ich seit einer Weile das System auf den neuesten Stand bringen (halt komplett neu installieren), aber den heruntergeladenen Dateien kann ich jetzt nicht trauen.
An von.wert: Zugegeben, "wissentlich falsche" Angabe war vorsätzlich. Allerdings aus Notwehr, denn um ein neues Thema hier zu starten, muss man das System UND die Version angeben, sonst darf man nicht posten. Das älteste, dass man anklicken kann, ist derzeit (aus guten Gründen) 22.04...
Tja, muss halt von einem anderen System aus neu herunterladen, ein schreibgeschütztes Medium erstellen und neu installieren...
Unter Linux hatte ich bisher keine solche "issues", das finde ich schon ein wenig erschreckend. Hatte das jemand schon gehabt?
Danke nochmals!

Vor Jahren (und 20.04 ist nun mal uralt) hat es ein Problem mit einem File in einem Paket, wovon sha256sum bzw. dessen Paket coreutils abhängen, gegeben. Damit haben sha256sum u.a. wie gpg nicht mehr korrekt gearbeitet, es hat falsche Ausgaben gebracht. Durchaus möglich, daß Deine Downloads i.O. sind.

Btw., Dir ist aber schon klar, daß Du jedesmal 5.9 GiB ziehst?

Linuxonly schrieb:

muss halt von einem anderen System aus neu herunterladen

Warum hast Du das nicht gleich gemacht?

...und wenn Du schon neu ziehen und installieren mußt, dann gleich 25.10 (wenn es denn weiter Ubuntu sein soll). Davon ist es Ende April nur ein Schritt auf 26.04 statt eines Sprunges im August auf 26.04.1.

https://releases.ubuntu.com/25.10/ → ubuntu-25.10-desktop-amd64.iso (5.3 GiB)

Linuxonly, laß diesen Unfug mit ständigen "\\" weg! Absätze werden mit 2x Return erzeugt.

Linuxonly schrieb:

Allerdings aus Notwehr, denn um ein neues Thema hier zu starten, muss man das System UND die Version angeben, sonst darf man nicht posten.

Nein, muss man nicht. Wenn man aber Ubuntu auswählt muss man auch eine gültige Version auswählen.

tomtomtom schrieb:

Linuxonly schrieb:

Allerdings aus Notwehr, denn um ein neues Thema hier zu starten, muss man das System UND die Version angeben, sonst darf man nicht posten.

Nein, muss man nicht. Wenn man aber Ubuntu auswählt muss man auch eine gültige Version auswählen.

Das meine ich ja! Ich habe "Ubuntu" ausgewählt und dann habe ich beim Veröffentlichen nur eine kurze Fehlermeldung bekommen, ohne Hinweis, wo genau etwas fehlt. Und so habe ich dann gecheckt, dass man noch eine Version aus dem entsprechenden Menü auswählen muss. Leider war 20.04 nicht dabei...

Aber ich bin nun mal neu hier. Und mit 20.04 wird es sich schnell bei mir (notgedrungen) erledigen.

Linuxonly,

wenn der Direktdownload deiner Meinung nach nicht richtig funktioniert, dann versuche es doch mit Torrent.

Das hat den Vorteil, dass die Prüfsumme schon während des Downloads überprüft wird.

BitTorrent

Memtest? Smartctl? Dmesg?

Test mit lokal produzierter Testdatei:

1
2
3
4
5
6
7

$ yes {0001..1024} | head -c 1G | tee test.a test.b | sha256sum
8ab3e65f7257299ce6e98824a64bcbcae6540b06f9bb02220bd337a6e29133ab  -
$ sha256sum test.{a,b}
8ab3e65f7257299ce6e98824a64bcbcae6540b06f9bb02220bd337a6e29133ab  test.a
8ab3e65f7257299ce6e98824a64bcbcae6540b06f9bb02220bd337a6e29133ab  test.b
$ cmp test.a test.b && echo OK || echo FAIL
OK

Mit cmp kannst du auch deine ISO-Dateien vergleichen, zeigt dir dann an wo der Unterschied ist. Das kann man dann auch mal näher mit hexdump anschauen.

1
2
3
4
5
6
7
8
9

$ cmp test.a test.b && echo OK || echo FAIL
test.a test.b differ: byte 128974849, line 25191
FAIL
$ hexdump -C -s 128974840 -n 16 test.a
07affff8  30 34 30 39 20 30 34 31  78 20 30 34 31 31 20 30  |0409 041x 0411 0|
07b00008
$ hexdump -C -s 128974840 -n 16 test.b
07affff8  30 34 30 39 20 30 34 31  30 20 30 34 31 31 20 30  |0409 0410 0411 0|
07b00008

Reicht manchmal zur Beurteilung, ob das komplett falsche Daten sind. Oder Nullen. Oder Bitflips...

Torrent ist auch eine Idee, das hat blockweise Prüfsummen - das Problem bei der Prüfsumme ist ja, du weißt dann daß es falsch ist, aber nicht was genau wo wie warum falsch...

Aber auch hier, wenn die Korruption erst nach dem Schreiben entsteht, hilft es nur wenn der Torrent-Client nochmal erneut verifiziert. Manche Clients machen das nicht (weils eben dauert) sondern cachen das einfach. Der Fall daß der Torrent-Client sagt, alles OK aber Datei trotzdem falsch, den gibts dann halt doch.

Linuxonly schrieb:

... Hatte das jemand schon gehabt?

Ja, wenn sich ein Datenträger verabschiedet oder Fehler im Dateisystem sind:

rklm schrieb:

... Schau mal auf die S.M.A.R.T.-Daten (sudo smartctl --all /dev/sda usw.), ins Journal (journalctl) und als letzte Maßnahme fsck von der Recovery-Console.

Bei mir half nur noch fsck und danach wurde der Datenträger in die ewigen Jagdgründe verabschiedet.