ISO Images mounten

[Kamikaze]

http://wiki.bsdforen.de/index.php/ISO_Images_mounten

Es fehlen noch die Anweisungen für Net- und OpenBSD. Vervollständigung von jemandem der weiß wie's geht wäre gut.

 

[quarzsnoopy]

NetBSD 3.0

Hab mit dem Editieren von Wiki keine Erfahrungen und hab jetzt im Moment auch leider keine Zeit.
Deshalb pumpe ich das hier mal fix rein:


vnconfig -c /dev/vnd0 /root/livecd/NetBSD-LiveCD.iso
vnconfig -l
# vnd0: / (/dev/wd0a) inode 1488582
# vnd1: not in use
# vnd2: not in use
# vnd3: not in use

mount -t cd9660 /dev/vnd0a /IMAGE
mount
# /dev/vnd0a on /IMAGE type cd9660 (read-only, local)

ls -la /IMAGE/
.... und was man dann auch alles tun möchte ....

.... nach Abschluss seiner Arbeiten dann alles wieder abbauen:
umount /IMAGE
vnconfig -u vnd0
vnconfig -l
# vnd0: not in use
# vnd1: not in use
# vnd2: not in use
# vnd3: not in use


Mehr Infos mit "man vnconfig" unter EXAPLES...

 

[Kamikaze]

Danke, ich habe es eingefügt.

 

[SierraX]

Ich halte das für zu aufgebläht. Im Grunde brauchst du (zu FreeBSD) Nur mdconfig durch vnconfig zu ersetzen und hast das ergebniss welches du erreichen wolltest. Mal davon abgesehen, das vnd0a nicht stimmen dürfte, da daß disklabel bei i386 vnd0d vorsieht.

 

[oenone]

OpenBSD sollte im grunde äquivalent zu netbsd sein... (besser svnd0 statt vnd0, sonst alles gleich)

auf bald
oenone

 

[quarzsnoopy]

Ich halte das für zu aufgebläht. Im Grunde brauchst du (zu FreeBSD) Nur mdconfig durch vnconfig zu ersetzen und hast das ergebniss welches du erreichen wolltest. Mal davon abgesehen, das vnd0a nicht stimmen dürfte, da daß disklabel bei i386 vnd0d vorsieht.

Das ist nicht ganz richtig, da die Parameter von "mdconfig" nicht die gleichen sind, die "vnconfig" braucht. Und genau diese Kleinigkeiten haben mir beim umschreiben und anpassen meiner Scripte immer Zeit gekostet. Das ist so wie es ist garnicht so schlecht!


Hier meine FreeBSD-Beispiele:


# Beispiel fuer FreeBSD bis zur Version 4:
# ========================================
#
# vnconfig -c /dev/vn0c /var/tmp/NetBSD-LiveCD.iso
# mount -t cd9660 /dev/vn0c /IMAGE
#
# umount /IMAGE
# vnconfig -u /dev/vn0c
#
#
#
# Beispiel fuer FreeBSD ab der Version 5:
# =======================================
#
# mdconfig -a -t vnode -u 1 -f /var/tmp/NetBSD-LiveCD.iso
# mount -t cd9660 /dev/md1 /IMAGE
#
# umount /IMAGE
# mdconfig -d -u 1

 

[Kamikaze]

Verbesserungen wenn möglich selbst einpflegen, ich habe nur FreeBSD installiert.

 

[SierraX]

@quarzsnoopy: Ich glaub wir machen das alle schon lang genug, als das wir wissen, das die Parameter 2 verschiedener Befehle voneinander abweichen (können), bin halt auch ein Fauler Sack also hab ich die ganzen Parameter nicht aufgeschrieben.
Was ich natürlich nicht wusste, das bei FreeBSD 4 es so ausschaut wie es das bei Net- und OpenBSD immernoch tut. Kann ggf. FreeBSD 5 vnconfig auch noch?

Mir hat halt das mit der Liste nicht gefallen (unnötig und verwirrend) und daß das Device scheinbar falsch ist, da es sich dabei nur um / handelt und nicht um die ganze Disk. Vergleich mal hier

http://www.netbsd.org/de/Documentation/bootcd.html#netbsd_mountimage

 

[quarzsnoopy]

....
Was ich natürlich nicht wusste, das bei FreeBSD 4 es so ausschaut wie es das bei Net- und OpenBSD immernoch tut. Kann ggf. FreeBSD 5 vnconfig auch noch?

Was ich so weiss, nicht (FreeBSD 6.0):

# vnconfig -l
ERROR: vnconfig(8) has been discontinued
Please use mdconfig(8).
You have new mail in /var/mail/root

....
Mir hat halt das mit der Liste nicht gefallen (unnötig und verwirrend) und daß das Device scheinbar falsch ist, da es sich dabei nur um / handelt und nicht um die ganze Disk. Vergleich mal hier
http://www.netbsd.org/de/Documentation/bootcd.html#netbsd_mountimage

Hier weiss ich nicht was Du meinst. Man gibt doch immer ein Verzeichnis als Mountpoint an, nicht "/".

 

[steinlaus]

...Was ich natürlich nicht wusste, das bei FreeBSD 4 es so ausschaut wie es das bei Net- und OpenBSD immernoch tut. Kann ggf. FreeBSD 5 vnconfig auch noch?...

Laut man-Page gilt wohl:
FBSD >= 5 --> md/mdconfig (ersetzt vn/vnconfig; die man-Page spricht sogar von einer "feindlichen Übernahme" )
FBSD <= 4 --> vn/vnconfig (wobei es wohl "md", aber noch nicht "mdconfig", bereits unter 4 gab)

 

[SierraX]

Hier weiss ich nicht was Du meinst. Man gibt doch immer ein Verzeichnis als Mountpoint an, nicht "/".

vnd0a: Laut NetBSD ist das 'a' im Disklabel die root ( / ) 'b' das swap, 'c' steht für das NetBSD Slice und 'd' für die gesammte Disk

http://www.netbsd.org/guide/en/chap-inst.html#chap-inst-install-partition

Da bei einem ISO File nur selten ein Disklabel a vorhanden sein wird nämlich nur wenn es sich um eine bootfähige Disk handelt (bin ich mir aber nicht sicher) sollte ein mount vnd0a nicht funktionieren. Seis drum ich hab vorhin ein ISO gemountet und tat das mit vnd0d was klaglos funktionierte.

 

[Kamikaze]

Könnte noch jemand Prüfen ob unter NetBSD auch cat schneller ist als dd? http://wiki.bsdforen.de/index.php/ISO_Images_von_optischen_Medien_erzeugen

Nur so aus Interesse.

 

[SierraX]

Das komische ist, mit dd ist das ISO kleiner.
Habs mit der XIII CD 4 getestet

NetBSD 2.1

mit cat : Größe 462MB Zeit: 6m36
mit dd : Größe 457MB Zeit: 8m39

auslastung konnte ich nicht testen, weil ich nicht weiß wie das geht. Aber ~30% länger macht schon was aus.

 

[Kamikaze]

Ich habe einfach den Aufruf mit time gestartet, die erste Zeit ist am relevantesten, das ist die reale dauer, die 2. und 3. geben die Zeit an die die CPU damit beschäftigt war. Die sollte bei wenigen Sekunden liegen.

Immer eine frisch eingelegte CD verwenden damit sie nicht im cache liegt.

Ich habe die images mit md5 vergliechen, der hash war bei meinen Tests immer identisch. Genauso wie die Länge.

--- edit ---
Ich habe noch ein paar Tests gemacht, und es scheint das es nicht bei allen CDs identische Ergebnisse gibt. Welcher befehl jetzt das richtige image produziert, kann ich aber nicht sagen.

--- edit ---
Ich habe jetzt 2 ISOs (eine mit cat, eine mit dd) mit unterschiedlicher md5 Summe gemountet und die md5 Summen der darauf befindlichen Dateien ermittelt. Diese sind identisch mit den Dateien auf der CD.

 

[teuk]

ich habe noch ein paar Tests gemacht, und es scheint das es nicht bei allen CDs identische Ergebnisse gibt. Welcher befehl jetzt das richtige image produziert, kann ich aber nicht sagen.

Im Zeifelsfall wuerde ich mich dann an das (FreeBSD-)Handbuch halten (17.6.6).

Ein Link auf das Handbuch wuerde sich vielleicht auch ganz gut unter deinem Wikieintrag als weiterfuehrende Literatur machen, ob wohl dort das "umount" und "mdconfig -d ..." fehlt.

 

[0815Chaot]

Ich habe einfach den Aufruf mit time gestartet, die erste Zeit ist am relevantesten, das ist die reale dauer

Nö, so kannst du nicht wirklich objektiv benchmarken. Die reale Zeit wird u.a. davon beeinflußt, welche anderen Prozesse auf dem System sich während der Laufzeit von cat/dd wie viel eigene Rechenleistung angefordern. Dementsprechend bleibt für cat/dd mehr oder weniger Rechenleistung übrig und die reale Laufzeit verkürzt oder verlängert sich. Mit der Laufzeit/Performance eines bestimmten Prozesses hat das aber nicht mehr viel zu tun.

die 2. und 3. geben die Zeit an die die CPU damit beschäftigt war. Die sollte bei wenigen Sekunden liegen.

Ja, denn die CPU hat mit der Sache auch nicht sonderlich viel zu tun. Der Großteil der Arbeit liegt beim SCSI-/ATA-Controller (außer, man schaltet auf PIO). An dessen Leistungswerte wird man als Userspace-Programm allerdings nicht derart gezielt rankommen, als daß man es einem bestimmten (dem eigenen) Prozeß zuordnen könnte.

Im Grunde ist die Performance auch erstmal zweitrangig. Primär ist wichtig, daß die Daten korrekt ausgelesen werden. Gerade das scheint aber noch ganz und gar nicht klar zu sein:

Ich habe jetzt 2 ISOs (eine mit cat, eine mit dd) mit unterschiedlicher md5 Summe gemountet und die md5 Summen der darauf befindlichen Dateien ermittelt. Diese sind identisch mit den Dateien auf der CD.

Das kann schon sein, denn cat(1) arbeitet zeichenweise und dd(1) blockweise. Normalerweise will man blockorientierte Geräte wie Massenspeicher blockweise kopieren. Kopiert man zeichenweise, kann sich die Gesamtgröße eines blockorientierten Datenträgers verändern, auch wenn die Dateien selbst augenscheinlich nicht verändert wurden.

Ich denke ehrlich gesagt nicht, daß dd(1) da was falsch macht, eher liegt der Fehler bei cat(1). Das kannst du ja aber ganz leicht austesten: Mach dir ein ISO-Image mit mkisofs(8), brenne es auf CD und lese die CD dann einmal mit cat(1) und dann mit dd(1) ein. Anschließend vergleiche die MD5-Summen der drei Images. Leider habe ich momentan keine Zeit/Lust, das selbst auszutesten. In diesem Sinne: Freiwillige vor.

 

[Björn König]

Das komische ist, mit dd ist das ISO kleiner.
Habs mit der XIII CD 4 getestet

NetBSD 2.1

mit cat : Größe 462MB Zeit: 6m36
mit dd : Größe 457MB Zeit: 8m39

auslastung konnte ich nicht testen, weil ich nicht weiß wie das geht. Aber ~30% länger macht schon was aus.

Das liegt wohl an der Blockgröße, dass dd langsamer ist. Probiere mal höhere Werte, also z.B. bs=8k oder sogar bs=64k.

Ergänzung:
Ich hab das übrigens mit cat und dd unter FreeBSD 6.1 ausprobiert und konnte keinen Größenunterschied der ISO-Datei feststellen.

Björn

 

[Kamikaze]

Nö, so kannst du nicht wirklich objektiv benchmarken. Die reale Zeit wird u.a. davon beeinflußt, welche anderen Prozesse auf dem System sich während der Laufzeit von cat/dd wie viel eigene Rechenleistung angefordern....

Das ist doch vollkommen egal wenn das System nicht gerade ausgelastet ist. Es sollte quasi ausschließlich von der Geschwindigkeit des CD-Rom abhängen. Die Kopierzeiten haben sich bei jedem Versuch nur minimal unterschieden. Der Abstand von 14 Sekunden bei einer 74MB CD bleibt gleich.

Das kann schon sein, denn cat(1) arbeitet zeichenweise und dd(1) blockweise. Normalerweise will man blockorientierte Geräte wie Massenspeicher blockweise kopieren. Kopiert man zeichenweise, kann sich die Gesamtgröße eines blockorientierten Datenträgers verändern, auch wenn die Dateien selbst augenscheinlich nicht verändert wurden.

Wenn man jedes Byte einzeln nimmt kann doch eigentlich nichts verloren gehen. Das Einlesen von Blöcken scheint mir kritischer, vor allem wenn die CD mit anderer Blockgröße erzeugt wurde als die die man zum Auslesen verwendet. Kennt jemand die Standard Blockgröße bei CDs?

Wenn alle Dateien auf der CD unveränderts sind... wen kümmert's dann das das Image nicht vollkommen identisch ist?

Wie gesagt ich habe eine CD genommen, ein image mit cat erzeugt, eins mit dd. Ich habe die Images gemountet und von auf jedem Image und der CD die MD5 Summen aller Dateien erzeugt. Da die alle identisch sind kann man doch gar kein Urteil darüber Fällen welche Methode richtig oder falsch ist. Aus dem Bauch heraus zu sagen das dd richtig und cat falsch ist gefällt mir gar nicht.

 

[Björn König]

Kennt jemand die Standard Blockgröße bei CDs?

Unterschiedlich. Bei Daten-CDs in der Regel 2048 Byte. Bei Audio-CDs 2352 Byte. Es gibt noch andere Blockgrößen abhängig vom Format.

 

[Kamikaze]

Nach vielem Testen muss ich feststellen, das tatsächlich cat der Übeltäter ist, da es jedes mal aufs neue andere images erzeugt. Bzw. je nach shell unter der es läuft.

 

[nakal]

Ich habe auch die Erfahrung gemacht, dass bei man bei dd unbedingt die richtige Blockgröße eingeben muss beim Kopieren von CDs.

Bei normalen Mode1-CDs (Daten) muss es 2048 sein, sonst werden beim Image die letzten modulo bs Daten abgeschnitten, die nicht mehr geholt werden konnten.

Ich habe schon viel Ärger damit gehabt.

cat sollte keine Performanzeinbußen haben, aber ob es da richtig gemacht wird kann ich auch nicht sagen.

 

[Kamikaze]

Das Problem scheint zu sein, das die shell, die den output in eine Datei weiterleitet, diesen leider irgendwie verändert. Deswegen kann man sich auf cat nicht verlassen.

 

[ouTi]

ich nehm meist einfach ein cp

cp /dev/cd0 /home/outi/iso/disc.iso
oder
cp /dev/acd0 /home/outi/iso/disc.iso

hat bisher auch immer funktioniert, aber keine ahnung, ob irgendetwas technisch dagegen spricht

 

[Björn König]

Das Problem scheint zu sein, das die shell, die den output in eine Datei weiterleitet, diesen leider irgendwie verändert. Deswegen kann man sich auf cat nicht verlassen.

Welche Shell verwendest du denn in diesem Fall? Tritt die Veränderung mit einer anderen etwa nicht auf?

 

[Kamikaze]

Ich habe mit tcsh und sh getestet. Bei beiden hat das ISO die falsche md5 Summe, aber sie sind jeweils unterschiedlich falsch. Innerhalb einer shell kommt immer das gleiche falsche Image heraus. Zwischen den Shells unterscheiden sie sich.