Hardware > Hardware-Tips

Images von CDs erstellen

<< < (5/7) > >>

Freud-Schiller:
trotzdem mit wesentlich mehr solaris wissen als ich bewaffnet ;)

meik:

--- Zitat von: Freud-Schiller am 02. Februar 2007, 16:41:27 ---äh mein fehler, ich teste auf der u60 die unterschiedlichen versionen! bei beiden ist die slice2 nicht die größte!

kann das sein, daß whole disk nur für hdd gilt?

--- Ende Zitat ---

Ja. Das ist ja auch nur eine Konvention. (Und IMHO eine ziemlich seltsame, warum ist Slice 2 die "whole disk", warum nicht Slice 0 oder Slice 7?)

So aus dem Kopf enthalten Slice 0 die Installationsdaten, Slice 1 das Miniroot und alle weiteren Slices plattformspezifischen Bootcode (für sun4, sun4c, sun4m, sun4u, ...). Das genaue Format ist in einigen Blueprints [1] beschrieben, wie man eigene Boot- oder Installations-CDs für Solaris baut und hat sich bis einschließlich Solaris 9 nicht geändert. Bei Solaris 10 sieht es erstmals wieder anders aus, aber das beschreibt ein (neueres) Blueprint. :-)

[1] http://www.sun.com/blueprints/browsesubject.html#jumpstart

escimo:
Sorry, ich habe das Verlangen meine Erkenntnisse und Probleme hier mit einzubringen: :-[

Ich versuche seit mehreren Tagen ein Image von einer Solaris 1.1.1 AnswerBook CD-ROM mit "Rockridge Filesytem and UFS" Dateisystem zu erstellen. Leider ohne jeglichen Erfolg.  :-\

UFS steht hier für das alte Unix File System "4.2BSD", welches a.u. auch unter SunOS 4.1.4 zum Einsatz kommt.

Generell habe ich die CD-ROM bis jetzt einzig unter SunOS 4.1.4 mittels
   # mount -tr 4.2 /dev/sr0 /cdrom
einhängen können. Unter Solaris 10 war das leider nicht (mehr) möglich. Dieses Dateisystem wird Kernel-seitig nicht (mehr) unterstützt.

TEIL 1: Folgendes habe ich bereits ausprobiert:

[1a] cat /dev/sr0 >> answerbook.iso (block-device unter SunOS 4.1.4)
[1b] cat /dev/rdsk/c0t0d0s2 >> answerbook.iso (raw device unter Solaris 10 x86/x64)
Ergebnis: Image wird erstellt; Brennprogramm bricht mit vermeintlichen Fehler beim Schreiben auf CD-R(W) ab; erstelltes Medium kann auch unter SunOS nicht mehr gelesen/eingehangen (mount) werden.

[2] Image über Windows erstellen
Ergebnis: Selbes Dilemma, siehe [1]

[3a] cp -Rp /cdrom/* /home/sx/ab/
[3b] cd /cdrom && tar cvf /home/sx/ab.tar ./*
CD-ROM unter SunOS mounten und alle Dateien temporär in Verzeichnis zu kopieren.
Ergebnis: Das Verzeichnis ab/ bzw. das TAR-Archiv ab.tar wird deutlich größer, als das was auf die CD-ROM passt mit > 950 MByte :o  (symbolische Links und dadurch evtl. doppelte Dateien ???)


TEIL 2: Meine Fragen dazu:

[\A] Hat jemand von Euch Ideen, mit welcher Blockgröße (Standard 512 Byte, später 1024 Byte) das alte UFS (4.2BSD File System) auf der CD-ROM konfiguriert ist bzw. wie ich die Blockgröße auf der CD-ROM ermitteln könnte?
Anmerkung: Das frage ich, weil die komplette Kopie auf der Festplatte größer als die Kapazität des Original-Mediums ist ???

[\B] Könnte folgendes Kommando mit der korrekten Blockgröße Wirkung zeigen:
dd if=/dev/sr0 bs=??? of=/home/sx/answerbook.iso
Anmerkung: für bs mit Werten 512 / 1024 / 2048 / evlt. größer oder gar kleiner

In diesem Fall wäre die Standard-Blockgröße 2048 Byte für Rockridge bzw. >=2048 Byte für UFS-Dateisysteme. Siehe Auszug aus Manpage von cdrecord(1)

--- Zitat ----data  If this flag is present, all subsequent tracks  are
              written  in CD-ROM mode 1 (Yellow Book) format. The
              data is a multiple of 2048 bytes.   The  file  with
              track data should contain an ISO-9660 or Rock Ridge
              filesystem image (see mkisofs for more details). If
              the track data is an ufs filesystem image, fragment
              size should be set to 2 KB or  more  to  allow  CR-
              drives  with  2  KB  sector  size to to be used for
              reading.

              -data is the default, if no other flag is  present.

              If  neither  -data  nor -audio have been specified,
              cdrecord defaults to -audio for all filenames  that
              end  in  .au  or  .wav  and  to -data for all other
              files.

              2048 bytes.
--- Ende Zitat ---

Für Vorschläge wäre ich dankbar.

Grüße
escimo

Freud-Schiller:
Hi Stephan,

[kurze Version-lange wird nachgeliefert]
ich benutze sehr erfolgreich die bei Dir als Nummer 3a bezeichnete Methode.

Ich denke(benutze dieses Verb sonst recht selten, bin mir relativ sicher), daß die Blocksize bei 512 liegt. Alle SUN typischen Laufwerke arbeiten mit dieser Blocksize.

Gruß David

p.s. Jörg KÖNNTE Licht ins Dunkel bringen und bestimmt geht mit einen Tools auch die Erstellung eines ISO Images von UFS, doch die Frage ist, wer ihm einen Ton entlocken kann *g*

vab:
Also, Ihr habt immer Sorgen...  hier ein paar Bemerkungen:

1.  Das 4.2BSD-Dateisystem kann auch von NetBSD gelesen werden.  Das ist aber nur interessant, wenn Du die Daten haben willst.  Du sagst aber, Du willst ein Image haben.

2. cat mit ">>" hängt an.  War "answerbook.iso" denn vorher leer?

3. cat ist bei block devices nicht so gut.  Nimm dd.

4. Beim Lesen von der CD kannst Du ruhig blocksize 2k nehmen, das dd macht das schon richtig.  :-)  Dein Problem liegt ohehin nicht an der Blockgöße.

5. In Deinem Beispiel von [1b] solltest Du lieber die block device nehmen.


Viel Erfolg -- Volker

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete