[ipxe-devel] Bug in UEFI Sanboot with iso9660

[Christian Nilsson]

I think it is also "valid" (as in common practice to implement support) to
have a iso9660 and search for /EFI/BOOT/BOOTX64.EFI
or /EFI/BOOT/BOOTIA32.EFI depending on architechture.

So maybe it should search for GPT structure first and if it exists skip
possible 9660 detection?

On Mon, Dec 12, 2016 at 8:23 PM, Vish Ishaya Abrams <vish.ishaya at oracle.com>
wrote:

> Hello
>
> With current master, after installing windows 2K12 onto an iscsi drive and
> trying to sanboot in UEFI mode it fails. I tracked the issue down to the
> iso9660 detection code. It appears that a windows 2K12 install appears as
> an iso9660 installation in addition to having a GPT:
>
> # isoinfo -d -i /dev/sdb8
> CD-ROM is in ISO 9660 format
> System id:
> Volume id: IR3_SSS_X64FREE_EN-US_DV9
> Volume set id: IR3_SSS_X64FREE_EN-US_DV9
> Publisher id: MICROSOFT CORPORATION
> Data preparer id: MICROSOFT CORPORATION, ONE MICROSOFT WAY, REDMOND WA
> 98052, (425) 882-8080
> Application id: CDIMAGE 2.53 (01/01/2005 TM)
> Copyright File id:
> Abstract File id:
> Bibliographic File id:
> Volume set size is: 1
> Volume set sequence number is: 1
> Logical block size is: 2048
> Volume size is: 2217916
> El Torito VD version 1 found, boot catalog is in sector 22
> NO Joliet present
> NO Rock Ridge present
> Eltorito validation header:
>     Hid 1
>     Arch 0 (x86)
>     ID 'Microsoft Corporation'
>     Key 55 AA
>     Eltorito defaultboot header:
>         Bootid 88 (bootable)
>         Boot media 0 (No Emulation Boot)
>         Load segment 0
>         Sys type 0
>         Nsect 8
>         Bootoff 876 2166
>
> # fdisk --list /dev/sdb8
>
> Disk /dev/sdb8: 18.6 GiB, 20004052992 bytes, 39070416 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: gpt
> Disk identifier: 8071B2D8-D75D-49E3-B3DD-B0401535345E
>
> Device        Start      End  Sectors  Size Type
> /dev/sdb8p1    2048   616447   614400  300M Windows recovery environment
> /dev/sdb8p2  616448   819199   202752   99M EFI System
> /dev/sdb8p3  819200  1081343   262144  128M Microsoft reserved
> /dev/sdb8p4 1081344 39069695 37988352 18.1G Microsoft basic data
>
> # file -s /dev/sdb8
> /dev/sdb8: DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163
> "Invalid partition table" at offset 0x17b "Error loading operating system"
> at offset 0x19a "Missing operating system" ISO 9660 CD-ROM filesystem data
> 'IR3_SSS_X64FREE_EN-US_DV9' (bootable); partition 1 : ID=0xee, start-CHS
> (0x0,0,2), end-CHS (0x3ff,255,63), startsector 1, 4294967295 sectors
>
> the efi_block code detects this as an iso_9660 filesystem and sets a
> blksize_shift of 2 and it does not successfully read the EFI filesystem. If
> I comment out the blksize_shift setting, it boots just fine. I also tested
> booting a couple of actual iso filesystems which detected a blksize_shift
> of 2. Both the ubuntu installer iso and the windows installer iso boot just
> fine with the blksize_shift commented out.
>
> This leads me to believe that the blksize_shift code is not necessary in
> uefi mode. I have commented it out in my build, but I'm not sure if there
> are some other odd iso images which require this setting. If so, then we
> need a way to detect the above case where we have an iso9660 that also has
> an EFI GPT and we can disable setting the blksize_shift in that case.
>
> Any thoughts?
> Vish
>
>
> _______________________________________________
> ipxe-devel mailing list
> ipxe-devel at lists.ipxe.org
> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20161212/edec0ce7/attachment.htm>