To start it would help if you could provide some logs with adb. The x86 firmware to get a dump of whats going on just simply throw the command adb logcatfrom an elevated command prompt. Making it simpler to read though it should be a dump and pretty straight forward you can try to add -v (verbose) long looking like: abd logcat -v long
hopefully the adbd daemon has started since thats part of the init job.
However, if it has not and cannot get a logcat then you can try to skip part of the boot process to get thing farther along within the boot process by stopping the zygote by:
From the x86 developers website:
Stop zygote to run automatically:
Go within the the vendor/whatever_device_oem/eeepc/init.rc, change following lines:
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
socket zygote stream 666
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
to:
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
socket zygote stream 666
onrestart write /sys/android_power/request_state wake
onrestart write /sys/power/state on
disabled
oneshot
At this point hopfully stopping the zygote will get things communicating once the davlik starts going since that is what gets things in the virtual machine going.
Try to pull logs through the above mentioned logcat command.
When you want to start zygote manually after you get or if it fails then throw the command from an adb shell start zygote or if unable to get an adb shell you could just try from a terminal emulator start zygote if that fails then stop and revert the changes to the vendor/whatever_device_oem/eeepc/init.rc from the booted is is, or within the iso, or before re-compilation.
Hopefully by this point you can post a dump output so we can get to the nitty gritty of what is going on.
Though it sounds like a boot order issue from the primary bootloader to the secondary bootloader and so on. It could also be any of the other pertinent paths needed to boot.
With that, after going through your long detailed steps that you have tried for debugging. Leading to my long detailed winded answer to state logs are key to debugging. Of the top off my head I say that it is most likely a path issue that can be corrected using the set command from a linux based system or linux like system command prompt or emulator. (Key by the way when saving a brick from grub-recovery).
Throw the set command to see what the system recognizes and see as the way to the chosen path.
See what's shown and compared to what's needed such as set root, cmdpath, kernel, boot, grub, vmlinux or aboot, and many more things required for boot but not the same let device and OEM, OS version, or variants.
The syntax is:
set {envvar=value}
Simplified:
Set option = (Value)/the/chosen/path
To delete/remove an environmental variable just us unset instead of the set command.
GN'U technical manual explains what's appears to be your asked issue:
https://www.gnu.org/software/grub/manual/grub/html_node/set.html#set
GRUB’s normal start-up procedure involves setting the ‘prefix’ environment variable to a
value set in the core image by grub-install, setting the ‘root’ variable to match, loading
the ‘normal’ module from the prefix, and running the ‘normal’ command (see Section 16.3.51
[normal], page 77). This command is responsible for reading ‘/boot/grub/grub.cfg’, run-
ning the menu, and doing all the useful things GRUB is supposed to do
Start your debugging solutions with the set command to get the proper boot variables in order. If you have to delete a variable that's been set then use the unset command.
If not that than we need logs to find out what's going on with the boot process.
