I an installing on an internal notebook HDD that I use as an external dribe from the USB

The drive is a 500 GB HDD but has 50 GB, 50 GB, 50 GB partitions on it and the rest is unallocated at the moment

I have android x86 (android-x86_64-9.0-rc2.iso) installed on the first partition (sdb1) and I also installed EFI GRUB2 while installing android

I then installed LineagOS x86 (cm-x86_64-14.1-r2.iso) to the second partition (50 GB) and I also told it to installed EFI GRUB2 while installing LineagOS

The GRUB from LineageOS seems to have overwritten the GRUB from android-x86 and now I can't boot into android-x86 from the BIOS boot screen, even though it's files are all there in the first partition

Is there any way to edit the GRUB for LineagOS and add an entry to boot android-x86 from the first partition?

I also have in internal SATA HDD inside the notebook with Windows 10. I do not want the bootable installations on the external hard drive to affect this windows installation or the internal drive in any way, but it seems the EFI GRUB2 that got installed while installing android-x86 and LineageOS got installed on the internal HDD. This is still still acceptable because it doesn't seem to have affected the windows installation or it's booting procedure in any way, but I am not experienced with GRUB and whatever it is that I have to do, I want to make sure it will not affect the Windows 10 installtion on my internal hard drive.

To summarize:

sdb1: android-x86 sdb2: LineageOS, bootable using it's GRUB (this grub menu shows up when I select the entry for it in the BIOS boot menu)

How do I edit this GRUB menu to also point to the android-x86 installation? Is it possible to do this from Windows?

  • The speed is not going to be ideal if I understand your question correctly.
    – William
    Feb 1, 2020 at 16:20
  • @William why would the speed not be ideal?
    – user17915
    Feb 1, 2020 at 17:00
  • it's just typically slower that is all
    – William
    Feb 1, 2020 at 17:02

1 Answer 1


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


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}


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:


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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .