Bug regarding data.img on Android X86 6.0 r2

2,147 views
Skip to first unread message

Terence Wu

unread,
Jan 23, 2017, 10:02:08 AM1/23/17
to Android-x86
I tested on my Lenovo MIIX310 (cherry trail) with x64 version. I believe this bug happens not only on this device.
====
Description
====
On UEFI devices without external USB boot option (or USB boot is limited to Winboot only), the way to install Android X86 seems to rely on Android Installer (http://forum.xda-developers.com/android/software/winapp-android-x86-installer-uefi-t3222483).
The installer use a grub.cfg with menuitem like this:
menuentry 'Android X86' --class android-x86 {
search --file --no-floppy --set=root /AndroidOS/system.sfs
linux /AndroidOS/kernel root=/dev/ram0 androidboot.hardware=android_x86_64 quiet DATA=/AndroidOS
initrd /AndroidOS/initrd.img
}
where a data.img is placed within C:\AndroidOS, and DATA=/AndroidOS will lead the system to read and write data into the img. HOWEVER, when 6.0 r2 is installed by this way, it seems that the data.img is ignored and it creates another folder named AndroidOS wihtin C:\AndroidOS.
The r1 build doesnot have the same issue.

Chih-Wei Huang

unread,
Jan 23, 2017, 10:10:44 AM1/23/17
to Android-x86
2017-01-23 13:46 GMT+08:00 Terence Wu <jiaye...@gmail.com>:
> I tested on my Lenovo MIIX310 (cherry trail) with x64 version. I believe
> this bug happens not only on this device.
> ====
> Description
> ====
> On UEFI devices without external USB boot option (or USB boot is limited to
> Winboot only), the way to install Android X86 seems to rely on Android
> Installer
> (http://forum.xda-developers.com/android/software/winapp-android-x86-installer-uefi-t3222483).
> The installer use a grub.cfg with menuitem like this:
>>>
>>> menuentry 'Android X86' --class android-x86 {
>>>
>>> search --file --no-floppy --set=root /AndroidOS/system.sfs
>>>
>>> linux /AndroidOS/kernel root=/dev/ram0
>>> androidboot.hardware=android_x86_64 quiet DATA=/AndroidOS
>>>
>>> initrd /AndroidOS/initrd.img
>>>
>>> }
>
> where a data.img is placed within C:\AndroidOS, and DATA=/AndroidOS will
> lead the system to read and write data into the img. HOWEVER, when 6.0 r2 is

No. Before 6.0-r2 this has no effect.

> installed by this way, it seems that the data.img is ignored and it creates
> another folder named AndroidOS wihtin C:\AndroidOS.
> The r1 build doesnot have the same issue.

This is exactly the designed behavior of 6.0-r2 --
DATA is used to specify the data subdirectory
(or data partition if it's a block device)

You seems to confuse it with SRC.
What you need is SRC=/AndroidOS
(but could be skipped in this case).


--
Chih-Wei
Android-x86 project
http://www.android-x86.org

Jon West

unread,
Jan 23, 2017, 10:21:20 PM1/23/17
to Android-x86
i have an updated version of that installer here: https://github.com/BlissRoms-x86/Androidx86-Installer-for-Windows and a dirty executable if you want to test it, here: https://www.androidfilehost.com/?w=files&flid=140019 It should work with the newer Android-x86 versions. 

Jon West

unread,
Jan 23, 2017, 10:29:02 PM1/23/17
to Android-x86
I would like to bring up the question of security with replacing the data.img with a folder. Has this led to any data corruption booting between OS's on your tests? On some test machines, it seems to be vulnerable to malware being copied to that folder and transmitted from machine to machine. There are likely other issues that could arise from this as well. 

Chih-Wei Huang

unread,
Jan 24, 2017, 6:18:32 AM1/24/17
to Android-x86
2017-01-24 11:29 GMT+08:00 Jon West <electr...@gmail.com>:
> I would like to bring up the question of security with replacing the
> data.img with a folder. Has this led to any data corruption booting between
> OS's on your tests? On some test machines, it seems to be vulnerable to
> malware being copied to that folder and transmitted from machine to machine.
> There are likely other issues that could arise from this as well.

Sorry. I didn't see your point.
Did you imply data.img is more secure than a folder?
I don't see so. No one is more secure than the other.

Basically speaking, data.img is just a workaround to allow
android-x86 to install and run on a non-Linux compatible filesystem
(i.e., ntfs or fat32). We have no choice but to use it.
If installed to Linux filesystem (ext4, etc), a data subfolder
(or a subforlder specified by DATA=) is (and should be) used.

You should not use a data subfolder on ntfs or fat32.
Using data.img on ext4 is also unnecessary.
But in either way, I don't see how they relate to security.

Miker1029

unread,
Jan 24, 2017, 3:20:13 PM1/24/17
to andro...@googlegroups.com
Agreed, Simply Install to an EXT4 Partition, OR, Alongside a Linux
Install... My Personal Experience is to Use a EXT4 Partition, Just for
the Versatility....

Mike

Povilas Staniulis

unread,
Jan 24, 2017, 4:41:50 PM1/24/17
to andro...@googlegroups.com
Android is Linux based and should be installed to a Linux partition.
img files are just a workaround for those who don't want to partition
their HDDs.

Terence Wu

unread,
Feb 2, 2017, 11:09:35 AM2/2/17
to Android-x86


在 2017年1月23日星期一 UTC+8下午11:10:44,Chih-Wei Huang写道:
Thanks for your reply. On some windows tablets, take Lenovo MIIX310 for example, only accept bootable USB disk with winboot, other OS, like Linux as well as Android X86 installation image, will not boot. 

Thus, there seems to be no way to install Android X86 without an Win32 installer, which can only select partitions of NTFS and FAT32. With subdirectory, Android's data files will cause "disk errors" or "un-deletable files" in FAT32 and NTFS. In this case, data.img seems to be more useful.

In older builds, like 6.0 r1, if you replace data.img with folder named data, it also works without changing grub.cfg. So those older builds are compatible with both data.img and data directory. Maybe the old design is better - no need to make that change (which I take as "bugs").

Terence Wu

unread,
Feb 2, 2017, 11:09:36 AM2/2/17
to Android-x86


在 2017年1月23日星期一 UTC+8下午11:10:44,Chih-Wei Huang写道:
2017-01-23 13:46 GMT+08:00 Terence Wu <jiaye...@gmail.com>:

Thank you for your reply. But I would like to point out 2 problems.

First, some tablets from several manufacturers can only boot from USB devices with winboot files, that means any non-Windows-based installation USB stick will not boot in those devices (my Lenovo MIIX310 is, unfortunately this kind of device). So the only way to install Android X86 seems to use a Win32 Installer, which cannot recognize ext2/3/4 partitions due to Windows limitations (even with newer Windows 10 builds with Linux support). So in these cases, installing on FAT32/NTFS partitions is inevitable, and data.img is still very useful.

Second, previous builds like 6.0 r1 and CM13 rc1 have already supported BOTH data.img and "data" subdirectory. With the same grub.cfg using "DATA=/AndroidOS", if a data.img file exists in C:\AndroidOS, it will use the img directly; otherwise it will create a "data" subdirectory instead. That means subdirectory is already supported. I see no necessity to design the "new feature" (what I took as a bug lol) for the old one is good enough, and, better. 

Based on my consideration in the First point, and the fact that many people don't want to mess up with their partitions or file systems, I suggest the old way to deal with data maybe better - or if I misunderstood something here- or is there a method to use data.img again - or if you would like to introduce another way to install in such devices (mostly cherry-trail devices), please let me know.

I can offer assistance if you want further testing on this kind of devices.

BTW, now only 6.0r1 and RemixOS 3.0(touch support has dropped?) works on MIIX310 (r2 cannot), with rotation wrong, battery un-detected and WLAN unusable. I assumed that a newer kernel for Cherry-trail support is needed?

Thanks again.

Terence Wu

unread,
Feb 2, 2017, 11:09:36 AM2/2/17
to Android-x86


在 2017年1月24日星期二 UTC+8上午11:21:20,Jon West写道:
Thanks for the reply. Do you know any builds that works on CherryTrail with WLAN workable and battery status correct? 

Chih-Wei Huang

unread,
Feb 2, 2017, 11:42:10 AM2/2/17
to Android-x86
2017-01-28 16:52 GMT+08:00 Terence Wu <jiaye...@gmail.com>:
>
> Thank you for your reply. But I would like to point out 2 problems.
>
> First, some tablets from several manufacturers can only boot from USB
> devices with winboot files, that means any non-Windows-based installation
> USB stick will not boot in those devices (my Lenovo MIIX310 is,
> unfortunately this kind of device). So the only way to install Android X86
> seems to use a Win32 Installer, which cannot recognize ext2/3/4 partitions
> due to Windows limitations (even with newer Windows 10 builds with Linux
> support). So in these cases, installing on FAT32/NTFS partitions is
> inevitable, and data.img is still very useful.

That's right.
On FAT32/NTFS partition you should use data.img.
(I've said that in another post)

> Second, previous builds like 6.0 r1 and CM13 rc1 have already supported BOTH
> data.img and "data" subdirectory. With the same grub.cfg using
> "DATA=/AndroidOS", if a data.img file exists in C:\AndroidOS, it will use
> the img directly; otherwise it will create a "data" subdirectory instead.
> That means subdirectory is already supported. I see no necessity to design
> the "new feature" (what I took as a bug lol) for the old one is good enough,
> and, better.

"DATA=/AndroidOS" is a wrong syntax (and no effect) before (include) 6.0-r1.
In 6.0-r2, it means the data subdirectory is "AndroidOS".
The feature allows the users to specify the data subdirectory if they want.
If you want to use data.img as before, you have to remove "DATA=/AndroidOS"
from your cmdline as I have explained.


> Based on my consideration in the First point, and the fact that many people
> don't want to mess up with their partitions or file systems, I suggest the
> old way to deal with data maybe better - or if I misunderstood something
> here- or is there a method to use data.img again - or if you would like to
> introduce another way to install in such devices (mostly cherry-trail
> devices), please let me know.

The "old way" is always supported, of course.
Indeed I think you misunderstood (misuse) the meaning of DATA=.
If you want to say "my android-x86 installation dir is /AndroidOS",
it should be "SRC=/AndroidOS" instead of "DATA=/AndroidOS".

> I can offer assistance if you want further testing on this kind of devices.
>
> BTW, now only 6.0r1 and RemixOS 3.0(touch support has dropped?) works on
> MIIX310 (r2 cannot), with rotation wrong, battery un-detected and WLAN
> unusable. I assumed that a newer kernel for Cherry-trail support is needed?

Please open another thread for such a question.
List what versions you have tested and what peripherals work or not,
with dmesg and lsmod attached.

Usually a newer kernel is better.
But sometimes you may encounter some regressions.
(something works in an older kernel but breaks in a newer kernel)
In this case you should report it carefully with details as possible.
Reply all
Reply to author
Forward
0 new messages