Getting a custom ramdisk to boot on Android - android

I am working on a "GNU/Linux on Android" type of project that is based on Mikael Q. Kuisma's work here .
I built a tool that downloads a toolchain, compiles the kernel, archives the custom ramdisk, and finally bundles them into a boot image.
Expected result:
Kernel boots.
Ramdisk gets loaded and /init is executed using /sbin/busybox.
Actual result:
Kernel does boot.
The kernel never seems to reach /init, and hangs without panicking.
I've tried adding calls to /sbin/busybox poweroff in the /init script to see if it was actually reaching execution, nothing changed.
I identified a few points that seemed problematic, one being this:
[ 3.880314] Warning: unable to open an initial console.
[ 3.880429] Waiting for root device ... # Might be the problem.
[ 4.882304] lct will vote for sdp current
[ 4.882437] pmi632_charger: smblib_update_usb_type: lct v02 battery charge APSD=SDP PD=0
[ 4.889933] msm-dwc3 7000000.ssusb: DWC3 exited from low power mode
[ 5.520181] of_batterydata_get_best_profile: light_4000mAh found
[ 8.760236] cfg_timer_func enter
[ 8.760267] cfg_work_routine enter
# Nothing appears after this point...
I have included the source code for my build tool with the kernel log buffer in this git repository. You can find the defconfig I used for the kernel build here.
Any help would be appreciated. :)

Related

Android Port bootloop due to non updatable apex or boringssl checks

I am building LineageOS 18.1 for tecno kd7. I have system, system_ext, product & vendor paritions. The rom port I built is having a boot loop.
Here is the last_kmsg
What is causing the boot loop?
I am suspecting these lines
[ 1.802608] (0)[354:apexd]apexd: This device does not support updatable APEX. Exiting
[ 2.352523] (0)[1:init]reboot: Restarting system with command 'boringssl-self-check-failed'
I just need direction on what I need to what is causing the phone to bootloop
I also faced the same issue. The boringssl-self-test binary is using incorrect libcrypto.so library.
You can run the boringssl-self-test with strace and check for the issue.
In file : external/boringssl/selftest/boringssl_self_test.rc
service boringssl_self_test64_vendor /system/bin/strace -tt /vendor/bin/boringssl_self_test64
setenv BORINGSSL_SELF_TEST_CREATE_FLAG true # Any nonempty value counts as true
#reboot_on_failure reboot,boringssl-self-check-failed
stdio_to_kmsg
seclabel u:r:vendor_boringssl_self_test:s0

Ask questions about Android VTS

I ask questions about Android VTS.
I am currently working on ubuntu 18.04, and target device is working on AVD.
First of all, the environment I set is as follows.
$ sudo apt-get install git-core gnupg flex bison build-essential zip curl zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig
$ mkdir android && cd android
$ repo init -u https://android.googlesource.com/platform/manifest -b android-11.0.0_r28
$ repo sync -c -j $(($(nproc) - 2)) --no-tags --no-clone-bundle
$ repo start android-11.0.0_r28 --all
$ . build/envsetup.sh
$ lunch sdk_phone_x86_64-userdebug
$ m
I have successfully built and confirmed that the emulator works well.
$ emulator -no-window -writable-system
$ adb root remount
$ adb device
List of devices attached
emulator-5554 device
After that, I built the following vts to analyze the behavior of Android keymaster.
$ cd hardware\interfaces\keymaster\3.0\vts\functional
$ mm
After successful module build, I ran the emulator and pushed the binary as follows.
$ emulator -no-window -writable-system
$ adb root remount
$ adb push out\soong\.intermediates\hardware\interfaces\keymaster\3.0\vts\functional\VtsHalKeymasterV3_0TargetTest\android_x86_64\VtsHalKeymasterV3_0TargetTest /data/tmp
I did the above successfully, and I ran the binary and it looks like this:
$ adb shell /data/tmp/VtsHalKeymasterV3_0TargetTest
[==========] Running 12 tests from 1 test suite.
[----------] Global test environment set-up.
[----------] 12 tests from GoogleTestVerification
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<KeymasterVersionTest>
Paramaterized test suite KeymasterVersionTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<KeymasterVersionTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<NewKeyGenerationTest>
Paramaterized test suite NewKeyGenerationTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<NewKeyGenerationTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<GetKeyCharacteristicsTest>
Paramaterized test suite GetKeyCharacteristicsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<GetKeyCharacteristicsTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<SigningOperationsTest>
Paramaterized test suite SigningOperationsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<SigningOperationsTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<VerificationOperationsTest>
Paramaterized test suite VerificationOperationsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<VerificationOperationsTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<ExportKeyTest>
Paramaterized test suite ExportKeyTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<ExportKeyTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<ImportKeyTest>
Paramaterized test suite ImportKeyTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<ImportKeyTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<EncryptionOperationsTest>
Paramaterized test suite EncryptionOperationsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<EncryptionOperationsTest> (1 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<MaxOperationsTest>
Paramaterized test suite MaxOperationsTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<MaxOperationsTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<AddEntropyTest>
Paramaterized test suite AddEntropyTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<AddEntropyTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<AttestationTest>
Paramaterized test suite AttestationTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<AttestationTest> (0 ms)
[ RUN ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<KeyDeletionTest>
Paramaterized test suite KeyDeletionTest is defined via TEST_P, but never instantiated. None of the test cases will run. Either no INSTANTIATE_TEST_SUITE_P is provided or the only ones provided expand to nothing.
Ideally, TEST_P definitions should only ever be included as part of binaries that intend to use them. (As opposed to, for example, being placed in a library that may be linked in to get other utilities.)
[ OK ] GoogleTestVerification.UninstantiatedParamaterizedTestSuite<KeyDeletionTest> (0 ms)
[----------] 12 tests from GoogleTestVerification (2 ms total)
[----------] Global test environment tear-down
[==========] 12 tests from 1 test suite ran. (3 ms total)
[ PASSED ] 12 tests.
It only took 3ms to complete the following.
When I check it closely, the test itself does not seem to proceed.
I have not made any additional changes to the source or other details.
Anyone who knows what else I need to do to run the keymaster vts would be appreciated.

recipe for target 'ninja_wrapper' failed / flex core dumps

First time android builder here. I used to do a lot of roll your own back on FreeBSD in the day. Getting back into geekdom with android.
I am trying to build android-7.0.0_r14 for the Nexus 6 NBD90Z to run under emulation. I plan to eventually build for my actual phone and this config is pretty close. I am building on ubuntu 18.04 LTS which is newer than what the docs recommend. Maybe that is a bit adventurous.
Here is what I get when I run make.
... snip
build/core/base_rules.mk:316: warning: ignoring old commands for target
out/target/product/shamu/system/lib/soundfx/libqcomvoiceprocessing.so'
Starting build with ninja
ninja: Entering directory.'
ninja: warning: multiple rules generate out/target/product/shamu/system/etc/gps.conf. builds involving this target will not be correct; continuing anyway [-w dupbuild=warn]
[ 0% 1/35600] Lex: libaidl-common <= system/tools/aidl/aidl_language_l.ll
FAILED: /bin/bash -c "prebuilts/misc/linux-x86/flex/flex-2.5.39 -oout/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_l.cpp system/tools/aidl/aidl_language_l.ll"
flex-2.5.39: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
Aborted (core dumped)
ninja: build stopped: subcommand failed.
build/core/ninja.mk:148: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
A core dump for flex was not produced in spite of the error message given.
out/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_l.cpp does not exist. That entire folder is empty. It would seem that something is not downloading/copying the aidl_language_l.cpp.
Any ideas on what I might have messed up?
I am still a little confused at the complexity of git/repo/make/ninja/soong/lunch to conduct a build. It is likely that I missed something obvious.
Thanks,
Jason C. Wells
Just replace your make by export LC_ALL=C make or put the export in your .bashrc
After I looked at this a little closer I realized the prebuilt prebuilts/misc/linux-x86/flex/flex-2.5.39 would dump core with no arguments. I created a soft link to /usr/bin/flex. Compilation seems to be proceeding.
I haven't answered why the prebuilt was dumping. My goal is to compile android, not troubleshoot the tools.
I performed Snorky's steps. I deleted my output directory for libaidl-common_intermediates. I deleted my soft link and restored the android tree version of flex. I re-ran make at the top of the local repo. The build proceeded past the error above and stopped at a new error. It appears that Snorky's answer worked.
Doh! I'm new so S.O. didn't give credit for my upvote.

Unable to boot freshly built CyanogenMod 13

After playing around with the latest build of CM for my device (12.1), I decided to try and build my first ROM. So I got Linux, synced sources for 13, etc. (My device tree is here.)
I had to grapple with a few audio-related build errors before I finally got it to build. (If it makes any difference, all the commits I had to revert were related to PCM audio offloading.)
Now, when I try to boot the ROM, it immediately reboots to recovery without even displaying the boot animation. Looking at /proc/last_kmsg, the problem seems to be about SELinux:
...
[ 4.340084] init: (Initializing SELinux enforcing took 0.51s.)
[ 4.349071] type=1400 audit(1468237723.015:4): avc: denied { fowner } for pid=1 comm="init" capability=3 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0
[ 4.349387] init: SELinux: Could not set context for /init: Operation not permitted
[ 4.349506] init: restorecon failed: Operation not permitted
[ 4.349699] init: Security failure; rebooting into recovery mode...
[ 4.350353] SysRq : Emergency Remount R/O (triggered by init:1)
[ 4.350581] Emergency Remount complete
[ 4.350889] reboot - triggered with task: init (1:1)
...
I'm not familiar with SELinux apart from the fact that it makes system modifications a lot harder, but from what I've seen, both the device-specific and general init.te files in the Android source allow init to use the fowner capability.
I've tried:
Modifying the sepolicy file by making the init domain permissive
Rebuilding the entire ROM with permissive init; in init.te
Commenting out restorecon /adb_keys and restorecon_recursive /mnt in init.rc
Rebuilding the device kernel with EXTRA_CFLAGS += -DCONFIG_ALWAYS_ENFORCE=true
Searching for a solution on Google - a person on XDA had the exact same problem as me but subsequent posts from him/her did not yield any progress or solutions on the matter
None of them made any difference, so basically, I'm fresh out of ideas.
What am I doing wrong?

Kernel Configuration - Nexus Platform join failed

I am doing kernel configuration for ICS. I needed to enable Posix message queue as it is required in one of our applications. But enabling this option resulted in error. The make was successfull. But the image could not be loaded. The dmesg was:-
disagrees about version of symbol module_layout.
init: untracked pid 2038 exited.
logcat :-
mknod : '/dev/nexus_proxy' failed
NEXUS_Platform_Join [CONSTRUCTOR] failed.
Looks like you rebuilt only the kernel.
You need to build any kernel-modules (*.ko files) and
update them onto the filesystem.
Here is a detailed discussion on the disagrees about version of symbol error.

Categories

Resources