On 07.12.17 08:00, Jonathan Gray wrote:
On Fri, Dec 01, 2017 at 04:10:33PM +0100, Alexander Graf wrote:
Commit 884bcf6f65 (efi_loader: use proper device-paths for partitions) tried to introduce the el torito scheme to all partition table types: Spawn individual disk objects for each partition on a disk.
Unfortunately, that code ended up creating partitions with offset=0 which meant that anyone accessing these objects gets data from the raw block device instead of the partition.
Furthermore, all the el torito logic to spawn devices for partitions was duplicated. So let's merge the two code paths and give partition disk objects good offsets to work from, so that payloads can actually make use of them.
Fixes: 884bcf6f65 (efi_loader: use proper device-paths for partitions) Reported-by: Yousaf Kaukab yousaf.kaukab@suse.com Signed-off-by: Alexander Graf agraf@suse.de
This once again broke being able to find a DEVICE_PATH_TYPE_MEDIA_DEVICE node with the loaded image protocol on rpi_3 with mmc/usb.
Hooray :). Do you think you could somehow assemble a test that runs inside Travis-CI to make sure we catch your loader? I still need to do a better one for grub to ensure that that one's happy too.
broken ## Starting EFI application at 01000000 ... Scanning disk sdhci@7e300000.blk... efi_disk_register BLK efi_disk_add_dev name=sdhci@7e300000.blk, if_typename=mmc_blk, dev_index=0 offset=0, part=0 efi_disk_create_partitions efi_disk_add_dev name=sdhci@7e300000.blk:1, if_typename=mmc_blk, dev_index=0 offset=8192, part=1 efi_disk_create_partitions efi_disk_add_dev name=sdhci@7e300000.blk:4, if_typename=mmc_blk, dev_index=0 offset=16384, part=4 Scanning disk usb_mass_storage.lun0... efi_disk_register BLK efi_disk_add_dev name=usb_mass_storage.lun0, if_typename=usb_storage_blk, dev_index=0 offset=0, part=0 efi_disk_create_partitions efi_disk_add_dev name=usb_mass_storage.lun0:1, if_typename=usb_storage_blk, dev_index=0 offset=8192, part=1 efi_disk_create_partitions efi_disk_add_dev name=usb_mass_storage.lun0:4, if_typename=usb_storage_blk, dev_index=0 offset=40960, part=4 Found 6 disks efi_dp_match a: len 20 type 1 b: len 20 type: 1 efi_dp_match a: len 20 type 1 b: len 20 type: 1 efi_dp_match a: len 20 type 1 b: len 20 type: 1 efi_dp_match a: len 20 type 1 b: len 20 type: 1 efi_dp_match a: len 11 type 3 b: len 11 type: 3 efi_dp_match a: len 11 type 3 b: len 11 type: 3 efi_dp_match a: len 11 type 3 b: len 11 type: 3 efi_diskprobe efi_device_path_depth looking for type 4 i=0 type 1 efi_device_path_depth looking for type 4 i=1 type 3 efi_device_path_depth looking for type 4 i=2 type 3 efi_device_path_depth looking for type 4 i=3 type 3 efi_device_path_depth no match for type 4 depth=-1
I can reproduce this with grub here as well - the device path passed in via loaded image seems to have something to it that's wrong. I can't quite figure out what - printing it with our own helpers seems to show a correct path:
do_bootefi_exec: dp=/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Usb(0x6,0x0)/HD(Part1,Sigcb08e82d)
I'll need to dig a bit further into this to understand where things are going wrong...
Alex