hallo Debian installierer,
ich wollte mal mehr offline-installieren und habe mich entschieden für
https://cdimage.debian.org/debian-cd/11.2.0/amd64/jigdo-16G/
Jigdo-Download des knapp 16GB grossen Image inkl. sha256 Verifikation
hat gut geklappt.
PROBLEM:
das Ding geht nicht auf mein USB Stick :-/
Mein USB Stick ist ein SanDisk 16GB Ultra Flair USB 3.0, ja ich hab
sogar 2 Exemplare davon und mit beiden dasselbe verhalten.
Der Rechner bootet vom Stick, Die Debian-Installation startet.
Die 'Install media verification' schlägt fehl und natürlich schlägt die
Installation irgendwo "später" fehl. Der Zielmassenspeicher ist dann
nicht bootbar, nicht benutzbar.
FRAGE:
Kann hier jemand von erfolgreichem Einsatz mit o.g. Image berichten?
(habe ich wirklich 2 Montagsexemplare von USB-Sticks erwischt, welche
netto nur gerade 15.xyGB Platz bieten und die Macher des Images sind zu
nah an die Groessengrenze von SanDisk-Sticks?)
Dann wird wohl dein USB-Stick etwas kleiner sein, als das, von dem das
Debian-Image gezogen wurde.
Aber erstmal eine andere Frage. Wie hast du das Image aufn USB-Stick
bekommen?
... schrieb:> Aber erstmal eine andere Frage. Wie hast du das Image aufn USB-Stick> bekommen?
[c]# dd if=imagexyz16GB.ido of=/dev/sdf bs=1M status=progress
[c/]
Mit einem Datenträger von 32MB und 128MB Groesse komme ich durch, aber
dann ist davon sooo viel Platz verschwendet... ;-)
> Wieso willst du eigentlich unbedingt dieses 16GB-Image haben? Nimm doch> einfach ein stinknormales ISO-File und pack es auf den Stick.
das ist eines der von Debian angebotenen "stinknormalen ISO-file", bloss
dass es eben eine MENGE Debian-Packages mit dabei hat.
Die anderen Debian ISO-Images sind "durchwegs" von der Machart
"NetInst", holen sich also die Riesenmenge an Packages direkt aus dem
Internetz (davon habe ich, das kenne ich, das tut) Nicht so prickelnd
wenn man nicht wirklich Breitbandig angebunden ist, am Ort wo man zu
installieren hat...
(und nein: ich hab nicht nur 1x zu installieren und darum wollte ich was
anderes versuchen)
übender schrieb:> ich wollte mal mehr offline-installieren und habe mich entschieden für> https://cdimage.debian.org/debian-cd/11.2.0/amd64/jigdo-16G/>> PROBLEM:> das Ding geht nicht auf mein USB Stick :-/
Wie erstellst Du denn den USB-Stick? Wenn Du dazu die Software
"unebootin" nutzt, so hatte Jack V. kürzlich in einem anderen Thread
dankenswerterweise darauf hingewiesen, daß Debian von dieser Software
mittlerweile in seiner Dokumentation (hier: [1]) sogar expressis verbis
abrät. In der verlinkten Dokumentation wird zur Verwendung von cp(1)
oder dd(1) unter Linux, sowie von Win32DiskImager unter Windows gerat.
Ansonsten kann es natürlich auch sein, daß Dein Image einige wenig
größer ist als Deine USB-Sticks. Dann böte sich die Anschaffung Nutzung
eines größeren an.
[1] https://www.debian.org/releases/stable/amd64/ch04s03.en.html
übender schrieb:> Mit einem Datenträger von 32MB und 128MB Groesse komme ich durch, aber> dann ist davon sooo viel Platz verschwendet... ;-)
Na dann installier den Scheiß doch einfach ganz fix und lösche danach
den Stick, um ihn wieder einer vernünftigen Verwendung zuzuführen.
Alternativ: kaufe einfach einen 16GB-Stick, der auch tatsächlich 16GB
hat.
Als Installationsmedium für Debian nutze ich einen 32GB-Stick für ein
4GB-Image. In den restlichen Platz installiere ich mir ein lauffähiges
und gut mit Werkzeugen ausgestattetes Debian-System. Das hat mir schon
geholfen, falls as Zielsystem rumzickt, die Probleme zu finden, Daten zu
retten oder auch zur Ablage weiterer .deb-Pakete aus anderen Quellen
(ubuntu, security, backports, Fremdtreiber uvm.
Vielleicht ist das eine Option für Dich, die "überchüssigen" nicht ganz
16GB eines 32GB-Sticks zu nutzen.
Mario P.
c-hater schrieb:> Alternativ: kaufe einfach einen 16GB-Stick, der auch tatsächlich 16GB> hat.
Leichter gesagt als getan. Die Hersteller nehmen's mit den Größenangaben
da nicht immer so genau, und auf der Schachtel steht eher selten sowas
wie:
1
Kapazität: 16GB*
2
3
* und wir meinen tatsächlich 16GB
übender schrieb:> Mit einem Datenträger von 32MB und 128MB Groesse
… würde es mich nicht wundern, wenn das nicht richtig bootet.
Laut Jigdo-Information ist das ISO-Image 15778799616 Bytes groß. In
einem Unboxing-Video wurde eine Sektorzahl von 30031840 angezeigt, was
einer Speichergröße von 15376302080 entspricht. Also haben entweder die
Debian-Maintainer den freien Speicher gängiger USB-Sticks überschätzt
oder Sandisk legt die Zahl von Reservesektoren besonders großzügig aus.
Wie auch immer, es bleibt Dir nichts anderes übrig, als einen größeren
Stick zu nehmen.
Norbert schrieb:> Merksatz:> Wenn ein Hersteller eines Mediums 16GB schreibt, dann meint er 16GB.> Nicht -- wie mancher es sich vielleicht wünschen würde -- 16GiB.
Nein, eben nicht. Er meint etwas, das ganz grob in dem Bereich liegt.
Beispiel ein laut Hersteller 32GB großer Stick, den ich hier habe. fdisk
unter Linux meint:
Tja Rolf, da unterliegst du einem Irrtum.
> Festplatte /dev/sdc: 28,88 GiB, 30987517952 Bytes, 60522496 Sektoren
Der Stick hat 28,88 GiB (base2), das sind 30.987517952 MB (base10) also
metrische Größen.
übender schrieb:> (habe ich wirklich 2 Montagsexemplare von USB-Sticks erwischt, welche> netto nur gerade 15.xyGB Platz bieten und die Macher des Images sind zu> nah an die Groessengrenze von SanDisk-Sticks?)
Überprüfe mal den Speicher:
https://fight-flash-fraud.readthedocs.io/en/latest/
Mario M. schrieb:> Also haben entweder die> Debian-Maintainer den freien Speicher gängiger USB-Sticks überschätzt
Wohl eher das. Auf den Usb-Sticks geistern oft Sachen drauf, die auch
Speicher verbrauchen.
Man müsste erstmal ein Diagnose-"Gerät" drauf ansetzen.
Ich frage mich aber gerade: Disketten konnte man früher so formatieren,
dass die noch etwas mehr Speicher haben, als sonst üblich. Müsste das
bei Usb-Sticks nicht auch gehen? Man bräuchte vielleicht ein extra
sparsames, aber trotzdem noch kompatibles Format.
Partitionieren soll ja mit NTFS ganz gut gehen.
> Ich frage mich aber gerade: Disketten konnte man früher so formatieren,> dass die noch etwas mehr Speicher haben, als sonst üblich. Müsste das> bei Usb-Sticks nicht auch gehen? Man bräuchte vielleicht ein extra> sparsames, aber trotzdem noch kompatibles Format.
Nein, das sind 2 komplett unterschiedliche paar Schuhe.
In FLASH-speicher (auch in RAM, ROM, also alles Chip-basierte) gibt es
immer nur eine endliche ganzzahlige Menge an Speicherzellen; diese
bestehen aus Schaltungsstrukturen welche bei der Chipherstellung gezielt
gemacht werden ("gezeichnet", belichtet).
Davon kann man bei der Anwendung nach der Herstellung nicht "welche
dazumogeln".
Bei Floppies hingegen ist die Traegerscheibe "in Broeseln" magnetisch
und man benötigt eine Mindestmenge an solchen Broeseln um "einen
Flecken" sicher als "1" oder "0" später wieder zu lesen.
Aus praktischen Gründen lässt man die Floppyscheibe mit konstanter
Drehzahl rotieren und die "Flecken" werden über zeitliche Taktung
gemacht; daraus folgt unweigerlich dass in den inneren Kreisspuren diese
"Flecken" als kürzere Strecken ausfallen (näher am nötigen minimum) und
auf den äußeren Kreisspuren als längere Strecken ausfallen (deutlich
mehr als das minimum).
Die physikalische Form der Aufzeichnung auf magnetischen Datentraegern
ist also analog und zumindest bei Floppies schon gar nicht eng gekoppelt
mit was die Struktur des Materials hergibt. (Festplatten und moderne
Magnetbänder sind eine andere Hausnummer...)
Solche erwähnte Sonderformate nutzten die Betrachtung aus, dass im
Standardfall auf den äusseren Kreisspuren "Magnetfläche verschwendet"
ist, entsprechend wurde damit versucht -im Rahmen von was die
Floppycontroller hergaben- die "Fleckengrösse" auf den äusseren
Kreisspuren kürzer zu machen (näher ans Minimum zu bringen) um mehr
davon unter zu bringen.
Die alten DD (Double Density) Floppies auf den "Schukarton-Macs" hatten
das Standardmässig und fassten 800kB, anstatt bloss 720kB wie bei PCs.
Wow: 11% mehr!
Jene Floppylaufwerke drehen die Scheiben aber in 4 (WIMRE) verschiedenen
Drehzahlstufen, je nach aktuellem Radius der Kreisspuren. PC-Floppies
können das jedoch nicht (K.A. ob die Einschränkung vom LW oder den
Controllern vorgegeben ist).
Bei den HD (High Density) Floppies hat Apple jedoch auf solche
Sperenzchen verzichtet, was letztlich den Floppybasierten Datenaustausch
deutlich erleichtert hat, v.a. zu den Macs hin.
Ein weiterer Kniff ist die Distanz zwischen den Kreisspuren. Die
Kreisspuren liegen nicht dicht an dicht nebeneinander um mechanische
Toleranzen auszugleichen, vorallem die Zentrierung von einem Einlegen
zum nächsten oder in einem Laufwerk und in anderen.
Letztlich wurde von IBM dank höherer Präzision der LW von HD=1440kB auf
??=2880kB verdoppelt - aber spät und eben nur mit Laufwerke von IBM!
(zur Technik bei LS-120 & Zip-Floppies: nicht hier... Bitte selber
nachschlagen. Bernoulli ebenfalls :-p und auch was bei CD/DVD
rausgekommen ist wo die Prioritäten anders waren)
----
Der Andere Denkansatz "mehr Information" in gegebener Anzahl
Speicherstellen unterzubringen nennt sich Datenkompression. Einfach
komprimierte Dateiarchive ablegen.
Oh Wunder: Debian-packages sind standardmässig komprimiert!
Und ja: "selber" komprimierende Dateisysteme gibt es, da muss man sich
als Anwender nicht mehr "zu Fuss" darum kümmern. Eine ganze Auswahl ist
insbesondere unter Linux verfügbar, wird hauptsächlich im Bereich
"Embedded" genutzt für Gerätefirmware (in ROM, gerne auch FlashROM -
womit wir wieder bei USB-Sticks wären...)
Sowas bringt aber andere Nachteile mit sich.
Im Anwendungsfall "Installation" wo der Datenträger nur lesend
eingesetzt ist könnte dies eine Überlegung/Abwägung Wert sein - diese
Übung überlasse ich aber den Debian-Leuten welche sich um die
Aufbereitung der Installationsmedien kümmern...
flopper mit graubart schrieb:> Nein, das sind 2 komplett unterschiedliche paar Schuhe.
Vielen Dank für die (weiter unten) ausführliche(re) Antwort. :)
(+1)
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten