# @(#)README	1.7 99/11/23 joerg

Note:

	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.

*****************************
Notes for version 1.12

	Joliet support is now complete.  See the -J option.

	The file scanning code is much improved - mkisofs can use multiple
	sources of input files and merge them together to form the output
	image.  In addition, each source can be grafted at any point in the
	iso9660 image.

	The image writing code has been cleaned up to make it much easier
	to add custom extensions.

	The ADD_FILES feature has been removed as it didn't work well,
and it was hard to figure out.  The recent rearrangements in the
file scanning code would tend to solve these issues.

*****************************
Notes for version 1.11

	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.

*****************************
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).

Transparent decompression (-z option) is available on Linux kernels
using kernel version 2.4.14 or 2.4.9-ac14 or later.

You also need the zisofs-tools package, containing the mkzftree
utility, to create the compressed files; this package is available at:

ftp://ftp.kernel.org/pub/linux/utils/fs/zisofs/

The mkzftree utility can also be used to read compressed CD-ROMs on
systems which do not support transparent decompression.

The use of a separate utility allows compression to be controlled on a
per-file basis.  A file which is not compressed can be read on any
system.

Transparent decompression is implemented as an extension to Rock
Ridge, so Rock Ridge needs to be enabled (-R or -r options.)

/* @(#)README.eltorito	1.3 20/05/10 eric, 2000-2020 J. Schilling */

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.img -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.

Since many BIOS implementations now have problems with larger boot images,
modern boot implementations use the no emulation boot and load the rest
of the boot image after Eltorito did load a single 2048 byte sector. Use
a command line like this to create a modern boot:

mkisofs -V MYVOL -iso-level 4 -R -b boot/grub/stage2_eltorito -no-emul-boot \
	-boot-load-size 4 -boot-info-table -o myvol.iso thisdir

or even a modern boot and EFI boot support at the same time:

mkisofs -V MYVOL -iso-level 4 -R -b boot/grub/stage2_eltorito -no-emul-boot \
	-boot-load-size 4 -boot-info-table \
	-eltorito-alt-boot -eltorito-platform efi -b boot/grub/boot.efi \
	-no-emul-boot
	-o myvol.iso thisdir

Depending on the BIOS and on the EFI boot code, the -boot-load-size option
may also be needed for the EFI boot.

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.

# @(#)README.graft_dirs	1.1 00/01/12 joerg
#
This is from "Eduardo M. A. M. Mendes" <mendes@mgconecta.com.br>

Creating multi-session CD's with dir=/ feature Micro Howto

This mini-howto was written as guide to help me to create multi-session CD's
with the possibility of determining the location of files. I hope
that this guide helps you too.

In order to use cdrecord it is first necessary to define to which scsi bus
the cd-writer is connected. In my case the setup is dev=0,3,0. It is also
interesting to have a separate directory in which all image files can
be dumped: /home/cdsource is the directory I chose for dumping the images.

The best way to understand how to create multi-session cds is to read
README.multi. Most of what is going to be said here is based on that
README file and on the help of several cdrecord users.

This Micro Howto is divided into two parts as follows:

Example a) A dir/=/dir1/dir2 example

Example b) A dir1/dir2/=/dir3/dir4 and dir1/dir2a=/dir5/dir6 example


We are now ready to start.

Example a) An dir/=/dir1/dir2 example

A simple example will demonstrate that we can create multi-session cds
with the dir_feature of the type dir/=/dir1/dir2

Objetive: Saving root directories of Redhat 6.1 and Col 2.3 on a single CD.

Observation: Redhat installation is mounted on COL 2.3 at /mnt/redhat

First image - RedHat 6.1 - /mnt/redhat/root

mkisofs -D -l -r -f -m core -L -o image1.raw redhat/=/mnt/redhat/root

This will create a redhat directory on the cd. The option -D should be
used with care. The other options used in the above command are just
to demonstrate the use of mkisofs.  Please
refer to man mkisofs if you want to know more.


To see if the image is created as expected, we need to mount image1.raw using
the option -o loop (Linux only! for information on Solaris read README.verify)
as follows:

mount -t iso9660 image1.raw /mnt/image -o loop

To see the contents type:

ls -l /mnt/image/redhat

Does it look ok?  Great! Unmount /mnt/image. Now the burning process itself:

cdrecord -v -dev=0,3,0 -multi -eject image1.raw

To check the burned image we need to mount the cd; something like

mount -t iso9660 /dev/scd0 /mnt/cdroms

/mnt/cdroms is the device file for the cdrom I use.


Second image - Caldera 2.3 - /root


To create the second image on our cd, we need get information
about sectors related to the first track. To do that, issue the command

cdrecord -v -dev=0,3,0 -msinfo

Cdrecord returns the following number

0,135563

This number is the format XX,YY discussed on README.multi.  XX would be used
for testing the images as well as burning the new track.

mkisofs -D -l -r -f -m core -L -C 0,135563 -M /dev/scd0 -o image2.raw  caldera/=/root

Now we need to check of image2.raw is ok. The following command creates exactly what we
need.  Plese note that -C option. Only the first number changes in this case. The second one
is always zero.  In our case the first number is zero due to cdrecord -msinfo.  When
more tracks are added to the cd this number will change.

mkisofs -D -l -r -f -m core -L -C 0,0 -M /dev/scd0 -o image2_test.raw  caldera/=/root

mount -t iso9660 image2_test.raw /mnt/image -o loop

ls -l /mnt/image shows that there are two directories: redhat and caldera, just the way
we wanted.

Now let us burn image2.raw (not image2_test.raw)

cdrecord -v -dev=0,3,0 -multi -eject image2.raw

We can mount the CD again to see that the two directories are there.  We can carry on
doing this until we decide to close the CD. If this is the case, don't use -multi when
burning the last session.

b) A dir1/dir2/=/dir3/dir4 and dir1/dir2a=/dir5/dir6 example

The above example seems a bit silly, one could argue. Why did I create a single directory
called root and within two sub-directories: redhat and caldera?

Using the procedure described above we would do as follows:

mkisofs -D -l -r -f -m core -L -o image1.raw etc/redhat/=/mnt/redhat/etc

cdrecord -v -dev=0,3,0 -multi -eject image1.raw

To check the burned image we need to mount the cd; something like

mount -t iso9660 /dev/scd0 /mnt/cdroms

cdrecord -v -dev0,3,0 -msinfo

Cdrecord returns the following number

0,14391

The second image can be created using

mkisofs -l -r -f -m core -L -C 0,14391 -M /dev/scd0 -o image2.raw  etc/caldera/=/etc

Creating a test image2

mkisofs -l -r -f -m core -L -C 0,0 -M /dev/scd0 -o image2_test.raw etc/caldera/=/etc

mount -t iso9660 image2_test.raw /mnt/image1 -o loop

It works!!   That is great!!!

Now the burning process itself.

cdrecord -v -dev=0,3,0 -multi -eject image2.raw

and we're done !!!!

To add more tracks just do as indicated above.

Good luxk!!!

Eduardo Mendes - 11/23/99

Making HFS bootable CDs

*******
The HFS boot code in mkisofs/mkhybrid is now very out of date ...
it does not support booting from IDE CDROMS, and probably won't work on
"newer" Macs.

The HFS boot code will be updated at some point in the future
*******

It *may* be possible to make the hybrid CD bootable on a Mac. As I do not
have easy access to a CD-R (nor a Mac) at the moment, I have not actually
created and written a bootable hybrid to CD - however, I *think* it will work!

A bootable HFS CD requires an Apple CD-ROM (or compatible) driver, a bootable
HFS partition and the necessary System, Finder, etc. files.

A driver can be obtained from any other Mac bootable CD-ROM using the
"apple_driver" utility (to make, type "make apple_driver"). This file can
then be used with the -boot-hfs-file option. See below for usage.

The HFS partition (i.e. the hybrid disk in our case) must contain a
suitable System Folder, again from another CD-ROM or disk.

For a partition to be bootable, it must have it's "boot block" set. The boot
block is in the first two blocks of a partition. For a non-bootable partition
the boot block is full of zeros. Normally, when a System file is copied to
partition on a Mac disk, the boot block is filled with a number of required
settings - unfortunately I don't know the full spec for the boot block ...

I'm guessing that this will work OK ...

Therefore, the utility "apple_driver" also extracts the boot block from the
first HFS partition it finds on the given CD-ROM and this is used for the
HFS partition created by mkhybrid.

To extract the driver and boot block:

apple_driver CDROM_device > HFS_driver_file

where CDROM_device is the device name used by the CD-ROM (e.g. /dev/cdrom)

The format of the HFS driver file is:

	HFS CD Label Block                              512 bytes
	Driver Partition Map (for 2048 byte blocks)     512 bytes
	Driver Partition Map (for 512 byte blocks)      512 bytes
	Empty                                           512 bytes
	Driver Partition                                N x 2048 bytes
	HFS Partition Boot Block                        1024 bytes

The Perl script "hdisk.pl" can be used to give a listing of what's on
a Mac CD. hdisk.pl is part of hfsutils.

A hybrid CD is made using the option "-boot-hfs-file" e.g.

mkhybrid -boot-hfs-file HFS_driver_file -o hfs.raw src_files/

The -boot-hfs-file implies the -hfs option.

PLEASE NOTE:

By using a driver from an Apple CD and copying Apple software to your CD,
you become liable to obey Apple Computer, Inc. Software License Agreements.

The driver code (both extracting the driver and creating partitions etc.
is based on code from "mkisofs 1.05 PLUS" by Andy Polyakov
<appro@fy.chalmers.se> (see http://fy.chalmers.se/~appro/mkisofs_plus.html)


Any comments, bug reports/fixes to the address below

James Pearson (j.pearson@ge.ucl.ac.uk)
19-Jul-2000

Find file types by using a modified "magic" file

Based on file v3.22 by Ian F. Darwin (see libfile/LEGAL.NOTICE and
libfile/README.dist - File v3.22 can be found at many archive sites)

For each entry in the magic file, the "message" for the initial offset MUST
be 4 characters for the CREATOR and 4 characters for the TYPE - white space is
optional between them. Any other characters on this line are ignored.
Continuation lines (starting with a '>') are also ignored i.e. only the initial
offset lines are used.

e.g magic entry for a GIF file:

# off	type		test		message
#
# GIF image
0       string          GIF8            8BIM GIFf
>4      string          7a              \b, version 8%s,
>4      string          9a              \b, version 8%s,
>6      leshort         >0              %hd x
>8      leshort         >0              %hd,
#>10    byte            &0x80           color mapped,
#>10    byte&0x07       =0x00           2 colors
#>10    byte&0x07       =0x01           4 colors
#>10    byte&0x07       =0x02           8 colors
#>10    byte&0x07       =0x03           16 colors
#>10    byte&0x07       =0x04           32 colors
#>10    byte&0x07       =0x05           64 colors
#>10    byte&0x07       =0x06           128 colors
#>10    byte&0x07       =0x07           256 colors

Just the "8BIM" "GIFf" will be used whatever the type of GIF file it is.
The continuation lines are used by the "file" command, but ignored by
mkhybrid. They could be left out completely.

The complete format of the magic file is given in the magic man page (magic.5).

See the file "magic" for other examples

Use with the -magic magic_file option, where magic_file is a file
described above.

The magic file can be used with the mapping file (option -map) - the order
these options appear on the command line is important.  mkhybrid will try to
detect if the file is one of the Unix/Mac files (e.g. a CAP or Netatalk
file) first. If that fails, it will then use the magic and/or mapping
file e.g:

mkhybrid -o output.raw -map mapping -magic magic src_dir

The above will check filename extensions first, if that fails to set the
CREATOR/TYPE, the magic file will be used. To check the magic file
before the filename extensions, use:

mkhybrid -o output.raw -magic magic -map mapping src_dir


Using just a magic file - filename extensions will not be checked e.g:

mkhybrid -o output.raw -magic magic src_dir

For the magic method to work, each file must be opened and read twice
(once to find it's CREATOR/TYPE, and a second time to actually copy the
file to the CD image). Therefore the -magic option may significantly
increase processing time.

If a file's CREATOR/TYPE is not set via the magic and mapping matches,
then the file is given the default CREATOR/TYPE.

Hiding files on a CD
=====================

This document attempts to show how to hide files from being seen by an
operating system accessing a CD as an ISO9660/Rock Ridge, Joliet or HFS
CD. It also highlights some of the limitations ...

Note: this document is about the various -hide options - not be confused with
the -hidden options.

The -hidden options set the 'EXISTENCE' bit in the directory entry which
means the file or directory will be invisible - unless some special option
is used to mount or view the CD - Linux has the 'unhide' mount option to
make these files visible. i.e. the directory entry exists on the CD.

With hindsight, to avoid confusion with the -hidden option, it would have
been better to chose an option name like '-omit' instead of '-hide'...

The various -hide options actually exclude the relevant directory entry
from the directory tree. Therefore, it is not possible to access a file
or directory that has be hidden with the -hide option when the ISO9600/Rock
Ridge directory is mounted - because the directory entry does not exist on the
CD (but the file data does). You would probably be able to access this file
or directory when mounted as a Joliet or HFS CD (depending on other options
used). Similarly, a directory entry hidden with the -hide-joliet option
will not be accessible when mounted as an Joliet CD. Similarly for -hide-hfs
etc.

If you don't want a file or directory to appear on the CD at all, then use the
-exclude options, not the -hide options (mkisofs completely ignores any
file/directory excluded with the -exclude options).


Using the hide options
======================

There are 6 hide options:

-hide		   Hide a file/directory from the ISO9660/Rock Ridge directory
-hide-list	   As above, but read file names from a file
-hide-joliet	   Hide a file/directory from the Joliet directory
-hide-joliet-list  As above, but read file names from a file
-hide-hfs	   Hide a file/directory from the HFS directory
-hide-hfs-list	   As above, but read file names from a file

You can use the -hide, -hide-joliet and/or -hide-hfs options as many times
as you like on the command line, but if you have many files to hide, then
it may be better to put your file names in a file (one per line) and use
the corresponding 'list' option. You can also use the three -hide-list options
as many times as you want.

The arguments to the -hide options are either the 'basename' or the 'whole
path name' of a file. That is, if you use the option:

% mkisofs -hide ABC [-other-options] CD_directory

then any file with the name ABC will be hidden. If you want to be more
specific, then use the whole name - as seen by mkisofs e.g.:

% mkisofs -hide CD_directory/XYZ/ABC [-other-options] CD_directory

will hide just the file 'CD_directory/XYZ/ABC' - not any other file called
'ABC' that might exist under 'CD_directory'. However, if your command line
is like:

% mkisofs -hide CD_directory/XYZ/ABC [-other-options] ./CD_directory

Then the file 'CD_directory/XYZ/ABC' will not be hidden because as far as
mkisofs is concerned. Its whole path is actually './CD_directory/XYZ/ABC'.

You can use wild cards in the -hide arguments.

If the file name to be hidden is a directory, then the directory and all
its contents are hidden.

The main use of the hide options is on a multi platform (hybrid CD) to hide
various files/directories that are operating system specific from been seen
on the CD when mounted on another OS. i.e. You may want to hide Macintosh
executables from being seen when the CD is mounted as a Joliet CD on a PC etc.

For example, say we want to create a ISO9660/Rock Ridge, Joliet, HFS hybrid
CD from files/directories in the directory called 'cd_dir' - which are:

MAC/
MAC/app
MAC/data/
MAC/data/file1
PC/
PC/app
PC/data/
PC/data/file1
UNIX/
UNIX/app
UNIX/data
UNIX/data/file1
COMMON/
COMMON/some_files

We could use the command line:

% mkisofs -r -J -hfs -hide MAC -hide PC -hide-joliet MAC \
	-hide-joliet UNIX -hide-hfs PC -hide-hfs UNIX -o cd.iso cd_dir

This will give a CD that when mounted as a Rock Ridge CD, you will only
see the directories UNIX and COMMON, as a Joliet CD the directories
PC and COMMON, and as an HFS CD the directories MAC and COMMON.

If you also had the three files in the current directory called README.hfs,
README.joliet and README.unix - but you wanted to have each of these
files appear as just 'README' when mounted, then you could use the above
command line with the following:

% mkisofs -r -J -hfs -graft-points -hide MAC -hide PC -hide-joliet MAC \
	-hide-joliet UNIX -hide-hfs PC -hide-hfs UNIX \
	-hide README.hfs -hide README.joliet -hide-joliet README.hfs \
	-hide-joliet README.uni -hide-hfs README.joliet -hide-hfs README.unix \
	README=README.hfs README=README.joliet README=README.unix \
	-o cd.iso cd_dir

Note: we've used the -graft-points option as we're using the '=' syntax
to insert the files called README.hfs, README.joliet and README.unix as
'README'

The resulting CD when mounted as a Rock Ridge CD, will have the directories
UNIX and COMMON - with the file called README - which was originally
called README.unix.

However, in most circumstances, it would be better to have the contents
of each of the OS specific directories (plus the contents of the COMMON
directory) to appear at the top level of the CD. i.e. when the CD is mounted
(as ISO9660/Rock Ridge, Joliet or HFS) it has the contents:

README
app
data/file1
some_files

Unfortunately, this is not as straight forward as it may seem - i.e. doing
the following may seem OK, but it won't work - for reasons I'll explain
later:

It gets a bit messy using the -graft-points syntax above, so we'll assume
each of the MAC, UNIX and PC directories contain the correct README, We'll
also change to the 'cd_dir' directory and use the command:

mkisofs -r -J -hfs -hide MAC -hide PC -hide-joliet MAC \
	-hide-joliet UNIX -hide-hfs PC -hide-hfs UNIX \
	-o cd.iso MAC PC UNIX COMMON

You will get errors like:

mkisofs: Error: UNIX/README and MAC/README have the same Rock Ridge name
...
mkisofs: Unable to sort directory

This is because you can not hide "pathspecs" that are directories ("pathspecs"
are file names given on the command line, or in a path-list file). This a
"feature" of mkisofs. In this case nothing is actually hidden at all.

So you might think that the following may work:

mkisofs -r -J -hfs -hide "MAC/*" -hide "PC/*" -hide-joliet "MAC/*" \
	-hide-joliet "UNIX/*" -hide-hfs "PC/*" -hide-hfs "UNIX/*" \
	-o cd.iso MAC PC UNIX COMMON

which may appear to work - but when the CD is mounted as an ISO9660/Rock Ridge
or Joliet CD, then the directory "data" is missing.

Again this is a feature of mkisofs - the directories PC/data and UNIX/data
are mapped by mkisofs to the same output directory called "/data" - the
various "hide" flags are stored with this directory info - in this case as
the output directory "/data" is first hidden from the ISO9660/Rock Ridge and
then the Joliet directory, the net result is that "/data" gets hidden from
both directories ... the way mkisofs hides HFS directories is slightly
different, so in this case the directory "data" exists on the HFS volume
and contains the correct contents.

However, it is possible to obtain the required result, but we have to be
careful about hiding multiple input directories that map to a single output
directory.

To do this we have to hide just the files in these directories (or more
accurately, all the non-directories). This is best done by using lists of
files to hide for example:

find PC -type f -print > pc.list
find UNIX -type f -print > unix.list
find MAC -type f -print > mac.list

mkisofs -r -J -hfs -hide-list pc.list -hide-list mac.list \
	-hide-joliet-list unix.list -hide-joliet-list mac.list \
	-hide-hfs-list pc.list -hide-hfs-list unix.list \
	-o cd.iso MAC PC UNIX COMMON

i.e. instead of trying to hide a directory and letting mkisofs hide its
contents, we explicitly hide all the files in the directory, but not the
directory and any of its sub-directories.

This will work for the above input files, but if your directory trees contain
symbolic links and/or directories that will not get merged, then the hide lists
will have to be tailored to get the required result.


James Pearson 22-Nov-2001

Any comments/problems to j.pearson@ge.ucl.ac.uk

Some thoughts on Joliet - why it is a dumb idea to have a CD
with Joliet enhancements but without Rock Ridge.
It also helps you to understand why it it not possible to append
a new session to a multi-session Joliet CD when Rock Ridge is
missing.

-	Joliet is not an accepted independant international standard
	like ISO-9660 or Rock Ridge (IEEE-P1282).
	Joliet has been created in 1995 - Rock Ridge in 1990.
	Rock Ridge became a IEEE standard around 1992.

Joliet is an unjustified addition to ISO-9660.

-	The Joliet tree has no relation to the
	ISO-9660 tree. Files from the ISO-9660 tree and from the
	Joliet tree only share content. In general, it is not
	possible to find the ISO-9660 name from a Joliet name
	and vice versa if you check both trees on a CD.

	Rock Ridge extensions are located at the end of each
	ISO-9660 directory record. This makes the Rock Ridge
	tree closely coupled to the ISO-9660 tree.

-	Joliet does not allow all characters too, so the
	Joliet filenames are not identical to the filenames
	on disk.

	As the ISO-9660 tree is the standard reference tree
	on a CD and the ISO-9660 filenames don't allow all
	characters and there is a length limitation, the
	ISO-9660 names cannot be mapped to the filenames on the
	OS reference tree on disk for doing multi-session.

	Due to different limitations, the short ISO-9660 name
	is in most cases not equal to the Joliet name or the
	Rock Ridge name.

-	Joliet has a filename length limitation of 64 chars (independent
	from the character coding and type e.g. European vs. Japanese)
	This is annoying as modern filesystems all allow 255 chars
	per path name component.

	Joliet uses UTF-16 coding while Rock Ridge uses ISO-8859 or
	UTF-16 based chars and allows 255 octets. Using UTF-8,
	Rock Ridge allows 85 Japanese characers or 255 US-ASCII chars.

Other than slightly longer filenames, Joliet offers no new properties
over plain ISO 9660. Rock Ridge is an open extendable standard and
there is no filesystem property on Win32 that could not be implemented
using Rock Ridge.

Except Linux and FreeBSD, there is no POSIX-like like OS that supports
Joliet. Never create Joliet only CD's for that reason.

Notes on using the --osx-hfs option when running mkisofs on MacOS X

mkisofs does not use any of the MacOS APIs to access files - it uses
standard (POSIX style) library calls. Under normal circumstances, all
mkisofs will 'see' is the data fork of files on an HFS (or HFS+) file system.

However, Apple have provided a way for POSIX style applications to
access the resource fork - using the following syntax:

If a file exists on an HFS volume with the name 'foo', then the resource fork
can be accessed using the file name 'foo/rsrc' or foo/..namedfork/rsrc'
(the data fork can also be accessed using 'foo/..namedfork/data').

These 'pseudo' file names are not normally visible in a directory - unless
you access them directly (e.g. 'ls -l */rsrc etc).

To access the finder information, Apple have provided an undocumented library
function called getattrlist(). Fortunately there are example of its usage
in the Darwin (MacOS kernel) source code.


Although MacOS X can use HFS(+) as its file system, Apple have decided to
move away from using HFS to store finder info and resource data - for
example, the TYPE of a file may be based on its file name extension and the
TYPE field in the finder info empty.

mkisofs knows nothing about these file name extension mappings, so if the
--osx-hfs option is used and the source files are on MacOS X HFS(+) volumes,
by the fact that they are HFS files, they will get identified as 'MacOS X HFS'
and the resulting file on the output CD image will have empty TYPE and CREATOR
fields.

Therefore, if the input finderinfo is blank and the the resource fork is
empty, mkisofs will assume the input file is not a 'real' HFS file - which
means the TYPE and CREATOR may then be set using the file's magic number or
mkisofs' file name extension mapping.

The only real benefit of using the --osx-hfs option is when the source files
are on an OS9 or earlier HFS or HFS+ volume e.g. an existing HFS CD.

James Pearson 3-Jul-2002

mkhybrid v1.13 has now merged with, and is a part of mkisofs v1.13

HFS hybrid code Copyright (C) James Pearson 1997, 1998, 1999, 2000
libhfs code Copyright (C) 1996, 1997 Robert Leslie
libfile code Copyright (c) Ian F. Darwin 1986, 1987, 1989,
	1990, 1991, 1992, 1994, 1995
mkisofs code Copyright 1993 Yggdrasil Computing, Incorporated

*** NEWS ***

Macs can now read Joliet CDs - see http://www.tempel.org/joliet/

***

*** IMPORTANT ***

The meaning of some of the HFS command line options has changed since
version 1.12b5.2. This change is to make the way mkisofs decodes the
various Apple/Unix file formats (CAP, AppleDouble, MacBinary etc.) less
confusing and more logical. To decode one or more of the Apple/Unix files,
then the corresponding "double dash" option must be given (i.e. --cap,
--double, --macbin etc.) mkisofs can search for all known Apple/Unix files
by using the -probe option.

The options that have changed are:

Option		old meaning			new meaning
======		===========			===========

-hfs		Create an HFS hybrid CD		Create an HFS hybrid CD.
		and attempt to decode all	Any Apple/Unix file is only
		Apple/Unix files (except	decoded if one or more of
		MacBinary and AppleSingle)	the "double dash" options are
						given

-apple		Create an ISO9660 with		Create an ISO9660 with
		Apple extensions CD and		Apple extensions CD. Any
		attempt to decode all		Apple/Unix file is only decoded
		Apple/Unix files (except	if one or more of the
		MacBinary and AppleSingle)	"double dash" options are given

-no-mac-files	Do not attempt to decode	No longer used
		any Apple/Unix file

-probe		Attempt to decode		Attempt to decode all
		MacBinary and AppleSingle	Apple/Unix files
		as well as the other
		Apple/Unix files

***

Most of the HFS features work fine, however, some are not fully tested.
These are marked as "Alpha" in the man page.

See "ChangeLog.mkhybrid" for any minor changes/bug fixes

If you are using SunOS 4.1.[34], then you need the following patches
to read CDs with associated files:

SunOS 4.1.3:		Patch 101832-05
SunOS 4.1.3_U1:		Patch 101833-02
SunOS 4.1.4:		Patch 102583-02


EXAMPLES

To create a HFS hybrid CD with the Joliet and Rock Ridge extensions of
the source directory cd_dir:

% mkisofs -o cd.iso -r -J -hfs cd_dir

To create a HFS hybrid CD from the source directory cd_dir that contains
Netatalk Apple/Unix files:

% mkisofs -o cd.iso --netatalk cd_dir

To create a HFS hybrid CD from the source directory cd_dir, giving all files
CREATOR and TYPES based on just their filename extensions listed in the file
"mapping".:

% mkisofs -o cd.iso -map mapping cd_dir

To create a CD with the 'Apple Extensions to ISO9660', from the source
direcories cd_dir and another_dir. Files in all the known Apple/Unix format
are decoded and any other files are given CREATOR and TYPE based on their
magic number given in the file "magic":

% mkisofs -o cd.iso -apple -magic magic -probe cd_dir another_dir

The following example puts different files on the CD that all have
the name README, but have different contents when seen as a
ISO9660/RockRidge, Joliet or HFS CD.

Current directory contains:

% ls -F
README.hfs     README.joliet  README.unix    cd_dir/

The following command puts the contents of the directory "cd_dir" on the
CD along with the three README files - but only one will be seen from
each of the three filesystems:

% mkisofs -o cd.iso -hfs -J -r \
        -hide README.hfs -hide README.joliet \
        -hide-joliet README.hfs -hide-joliet README.unix \
        -hide-hfs README.joliet -hide-hfs README.unix \
        README=README.hfs README=README.joliet README=README.unix \
        cd_dir

i.e. the file README.hfs will be seen as README on the HFS CD and the
other two README files will be hidden. Similarly for the Joliet and
ISO9660/RockRidge CD.

There are probably all sorts of stange results possible with
combinations of the hide options ...


Any comments, bug reports/fixes about the HFS parts of mkisofs to the
address below.

Please state the version, platform and command line used when submitting
a bug report - the output from "-log-file -v" would help.

James Pearson (j.pearson@ge.ucl.ac.uk)

I have extended mkhybrid to create a CD that is bootable via PPCbug
on a PowerPC Reference Platform compliant machine (referred to as
PReP).

This includes a number of IBM RS-6000 clones, along with most of
Motorola's embedded PowerPC boards, such as the MTX and MVME
boards. (The motorola boards are sometimes referred to as PowerPlus)

To build a bootable CD, you will first need a kernel image for your
machine. Put the image somewhere in the filesystem you want
to generate and ISO9660 image from.

The '-B' or '-prep-boot' flags are used to specify the image file
to use. The path must be relative to the root of the CD filesytem,
NOT from the current directory.

For example: to make an image of /tmp/cd and use the image file
/tmp/cd/zImage, (with rock ridge extensions) use:

mkhybrid -r -B zImage /tmp/cd -o cd.img

Since there are four entries for bootable 'partitions', I have
allowed up to 4 different images to be used. This might be
usefull if one has need of different kernel images for different
machines on the same CD.

The first image will be in the first partition entry, so if one
uses:

mkhybrid -r -B zImage1 -B zImage2 -B zImage3 -B zImage4 /tmp/cd

This will result in 4 bootable images. To boot off the first image
from PPCbug, use 'pboot 0 41' from the ppcbug> prompt.
(assuming the CDROM is at SCSI ID 4.. replace the 4 with the SCSI
ID of the CDROM if not.) The second image is at 'pboot 0 42', etc.

There should not be any conflicts with any of the HFS or hybrid
functions, since the space used by the PReP partition maps is
unused by anything else. If fact, the goal is to make a CD
bootable on both Mac's and PReP machines ;)

For any questions contact me at one of the following addresses:
troy@microux.com
troy@blacklablinux.com
hozer@drgw.net

The -icon-position option will attempt to preserve folder window positions,
scroll bars, views etc. for Apple/Unix file formats that support this
information (see below for which Apple/Unix encoding are supported).

This information is stored in the 'FinderInfo' part of a Apple/Unix directory.
For example, in a CAP directory structure a directory called 'dirA' will
have the necessary FinderInfo stored in file '.finderinfo/dirA'. This file
stores information including, the folder's location and size on screen,
its scroll positions, folder View (view as Icons, Small Icons, etc.).

However, the similar FinderInfo data for the 'root' folder is a special case.
For example, if a directory called '/some/dir/macfiles' is a CAP volume that
is mounted on a Mac as 'macfiles', then the FinderInfo for this directory
is stored in the file '/some/dir/.finderinfo/macfiles' - which is outside
the CAP directory structure.

To get round this, an extra option, '-root-info' is used that takes as its
argument the name of the file that stores the root folder's FinderInfo.

Using the above example, the command file options will be something like:

% mkhybrid --cap -root-info /some/dir/.finderinfo/macfiles /some/dir/macfiles

The format of the root FinderInfo file must be the same as the 'double-dash'
option(s) given on the command line.

The Apple/Unix encodings that mkhybrid can decode the root FinderInfo are:

CAP:
	CAP directory:		/some/dir/macfiles
	Root FinderInfo file:	/some/dir/.finderinfo/macfiles

Netatalk:
	Netatalk directory:	/some/dir/macfiles
	Root FinderInfo file:	/some/dir/.AppleDouble/RootInfo

EtherShare:
	EtherShare directory:	/some/dir/macfiles
	Root FinderInfo file:	/some/dir/.rsrc/macfiles

If an HFS disk is mounted on a Linux platform, then the root FinderInfo
files are:

Option 'fork=cap':
	Root FinderInfo file:	/mountpoint/.rootinfo

Option 'fork=double':
	Root FinderInfo file:	/mountpoint/%RootInfo

Option 'fork=netatalk':
	Root FinderInfo file:	/mountpoint/.AppleDouble/RootInfo


The '-root-info' option implies the '-icon-position' option. Future releases
of mkhybrid may automatically find the root FinderInfo file.

The volume name is not set from the root FinderInfo file. Use the -V or
-hfs-volid options to set the volume name.

Currently UShare, SGI/XINET, PC Exchange and SFM Apple/Unix root FinderInfo
files are not supported by mkhybrid - more information about these formats
is required in order to supoort them.

AppleSingle and MacBinary are file only formats - they don't support folders
or volumes.

Using this option, it is now possible to make a nearly true representation
of a Mac folder layout on a Unix/Linux platform.

James Pearson 26-Apr-2000

Any comments/problems to j.pearson@ge.ucl.ac.uk

/* @(#)README.session	1.3 99/03/02 eric */

	This release of mkisofs has basic support completed for
multiple sessions.  However, we still need some interaction
between cdrecord and mkisofs for this to work correctly. This is needed as
only cdrecord knows the different ways to gather these numbers for all
different drives. It may be that future versions of mkisofs will include
the needed support for MMC compliant drives.

	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. Note that there are operating
systems that don't allow to read from CD drives with a sector size
of 2048 bytes per sector. To use mkisofs on such an operating system, you
will need a version of mkisofs that includes the SCSI transport library
from cdrecord. Simply use the dev= syntax from cdrecord with -M in
such a case. It will tell mkisofs to use the SCSI transport library to
read from the CD instead of using the standard read() OS interface.

	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 cdrecord.

	Note that if you use -C and omit -M, it effectively means that
you are writing a new session, starting at a non-zero block number,
and you are effectively ignoring all of the previous session contents.
When this session is sent to the writer, the new session effectively
"erases" the previous session.

	In practice you should be able to do something like:

mkisofs [other options] -C `cdrecord dev=b,t,l -msinfo` \
		-M /dev/cdblkdev

Replace 'b,t,l' by the aproriate numbers for SCSIbus, target and lun
of your drive.

Note: As of the 1.12b5 release, the multi-session technology has
matured quite significantly.  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
cdrecord has been tested, and I believe it works correctly.  Caveat
Emptor.

[Mar 1, 1999].

Sort the order of file data on the CD
=====================================

Note: this option does not sort the order of the file names that appear
in the ISO9660 directory. It sorts the order in which the file data is
written to the CD image.

This option is useful in order to optimize the data layout on a CD.

To use, type something like:

mkisofs -o cdimage.iso -sort sort_file [other_options] cd_dir

The file 'sort_file' contains two columns of:

filename	weight

where filename is the whole name of a file/directory as mkisofs will see it
and weight is a whole number between +/- 2147483647

The files will be sorted with the highest weights first and lowest last.
The default weight is zero.

If the filename is a directory name, then all the files in that directory (and
sub-directories) will use its weight as their default weight.

e.g.

If the directory 'cd_dir' contains two directories called 'dir1' and 'dir2'
with files 'A', 'B' and 'C' in dir1 and 'X', 'Y' and 'Z', the the file
'sort_file' could look something like:

cd_dir/dir2	1000
cd_dir/dir2/Y	2000
cd_dir/dir1/B	-2000
cd_dir/dir1/A	-8000

Note: There must be only one space or tab character between the filename and
the weight and the weight must be the last characters on a line. The filename
is taken to include all the characters from the first in a line, up to, but
not including the last space or tab character on a line. This is to allow
for space characters to be in, or at the end of a filename.


The command:

mkisofs -o cdimage.iso -sort sort_file cd_dir

will sort the above file data as:

cd_dir/dir2/Y
cd_dir/dir2/X
cd_dir/dir2/Z
cd_dir/dir1/C
cd_dir/dir1/B
cd_dir/dir1/A

Note: files 'X' and 'Z' both have the weight 1000 - their sort order will then
be the normal ISO9660 sort order (i.e. alphabetical in this case).

File C will have the default weight of 0

Warning: the filenames in the sort list MUST match the whole path as seen by
mkisofs. i.e. in the above case, if the command line was:

mkisofs -o cdimage.iso -sort sort_file ./cd_dir

then the sort_file filename will have to changed as accordingly.

Notes
=====

CDs are written from the middle outwards. High weighted files will be nearer
the inside of the CD.

Wildcards in the filename list should work.

If a file appears more than once in the source directory tree, then the file
is only added once to the CD image - i.e. a hard linked file, or symbolic
link if using the -f option. The file will be sorted according to the
highest weighting given to any of the linked files.

Zero length files are not sorted - the 'start extent' *may* appear to be in
the middle of another file after sorting. This is because zero length files
are given the start extent after the last file added to the CD at that time.
This address is not changed by the sorting, so it may appear that the file
address is in another file - however as they are zero length, this will
not matter!

Directories are not sorted by this flag - directories HAVE to be in the
ISO9660 sort order - however, the files the directory entry points to, can be
anywhere on the CD.

Existing files from any previous sessions will not be sorted - they already
exist on the CD and can not be moved!

I have no idea if this is really useful ...


James Pearson 22-Nov-2001

Any comments/problems to j.pearson@ge.ucl.ac.uk

# @(#)README.sparcboot	1.1 99/12/12 joerg
#
The sparc boot feature does allow you to create your own Sun sparc boot disk.
This will allow you to create modified Solaris install disks or to create
installation CD's for other OS that run on sparc systems.

A CD that is bootable on a Sun sparc system has a Sun disk label on sector 0
and some Sun sparc disk partitions behind the ISO-9660 filesystem image.

The layout of a sparc boot CD:

----------------------------------------------------------------------------------------------------
|Sun disk label| Iso 9660 filesystem |Generic sun4 boot|sun4c boot|sun4m boot|sun4d boot|sun4e boot|
----------------------------------------------------------------------------------------------------

On older system CD's all boot partition contain a full UFS miniroot filesystem.
On newer CD's the images on slice 2 and above only contain boot redirects to
slice 1.

To create a CD that is bootable on Sun sparc systems you need to have the
boot images for the apropriate sparc architecture.

A boot image file usually is a UFS filesystem image that contains the
primary boot image at byte offset 512 ... 8191.

You may get such boot images by extracting partitions 1..5 from a Sun Solaris install CD,
but any bootable image should work.

Here is an expample how to do this with the Solaris 7 install CD.

dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s1 of=sun4
dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s2 of=sun4c
dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s3 of=sun4m
dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s4 of=sun4d
dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s5 of=sun4e


mkisofs -R -sparc-boot sun4,sun4c,sun4m,sun4d,sun4e -o boot.img /mnt/install

Will create the bootable image in boot.img.

If you like to make the boot images smaller, you may call 'fstyp -v'
on the images and use the 'size' value to get the needed minimal
boot image size in kB.

The result for the S7 boot CD is:

ufs
magic   11954   format  dynamic time    Wed Oct  7 00:00:30 1998
sblkno  8       cblkno  12      iblkno  16      dblkno  252
sbsize  2048    cgsize  2048    cgoffset 20     cgmask  0xfffffff0
ncg     7       size    25704   blocks  23987
			^^^^^
			This is the number of interest.
bsize   8192    shift   13      mask    0xffffe000
fsize   2048    shift   11      mask    0xfffff800
frag    4       shift   2       fsbtodb 2
minfree 10%     maxbpg  2048    optim   time
maxcontig 256   rotdelay 0ms    rps     90
csaddr  252     cssize  2048    shift   9       mask    0xfffffe00
ntrak   14      nsect   72      spc     1008    ncyl    102
cpg     16      bpg     1008    fpg     4032    ipg     3776
nindir  2048    inopb   64      nspf    4
nbfree  1768    ndir    667     nifree  24329   nffree  9
cgrotor 2       fmod    0       ronly   0

So you should call:

dd if=/vol/dev/dsk/c0t6/sol_7_sparc_sun_srvr/s1 of=sun4 bs=1k count=25704

To modify this filesystem, you can mount it using the fbk driver:

chmod +t ./sun4		# Need to do this to avoid vm cache aliasing problems

mount -F fbk -o rw,type=ufs /dev/fbk0:sun4 /mnt

# @(#)README.sunx86boot	1.3 05/02/25 Copyright 2003 J. Schilling

A Solaris x86 Boot CD looks the like this:

-	A PC type fdisk partition map is in CD sector 0 at offset 0
	This fdisk partition map contains a single Solaris 0x82 type
	partition starting at CD sector 0 at offset 512.

-	A SVr4 disk partition label is at CD sector 0 at offset 1024.
	This equates the usual 512 byte offset to the primary partition
	used by SVr4.

	This SVr4 partition label defines:

	-	Partition 0 to contain a usually UFS type boot filesystem

	-	Partition 1 to map the ISO-9660 filesystem.

		This seems to be a conceptual bug from Sun, as it is
		impossible to mount this partition because this partition
		would point outside the primary fdisk partition type 0x82

	-	Partition 2 maps the whole CD.


A boot CD created by Sun contains a master boot record in CD sector 0 offset 0.
The size if this MBR is 0x1BE (446 decimal) as usual on PCs.

At CD sector 0 offset 512, there is a "primary boot sector". The MBR assumes
that is always gets loaded together with the ""primary boot sector".

The El-Torito map for this CD defines a "no-emulation" boot sitting at CD sector 0
and being 4 512 byte sectors in size. This covers the 1024 bytes of above
boot code. Note that mkisofs will not put the no-emulation boot at sector 0
as it keeps the boot inside the area used for other file content data.

At CD sector 1..15, there is a secondary boot code that understands UFS and tries
to boot from UFS slice 0. If you like to boot from different filesystem types,
you need to replace this boot code. The real size used by the secondary boot
is 31 x 512 bytes == 15872 bytes.

To get hold of the three boot files, do the following with e.g. a Solaris 10
boot CD:

readcd dev=1,0 f=CD.out sectors=0-32

Replace dev=1,0 with the apropriate values for your system (see readcd -scanbus).

sdd if=CD.out bs=446 count=1 of=mboot
sdd if=CD.out count=1 iseek=512 of=pboot
sdd if=CD.out count=60 iseek=2048 of=bootblk

To create the needed files for the misofs command line example below, do the
following:

sdd if=mboot -fill of=eltoritoboot
cat pboot >> eltoritoboot

sdd -inull bs=2k count=1 of=genboot
cat bootblk >> genboot

If you like the CD to look more similar to the original Sun CDs, use:

cp eltoritoboot genboot
sdd -inull bs=1k count=1 >> genboot
cat bootblk >> genboot

If you like to create a CD similar to the Solaris 10 boot CD, do the following:

mkdir isodir
star -cPM -C /vol/dev/dsk/c1t1d0/multi_icd_sol_10_x86/s2 . | star -xp -xdot -C isodir
cp eltoritoboot isodir/.bootimage

mkisofs -G genboot  -no-emul-boot -b .bootimage -c .catalog -R -o bootcd.iso -sunx86-boot /vol/dev/dsk/c1t1d0/multi_icd_sol_10_x86/s0 isodir/

#ident @(#)readme.mk	1.1 07/06/14
###########################################################################
# Sample makefile for installing non-localized auxiliary files
###########################################################################
SRCROOT=	..
RULESDIR=	RULES
include		$(SRCROOT)/$(RULESDIR)/rules.top
###########################################################################

INSDIR=		share/doc/mkisofs
TARGET=		README
#XMK_FILE=	Makefile.man

###########################################################################
include		$(SRCROOT)/$(RULESDIR)/rules.aux
###########################################################################