Announcement: there is an English version of this forum on 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?
Wieso willst du eigentlich unbedingt dieses 16GB-Image haben? Nimm doch einfach ein stinknormales ISO-File und pack es auf den Stick.
... 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.
Merksatz: Wenn ein Hersteller eines Mediums 16GB schreibt, dann meint er 16GB. Nicht -- wie mancher es sich vielleicht wünschen würde -- 16GiB.
Bei Debian und moderner hardware braucht man öfters die Firmware aus "non-free". Daher würde ich auf den 16GB Stick lieber das 4GB Image aus non-free drauf pappen: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.2.0+nonfree/amd64/jigdo-dvd/ Allerdings lädt auch das mittlererweile etliches aus dem Internet, da es einiges an Updates gab.
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:
1 | Festplatte /dev/sdc: 28,88 GiB, 30987517952 Bytes, 60522496 Sektoren |
Da fehlt also ca. 1GB! Anderer Stick, laut Hersteller 64 GB groß:
1 | Festplatte /dev/sdc: 58,93 GiB, 63250104320 Bytes, 123535360 Sektoren |
Da sind es ca. 750 MB, die fehlen. Natürlich gibt's auch Hersteller, die das ehrlicher angeben.
:
Bearbeitet durch User
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.
Oh sorry, habe gerade erst die 32GB gelesen/realisiert. Da hat er tatsächlich zu wenig. Er ist falsch deklariert, Umtauschrecht geltend machen!
Hab's gerade mal bei einem von meinen getestet.
1 | # sfdisk -l /dev/sde |
2 | Disk /dev/sde: 29,5 GiB, 31611420672 bytes, 61741056 sectors |
3 | Disk model: Transcend 32G |
Die Sausäcke, nur 31,6GB. Betrüger wohin man schaut. ;-)
ü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)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.