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.ish...@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@lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel >
_______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
