Anonymous user
Talk:El-Torito: Difference between revisions
m
→BOOTBOOT Spam
(New page: == 2k limitation somewhere? == Could someone please explain where the "2k" comes from under "What's Next?" in the sentence: "you can start reading the file system, in the 2k that you have...) |
m (→BOOTBOOT Spam) |
||
| (9 intermediate revisions by 5 users not shown) | |||
Line 4:
"you can start reading the file system, in the 2k that you have available in your boot sector."
Is the El-Torito standard limited to loading boot sectors no larger than 2KiB? --[[User:Messiahandrw|MessiahAndrw]] 10:48, 27 July 2011 (UTC)
:If you follow the link to [[Bootable El-Torito CD with GRUB Legacy]], you will find the `genisoimage` option `-boot-load-size 4` (also used in this article) explained as follows: "''Specifies the number of 512-bytes sectors to load. Four 512-byte sectors (2048 bytes) is one CD sector and is the number supported by most BIOS.''" (Had to look it up myself, but there. ;-) ) -- [[User:Solar|Solar]] 12:13, 27 July 2011 (UTC)
I discovered this through experimentation (I'm trying to boot directly into my kernel using El-Torito rather than via a bootloader). I'm editing the article now to explain this. --[[User:Messiahandrw|MessiahAndrw]] 14:20, 27 July 2011 (UTC)
2K sectors come from the ISO9660 specification - see [http://en.wikipedia.org/wiki/Iso9660#Specifications http://en.wikipedia.org/wiki/Iso9660#Specifications].
The basic of storage is a Frame of 24 bytes, and a Sector is defined as 98 Frames. This gives 2352 usable bytes per Sector. Because CDs store their data in 1 single spiral, it is impossible to calculate the exact start of every single sector given the technology at the time (It is better now). As a result, all Sectors must have alignment data so the CD reader can precicely locate the start of the sector given a rough approximation from a calculation. In addition, CDs damage very easily, so they have always had error correcting data written into the sector so the sector can still be recovered correctly if damaged a little. As a result, ISO9660 splits the 2352 usable bytes per sector into 12 bytes of alignment/synchronisation data, followed by 2048 bytes of regular data, followed by 288 bytes of error detecting and correcting codes. [[User:Andyhhp|Andyhhp]] 00:20, 29 July 2011 (UTC)
== Proposals for enhancements ==
I am the developer of xorriso, which produces bootable
ISO 9660 images. Here are some proposals after reading
this wiki page.
I am ready to implement them here. But first i ask
whether such changes would be appreciated.
------------------------
The examples about floppy emulation and Legacy GRUB are
quite antique, meanwhile.
GRUB2 script grub-mkrescue should be mentioned:
http://www.gnu.org/software/grub/manual/html_node/Making-a-GRUB-bootable-CD_002dROM.html#Making-a-GRUB-bootable-CD_002dROM
Bootloader ISOLINUX should be mentioned:
http://www.syslinux.org/wiki/index.php/ISOLINUX
Probably
http://wiki.osdev.org/SysLinux
should get a sibling for the ISOLINUX aspects of SYSLINUX.
------------------------
"Writing an El-Torito Boot Sector"
This headline does not match the object which is described.
"El-Torito Boot Sector" would normally be the El-Torito
Boot Record, which is a ECMA-119 Volume Descriptor.
The description rather applies to the boot image,
which is the blob pointed to by an entry of the
El-Torito Boot Catalog.
With BIOS, that blob is the first stage of a boot loader.
With EFI, the blob is a FAT filesystem image (but not an
emulated floppy).
The structure of El-Torito Volume Descriptor, Boot Catalog,
and boot images should be described, in order to clarify
the possibilities of multiple boot images for e.g. BIOS
and EFI.
I.e. Boot Record points to Boot Catalog which lists the
available boot images.
Further one should mention that ISO images can carry
MBR and GPT for booting the image from hard-disk-like
devices (e.g. USB sticks).
Example of combined BIOS and EFI via El-Torito,
MBR, and GPT as was done for debian-7.1.0-amd64-netinst.iso:
xorriso -as mkisofs
...
-c isolinux/boot.cat
-b isolinux/isolinux.bin
-no-emul-boot -boot-load-size 4 -boot-info-table
-isohybrid-mbr syslinux/usr/lib/syslinux/isohdpfx.bin
-eltorito-alt-boot
-e boot/grub/efi.img
-no-emul-boot -isohybrid-gpt-basdat
...
boot1
...
Option -eltorito-alt-boot separates the settings
for the BIOS boot image from those for the EFI
boot image.
The files isolinux/isolinux.bin and boot/grub/efi.img
get into the ISO image from source directory ./boot1.
File syslinux/usr/lib/syslinux/isohdpfx.bin is copied
directly from the SYSLINUX installation into the ISO
image. It contains the MBR template.
Option -isohybrid-gpt-basdat announces the FAT image
boot/grub/efi.img as GPT partition.
See http://www.gnu.org/software/xorriso/man_1_xorrisofs.html
Description on byte level:
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt
--------
The boot information table does not belong to El Torito.
It is rather part of boot loader specifications,
possibly invented for ISOLINUX.
--------
-boot-info-table-o [IsoFile.iso]
must rather be
-boot-info-table [-o IsoFile.iso]
or more safely for the terminal
-boot-info-table -o IsoFile.iso
--------
Maybe one should explain the relations of mkisofs, genisoimage,
other clones, and the mkisofs emulation of xorriso.
I would volunteer to try this as unbiasedly as possible for
one of the competitors.
[[User:Scdbackup|Scdbackup]] 02:36, 15 October 2013 (CDT)
: After trying to apply smaller changes i decided to propose a re-write of large
: parts of the text. See my user page [[User:Scdbackup]].
: If no objections arise within a few days, i will put it on the article page.
:
: [[User:Scdbackup|Scdbackup]] 13:03, 18 October 2013 (CDT)
:: The re-written parts are now in the article. Review would be appreciated.
:: [[User:Scdbackup|Scdbackup]] 05:51, 20 October 2013 (CDT)
== BOOTBOOT Spam ==
What? Why? --[[User:Wxwisiasdf|Wxwisiasdf]] 21:46, 12 May 2022 (CDT)
| |||