I'm getting the below error while making system.img
there are all files like boot.img, vendor.img but not system img
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
set_selinux_xattr: No such file or directory searching for label
"/bt_firmware" e2fsdroid: No such file or directory while configuring
the file system loaded 3450 fs_config entries
Out of space? Out of inodes? The tree size of
/home/prashi_kadasi/arrow10/out/soong/.temp/tmpP2XFd3 is 1272721408
bytes (1213 MB), with reserved space of 0 bytes (0 MB). The max image
size for filesystem files is 4294967296 bytes (4096 MB), out of a
total partition size of 4294967296 bytes (4096 MB). 01:24:45 ninja
failed with: exit status 1
failed to build some targets (01:02 (mm:ss))
Check that you include this
/bt_firmware(/.*)? u:object_r:bt_firmware_file:s0
in your file_contexts and this
type bt_firmware_file, file_type;
in your file.te (and that you have your sepolicy included)
I know the solution to this was given for the most part, but I see this asked quite a lot and I figure this a good place to give a little background.
So the answer is usually given in some form of "add the offending label to file_contexts and and make sure its labeled", apart from that, rebuilding file_contexts and sepolicy/sepolicy.recovery and starting a new build fixes it.
The issue stems fro selabel_lookup failing, and in my experience this is usually due to additions to device trees and or changes that weren't accounted for before file_contexts.bin is created by the build system. You can learn a lot more about the issue from this now obscure commit
Related
I am trying to implement OTA functionality for a msm8998 board running Android 8.1.
I've generated the OTA file and followed the standard way of doing it,
I've run into two problems, solving either one would solve the issue:
OTA size is bigger than /cache, therefore even though recovery can mount /cache, the image cannot fit there. How would I increase the /cache size, and is it a good idea to do so?
If I put the OTA zip in /data/ or /sdcard/, I have an error during recovery, seemingly it can't mount it. How would I make /data/ mountable?
...
Finding update package...
I:Update location: /data/update.zip
Opening update package...
E:Failed to mount /data: Invalid argument
E:Unable to open '/data/update.zip': No such file or directory
E:failed to map file
W:failed to read uncrypt status: No such file or directory
W:Failed to read /sys/class/thermal/thermal_zone28/temp: Invalid argument
W:Failed to read /sys/class/thermal/thermal_zone27/temp: Invalid argument
I:current maximum temperature: 44756
I:/data/update.zip
I:0
I:time_total: 0
I:retry: 0
I:temperature_start: 44814
I:temperature_end: 44756
I:temperature_max: 44814
I:
Installation aborted.
Turns out you have to use RecoverySystem.installPackage(...) method AND have the OTA file be in /data/.
Previously I had tried RecoverySystem.installPackage(...) method but with file in /sdcard/, and separately by setting /cache/recovery/command myself and using /data/
When using RecoverySystem.installPackage(...) and the file in /data/, seems uncrypt is run on it before reboot, and that makes the update accessible to the recovery.
while trying to build my image, I am getting the following error: "ext4_allocate_best_fit_partial: failed to allocate 20001 blocks, out of space?"
I don't want to change the partition table inside bootloader of dev as there are other dependencies. What other solutions I can explore.
while playing around with Android ART and the "native" code file .oat/.elf which is created at the app installation process, I did notice something odd.
For my understanding, if the device is using ART (Android >= 5.0), the app will start with the compiled oat file (/data/dalvik-cache/arm64/).
Thats why I was kinda surprised when checking the used fd's of an app and did not find the file there. Only the normal apk (/data/app//base.apk) is listed there.
Check this output of my "ls -l /proc/PID/fd"
So I thought maybe it's just not listed there. So I did exchange the oat file of that app by myself by compiling another classes.dex with the dex2oat tool.
So even after changing the file, the app starts normally without any strange messages or errors (also in logcat).
What is the explanation for this? What is the detailed process Android does when starting an app under ART?
I hope someone can clear that up for me. Thanks a lot.
Based on #Paschalis comment, I investigated here and the oat file is indeed memory mapped on Android 5.0 devices (emulator):
a6af4000-a6af9000 r--p 00000000 1f:01 7366 /data/dalvik-cache/x86/data#app#my.app.works-1#base.apk#classes.dex
Check via:
cat /proc/<PID>/maps | grep dex
Sadly this isn't true anymore for Android 6.0 devices (Nexus 5 & arm-Emulator).
The odex file is within the /data/app/<APP>/oat/<ARCHITECTURE>/ folder as 'base.odex`
/data/app/app.app.works-1/oat/arm/base.odex
I still haven't found a valid reference for this, it is based on experiments and observations
I am using gdb for dumping core file for an android process. I am running gdbserver on the device on tcp port and gdb client on the desktop. When i do gcore on client i get the below error.
Does any one know why i'm getting this error , any help much appreciated.
(gdb) gcore
Command not implemented for this target.
The reason i'm doing this to dump process memory and extract Classes.dex file from the memory using core file. I've tried doing this using /proc/pid/mem and proc/pid/maps and dump memory but that has too many mapped regions , i couldn't find the area where the Classes.dex file is. Any other alternate approach is also welcome. Thanks for your help.
First of all, you can only dump odex from memory (because dex compiled to odex for execute). But its not a big deal to convert odex to dex using baksmali-smali.
To find odex in memory you can use gdb for checking magic number for every begin-address of mapped memory(proc/pid/maps - first column):
gdb --batch --pid "pid_task" -ex x/s "mem_start"
So, when returned value equal to "dey\n036", you can dump this memory region via gdb.
Try to begin checking memory addresses from the end of file "proc/pid/maps", it will be much faster.
PS Sorry for my english, but hope it will help.
#Chris Stratton, the memory mapped classes.dex file will be different from the dex file inside apk on disk, for example in cases of packed dex files, some part of dex will be deobfuscated, question is to dump the memory mapped classes.dex file by getting the process memory.
You can use GameGuardian for this. Need root.
Memory editor tab - menu - memory dump - input 0-0 as range and folder - press ok - wait for toast Dump end.
Go to selected folder - open maps file - search needed odex in regions - remember start address of region - open GameGuardian - menu - memory dump - input remembered address in both field as range - press ok - wait for toast Dump end.
Now you have in your folder .bin file with dumped odex file.
Also you can find address in drop down list in GameGuardian UI. Press drop down icon on right with dump range field.
Here some video examples how to do this:
How to dump odex file from memory on Android -
GameGuardian
I have developed a Loadable Kernel Module (LKM) for android.
I use kzalloc:
device = kzalloc(ndevices * sizeof (*device), GFP_KERNEL);
and it worked for a while, but after an update of my android (since 4.1 it's no more working), I got following error on insmod:
insmod module.ko
insmod: init_module 'module.ko' failed (No such file or directory)
DMESG says:
Unknown symbol malloc_sizes (err 0)
This has something to do with inux/slab.h, that's what I know.
I googled for days over days and I'm very frustrated not finding the solution to fix this problem and get the LKM working again.
Can maybe anyone help me out?
CONCLUSION:
The accepted answer is correct: Try to remove the slab.h and define the missing methods as "extern". Or in your kernel-source, use "make menuconfig" and change SLAB to SLUB (see first comment in answer for more details).
The remaining problems are handled in a new, more specific topic:
Interchangeability of compiled LKMs
So you need to tell us the kernel versions. But looking up linux kernel versions and memory allocators, it looks like the default mainline kernel switched from SLAB to SLUB.
By default, Linux kernel used a SLAB Allocation system until version
2.6.23, when SLUB allocation became the default.
Unless you're writing a module or something that depends on SLAB (which is very highly unlikely), then you probably don't want to be including linux/slab.h headers.