Zitat

Original von barry
prima input, mit dem Image in doppelter Größe. Wußt ich noch nicht.
Kann man denn auch 2 Image aneinanderhängen, 2 á 1,4 MB? Also "boot1.img" + "boot2.img"?[/qoute]

Wie schon fli4linux, macht das auf Image-Basis keinen Sinn, das wäre dann zweimal die Diskettenstruktur mit zwei Dateiverzeichnissen, Bootsektoren etc.

Das mit dem cpio hört sich für mich am schlüssigsten an. Wenn Du die erste Diskette mounten kannst, dann packe ihren Inhalt wie beschrieben auf das 2,88MB Image. Den Inhalt der zweiten mit cpio. Fragt sich nur noch, wie Du unterscheiden kannst, welcher Inhalt von der ersten, und welcher von der zweiten kommt...

Ist der Kernel nicht auf der ersten Diskette mit drauf? Auch müssten da irgendwelche Anzeichen von einem Bootloader sein.

(O.K. es gibt noch die alte Methode, dass man einen Kernel direkt booten kann, wenn man ihn auf die ersten Sektoren einer Diskette schmiert... Das initrd kommt dann auch nur mit dd drauf, d.h. die Diskette hat gar kein Filesystem - das kanns bei Dir aber nicht sein, wenn Du die erste Diskette mounten kannst.)

> Oder kann ich von der 1. Disk, die ja bootbar ist, ein Double-image machen und
> mit den Daten der 2. Disk ergänzen?
Geht leider nicht, da würde das Filesystem korrupt. Dieses muss bei 2,88 auf jeden Fall neu angelegt werden.

Viell Glück
rantanplan

P.S. ich würde mich anbieten, die beiden images mal genauer anzugucken. Vielleicht fällt mir dann die ultimative Lösung ein, lol
Also dd if=/dev/fd0 ... und ab die Post

• Zuerst werden aus beiden Diskette Images erstellt:
  dd if=/dev/fd0 of=boot[1,2].img bs=...
  
  
• Nun wird versucht, die Images zu mounten:
  mount boot1.img /mnt -oloop
  
  Resultat: bei Disk1 erfolg, bei Disk2 die Meldung
  mount: you must specify the filesystem type
  d.h. Diskette2 enthält kein Filesystem
  
  
• Vermutung: Disk2 enthält nur ein komprimiertes initrd, welches vom Kernel unmittelbar nach dem Booten geladen wird
  
  
• Versuch, boot2.img zu dekomprimieren:
  cat boot2.img | gunzip -c > initrd
  gunzip: stdin: decompression OK, trailing garbage ignored
  
  Resultat: Vermutung stimmt; wird haben nun ein initrd,welches das Filesystem enthält
  
  
• initrd wird für die spätere Verwendung wieder komprimiert:
  gzip -9 initrd
  
  
• Nun erstellen wir ein 2,88MB Disk Image, auf dem beide Disketten Platz finden sollen:
  dd if=/dev/zero of=dboot.img bs=10k count= 288
  mkfs.minix dboot.img
  
  
• Wir kopieren den Inhalt von boot1.img (=/mnt) nach dboot.img:
  mount dboot.img /mnt2 -oloop
  cp -R /mnt/* /mnt2
  
  
• Wir kopieren das initrd.gz auf dboot.img:
  cp initrd.gz /mnt2/boot
  
  
• Jetzt kommt der tricky Part: Lilo wird konfiguriert, so dass dboot.img bootfähig wird:
  

  Zitat

  /mnt2/etc/lilo.conf
  boot=/dev/loop0
  disk=/dev/loop0
  bios=0x00 # 2.88MB disk geometry
  sectors=36
  heads=2
  cylinders=80
  timeout=0
  #geometric
  image=/vmlinuz
  label="bootcd"
  root=/dev/ram0
  initrd=/boot/initrd.gz
  append="ramdisk_size=16384"

  
  Da das BIOS "von Haus aus" keine 2,88MB Bootdisketten kennt, müssen diese für Lilo genau beschrieben werden (Sektoren, Zylinder etc.)
  
  
• Aufrufen von lilo:
  lilo -r /mnt2
  
• Das war's (fast)! Jetzt wird noch ein CD-Image aus dem dboot.img erezugt:
  umount /mnt2
  mkisofs -J -b dboot.img dboot.img > dbootcd.iso