Broken pipe Debootstrap failed bei Installation von Debian 11 testing

[empty_string]

Hallo,
Ich wollte das letzte testing Image auf einen neuen Laptop über den installer von einem USB Stick installieren.
Bei der Installation des Basissystems schlägt der Installer fehl. Den letzten Teil des syslog habe ich angehangen.
Ich würde mich über einen Hinweis sehr freuen, vielen Dank!
Gruß
empty_string

Code: Alles auswählen

.... Eine ganze Reihe Broken pipe Meldungen....
Oct 15 09:42:42 debootstrap: sh: write error: Broken pipe
Oct 15 09:42:42 debootstrap: sh: write error: Broken pipe
Oct 15 09:42:42 debootstrap: sh: write error: Broken pipe
Oct 15 09:42:42 base-installer: error: exiting on error base-installer/debootstrap-failed
Oct 15 09:42:55 main-menu[570]: WARNING **: Configuring 'bootstrap-base' failed with error code 1
Oct 15 09:42:55 main-menu[570]: WARNING **: Menu item 'bootstrap-base' failed.
Oct 15 09:42:59 main-menu[570]: INFO: Modifying debconf priority limit from 'high' to 'medium'
Oct 15 09:42:59 debconf: Setting debconf/priority to medium
Oct 15 09:42:59 main-menu[570]: INFO: Falling back to the package description for brltty-udeb
Oct 15 09:42:59 kernel: [ 1225.132619] Lockdown: archdetect: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
Oct 15 09:42:59 kernel: [ 1225.134997] Lockdown: archdetect: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7

[Tintom]

Gab es Fehler bei der Übertragung auf den Stick? Hat der Stick evtl. einen Teildefekt? Wie hast du das Image übertragen? Einen Hinweis könnte der Vergleich der Checksummen geben. Wenn du mit sha256sum <Imagedatei> und sha256sum /dev/USB-Stick die Checksummen vergleichst, sollten beide Strings identisch sein.

[empty_string]

Vielen Dank für deine Antwort.
Die strings sind nicht identisch, habe das image 2x runtergeladen und auf unterschiedliche USB Sticks gespielt. Woran könnte das liegen?

Einmal mit

Code: Alles auswählen

cp debian-bookworm-DI-alpha1-amd64-netinst.iso /dev/sdb; sync 

und einmal mit

Code: Alles auswählen

dd if=debian-bookworm-DI-alpha1-amd64-netinst\(1\).iso of=/dev/sdb; sync

Code: Alles auswählen

sha256sum Downloads/debian-bookworm-DI-alpha1-amd64-netinst.iso /dev/sdb
23f1d510c59bea645d46b9800219ebe30388a1832af715f31a9bb3c5717cd8f2  Downloads/debian-bookworm-DI-alpha1-amd64-netinst.iso
b48f677eb7611826fc16a6f584de8db1b36eee14281807397c5d68fba4ee0c77  /dev/sdb


sha256sum Downloads/debian-bookworm-DI-alpha1-amd64-netinst\(1\).iso /dev/sdb
23f1d510c59bea645d46b9800219ebe30388a1832af715f31a9bb3c5717cd8f2  Downloads/debian-bookworm-DI-alpha1-amd64-netinst(1).iso
81965cc10418b761dd16477c84034febc0f44e88bc8c722aa78a7347ac294d93  /dev/sdb

[MSfree]

Ob cp oder dd, es sollte beides zum selben Ergebnis führen. Zumindest ist an deinen beiden Befehlen nichts auszusetzen.

Da die Prüfsummen bei beiden Versuchen unterschiedlich sind, würde ich von einem kaputten USB-Stick ausgehen.

[DeletedUserReAsG]

Ich würde für eine ziemlich wahrscheinliche Erklärung des Ausgangsproblems lieber das „DI-alpha1“ im Namen der Images von Debian 12 (Testing) zur Kenntnis nehmen.

Dass sich die Prüfsummen der Sticks hier unterscheiden, ist hingegen normal und erwartbar: sha256sum wird hier angewiesen, den gesamten Stick zu hashen – also auch die Teile mit undefiniertem Inhalt außerhalb des geschriebenen Images.

[MSfree]

Dass sich die Prüfsummen der Sticks hier unterscheiden, ist hingegen normal und erwartbar:

Das sehe ich anders.

sha256sum wird hier angewiesen, den gesamten Stick zu hashen – also auch die Teile mit undefiniertem Inhalt außerhalb des geschriebenen Images.

Der vordere Teil, der durch das Image überschrieben wird, ist in den beiden Fällen identisch. Der hintere mit zufälligen Werten beschriebene Teil ändert sich durch das Beschreiben des vorderen Teils nicht. Die Prüfsummen müssen also, wenn der Stick in Ordnung wäre, identisch sein.

Wearlevelling darf übrigens nicht der Auslöser solcher Unterschiede sein, denn das darf nicht dazu führen, daß sich Inhalte unkontrollliert verändern, sonst hätte man auch ganz schnell Datensalat im Dateisystem.

[DeletedUserReAsG]

Die Prüfsummen müssen also, wenn der Stick in Ordnung wäre, identisch sein.

Nein.

[MSfree]

Die Prüfsummen müssen also, wenn der Stick in Ordnung wäre, identisch sein.

Nein.

Dann erklär mal, warum.

[DeletedUserReAsG]

Dann erklär mal, warum.

Bin ich dein Diener, oder wie kommst du auf die Idee, mich im Imperativ anzusprechen?

Anyway:

[…] habe das image 2x runtergeladen und auf unterschiedliche USB Sticks gespielt.

(Hervorhebung von mir)

Gegenvorschlag: Blick auf meine Signatur werfen, Image laden, mit cp und dd wie oben gezeigt auf einen Stick schreiben und jeweils den gesamten Stick hashen. Wenn unterschiedlich, wegwerfen (weil muss ja kaputt sein) und nächsten Stick nehmen, solange wiederholen, bis kein Stick mehr da ist. Die ganzen kaputten Sticks kannst du mir dann ja schicken.

[GregorS]

Das sehe ich anders.

sha256sum wird hier angewiesen, den gesamten Stick zu hashen – also auch die Teile mit undefiniertem Inhalt außerhalb des geschriebenen Images.

Der vordere Teil, der durch das Image überschrieben wird, ist in den beiden Fällen identisch. Der hintere mit zufälligen Werten beschriebene Teil ändert sich durch das Beschreiben des vorderen Teils nicht. Die Prüfsummen müssen also, wenn der Stick in Ordnung wäre, identisch sein.

Du widersprichst Dir.
Einerseits sagst Du, dass der Bereich mit zufälligen Daten nicht geändert wird, Dann sagst Du, dass die Prüfsummen identisch sein müssten.

Wie ich das sehe, prüft

Code: Alles auswählen

sha256sum /dev/sdb

den ganzen Stick - nicht nur den durch das Image überschriebenen Bereich. D.h. es werden auch zufällige Daten einbezogen. Das kann IMO nicht zu identischen sha-Summen führen.

Gruß

Gregor

[Tintom]

Du widersprichst Dir. [...]

Der Punkt war hier, denke ich, dass verschiedene USB-Sticks verwendet wurden. Diese Info habe ich auch überlesen.

[DeletedUserReAsG]

Kann allerdings auch bei ein und demselben Stick Abweichungen im undefinierten Bereich geben: einerseits, weil dd in festen Blöcken schreibt, und cp nicht, so dass es da auf den letzten Bytes Unterschiede geben kann, andererseits weil es tatsächlich ein Wear-Leveling im unpartitionierten Bereich geben kann (wenngleich die in billigen Sticks verbauten Controller wohl die entsprechenden Informationen nicht verarbeiten).

[Tintom]

Mal zusammenfassend für @empty_string: Entweder du testest mit dem identischen Stick, dann sollten die Prüfsummen des Sticks identisch sein (Ausnahmen davon hat @niemand beschrieben). Sind sie es nicht, kann es ein Hinweis sein, dass die Daten falsch geschrieben wurden. Alternativ könntest du nach dem Schreiben auf den Stick die geschriebenen Daten wieder auslesen, z.B. so:
SIZE=$(du -b <Pfad_zur_ISO> | cut -f1); head -c $SIZE <USB-Stick> | sha256sum - <Pfad_zur_ISO>
Der Stick darf dann unterschiedlich sein, allerdings müssen hier die Prüfsummen identisch sein, sonst ist beim Übertragen der Datei etwas falsch gelaufen.

[empty_string]

Okay vielen Dank für die zahlreichen Antworten.
Ich habe jetzt tatsächlich mehrere Sticks probiert und alle vorher feinsäuberlich mit gparted formatiert etc.
Alle drei Installation funktionieren jetzt, mini.iso, netinstall und die DVD Version.
Da ich offline installieren musste habe ich zum ersten mal festgestellt, dass sich lediglich die CD/DVD Variante als "CDRom" einbinden lässt, die anderen brauchen dann irgendwann einen Spiegelserver.
Also danke nochmals!

[DeletedUserReAsG]

alle vorher feinsäuberlich mit gparted formatiert etc.

Damit hast du dir völlig überflüssige Arbeit gemacht. Erstaunlicherweise machen das viele Leute so – frag‘ mich, wo das herkommen mag. Beschäftigt sich heute keiner mehr mit den Sachen, die er macht?

[uname]

Ich habe den Thread nicht wirklich gelesen.

Aber ich möchte mal gerne auf grml-debootstrap (Doku) hinweisen.
Dieses Paket ist standardmäßig im Live-Linux https://grml.org vorhanden, kann aber auch bei Debian oder Ubuntu schnell nachinstalliert werden.

Es ist ein Wrapper rund um debootstrap. Es installiert kein GRML, sondern Debian.
Parameter muss man nicht direkt angeben. Alle Installationsparameter werden abgefragt.

Meine Vorgehensweise war mal bei einem alten Laptop, der nicht von einer Debian-Installations-CD booten wollte (geschweige denn dann WLAN konnte):
1.) Booten GRML-USB/CD-ISO mit Option toram -> USB-Stick kann dann abgezogen werden, CD kann entfernt werden
2.) WLAN konfigurieren in GRML-Live-Linux (da war der WLAN-Treiber kein Problem)
3.) Installation Debian über "grml-debootstrap"