Re: Summary of the Debian CD BoF at DC15
Hi,
Steve McIntyre wrote:
> I'm open to making more different-sized image types so long as they
> make sense - ask!
I think an all-in-one ISO image for large USB sticks or
old hard disks in old or new USB boxes is of interest.
Let the target devices grow with Debian's total size. :))
Users of such devices would benefit if debian-cd could
avoid creating nested partitions and illegal combination of
MBR partitioning with GPT partitioning.
An appended EFI System Partition marked in MBR seems to be
best digestible for partition editors.
Like the arm64 ISOs:
Volume id : 'Debian 8.1.0 arm64 1'
El Torito catalog : 918 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 UEFI y none 0x0000 0x00 768 919
El Torito img path : 1 /boot/grub/efi.img
System area options: 0x00000b00
System area summary: MBR cyl-align-all
ISO image size/512 : 329728
Partition offset : 0
MBR heads per cyl : 64
MBR secs per head : 32
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x00 0x83 0 329728
MBR partition : 2 0x00 0xef 329728 2048
In contrast to
Volume id : 'Debian 8.1.0 amd64 1'
El Torito catalog : 974 1
El Torito cat path : /isolinux/boot.cat
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 975
El Torito boot img : 2 UEFI y none 0x0000 0x00 832 995
El Torito img path : 1 /isolinux/isolinux.bin
El Torito img opts : 1 boot-info-table isohybrid-suitable
El Torito img path : 2 /boot/grub/efi.img
System area options: 0x00000102
System area summary: MBR isohybrid cyl-align-on GPT APM
ISO image size/512 : 505856
Partition offset : 0
MBR heads per cyl : 64
MBR secs per head : 32
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0x00 0 505856
MBR partition : 2 0x00 0xef 3980 832
MBR partition path : 2 /boot/grub/efi.img
GPT : N Info
GPT disk GUID : 2fd7ea575eadc7469cef97fb6e7a7721
GPT entry array : 12 208 overlapping
GPT lba range : 64 505802 505855
GPT partition name : 1 490053004f00480079006200720069006400
GPT partname local : 1 ISOHybrid
GPT partition GUID : 1 2fd7ea575eadc7469ced97fb6e7a7721
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1000000000000001
GPT start and size : 1 0 505800
GPT partition name : 2 490053004f004800790062007200690064003100
GPT partname local : 2 ISOHybrid1
GPT partition GUID : 2 2fd7ea575eadc7469cec97fb6e7a7721
GPT type GUID : 2 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 2 0x1000000000000001
GPT start and size : 2 3980 832
GPT partition path : 2 /boot/grub/efi.img
APM : N Info
APM block size : 2048
APM gap fillers : 0
APM partition name : 1 EFI
APM partition type : 1 Apple_HFS
APM start and size : 1 995 208
APM partition path : 1 /boot/grub/efi.img
The BIOS El Torito and ISOLINUX isohybrid stuff would stay.
GPT and APM would be used only for images which strive for
outmost bootability via actually ill EFI implementations.
UEFI specs state that MBR partition type 0xef is fully
sufficient to mark a System Partition on HD.
The limit for MBR partitioning is 2 TiB.
If GPT is desired for getting larger sizes, then
libisoburn1-1.4.0-3.deb in testing offers xorrisofs option
-appended_part_as_gpt .
Pioneers wanted.
GPT imposes the problem of backup GPT, which is to be placed
at the end of the storage device. This concept does not play
well with the idea of a disk image that shall fit onto larger
disks. MBR partitioning has no such problem.
> UEFI (and SB) on kFreeBSD is an unknown quantity at this time.
Preparing to do a kFreeBSD VM install in the next days,
i already got me a mini.iso.
It obviously has GRUB2 BIOS equipment for CD and HD.
Volume id : 'ISOIMAGE'
El Torito catalog : 55 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 5452
El Torito img path : 1 /boot/grub/i386-pc/eltorito.img
El Torito img opts : 1 boot-info-table
System area options: 0x00000201
System area summary: MBR protective-msdos-label cyl-align-off
ISO image size/512 : 23512
Partition offset : 0
MBR heads per cyl : 64
MBR secs per head : 32
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0xcd 1 23511
So possibly grub-mkrescue is a way to go for {BIOS,EFI}x{CD,HD}
or at least to learn how to do it with GRUB2.
On the other hand, the missing piece is just what the amd64 ISOs
implement by GRUB2 already.
xorriso-1.4.0 would reproduce the mini.iso BIOS equipment by:
--protective-msdos-label
-G --interval:local_fs:0s-15s:zero_mbrpt:'mini.iso'
-c '/boot.catalog'
-b '/boot/grub/i386-pc/eltorito.img'
-no-emul-boot
-boot-load-size 4
-boot-info-table
Where --interval:local_fs:0s-15s:zero_mbrpt:'mini.iso' would
cut the first 32 KB out of the existing mini.iso and re-use
them as System Area of the new ISO. You can do this yourself
by dd and use the disk path instead of "--interval:...".
Then add a piece of amd64 options
-eltorito-alt-boot
-e '/boot/grub/efi.img'
-no-emul-boot
and of arm64 (with amd64 suitable efi.img, of course)
-append_partition 2 0xef /local/hd/path/to/boot/grub/efi.img
ignoring the fact that you create two copies of efi.img.
I believe it is worth the waste.
Maybe this works.
I will make a test when i finished the file name truncation
for #798300 and fixed the kFreeBSD problems of libburn's
autotools equipment.
I could need instructions how to test EFI with qemu.
Have a nice day :)
Thomas
Reply to: