i suspect the real error is this:
lddtree: warning: /build/pyro/usr/sbin/kexec: did not match any paths

Drew does this look like a good next bug?

I see that sys-apps/kexec-tools is only set as a dependency if USE=loader_kernel_ramfs is set.

One of:
  factory_netboot_ramfs
  factory_shim_ramfs
  loader_kernel_ramfs
  recovery_ramfs
are required to emerge initramfs, but I'm not sure which one(s) were set when it was built through build_packages. Clearly not loader_kernel_ramfs, at any rate.

I tried:
USE="loader_kernel_ramfs" emerge-x86-generic chromeos-initramfs
and then ran test.sh again and it successfully built the four images.

I tried running the generated qemu script for each image. 
factory_netboot seemed to work
factory_shim seemed to work
loader_kernel had a kernel panic (not clear why)
recovery had a kernel panic when executing `exec >"${LOG_FILE}" 2>` in initramfs/recovery/init:main. I tried commenting that out and it got further, but died in initramfs/recovery/recovery_init.sh:verify_fw_version because the TPM device couldn't be opened (which is maybe not a surprise since it's running on an emulator).

I didn't want to dig too much deeper into the errors running these, in case they were related to me not building the images correctly.

As for getting test.sh to build correctly, is it a matter of updating the README.md to say that build_packages is not sufficient, and one must emerge chromeos-init with the appropriate USE flags first? Or is there something else that should be emerged that would have built initramfs correctly?

Is the loader_kernel_ramfs USE flag used anywhere?

Unless I'm missing something, the only places I see the USE flag referenced in code search are in .ebuild files where other dependencies are added conditionally based on whether loader_kernel_ramfs is present, but I don't see anything that actually uses it.

If it's not used anywhere, should we just remove initramfs/test/loader_kernel? What about other references to loader_kernel_ramfs? 

Additionally, sys-apps/kexec-tools fails to emerge for amd64 targets, such as amd64-generic and snappy, which further suggests to me that loader_kernel_ramfs USE flag may not get used anywhere.

Discussed offline. We'll remove loader_kernel, which is no longer being used (crbug/736054).

test.sh should then be able to build the other images.

recovery still has a kernel panic, which I suspect may be due to the recovery initramfs being built differently from test.sh than if was built through mod_image_for_recovery.sh

loader_kernel has been removed, so test.sh should run to completion now. As mentioned before, factory_*_ramfs seem to be working, but recovery_ramfs does not.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot