sonnenblen.de - Das unabhängige Sun User Forum
Hardware => Hardware-Tips => Thema gestartet von: Freud-Schiller am 31. Januar 2007, 13:11:24
-
Hi Leute, ich muß "einige" CDs ins trocke bringen und kann es mir nicht einen 1cm leisten, daß ich nach dem Image Vorgang feststelle, daß das Image nicht alles enthält.
Welche Programme nutzt Ihr, um mit einem PehCeh(Windows XP!) Images von ALLEN möglichen CDs zuerstellen?
(AIX,PPC,X86,SPARC ...) Da ich weiß, daß eine SPARC/Solaris CD mehr als nur eine Partition enthält vermute ich dies auch bei anderen UNIX Systemen.
Also welches Brenn/Image Programm habt Ihr bereits ERFOLGREICH getestet! Freeware wäre schön, doch auch ein Kaufprogramm wäre ok!
big THX!
David
-
Mit CloneCD konnte ich bisher von allen Medien Sicherheitskopien erstellen, außer von der Solaris 9 DVD. Dann habe ich sie eben runtergeladen. :D
Von HP-UX, AIX, Tru64 lassen sich ganz einfache ISO-Images erstellen, z.B. mit CDBurnerXP Pro: http://www.cdburnerxp.se/
-
um ein iso image unter solaris zu erstellen brauchst du keine zusätzliche software. du kannst mit dem befehlt "cat" den inhalt der geräte datei in ein file "pipen", angenommen dein CD/DVD laufwerk ist c1t6d0:
# /etc/init.d/volmgt stop
# cat /dev/rdsk/c1t6d0s2 >> /downloads/sol9_0905_HW_SPARC_dvd.iso
# /etc/init.d/volmgt start
auch um dein iso image zu "mounten", ähnlich wie du es unter windows mit zb DaemonTools machst kannst du solaris mittel verwenden:
# lofiadm -a /downloads/sol9_0905_HW_SPARC_dvd.iso
/dev/lofi/1
# mount -F hsfs -o ro /dev/lofi/1 /mnt
zum brennen liefert sun "cdrecord" oder "cdrw" mit.
g pressy
-
@ Ebbi, CloneCD nutze ich, hab nur angst, daß das format in 20jahren out ist ;-) das neue prog teste ich gerade
@ Pressy sichere ich damit nicht nur die einzelne partition der cd?
-
sichere ich damit nicht nur die einzelne partition der cd?
Wenn du, wie oben angegeben Slice2 verwendest, nicht.
-
# /etc/init.d/volmgt stop
# cat /dev/rdsk/c1t6d0s2 >> /downloads/sol9_0905_HW_SPARC_dvd.iso
# /etc/init.d/volmgt start
Bei den Solaris-Installationsmedien (CDs) existieren mehrere Slices auf einem Medium.
Kann man damit also alle Slices in einem ISO zusammenfassen? :)
Dann könnte man diese eine ISO, die alle Slices enthält, später mit jedem Brenn-Programm wieder auf ein aufnahmefähiges Medium übertragen ("brennen").
-
Kann man damit also alle Slices in einem ISO zusammenfassen? Smiley
ja, die slice zwei ist wie bei den internen disken die "backup-slice" und geht von cylinder 0 bis "n", somit sind alle anderen slices auch drinnen. ich sichere so schon seit langem meine CDs. einfach das iso in ein brennprogramm deiner wahl laden und wie jedes andere iso brennen.
gP
-
Dann sind also auch die "boot-fähigen Blöcke" in dem ISO enhalten, wenn ich Slice 2 (backup) sichere?
Funktioniert das bei normalen CD-ROMs (1 Slice) auch mit "s2" (Slice 2)?
Wie sieht das bei DVDs aus?
Gruß
escimo
-
Dann sind also auch die "boot-fähigen Blöcke" in dem ISO enhalten, wenn ich Slice 2 (backup) sichere?
ja, slice zwei ist alles. wie gesagt, von cylinder 0 bis zum letzten. In den cylinder befinden sich dann die Blöcke, egal welche. Damit machst du quasi ein binär abbild deiner CD/DVD
Funktioniert das bei normalen CD-ROMs (1 Slice) auch mit "s2" (Slice 2)?
ja, selbes prinzip, slice 2 ist alles, somit ist es auch egal wieviel slices man auf dem rolling belegt hat.
Wie sieht das bei DVDs aus?
genauso, ich sichere meine DVDs (auch die solaris installation DVD) ebenso...
gP
-
ok, habe ich verstanden! leider habe ich auf meiner u5(einiges system mit dvd) kein solaris, sondern ein gentoo linux(ich weiß ich weiß ;)) kann ich da ähnlich vorgehen? und wenn ja, wie?
-
hmm, mit "normalen" CD/DVD sollt es genau so über /dev/cdrom oder /dev/hdc (oder sdx, wo auch immer dein laufwerk ist) funktionieren. was linux aber mit mehreren slices macht ist fraglich, sollt aber theoretisch auch funktionieren.... einfach ausprobieren.. wirklich was kaputt machen kann man eh nicht .. ;)
gP
-
ok, dann würde ich folgendes testen:
solaris CD auslagern(wie beschrieben) mit
u60 unter solaris
u5 unter gentoo
dann die größe des image vergleichen, müßte doch aussage kräftig sein, oder?
-
ähm houston wie haben ein problem:
SunOS4.1.4
Slice0 -> 328990720
Slice1 -> 17039360
Slice2 -> 17039360
Slice3 -> 17039360
Slice4 -> 17039360
Slice5 -> 17039360
Slice6 -> 0
Solaris 2.4
Slice0 -> 36536200
Slice1 -> 17039360
Slice2 -> 17039360
Slice3 -> 17039360
Slice4 -> 17039360
Slice5 -> 17039360
Slice6 -> 0
ich kann mir das jetzt nicht erklären, habe genau den befehl befolgt
-
Du testest doch aber zwei unterschiedliche Solaris-Versionen. ???
Oder meinst du Slice 6?
-
ä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?
-
Ja, jetzt wo du es erwähnst. :o
Ist mir gar nicht aufgefallen.
Finde ich jetzt auch sehr merkwürdig. ???
-
hmmm, es sollten auch 8 slices sein, 0-7.... wie siehst du dir die slice grössen an? versuch das ding einmal zu brennen und davon zu booten, dann siehst du gleich ob es funktioniert hat oder nicht....
gP
-
nach dem "cat" liegt ja ne iso der slice vor und da bemesse ich nach der byte :) größe. slice 7 ist bei alles bisher getesteten cds 0 byte. vllt können ja Claus oder Jonny licht ins dunkel bringen
-
Gurus und Pros, helft mir! bidde
-
Sorry, kann dir da leider nicht weiterhelfen.
Bin aber auch weder Pro noch Guru :)
Claus
-
trotzdem mit wesentlich mehr solaris wissen als ich bewaffnet ;)
-
ä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?
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
-
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)
-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.
Für Vorschläge wäre ich dankbar.
Grüße
escimo
-
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*
-
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
-
Ich glaube ich habe den Übeltäter gefunden: Es ist - wie sollte es anders auch sein - das (beschränkte Windows-)Brennprogramm (Sonic WinOnCD). Naja, das war halt mit dabei. Da frage ich dann doch nicht. Selber Schuld. :-\
Eine positive Bestätigung habe ich durch CloneCD erhalten, mit dem es funktioniert. Das brennt im RAW-Mode, wenn die CD-ROM vorher binär ausgelesen wurde. In der CUE-Datei ist die Blockgröße auf 2352 Byte (Raw, binär) gesetzt und das CD-Image als "Mode 1" (Yellow Book) gekennzeichnet:
FILE "SUNOSAB1.img" BINARY
TRACK 1 MODE1/2352
INDEX 1 00:00:00
dd(1) sowie auch CloneCD bestätigen mir das sich 289881 Blöcke auf dem CD-ROM Medium befinden, was multipliziert mit 2048 Byte exakt die Image-Größe von 593.676.288 Bytes (rund 594 MByte) ergibt.
Meine Schlussfolgerung: meine (t)olle Brennsoftware erstellt mit dem Backup-Image standardmäßig ein ISO9660-Dateisystem. Und das geht natürlich in die Hose.
Obwohl ich unter WinXP auf dem T60 keinen Brenner über "cdrecord.exe -scanbus" angezeigt bekomme, habe ich im Manual von "cdrecord" folgende Optionen/Schalter gefunden:
-raw96p
Select Set RAW writing mode with 2352 byte sectors
plus 96 bytes of packed P-W subchannel data result-
ing in a sector size of 2448 bytes. This is the
less preferred raw writing mode as only a few
recorders support it and some of these recorders
have bugs in the firmware implementation. Don't
use this mode if your recorder supports -raw96r or
-raw16. Writing data disks in raw mode needs sig-
nificantly more CPU time than other write modes. If
your CPU is too slow, this may result in buffer
underruns.
-raw16 Select Set RAW writing mode with 2352 byte sectors
plus 6 bytes of P-Q subchannel data resulting in a
sector size of 2368 bytes. If a recorder does not
support -raw96r, this is the preferred raw writing
mode. It does not allow to write CD-Text or
CD+Graphics but it is the only raw writing mode in
cheap CD writers. As these cheap writers in most
cases do not support -dao mode. Don't use this
mode if your recorder supports -raw96r. Writing
data disks in raw mode needs significantly more CPU
time than other write modes. If your CPU is too
slow, this may result in buffer underruns.
(...)
-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.
Auf der Original-CD steht "Rockridge & UFS Format" - Ich komme dem Ziel langsam näher. Ich werde unter Solaris 10 booten und schauen, ob das angeblich kaputte CD-Image (Backup) mit cdrecord von da aus auf CD-RW zu bannen ist. :)
Gute Nacht,
escimo
-
Das kommt davon, wenn man zuviel mit Windows arbeitet ;-)
Windows ist zum Spielen (und auch das nicht wegen technischer Ueberlegenheit auf diesem Gebiet), nicht zum Arbeiten.
Mfg. Erisch
-
Das kommt davon, wenn man zuviel mit Windows arbeitet ;-)
Ja man verlässt sich dann einfach zu visehr auf die vorhandenen Anwendungen. ;)
# cdrecord -scanbus
Cdrecord-Clone 2.01 (i386-pc-solaris2.10) Copyright (C) 1995-2004 Joerg Schilling
Warning: Using USCSI interface.
Warning: Volume management is running, medialess managed drives are invisible.
Using libscg version 'schily-0.8'.
scsibus0:
0,0,0 0) 'MATSHITA' 'DVD-RAM UJ-842 ' 'RB01' Removable CD-ROM
scsibus1:
1,0,0 100) 'ATA ' 'HITACHI HTS54168' 'C7EP' Disk
Ich habe unter Solaris 10 das Image zwar brennen können, allerdings unterstützt cdrecord bei dem verwendeten cdrecord Interface-Treiber keinen RAW-Modus.
Hier die Befehle die ich genutzt habe:
# readcd (http://www.linuxcommand.org/man_pages/readcd1.html) -v -clone dev=0,0,0 speed=1 f=anwerbook-cd.raw
scsidev: '0,0,0'
scsibus: 0 target: 0 lun: 0
Warning: Using USCSI interface.
Read speed: 1058 kB/s (CD 6x, DVD 0x).
Write speed: 706 kB/s (CD 4x, DVD 0x).
TOC len: 48. First Session: 1 Last Session: 1.
01 10 00 A0 00 00 00 00 01 00 00
01 14 00 A1 00 00 00 00 01 00 00
01 14 00 A2 00 00 00 00 40 1B 06
01 14 00 01 00 00 00 00 00 02 00
Lead out 1: 289881
Capacity: 289881 Blocks = 579762 kBytes = 566 MBytes = 593 prMB
Sectorsize: 2048 Bytes
readcd: I/O error. read_cd: scsi sendcmd: no error
CDB: BE 00 00 00 00 00 00 00 00 F8 01 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 24 00 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x24 Qual 0x00 (invalid field in cdb) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 0.001s timeout 40s
readcd: read 2448 failed
readcd: read 2448_16 : OK
readcd: I/O error. mode select g1: scsi sendcmd: no error
CDB: 55 10 00 00 00 00 00 00 14 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0A 18 00 00 00 26 00 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x26 Qual 0x00 (invalid field in parameter list) Fru 0x0
Sense flags: Blk 0 (not valid)
resid: 20
cmd finished after 0.003s timeout 40s
Copy from SCSI (0,0,0) disk to file 'abcd.raw'
end: 289881
addr: 289881 cnt: 12
Time total: 886.070sec
Read 692996.77 kB at 782.1 kB/sec.
...erzeugt...
-rw-r--r-- 1 root root 709628688 Feb 27 16:08 abcd.raw
-rw-r--r-- 1 root root 50 Feb 27 15:53 abcd.raw.toc
# cdrecord (http://linuxcommand.org/man_pages/cdrecord1.html) -v -clone -raw96r dev=0,0,0 speed=4
Cdrecord-Clone 2.01 (i386-pc-solaris2.10) Copyright (C) 1995-2004 Jörg Schilling
TOC Type: 1 = CD-ROM
scsidev: '0,0,0'
scsibus: 0 target: 0 lun: 0
Warning: Using USCSI interface.
Using libscg version 'schily-0.8'.
SCSI buffer size: 57344
atapi: 1
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'MATSHITA'
Identifikation : 'DVD-RAM UJ-842 '
Revision : 'RB01'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x000A
Profile: 0x0012
Profile: 0x002B
Profile: 0x001B
Profile: 0x001A
Profile: 0x0016
Profile: 0x0015
Profile: 0x0013
Profile: 0x0014
Profile: 0x0011
Profile: 0x0010
Profile: 0x000A (current)
Profile: 0x0009
Profile: 0x0008
Profile: 0x0002
...
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO
Drive buf size : 1310720 = 1280 KB
FIFO size : 4194304 = 4096 KB
Encoding speed : 854x (64037 sectors/s) for libedc from Heiko Eißfeld
cdrecord: Drive does not support RAW recording.
cdrecord: Illegal write mode for this drive.
Mit folgendem Parametern konnte ich zwar das Image wieder brennen, allerdings war es dann genauso nicht lesbar:
# cdrecord -v -clone dev=0,0,0 speed=4 abcd.raw
RAW schreiben will er net. Hat mit cdrecord in dieser Hinsicht jemand mehr Erfahrung(en) sammeln können?
-
Das Gelumpe geht immer noch nicht. Ich habe auch die cdrecord-Option "-cuefile" ausprobiert:
# cdrecord -v -dev=0,0,0 speed=0 -cuefile=abcd.cue -sao
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO
Drive buf size : 1310720 = 1280 KB
FIFO size : 4194304 = 4096 KB
cdrecord: Unsupported sector size 2352 for data on line 2 in 'abcd.cue'.
# cat abcd.cue
FILE "abcd.raw" BINARY
TRACK 1 MODE1/2352
INDEX 1 00:00:00
Das hat es leider auch net gebracht. Wie brennt denn dieses "verflucht gute CloneCD" das Image mit seinen CCD-Daten.
Das folgende Tool soll angeblich ein CloneCD-Image kompatibel mit cdrecord machen:
http://linuxreviews.org/howtos/cdrecording/ccd2iso-0.1.tar.gz
Quelle:: http://linuxreviews.org/howtos/cdrecording/
Ich weis net so richtig weiter. Wenn alle Stricke reißen, bin ich wohl gezwungen auf das CloneCD-Image oder eine Kopie aller Dateien anzustreben. Beide Varianten sind unbefriedigend für mich. :(
-
Ich habe unter Solaris 10 das Image zwar brennen können, allerdings unterstützt cdrecord bei dem verwendeten cdrecord Interface-Treiber keinen RAW-Modus.
Hast Du denn die Möglichkeit ein anderes Laufwerk zu probieren? Oder eine neuere Version von cdrecord?
Auf meinem Firmen-Notebook sieht es so aus (Win XP + Cygwin):
Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-cygwin) Copyright (C) 1995-2008 Jörg Schilling
...
Using libscg version 'schily-0.9'.
...
Vendor_info : '_NEC '
Identifikation : 'DVD+-RW ND-6650A'
Revision : '102C'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
...
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96R RAW/R96R
Ich habe jetzt keinen konkreten Brennversuch gestartet, aber es sieht zumindest so aus als ob der RAW-Modus hier möglich sein sollte.
-
Hi TLI.
Cdrecord-ProDVD-ProBD-Clone 2.01.01a38 (i686-pc-cygwin) Copyright (C) 1995-2008 Jörg Schilling
...
Supported modes: TAO PACKET SAO SAO/R96R RAW/R96R
:o
Das scheint bei dir eine erweiterte Version zu sein, im Gegensatz zu der von mir unter Solaris 10 eingesetzten Variante von cdrecord.
Cdrecord-Clone 2.01 (i386-pc-solaris2.10) Copyright (C) 1995-2004 Joerg Schilling
Ich habe noch ein externes USB 2.0-Laufwerk (NEC). Ich probiere es aus.
Unter Solaris kann ich das leider nun nicht mehr testen, denn das wurde für Migrationstests mit OpenSolaris 2008.11 sowie Ubuntu 8.10 platt gemacht. Unter (derzeit) Ubuntu werde ich das mit dem externen Brenner probieren, obwohl ich glaube gelesen zu haben, dass die Treiber von cdrecord USB-Brenner angeblich nicht bedienen können. Ich probiere es aus und berichte.