When run on a read-only (golden) source fileset, we get:
First off, why is genisoimage by default writing back to the original source files in the first place (!); and, secondly, what might one call at the commandline when invoking genisoimage to prohibit this behavior? manpages seem to fail here...
As mentioned in the output from genisoimage, the file which commonly gets written to is isolinux.bin,
...although there might be others in certain instances (comments, anyone?)
BTW: The original citations were taken from the OP found in this serverfault thread. I was able to reproduce the output on my (offline) "distro-maker" using a similar commandline with the sourcefile partition set as read-only. If allowed, genisoimage will definitely do as it indicates; and the target sourcefile (isolinux.bin) will be altered.
There doesn't seem to be any help in the manpages regarding a commandline parameter which would suppress this behavior. Which of your above commandline parameter(s) might work to keep these writebacks from occurring? Is the entire string to be utilized as a kind of "panacea"???
In any event, it seems as though this is a widely-applicable issue; and, judging from the number of hits this thread had in just the first 24 hours (over 5K), I'm not the only one out here with some concern...
ok you want to recreate the own iso-file but fot the "-boot-info-table" options trigger the mkisofs/genisoimage so it wants to regenerate the boot table located is in the your boot-image and then its fails because isolinux.bin is default read-only permission from iso or mounted iso.
if you dont need to edit the boot image and/or boot-info-table *(iso fs sys infors,size of boot image,checksum info and all its locations...)
so remove the -boot-info-table your commandline and your command then your process must be works.
but the default/recommend way , copy the contents of all files from iso to writable an empty (newly created) directory and then execute the default mkisofs/genisoimage commands on to the this directory.
As this parameter seems to be rather ubiquitous in the context of pre-specified distro ISO build commandlines, could someone elaborate on what the implications might be for an ISO generated without calling -boot-info-table at build time (in both CD/DVD and flash media endpoint contexts)?
; This table hopefully gets filled in by mkisofs using the
; -boot-info-table option. If not, the values in this
; table are default values that we can use to get us what
; we need, at least under a certain set of assumptions.
global iso_boot_info
iso_boot_info:
bi_pvd: dd 16 ; LBA of primary volume descriptor
bi_file: dd 0 ; LBA of boot file
bi_length: dd 0xdeadbeef ; Length of boot file
bi_csum: dd 0xdeadbeef ; Checksum of boot file
bi_reserved: times 10 dd 0xdeadbeef ; Reserved
bi_end:
The format of this table is as follows; all integers are in sec-
tion 7.3.1 ("little endian") format.
Offset Name Size Meaning
8 bi_pvd 4 bytes LBA of primary volume descriptor
12 bi_file 4 bytes LBA of boot file
16 bi_length 4 bytes Boot file length in bytes
20 bi_csum 4 bytes 32-bit checksum
24 bi_reserved 40 bytes Reserved
The 32-bit checksum is the sum of all the 32-bit words in the
boot file starting at byte offset 64. All linear block addresses
(LBAs) are given in CD sectors (normally 2048 bytes).
Example of Boot Information Table. (starts at offset 8 and is 56 bytes long.)
.........
[ORG 0x7C00]
[BITS 16]
start:
jmp 0x0000:boot
times 8-($-$$) db 0
; Boot Information Table
bi_PrimaryVolumeDescriptor resd 1 ; LBA of the Primary Volume Descriptor
bi_BootFileLocation resd 1 ; LBA of the Boot File
bi_BootFileLength resd 1 ; Length of the boot file in bytes
bi_Checksum resd 1 ; 32 bit checksum
bi_Reserved resb 40 ; Reserved 'for future standardization'
boot:
; Boot code here - set segment registers etc...
jmp $
.........
now lets look at the our mounts.
--------------------------
so we can see the just first lines (bytes) in the images.for see the boot-table..
# hexdump -Cv /cdrom_with_boot/isolinux/isolinux.bin|head -4
00000000 fa ea 40 7c 00 00 90 90 10 00 00 00 87 00 00 00 |..@|............|
00000010 93 39 00 00 a4 87 2c 54 00 00 00 00 00 00 00 00 |.9....,T........|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
# hexdump -Cv /cdrom_without_boot/isolinux/isolinux.bin|head -4
00000000 fa ea 40 7c 00 00 90 90 10 00 00 00 86 00 00 00 |..@|............|
00000010 93 39 00 00 a4 87 2c 54 00 00 00 00 00 00 00 00 |.9....,T........|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
#### in this boot-table is not modified that come from original iso (read-only) but !!
#### in the below command (isoinfo which read the iso information) displays the it is 135(87 hex) NOT 134 (86 hex)
#### so actually LBA of the our boot-image (isolinux.bin) value is actually wrong ( its in the boot-table and locate offset 12-16. bytes of the boot-image)
#### real LBA is must be 135(87 hex) but seem like 134.
# hexdump -Cv /cdrom_original/isolinux/isolinux.bin|head -4
00000000 fa ea 40 7c 00 00 90 90 10 00 00 00 86 00 00 00 |..@|............|
00000010 93 39 00 00 a4 87 2c 54 00 00 00 00 00 00 00 00 |.9....,T........|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
original and without_boot isos boot table's are same because of we change the boot-file from original iso in when creating the without_boot iso.
with boot and without boot isos boot table differs in the 13.byte(s). and if i m not point to wrong offset it was for BootFileLocation.(12-16 nr. bytes for saving lba of boot file/image location) . because of we want to re-genarate the boot-table with new values with boot-info-table option.(but it seems there are just one change)
lets remember this.
...........
Offset Name Size Meaning
8 bi_pvd 4 bytes LBA of primary volume descriptor
12 bi_file 4 bytes LBA of boot file
so we want to modify boot-table (with -boot-info-table) values and LBA of the Boot File (as addresssing to CD-ROM image in) was changed..it is all.
-boot-info-table
Specifies that a 56-byte table with information of the CD-ROM layout will be patched in at offset 8 in the boot file. If this
option is given, the boot file is modified in the source filesystem, so make a copy of this file if it cannot be easily regen-
erated! See the EL TORITO BOOT INFO TABLE section for a description of this table.
lets look at the more preview.
( first read the boot-info-table and then gets primary volume descriptor address after gets information from the primary volume descriptor )
we already gets the lba boot table values from hexdump. (see above)
-----------------------------------------------------------------------------------------
86 hex = 134 dec (lba boot image) --> original iso (cdrom)
87 hex = 135 dec (lba boot image) --> new iso's values (with_boot and without_boot)
-----------------------------------------------------------------------------------------
at the sametime we check it from isoinfo via primary volume descriptor (like ext fs superblock --> more details in cdfs-iso-primary.html)
i see the boot image locations from above outputs in there new iso boot image's lba values are same and little differ from the original iso.
probably mkisofs/genisoimage located its (and others iso fs specs) to default values (pre-defined in the mkisofs/genisoimage ) of iso filesystem while creating new iso and therefore there is a little change.
finally only change seems this and to me it must not be problem for boot process while system boot.
and i tested all isos in the vm enviroment and all of them are worked success without any warning or exception.
