[ 62% 16150/26047] Create system-qemu.img now
FAILED: out/target/product/trusty/system-qemu.img
/bin/bash -c "(export SGDISK=out/host/linux-x86/bin/sgdisk SIMG2IMG=out/host/linux-x86/bin/simg2img; device/generic/goldfish/tools/mk_combined_img.py -i out/target/product/trusty/system-qemu-config.txt -o out/target/product/trusty/system-qemu.img)"
1+0 records in
2048+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0063128 s, 166 MB/s
Traceback (most recent call last):
File "device/generic/goldfish/tools/mk_combined_img.py", line 163, in <module>
main()
File "device/generic/goldfish/tools/mk_combined_img.py", line 135, in main
if check_sparse(partition["path"]):
File "device/generic/goldfish/tools/mk_combined_img.py", line 12, in check_sparse
with open(filename, 'rb') as i:
IOError: [Errno 2] No such file or directory: 'out/target/product/trusty/vbmeta.img'
13:44:11 ninja failed with: exit status 1
#### failed to build some targets (19:41 (mm:ss)) ####
qemu-system-aarch64
-M virt
-cpu cortex-a57
-smp 1
-m 2048
-monitor none
-parallel none
-serial mon:stdio
-kernel Image -append "root=/dev/vda rootfstype=ext4 ro init=/init loglevel=8 selinux=1 checkreqprot=1 androidboot.selinux=permissive androidboot.hardware=qemu_trusty console=ttyAMA0"
-device virtio-gpu-pci
-drive format=raw,file=system-custom.img
-drive format=raw,file=userdata-custom.img
LABEL=data /data ext4 noatime,nosuid,nodev,errors=panic wait
init: init first stage started!
[...]
init: Loading SELinux policy
[...]
selinux: SELinux: Loaded policy from /vendor/etc/selinux/precompiled_sepolicy
selinux: SELinux: Loaded file_contexts
random: init: uninitialized urandom read (40 bytes read)
random: init: uninitialized urandom read (40 bytes read)
init: init second stage started!
[...]
ueventd: Coldboot took 1.344 seconds
[...]
init: starting service 'storageproxyd'...
libprocessgroup: CgroupMap::FindController called for [1] failed, RC file was not initialized properly
libprocessgroup: Failed to make and chown /uid_0: Read-only file system
libprocessgroup: CgroupMap::FindController called for [829] failed, RC file was not initialized properly
init: createProcessGroup(0, 829) failed for service 'storageproxyd': Read-only file system
init: cpuset cgroup controller is not mounted!
init: Service 'storageproxyd' (pid 829) exited with status 1
init: Sending signal 9 to service 'storageproxyd' (pid 829) process group...
libprocessgroup: CgroupMap::FindController called for [1] failed, RC file was not initialized properly
libprocessgroup: CgroupMap::FindController called for [1] failed, RC file was not initialized properly
init: starting service 'storageproxyd'...
libprocessgroup: CgroupMap::FindController called for [1] failed, RC file was not initialized properly
libprocessgroup: Failed to make and chown /uid_0: Read-only file system
init: createProcessGroup(0, 830) failed for service 'storageproxyd': Read-only file system
libprocessgroup: CgroupMap::FindController called for [830] failed, RC file was not initialized properly
init: cpuset cgroup controller is not mounted!
init: Service 'storageproxyd' (pid 830) exited with status 1
init: Sending signal 9 to service 'storageproxyd' (pid 830) process group...
...and so on in loop
--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en
---
You received this message because you are subscribed to the Google Groups "Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/a30c5a05-6134-43a5-8f3b-32313e32bac0%40googlegroups.com.
Many thanks for your answers
In fact what I'm trying to do is using QEMU files into AOSP source code to get Android (with GUI) built and running on a standard/upstream QEMU version.
This would give the ability of running Android and its future
releases without real "porting", on any device running a Linux
kernel (be it upstream or not) and having KVM working on it. Which
would be extremely interesting.
From what you write, it seems qemu-trusty-arm64 is not really for me. So what I'm trying to do is probably more about using device/generic/qemu/qemu_arm64.mk (and others archs) files included into AOSP. So I'll continue into this other subject : https://groups.google.com/forum/?hl=bn#!topic/android-building/kbiEg5OxBGU
While talking with you, I noticed that AVD Emulator is different
from upstream QEMU, probably about goldfish and ranchu related
things. Things working fine with the emulator (aosp_x86_64-eng for
example and android-goldfish-4.14-dev which seems mandatory to get
Android 10 working with AVD Emulator) does not seems to be working
with upstream QEMU (at least I can't get the GUI). Therefore the
documentation about AVD Emulator builds
https://source.android.com/setup/create/avd didn't really help me
for upstream QEMU.
Can you confirm it's possible to use modern versions of AOSP on upstream QEMU? Someone did succeed in the past with Android 6 / untouched AOSP and a extended compatibility kernel (I have one based on android-goldfish-4.14-dev), this is why I'm trying with newer versions of AOSP. This was documented here, but it's not up to date anymore : https://www.collabora.com/news-and-blog/blog/2016/09/02/building-android-for-qemu-a-step-by-step-guide/
Thank you in advance
Julien
You received this message because you are subscribed to a topic in the Google Groups "Android Building" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-building/fY-gdZQ-67M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/CAGSQo01HoD%2B8b1LdOrqaqmnQK5Fa1Ys9REVZ9Rt-85E4WrYRaw%40mail.gmail.com.
Many thanks for your answers
In fact what I'm trying to do is using QEMU files into AOSP source code to get Android (with GUI) built and running on a standard/upstream QEMU version.
This would give the ability of running Android and its future releases without real "porting", on any device running a Linux kernel (be it upstream or not) and having KVM working on it. Which would be extremely interesting.
From what you write, it seems qemu-trusty-arm64 is not really for me. So what I'm trying to do is probably more about using device/generic/qemu/qemu_arm64.mk (and others archs) files included into AOSP. So I'll continue into this other subject : https://groups.google.com/forum/?hl=bn#!topic/android-building/kbiEg5OxBGU
While talking with you, I noticed that AVD Emulator is different from upstream QEMU, probably about goldfish and ranchu related things. Things working fine with the emulator (aosp_x86_64-eng for example and android-goldfish-4.14-dev which seems mandatory to get Android 10 working with AVD Emulator) does not seems to be working with upstream QEMU (at least I can't get the GUI). Therefore the documentation about AVD Emulator builds https://source.android.com/setup/create/avd didn't really help me for upstream QEMU.
Can you confirm it's possible to use modern versions of AOSP on upstream QEMU? Someone did succeed in the past with Android 6 / untouched AOSP and a extended compatibility kernel (I have one based on android-goldfish-4.14-dev), this is why I'm trying with newer versions of AOSP. This was documented here, but it's not up to date anymore : https://www.collabora.com/news-and-blog/blog/2016/09/02/building-android-for-qemu-a-step-by-step-guide/
Thank you in advance
Julien
On 3/2/20 10:51 PM, 'Matthew Maurer' via Android Building wrote:
This target is a testing target used for evaluating our reference TrustZone implementation. "storageproxyd" is continuously resetting there because it is not being launched by our test script which would attach a virtual RPMB resource.
A few notes about this target:
* It does not have a GUI* Running Java is not supported and unlikely to work* It requires a custom EL3 and Trusty running alongside it to work
The manifest for these components is at https://android.googlesource.com/trusty/manifest, and that manifest contains a checked in prebuilt of the qemu_trusty_arm64-userdebug target that we are currently testing against.
If you tell me more about what you're trying to make the target do, I may be able to give you further help with getting it to do what you want. If you aren't trying to use or inspect the Trusty TZ implementation, this target probably isn't the one you're looking for.
On Mon, Mar 2, 2020 at 1:34 PM Dan Willemsen <dwill...@google.com> wrote:
+Matthew Maurer Do we have any documentation on this target? I think the last time we talked about this target it was only minimally functional.
- Dan
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en
---
You received this message because you are subscribed to the Google Groups "Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/a30c5a05-6134-43a5-8f3b-32313e32bac0%40googlegroups.com.
--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Android Building" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-building/fY-gdZQ-67M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-...@googlegroups.com.
Hi Victor,
Indeed yes I succeeded in running AOSP 10, then AOSP 11 few time after it was made available, on upstream QEMU (at least on Debian 10's QEMU). I succeeded in both x86_64 and arm64. Here's some information I kept and remember from this work.
In both case, aosp_xxxxx builds are really "emulator specific". Emulator which is called ranchu, but was previously called goldfish in its previous versions, so this is why we will use and tweak ranchu and goldfish files in the process.
Let's start from AOSP 10 (aosp_x86_64-eng)
none /cache tmpfs nosuid,nodev,noatime defaults
none /data tmpfs nosuid,nodev,noatime defaults
/devices/*/block/sr* auto auto defaults voldmanaged=cdrom:auto
/devices/*/usb*/* auto auto defaults voldmanaged=usb:auto,encryptable=userdata
/devices/*/mmc0:a*/* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/*sdmmc*/* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/80860F14:01/mmc_* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/80860F14:02/mmc_* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/80860F16:00/mmc_* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/PNP0FFF:00/mmc_* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/dev/block/sdb /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,check,quota,reservedsize=128M,first_stage_mount
/dev/block/sdc /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,check,quota,reservedsize=128M,first_stage_mount
/devices/*/block/sr* auto auto defaults voldmanaged=cdrom:auto
/devices/*/usb*/* auto auto defaults voldmanaged=usb:auto,encryptable=userdata
/devices/*/mmc0:a*/* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/*sdmmc*/* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/80860F14:01/mmc_* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/80860F14:02/mmc_* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/80860F16:00/mmc_* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/*/PNP0FFF:00/mmc_* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
on boot
setprop ro.hardware.egl swiftshader
setprop debug.hwui.renderer opengl
setprop debug.hwui.renderer ${ro.kernel.qemu.uirenderer}
setprop ro.opengles.version ${ro.kernel.qemu.opengles.version}
setprop ro.zygote.disable_gl_preload 1
[...]
kvm -m 4096 -smp 4 -kernel bzImage -append "root=/dev/sda rootfstype=ext4 ro init=/init selinux=1 checkreqprot=1 androidboot.selinux=permissive console=ttyS0 androidboot.hardware=ranchu loglevel=8" -serial mon:stdio -drive format=raw,file=system.img -vga std
Add CONFIG_NETFILTER_ADVANCED=y before adding "android-base" config options
Device Drivers --->
Virtio drivers (check everything just in case),
Graphics support
Cirrus driver for QEMU emulated device
DRM Support for bochs dispi vga interface (qemu stdvga)
Virtio GPU driver
Console display driver support
Framebuffer Console supportCONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_BYD=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_FOCALTECH=y
CONFIG_MOUSE_PS2_SMBUS=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
ARM64
For AOSP 10 using aosp_arm64, I believe it was exactly the same
approach, but I had to remove some services that were failing in
loop during the android boot logo, and possibly remove them from
"manifest.xml" so that Android doesn't try (and fail) to find
them. I don't remember which ones, as I'm not finding back my
notes about that. The command line I used to run it was different
from x86_64 kvm one :
qemu-system-aarch64 -M virt -cpu cortex-a72 -accel tcg,thread=multi -smp 4 -m 4096 -kernel Image.gz.ax86 -monitor none -parallel none -append "root=/dev/vda rootfstype=ext4 ro init=/init selinux=1 checkreqprot=1 androidboot.selinux=permissive console=ttyAMA0 androidboot.hardware=ranchu loglevel=8" -serial mon:stdio -vga std -device ramfb -drive format=raw,file=system.img -device nec-usb-xhci -device usb-kbd -device usb-mouse -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd
And from an arm64 machine with enough RAM, using kvm as arm64 :
kvm -M virt -cpu host -accel kvm -smp 4 -m 4096 -kernel Image.gz.ax86 -monitor none -parallel none -append "root=/dev/vda rootfstype=ext4 ro init=/init selinux=1 checkreqprot=1 androidboot.selinux=permissive console=ttyAMA0 androidboot.hardware=ranchu loglevel=8" -serial mon:stdio -vga std -device ramfb -drive format=raw,file=system.img -device nec-usb-xhci -device usb-kbd -device usb-mouse -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd
At that time I was using the android-x86 kernel (which can be built for arm64 too) and my fstab.ranchu file was
none /cache tmpfs nosuid,nodev,noatime defaults
none /data tmpfs nosuid,nodev,noatime defaults
If building a kernel from standard android kernel code, and using ext4 partitions files for these, beware, it's not sda sdb sdc anymore, but vda vdb vdc...
AOSP 11 : I clearly need to play again with QEMU
and AOSP 11 and look into all my files with Meld in order to be
able to give you a working/verified list of everything to do in
order to have AOSP 11 running on QEMU (x86_64 and arm64), I'll
have some time tomorrow to do that! I'm sure enough swiftshader
related things aren't included anymore into AOSP 11
Goldfish/ranchu build configuration files (so those things should
be added).
Recently while playing with Glodroid, Pinephone and RPi 4,
Swiftshader then real Mesa, I noticed that some things related to
Goldfish and Audio suddenly changed on AOSP 11, requiring some
more modifications compared to when AOSP 11 was made available.
Best regards,
Julien
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Android Building" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-building/fY-gdZQ-67M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/a52e9878-7432-4b28-b011-3e58d706491cn%40googlegroups.com.
Hi Jake,
In order for everybody to compare what differs in case of problems, I uploaded here the results (for both AOSP 10 from today and 11 from yesterday)
Kernel included (with .config file)
Looks like the kernel panic says that the "/init" executable file (stated into the kernel parameters "root=/dev/vda rootfstype=ext4 ro init=/init") wasn't found by the kernel (so the kernel was unable to start the actual operating once ready). It can be because it didn't find the "/dev/vda " disk, because it failed to mount it as "ext4" or because the "/init" file (or link) isn't at the right place.
Here's attached a screen capture to show how I placed my files
into the rootfs.img partition (sometimes pictures are easier to
understand than my complicated explanations 😁). "/init" is a
symbolic link that drives to "/system/bin/init", which is an
android tailored init executable (completely configured by
"/system/etc/init/hw/init.rc" file, which itself includes a lot of
others *.rc files addresses). Just for comparison, on most Linux
distributions, the init process is a link to "systemd" executable
which will start all the services.
For the "defconfig" file copied as ".config" file, I place it at the root of the kernel tree, for example I have "/home/user/Desktop/work/kernel-src/arch/arm64/configs/defconfig" copied here : "/home/user/Desktop/work/kernel-src/.config"
Running menuconfig and saving, is taking into account and
automatically mixing the parameters sets that have been placed
into the ".config" files, in a way that gives the same results as
when using the "scripts/kconfig/merge_config.sh" method described
here https://source.android.com/devices/architecture/kernel/config
(if you prefer using only files and command lines instead of
editing .config manually, this other approach is interesting).
During my attempts, I firstly ran menuconfig after having appended together the content of defconfig, CONFIG_NETFILTER_ADVANCED=y, android base and recommended configs files to .config. Then I ran it a second time after having added the things from android-base-conditional.xml, virtio things and removed the 2 options (CONFIG_AIO and ANDROID_BINDERFS) that were causing trouble on android's boot; but I wouldn't be too surprised to see the same results if running menuconfig only once after everything has been added.
Without the "menuconfig" steps (or the use of merge_config.sh
script), the build process would be asking an almost endless
stream of "yes/no" questions. After menuconfig if only asks few
questions before starting to work.
Hope this will help!
Good luck and have a nice day
Julien
--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "Android Building" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/android-building/fY-gdZQ-67M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to android-buildi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/d58fe95b-040a-4b9e-a145-b650b438e323n%40googlegroups.com.