libburnia/legacy
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Argument "." for system area import commands

Browse Source
This commit is contained in:
Thomas Schmitt
2014-10-28 14:07:32 +00:00
parent b66bf3e391
commit 9cd6c71d39
9 changed files with 330 additions and 240 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
libisoburn/trunk/xorriso/xorriso.1
View File

@ -9,7 +9,7 @@
.\" First parameter, NAME, should be all caps
.\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
.\" other parameters are allowed: see man(7), man(1)
.TH XORRISO 1 "Version 1.3.9, Sep 28, 2014"
.TH XORRISO 1 "Version 1.3.9, Oct 28, 2014"
.\" Please adjust this date whenever revising the manpage.
.\"
.\" Some roff macros, for reference:
@ -2914,22 +2914,25 @@ capability to influence the bootability of the existing sessions, unless one
can assume overwriteable media.
.br
There are booting mechanisms which do not use an El Torito record but rather
start at the first bytes of the image: PC\-BIOS MBR for hard\-disk\-like devices,
start at the first bytes of the image: PC\-BIOS MBR or EFI GPT for
hard\-disk\-like devices,
APM partition entries for Macs which expect HFS+ boot images,
MIPS Volume Header for old SGI computers, DEC Boot Block for old DECstation,
SUN Disk Label for SPARC machines, HP\-PA boot sector for HP PA\-RISC machines.
.br
The boot firmware EFI may use programs which are located in a FAT filesystem
and announced by an MBR partition table entry.
.br
.TP
\fB\-boot_image\fR "any"|"isolinux"|"grub"
.br
"discard"|"keep"|"patch"|"show_status"|bootspec|"next"
.br
Define the handling of a set of El Torito boot images which
has been read from an existing ISO image or define how to make a prepared
boot image file set bootable. Such file sets get produced by ISOLINUX or GRUB.
Define the equipment of the emerging filesystem with boot entry points.
.br
With systems which boot via BIOS or EFI this is a set of El Torito
boot images, possibly MBR boot code, and possibly partition tables of
type MBR, GPT, or APM.
Such file sets get produced by boot loader systems like ISOLINUX or GRUB.
.br
Each \-boot_image command has two parameters: type and setting. More than one
\-boot_image command may be used to define the handling of one or more boot
images. Sequence matters.
@ -2939,10 +2942,22 @@ Type \fBany\fR makes
no assumptions about the origin of the boot images.
.br
El Torito boot images of any type can be newly inserted, or discarded,
or patched, or kept unaltered.
Whether to patch or to keep depends on whether
the boot images contain boot info tables.
When loading an ISO filesystem, system area and El Torito boot images get
loaded, too. The default behavior is not to write loaded El Torito boot images
and to write the loaded system area content without alterations.
.br
\fBdiscard\fR gives up the El Torito boot catalog and its boot images.
regardless whether loaded from an ISO filesystem or defined by commands.
Any BIOS or EFI related boot options get revoked.
Nevertheless, loaded system area data stay valid. If desired, they have to be
erased by
.br
\-boot_image any system_area=/dev/zero
.br
\fBkeep\fR keeps or copies El Torito boot images unaltered and writes a new catalog.
.br
\fBpatch\fR applies patching to existing El Torito boot images
if they seem to bear a boot info table.
.br
A boot info table needs to be patched when the boot image gets newly
introduced into the ISO image or if an existing image gets relocated.
@ -2966,15 +2981,15 @@ and their designated fate.
.br
A \fBbootspec\fR is a word of the form name=value. It is used to describe
the parameters of a boot image by an El Torito record or a MBR.
the parameters of a boot feature.
The names "dir", "bin_path", "efi_path" lead to El Torito bootable images.
Name "system_area" activates a given file as MBR.
Name "system_area" activates a given file as MBR or other disk header.
.br
On all media types this is possible within the first session. In further
sessions an existing boot image can get replaced by a new one, but depending
on the media type this may have few effect at boot time. See above.
.br
The boot image and its supporting files have to be added to the ISO image by
El Torito boot images have to be added to the ISO image by
normal means (image loading, \-map, \-add, ...). In case of ISOLINUX the files
should reside either in ISO image directory /isolinux or in /boot/isolinux .
In that case it suffices to use as bootspec the text "\fBdir=/isolinux\fR"
@ -3001,10 +3016,13 @@ one of the boot images. But it is not necessary that it appears in the
directory tree at all. One may hide it in all trees by \fBcat_hidden=on\fR.
Other possible values are "iso_rr", "joliet", "hfsplus", and the default "off".
.br
\fBbin_path=\fR depicts a boot image file, a binary program which is to be
started by the hardware boot facility (e.g. the BIOS) at boot time.
\fBbin_path=\fR depicts an El Torito boot image file, a binary program
which is to be started by the hardware boot facility (e.g. the BIOS)
at boot time.
.br
\fBefi_path=\fR depicts a boot image file that is ready for EFI booting.
\fBefi_path=\fR depicts an El Torito boot image file that is ready for
EFI booting. This is normally a FAT filesystem image not larger than
65535 blocks of 512 bytes (= 32 MiB \- 512).
Its load_size is determined automatically, no boot info table gets
written, no boot medium gets emulated, platform_id is 0xef.
.br
@ -3026,8 +3044,9 @@ The address is written as 64 bit little\-endian number. It is the
and then incremented by 5.
"grub2_boot_info=off" disables this patching.
.br
\fBplatform_id=\fR defines by two hex digits the Platform ID of the
boot image. "00" is 80x86 PC\-BIOS, "01" is PowerPC, "02" is Mac, "ef" is EFI.
\fBplatform_id=\fR defines by a hexadecimal or decimal number
the Platform ID of the boot image. "0x00" is 80x86 PC\-BIOS, "0x01" is PowerPC,
"0x02" is Mac, "0xef" is EFI (decimal "239").
.br
\fBid_string=\fRtext|56_hexdigits defines the ID string of the boot catalog
section where the boot image will be listed. If the value consists of 56
@ -3044,13 +3063,6 @@ They get attributed to the boot image entry in the catalog.
Any following \-bootimage bootspecs will affect the new image.
The first "next" discards loaded boot images and their catalog.
.br
\fBdiscard\fR gives up an existing boot catalog and its boot images.
.br
\fBkeep\fR keeps or copies boot images unaltered and writes a new catalog.
.br
\fBpatch\fR applies patching to existing boot images
if they seem to bear a boot info table.
.br
\fBsystem_area=\fRdisk_path copies at most 32768 bytes from the given
disk file to the very start of the ISO image.
This System Area is reserved for system dependent boot software, e.g. an MBR
@ -3073,6 +3085,12 @@ The boot image will then be mentioned in GPT as Basic Data
or GPT HFS+ partition, and in APM as HFS+ partition.
The first three GPT partitions will also be marked by MBR partitions.
.br
In multi\-session situations the existing System Area is preserved by default.
In in this case, the special disk_path "." prevents reading of
a disk file but nevertheless causes adjustments in the
loaded system area data. Such adjustments may get ordered by \-boot_image
commands.
.br
\fBgrub2_mbr=\fRdisk_path works like "any" system_area= with additional
patching for modern GRUB MBRs. The content start address of the first boot
image is converted to a count of 512 byte blocks, and an offset of 4 is added.
@ -3096,7 +3114,6 @@ This works with or without system_area= or boot image.
Bootspecs chrp_boot_part=, prep_boot_part=, and efi_boot_part= overwrite
this entry in the MBR partition table.
.br
In follow\-up sessions the existing System Area is preserved by default.
If types "isolinux" or "grub" are set to "patch", then "partition_table=on"
is activated without new boot image.
In this case the existing System Area gets checked whether it bears addresses
@ -3209,8 +3226,8 @@ RAM disk file.
and version 4.
For the appropriate value see in PALO source code: PALOHDRVERSION.
.br
\fBmips_discard\fR and \fBsparc_discard\fR
revoke any boot file declarations made for mips or mipsel resp. sparc.
\fBmips_discard\fR, \fBsparc_discard\fR, and \fBhppa_discard\fR
revoke any boot file declarations made for mips, mipsel, sparc resp. hppa.
This removes the ban on production of other boot blocks.
.br
\fBhfsplus_serial=\fRhexstring sets a string of 16 digits "0" to "9"