Three tiny squirmy subtle bugs combined themselves with the bug that was just fixed...
authorAlex Ionescu <aionescu@gmail.com>
Fri, 8 Jan 2016 01:18:08 +0000 (01:18 +0000)
committerAlex Ionescu <aionescu@gmail.com>
Fri, 8 Jan 2016 01:18:08 +0000 (01:18 +0000)
commit3bfe54c38c425c74daf3c082293de94cd62e0279
treebb81f00e73a3a035f317ff7b6ae9310bbdccd92b
parent79e72915d94b336b2a1800dc4bea6a651373e0ba
Three tiny squirmy subtle bugs combined themselves with the bug that was just fixed to make bootmgfw believe it was being booted from a raw removable disk (floppy). Because bootmgfw now correctly enumerates boot devices and detects the DVD/CDROM media, it could no longer 'find itself', believing it was on a floppy.
[BOOTLIB]: When failing to find a block device, keep going searching for more, instead of giving up (critical, because the CDROM FAT12 image is now device path #1, not #0).
[BOOTMGR]: Correctly use the right logical operator in EfiInitpGetDeviceNode to get the deepest-level media device node. We now get the CDROM node, not the raw node.
[CDMAKE]: Don't actually create an EFI/BOOT directory on the CDROM itself, but rather in the FAT12 image. Otherwise, this can confuse UEFI implementations to boot the boot manager off the raw CDROM, instead of the FAT12 image on the CDROM.

svn path=/trunk/; revision=70542
reactos/boot/environ/CMakeLists.txt
reactos/boot/environ/app/bootmgr/bootmgr.c
reactos/boot/environ/app/bootmgr/efiemu.c
reactos/boot/environ/lib/io/device.c