Bug#678883: IA 64 (Itanium) Wheezy unbootable iso images, patch proposal
Source: debian-cd
A patch proposal for the package debian-cd package of Wheezy.
It turned out that the script 'tools/boot/wheezy/boot-ia64' in the
debian-cd source package gives genisoimage the switches
-no-emul-boot
-b boot/boot.img
-c boot/boot.catalog
in similar way as I did it in my last message post. But the
--boot-load-size is absend and genisoimage uses its default load size.
The relevant script files in the debian-cd source package didn't
change after Sept. 2008. Since any Lenny and Sequeeze iso image is
able to boot, but not the Wheezy iso images, I assume that different
versions of genisoimage have different default boot-load-sizes.
You can read the following in the "EFI Specification version 1.10" of
Intel (http://www.intel.com/technology/efi/efiagree.htm), in section
"11.2.2.2 ISO-9660 and El Torito" at page 11-12:
"EFI differs from 'El Torito' 'no emulation' mode in that it does not
load the 'no emulation' image into memory and jump to it. EFI
interprets the 'no emulation' image as an EFI system partition. EFI
interprets the Sector Count in the Initial/Default Entry or the
Section Header Entry to be the size of the EFI system partition. If
the value of Sector Count is set to 0 or 1, EFI will assume the system
partition consumes the space from the beginning of the 'no emulation'
image to the end of the CD-ROM."
The boot image is a FAT file system which contains the EFI boot loader.
A sector has 2KB on a CD or DVD. So the boot-load-size must be the
size of the boot image - the count of 2K blocks (the size is rounded
up to full 2k blocks).
I examined the Lenny DVD-1 iso image: the boot-load-size is 0 - what
means that the boot image consumes the space to the end of the iso
image. But the boot image is much smaller here. Obviously the EFI-BIOS
implementations which are out there do not bother about that and boot
anyway.
The Wheezy Alpha-1 iso image has a boot-load-size of 4; this is wrong;
at least the Intel EFI-BIOS of my Itanium box didn't want to boot that.
The proposed solution is to add an explicit --boot-load-size switch
for genisoimage on the IA64 architecture. The patch doesn't change
anything on the other architectures.
The actual value is evaluated from the size of the boot image. When
the boot image size changes for some reason, the script still works
correctly.
I checked whether the patch works:
- installed Debian Lenny (5.0.10) on my Itanium box; it is the most
recent version that installs without any flaw,
- a Wheezy dist-upgrade (went catastrophic, the upgraded gdm doesn't
start anymore, remaining work at a console),
- created a local debian mirror using the data from the first Wheezy
alpha-1 DVD and some additional rsync'd wheezy installer-ia64 files of
a debian mirror,
- pulled the debian-cd source package of wheezy and build a set of
wheezy netinst cd with it.
The dumpet tool (Fedora 17 i386) outputs for the build netinst CD
(/boot/boot.img has 33.554.432 Bytes):
Validation Entry:
Header Indicator: 0x01 (Validation Entry)
PlatformId: 0x00 (80x86)
ID: ""
Checksum: 0x55aa
Key bytes: 0x55aa
Boot Catalog Default Entry:
Entry is bootable
Boot Media emulation type: no emulation
Media load segment: 0x0 (0000:7c00)
System type: 0 (0x00)
Load Sectors: 16384 (0x4000)
Load LBA: 1640 (0x00000668)
what is perfect in my opinion.
My Itanium box is able to boot it.
diff -r --context debian-cd-3.1.8/tools/boot/wheezy/boot-ia64
debian-cd-3.1.8-fix/tools/boot/wheezy/boot-ia64
*** debian-cd-3.1.8/tools/boot/wheezy/boot-ia64 2012-08-05
16:37:02.000000000 +0200
--- debian-cd-3.1.8-fix/tools/boot/wheezy/boot-ia64 2012-08-05
16:43:44.000000000 +0200
***************
*** 56,61 ****
--- 56,62 ----
add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-no-emul-boot"
add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-b boot/boot.img"
add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-c boot/boot.catalog"
+ add_mkisofs_opt $CDDIR/../$N.mkisofs_opts "-boot-load-size $[($(stat
-c%s "boot$N/boot/boot.img")+2047)/2048]"
add_mkisofs_opt $CDDIR/../$N.mkisofs_dirs "boot$N"
Kind regards
Stephan Schreiber
Reply to: