Android-x86 troubleshooting

Last modified: Sun Jun 2 10:54:01 EDT 2019

Unsolved problems



The Android-x86 installer asks if you want /system to be writable.  If you say no, it puts an ext4 image inside of a squashfs image inside of the primary ext4 file system.  If you say yes, you get an unpacked, writable system subdirectory underneath /android-7.1-rc1.

Black screen of death while booting kernel

KMS and nouveau are to blame.

The workaround is to use the Grub command gfxpayload and the kernel parameter nomodeset, as shown in the next section, to force use of the simple VESA framebuffer.

Booting with Grub2

Android-x86 installs with legacy Grub for some reason.  Based on its menu.lst file, I got the following working entry for grub.cfg.

menuentry "Android 7.1-rc1" {
  search --no-floppy --label --set=root Android-x86
  linux /android-7.1-rc1/kernel nomodeset root=/dev/ram0 androidboot.selinux=permissive buildvariant=userdebug SRC=/android-7.1-rc1
  initrd /android-7.1-rc1/initrd.img

Remove the gfxpayload line and the nomodeset parameter if you don't have the BSOD problem.  Add the parameter vmalloc=192M if you're running 32-bit.  (I assume that it is hardcoded that way in the 32-bit version of Android-x86.)

I never could get it to boot with LILO.

No sound


* The problem here is that Android has unnecessary layers of crap on top of ALSA.

What worked for me was to edit /system/etc/modules.blacklist to blacklist the module of the PCI card.  Kernel parameters snd.slots and modprobe.blacklist had no effect.

Walk away for a few minutes, return to find black screen of death

There's a bug where it won't come back after the screen blanks from idleness.  The workaround is to disable sleep, but this requires developer mode.

To enable developer mode, go into Settings > 'About tablet' and click 7 times on the build number at the bottom.

Now to disable screen blanking, go into Settings > 'Developer options' and enable 'Stay awake.'

The 'Stay awake' option only applies if the device is in "charging" status.  However, the timeout for all cases can be increased to 30 minutes under Settings > Display.

Spontaneous reboot while loading kernel—boot loop

The EeePC sometimes does this after a soft reboot.  A full shutdown and cold boot clears it.

Other stupid tricks that probably won't help

Manual initialization and test of ALSA

$ su
# alsa_aplay -l                       # List cards and devices
# alsa_ctl -f asound.state restore    # Restore known good ALSA state file
# alsa_aplay something.wav            # Play test wav
# alsa_amixer                         # Command-line mixer

/system/etc/ has this:

        for c in $(grep '\[.*\]' /proc/asound/cards | awk '{print $1}'); do
                f=/system/etc/alsa/$(cat /proc/asound/card$c/id).state
                if [ -e $f ]; then
                        alsa_ctl -f $f restore $c

So if you want to load an ALSA state file on every boot, you find out the ID string of the card from /proc/asound/card0/id (e.g., M2496) and put a working state file at /system/etc/alsa/M2496.state.

In my case, all this did was prove that ALSA was not the problem.

Dumping the log

# logcat -d -f log.txt

This was the stupid HAL failure:

09-02 12:36:38.867  1497  1518 W audio_hw_primary: out_write error: -12, sleeping...
09-02 12:36:38.878  1497  1518 I audio_hw_primary: choose pcmC0D0p for 0
09-02 12:36:38.878  1497  1518 E audio_hw_primary: my_pcm_open(4) failed: cannot set hw params: Invalid argument
09-02 12:36:38.878  1497  1518 I audio_hw_primary: my_pcm_open: re-try 44100 on card 0/0
09-02 12:36:38.878  1497  1518 E audio_hw_primary: pcm_open(out) failed: cannot set hw params: Invalid argument
09-02 12:36:38.878  1497  1518 W audio_hw_primary: out_write error: -12, sleeping...

Changing the I/O scheduler

# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
# echo noop > /sys/block/sda/queue/scheduler