# $Id: README,v 1.2 1997/02/23 15:42:18 eric Rel $ Note: There is a feature which can be optionally compiled into mkisofs that allows you to merge arbitrary directory trees into the image you are creating. You need to compile with -DADD_FILES for my changes to take effect. Thanks to Ross Biro biro@yggdrasil.com. This program requires a lot of virtual memory to run since it builds all of the directories in memory. The exact requirements depend upon a lot of things, but for Rock Ridge discs 12Mb would not be unreasonable. Without RockRidge and without the translation tables, the requirements would be considerably less. The cdwrite utility is maintained separately from mkisofs by yggdrasil.com. It is enclosed here as a convenience, since the two programs are often useful together. ***************************** Notes for version 1.10b1 Big news is that multi-session capability is very close to being done. There is still a missing interface to cdwrite that is used to determine the next writable address and the sector number of the last existing session. Until we get the interface to cdwrite done, this is a beta version. Bug involving DST fixed (dates are always calculated, since some files may be DST and other ones would not be). Unfortunately the notes on some of the small patches got lost. ***************************** Notes for version 1.06 Jan-Piet Mens <jpm@mens.de> added support for the '-m' switch. This allows exclusion of shell-style globs from the CDROM. See manual mkisofs.8 for more information. ***************************** Notes for version 1.05 Added support for '-r' switch. This is very similar to -R for Rock Ridge, but echos of the development environment are removed (i.e. uid/gid set to 0, and permissions of the files are canonicalized). Useful in applications where a distribution medium is being produced. ***************************** Notes for version 1.04 No notes for 1.04. ***************************** Notes for version 1.03 No notes for 1.03. ***************************** Notes for version 1.02. Minor bugfixes here and there. Support for compiled in defaults for many of the text fields in the volume header are now present, and there is also support for a file ".mkisofsrc" that can also read settings for these parameters. A short script "Configure" was added to allow us to set up special compile options that depend upon the system that we are running on. This should help stamp out the sphaghetti-isms that were starting to grow up in various places in the code. You should get more meaningful error messages if you run out of memory. ***************************** Notes for version 1.1. The big news is that SUSP CE entries are now generated for extremely long filenames and symlink names. This virtually guarantees that there is no limit (OK, well, about 600Mb) for file name lengths. I have tested this as well as I can, and it seems to work with linux. This would only be used very rarely I suspect. Also, I believe that support for VMS is done. You must be careful, because only Stream-LF and FIxed length record files can be recorded. The rest are rejected with error messages. Perhaps I am being too severe here. There is a bugfix in the sorting of entries on the disc - we need to stop comparing once we reach the ';' character. There are four new options -z -d -D -l -V. Some of these tell mkisofs to relax some of the iso9660 restrictions, and many systems apparently do not really seem to mind. Use these with caution. Some diagnostic programs to scan disc images are in the diag directory. These are not as portable as mkisofs, and may have some bugs. Still they are useful because they can check for bugs that I might have introduced as I add new features. ***************************** Notes for version 1.0. In version 1.0, the date fields in the TF fields were fixed - previously I was storing st_ctime as the file creation time instead of the file attribute change time. Thanks to Peter van der Veen for pointing this out. I have one slight concern with this change, however. The Young Minds software is definitely supplying 3 dates (creation, modification and access), and I would strongly suspect that they are incorrectly putting the file attribute change time in the file creation slot. I would be curious to see how the different RRIP filesystems treat this. Anyway, this is something to keep in the back of your mind. The symlink handling was not quite correct in 0.99 - this is now fixed. Only some systems seemed to have been affected by this bug. A command line option is now present to allow you to specifically exclude certain files from the distribution. The case where you do not have permissions to read a directory is now handled better by mkisofs. The directory that cannot be opened is converted into a zero-length file, and processing continues normally. A few portability things have been fixed (hopefully).
mkisofs-1.11 for NEXTSTEP 3.3 (Patched and with the new libposix.a)
mkisofs creates a CDROM image file in ISO9660 with RockRidge extensions.
The image file created may be used to burn a CDROM with any number of free
software. The resulting CDROM will be readable on practically any platform.
I use this to prepare CDROM image files, which are then transferred to a
Windows PC to actually burn a CDROM. There is CDDesigner.app, which
however is commercial. This, along with FILE2CD.EXE, provides a
freeware solution.
To compile mkisofs, you will need a NEXTSTEP 3.3 system with
3.3Patches installed and with a new statically linkable POSIX library
libposix.a from www.next.com, or more sepcifically:
http://enterprise.apple.com/NeXTanswers/HTMLFiles/2066.htmld/2066.html
Download and install these:
3.3Intel68kPatch.pkg.tar
3.3DeveloperPatch.pkg.tar
libposix.a
3.3Patch.ImprovedDNS.post_install or 3.3Patch.LibrariesOK.post_install
# ranlib /usr/lib/libposix.a
% sum /usr/lib/libposix.a
27352 3183
OPENSTEP 4.x doesn't have workable POSIX, and neither do versions
3.2 and earlier. Once compiled, the binary runs fine on OPENSTEP
4.x. It may run OK on NS3.x, but this is not tested.
I attempted to remove POSIX dependency, but I gave up. This is not trivial.
Makefiles, *.c files with *.c.orig counterpart have been modified slightly.
Take a diff to see these minor mods.
=== How to actually make a CDROM using mkisofs and a CDROM writer attached
to a Windows PC
[1] Plan directories to include (total size < 650MB)
optionally prepare .mkisofsrc in the base direcotory (see man mkisofs)
[2] Create CDROM image file using mkisofs
# For example, making CDROM of /Users (excluding lost+found directory)
mkisofs -o /ExtraSpace/users.cdr -R -T -l -V "HomeDir Snap" -x /Users/lost+found /Users
[3] Transfer file users.cdr to Windows machine with a CDROM writer.
[4] Use FILE2CD.EXE to burn image file to CDROM.
In MSDOS command shell, do:
file2cd users.cdr /postgap
It will find the drive.
*Note: FILE2CD.EXE, CD2FILE.EXE etc are freeware programs from:
http://www.mainstream.net/~jarnold/cdrom/
It needs an ADAPTEC SCSI driver WNASPI32.DLL available from
ftp://ftp.adaptec.com/pub/BBS/winnt/aspi32.exe
*** The above procedure worked for me with a Pentium PC with Windows NT4.0 (SP3)
with a Phillips CDD 2600 (came with an Adaptec SCSI card).
Adaptec's crappy CD software for Windows doesn't work.
===================================================================================
Additional Info
http://www.cd-info.com/CDIC/Technology/CD-R/FAQ.html
# $Id: README.eltorito,v 1.2 1997/02/23 15:44:59 eric Rel $
What is El Torito?
------------------
Simply put, El Torito is a specification that says how a cdrom should
be formatted such that you can directly boot from it.
The "El Torito" spec says that ANY cdrom drive should work (scsi/eide)
as long as the BIOS supports El Torito. So far this has only been
tested with EIDE drives because none of the scsi controllers that has
been tested so far appears to support El Torito. The motherboard
definately has to support El Torito. The ones that do let you choose
booting from HD, Floppy, Network or CDROM.
How To Make Bootable CDs
------------------------
For the x86 platform, many BIOS's have begun to support bootable CDs.
The standard my patches for mkisofs is based on is called "El Torito".
The "El Torito" standard works by making the CD drive appear, through BIOS
calls, to be a normal floppy drive. This way you simply put an floppy
size image (exactly 1440k for a 1.44 meg floppy) somewhere in the
iso fs. In the headers of the iso fs you place a pointer to this image.
The BIOS will then grab this image from the CD and for all purposes it
acts as if it were booting from the floppy drive. This allows a working
LILO boot disk, for example, to simply be used as is.
It is simple then to make a bootable CD. First create a file, say "boot.img"
which is an exact image of the boot floppu currently in use. There is
at least one HOWTO on making bootable floppies. If you have a bootable
floppy handy, you can make a boot image with the command
dd if=/dev/fd0 of=boot.img bs=10k count=144
assuming the floppy is in the A: drive.
Place this image somewhere in the hierarchy which will be the source
for the iso9660 filesystem. It is a good idea to put all boot related
files in their own directory ("boot/" under the root of the iso9660 fs,
for example), but this is not necessary.
One caveat - Your boot floppy MUST load any initial ramdisk via LILO,
not the kernel ramdisk driver! This is because once the linux kernel
starts up, the BIOS emulation of the CD as a floppy disk is circumvented
and will fail miserably. LILO will load the initial ramdisk using BIOS
disk calls, so the emulation works as designed.
The "El Torito" specification requires a "boot catalog" to be created as
ll.
This is a 2048 byte file which is of no interest except it is required.
My patches to mkisofs will cause it to automatically create the
boot catalog. You must specify where the boot catalog will go in the
iso9660 filesystem. Usually it is a good idea to put it the same place
as the boot image, and a name like "boot.catalog" seems appropriate.
So we have our boot image in the file "boot.image", and we are going to
put it in the directory "boot/" under the root of the iso9660 filesystem.
We will have the boot catalog go in the same directory with the name
"boot.catalog". The command to create the iso9660 fs in the file
bootcd.iso is then
mkisofs -b boot/boot.imh -c boot/boot.catalog -o bootcd.iso .
The -b option specifies the boot image to be used (note the path is
relative to the root of the iso9660 disc), and the -c option is
for the boot catalog file.
Now burn the CD and its ready to boot!
CAVEATS
-------
I don't think this will work with multisession CDs.
If your bootable floppy image needs to access the boot floppy, it has
to do so through BIOS calls. This is because if your O/S tries to talk to
the floppy directly it will bypass the "floppy emulation" the El Torito spec
creates through BIOS. For example, under Linux it is possible to
have an initial RAM disk loaded when the kernel starts up. If you let the
kernel try to read in the initial RAM disk from floppy, it will fail
miserably because Linux is not using BIOS calls to access the floppy drive.
Instead of seeing the floppy image on the CD, Linux will be looking at
the actually floppy drive.
The solution is to have the initial boot loader, called LILO, load your
initial RAM disk for you. LILO uses BIOS calls entirely for these
operations, so it can grab it from the emulated floppy image.
I don't think making a CD bootable renders it unreadable by non-El Torito
machines. The El Torito spec uses parts of the iso9660 filesystem which
were reserved for future use, so no existing code should care what it does.
Mkisofs currently stores identification records in the iso9660 filesystem
saying that the system is a x86 system. The El Torito spec also allows
one to write PowerPC or Mac id's instead. If you look at the code in write.c
you could figure out how to change what is written.
# $Id: README.session,v 1.2 1997/02/23 15:45:50 eric Rel $ This release of mkisofs has basic support completed for multiple sessions. At this point, it hasn't been tested thoroughly at all - we still need some interaction between cdwrite and mkisofs for this to work correctly. There are a few new options to mkisofs to allow for this. The first one is "-M /dev/scd0", and is used so that mkisofs can examine the entirety of the previous image so that it can figure out what additional files need to be written in the new session. There is also a temporary hack in mkisofs in the form of a '-C' option. The -C option takes two numbers as input, which are delimited by commas. For example, you could specify "-C 1000,1020", but you should never just make up numbers to use here. These numbers are determined from cdwrite. There are patches to cdwrite in the file cdwrite.c.diff, which add a new information gathering option. To use this, you specify '-m', and instead of actually writing any data, cdwrite dumps two numbers to stdout which are comma delimited. These are the same numbers that mkisofs uses with the -C option. Thus in practice you should in principle be able to do something like: mkisofs [other options] -C `cdwrite --device /dev/sgX --multi` \ -M /dev/cdblkdev to tie these things together. Admittedly this is a very crude interface between the two programs right now, and this will be cleaned up later. For now, it provides the minimal functionality required to write multiple session discs. Note: As of the 1.10b4 release, nobody has actually tried to burn any discs with this. It is entirely possible that bugs exists, or that further tweaks will be required somewhere along the way to get things working correctly. The data gathering mode of cdwrite has been tested, and I believe it works correctly. Caveat Emptor. [Nov 4, 1996].
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.