Fixing dual-boot to Android?

[floe]

Hi, maybe some people here may know how to fix this :-)

I've been playing around with Ubuntu 18.04 on my Hi10 Pro, which I installed in place of the old Windows partition (everything else untouched). This works more or less, but I currently can't boot back into Android. I can get the original boot selection screen with Android or Windows, but this just causes a reboot.

I suspect that this is just a messed-up EFI entry which could be fixed with efibootmgr, any suggestions how to directly boot to Android without the selector?

[floe]

In fact, if someone has a working dual-boot setup with Android and Linux, just running efibootmgr -v and posting the output might already be sufficient...

[danielotero]

I completely format the drive soon after I received the Tablet, installing Arch Linux on the full disk, so I'm not really able to help you in that regard. After that, I kept getting the boot selection with only the Android option, but one day it disappeared, and now boots directly to Linux.

That UEFI its really shitty...

[Carsuzan]

Same issue as floe

[Jerror]

First things first, find out where the Android boot image lives. Maybe it was thrown out with Windows. I was able to dual-boot Arch&Windows ok after wiping Android, and iirc the Android EFI entry stayed around. Like the Windows entry it loaded a Chuwi bootloader (seemed there were separate loaders for Windows and Android, designed to look identical, which would chainload the other as necessary). I wiped everything and went pure Arch after Chuwi's voodoo went off, wiping my EFI settings and replacing them with stock, for the umpteenth time. You could try triggering the voodoo yourself: just hold the power and volume+ buttons for 15 seconds (or hold power then press volume, I forget). If the Android option currently sends you to a bootloader, my money's on image problems, not EFI.

[floe]

No, I'm quite certain the Android partitions have remained untouched. What might be an option is to try and boot the Android boot partition via GRUB, and just nuke all the other proprietary bootloaders.

I'd still be interested in comparing the stock EFI settings, though.

[Orochimarufan]

I'll try shining some light into the darkness: from what I can tell, the android image uses the default boot image efi/boot/bootx64.efi and windows uses it's default efi/Microsoft/boot/bootmgfw.efi

The BIOS will sometimes try to restore the factory boot selection menu when it finds either (or both?) of them. Since efi/boot is the default boot image, it's not unlikely to be overwritten by either windows updates or, depending on distro config, Linux bootloader installs/updates

Personally, I removed efi/boot and renamed bootmgfw so it can't find it and instead manage my arch/windows dual boot using refind. Windows update still recreates both files occasionally.

Also note that the default boot menu seems to have some special magic for Android so I'm not sure if it's possible to boot into (at least the stock) Android without going through it.

A good trick for recovering from a cmos reset is to install an efi shell binary to the efi partition and add a startup script for it that launches your actual boot manager/os. That way you can use the shell option in the BIOS menu when the efi vars get messed up (like when the thing runs out of power completely)

[floe]

So I've been fiddling with this dualboot crap occasionally for the last half year, and found a lot of things that didn't work:

• booting Android directly from GRUB (failure expected)
• booting loader.efi from GRUB
• booting Android via Kernelflinger
• ... probably some other things I forgot.

The only thing that finally allowed me to boot back to Android was a factory restore with Intel's Phone Flash Tool Lite, using the factory image posted on the Chuwi forum. If you select the flash-no-erase-all.json config file, then your Linux install will remain untouched, except for the EFI System Partition... and then you can't boot Linux anymore O_o

However, as @Orochimarufan noted, the one thing the dualboot touchscreen loader is looking for regarding which OS to boot is the name of the EFI binary. So what does work is just putting the GRUB EFI binaries into EFI/Microsoft/Boot and renaming shimx64.efi to bootmgfw.efi, then the Windows logo on the selector will reappear and you can boot to Linux directly from the touch selector...

[floe]

Another update: by now, I'm pretty convinced that what messes up the Android install is not actually related to the boot process itself, i.e. it doesn't have to do with the EFI partition or any EFI vars or the crappy BIOS.

Instead, the problem seems to be that Ubuntu is a) very persistent in auto-mounting any ext4 filesystems it can find, including the Android system/data/etc. partitions, and b) that it seems to do something to the partitions which then causes Android to croak on boot...

[floe]

So I finally have Android/Linux dualboot working. In addition to copying/renaming the GRUB EFI loader, it's also important to disable the automounter for the Android partitions.

I've managed to fix this by setting the respective UUIDs to noauto in /etc/fstab as follows:

# do _not_ automount the Android partitions
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b  /none ext4 ro,noauto 0 0
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b1 /none ext4 ro,noauto 0 0
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b2 /none ext4 ro,noauto 0 0
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b3 /none ext4 ro,noauto 0 0

Maybe the root cause is related to the fact that these partitions actually all share the same UUID, but in any case, this seems to work.

[dual3zw]

So I finally have Android/Linux dualboot working. In addition to copying/renaming the GRUB EFI loader, it's also important to disable the automounter for the Android partitions.

I've managed to fix this by setting the respective UUIDs to noauto in /etc/fstab as follows:

# do _not_ automount the Android partitions
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b  /none ext4 ro,noauto 0 0
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b1 /none ext4 ro,noauto 0 0
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b2 /none ext4 ro,noauto 0 0
UUID=57f8f4bc-abf4-655f-bf67-946fc0f9f25b3 /none ext4 ro,noauto 0 0

Maybe the root cause is related to the fact that these partitions actually all share the same UUID, but in any case, this seems to work.

Hi, there's a lot of time form this post... But... Please, could you describe how do you did do to have dual boot with Android and Linux? I need a distro on my Hi10, but need Android too.

[floe]

A slightly more up-to-date documentation is here: https://github.com/floe/tuxblet The gist: when you boot the installer from an USB stick, try adding systemd.mask=udisks2 to the kernel commandline, then it should not mess up your Android partitions. After installation, copying the /EFI/ubuntu/ folder to /EFI/Microsoft/Boot/ and renaming shimx64.efi to bootmgfw.efi allows booting Linux via the Windows boot selection entry.

[dual3zw]

A slightly more up-to-date documentation is here: https://github.com/floe/tuxblet The gist: when you boot the installer from an USB stick, try adding systemd.mask=udisks2 to the kernel commandline, then it should not mess up your Android partitions. After installation, copying the /EFI/ubuntu/ folder to /EFI/Microsoft/Boot/ and renaming shimx64.efi to bootmgfw.efi allows booting Linux via the Windows boot selection entry.

Thanks man! I've tried Ubuntu 21.10 daily build (04.09) and everything is working, touch, rotation, audio, wifi. The only thing that not working yet are the cameras. I did't solved the problem with dual boot between Ubuntu and Android and had to back to Windows. When Canonical launch the final version, I'll try again.