Related
Presently we're running a little short on kernel exploits, with the following being the only one that looks remotely plausible:
http://xorl.wordpress.com/2010/01/14/cve-2009-4141-linux-kernel-fasync-locked-file-use-after-free/
Big hold-up? For all that we have a trigger, we don't have an exploit. I believe it's up to us at this point to make that happen.
If I'm reading it right, it looks like the bug initially rears its head right here:
Code:
void __kill_fasync(struct fasync_struct *fa, int sig, int band)
{
while (fa) {
struct fown_struct * fown;
if (fa->magic != FASYNC_MAGIC) {
printk(KERN_ERR "kill_fasync: bad magic number in "
"fasync_struct!\n");
return;
}
[B]fown = &fa->fa_file->f_owner;[/B]
/* Don't send SIGURG to processes which have not set a
queued signum: SIGURG has its own default signalling
mechanism. */
if (!(sig == SIGURG && fown->signum == 0))
send_sigio(fown, fa->fa_fd, band);
fa = fa->fa_next;
}
}
... as fa_file now points to invalid memory (having been free'd earlier). The f_owner member gets shot out to send_sigio, which look like this:
Code:
void send_sigio(struct fown_struct *fown, int fd, int band)
{
struct task_struct *p;
enum pid_type type;
struct pid *pid;
int group = 1;
read_lock(&fown->lock);
type = fown->pid_type;
if (type == PIDTYPE_MAX) {
group = 0;
type = PIDTYPE_PID;
}
[B]pid = fown->pid;[/B]
if (!pid)
goto out_unlock_fown;
read_lock(&tasklist_lock);
do_each_pid_task(pid, type, p) {
send_sigio_to_task(p, fown, fd, band, group);
} while_each_pid_task(pid, type, p);
read_unlock(&tasklist_lock);
out_unlock_fown:
read_unlock(&fown->lock);
}
... in which we see the f_owner member being dereferenced. Also it gets pushed through several other functions which may be exploitable.
There are several questions to be answered before we can start attacking this:
Can we resolve the address of the fa_file data structure so we can overwrite the f_owner value?
Can we do anything with it once we've done that? (Presumably we can set it to zero to cause a null-pointer dereference, but we're mmap_min_addr = 32768 on the most recent versions, so unless we can flag the mmap region to grow down and apply memory pressure to reach page 0 this will do us no good.)
Failing the plan above: are any of the functions that f_owner gets pushed into vulnerable? I evaluated this over the weekend, but without the help of a trained kernel dev I'm not going to get very far.
While I studied a lot of this in uni, I'll admit I'm green when it comes to actually writing these exploits. I'm hoping that this will get the creative juices flowing, and perhaps provide a more comprehensive resource in case any hard-core kernel hackers want to take a look at what we're doing or give us pointers (harhar) in the right direction.
Thanks, guys. Great work up to this point.
In the original POC if you change /bin/true to /system/bin/sh you can get a new shell to open just not as root. So I'm guessing that their needs to be more added to the POC to make it a full exploit.
Right, the fork()'s in the PoC exist only to cause the file descriptor's fasync_struct to be erroneously killed, not start a root session. The root session would need to be started (presumably) by the kernel doing something to our maliciously crafted fown_struct.
The tough part is figuring out exactly where and what that fown_struct needs to be.
Well I definetly agree with you that this seems to be our best best bet I am some what of a newbie when it comes to linux allthough i am learning as i go. Do you know of any good sites to read up on kernel hacking?
Sorry Guys just got the word that this one is dead for us.....
Here is the explantion i got.
some_person said:
Nope, the bug didn't exist in 2.6.27. That's why they say >= 2.6.28 are vulnerable.
As far as how the bug works, there are 2 other issues. 1) our kernel probably wasn't compiled with AT_RANDOM 2) we don't have an elf executable.
The exploit you found does not give us root access, it crashes the system. Basically, you open the "random number generator" file, lock it, and close it... but the lock release when you close it. Then you have to call an elf executable because that generates a random number (running an elf executable) provided the kernel was compiled AT_RANDOM. you continue to call that executable (and generating random numbers) until the the lock is released on the "random number generator" file... then it's your program's turn... the kernel tries to send your program notification that the file is available, but your program has moved on. BLAM the kernel stops (or "oops").
Click to expand...
Click to collapse
Sorry to dredge up an old thread:
This exploit *will* work. According to Zanfur, the hole is in our kernel. We need to use it without AT_RANDOM (which I dont know how to do).
http://sourceware.org/ml/libc-alpha/2008-10/msg00016.html
I am pretty sure we do have elf executables, here is proof:
% file m6
m6: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
If our kernel is susceptible to this bug then it should work, as long as there is a way to do it without at random.
Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.
jballz0682 said:
Though I do not in any way represent my self as a hacker or developer I was wondering if I could throw in my 2 cents. I notice that this bug/exploit won't work because it requires AT RANDOM. I was wondering if it s possible to write code that does what the function does and insert it in. Is root required to do this (i.e. insert code into the kernel that wasn't there before) or is this a matter of know-how? Just some brainstorming I thought that I would throw in.
Click to expand...
Click to collapse
This won't get us root. Even zanfur said it. Moving on....
Framework43 said:
This won't get us root. Even zanfur said it. Moving on....
Click to expand...
Click to collapse
To clarify, even if we get AT_RANDOM functionality working, we can't use this to exploit our kernel. All we can do with this is get data from a file that was recently closed. The point of this exploit is to send a signal to a process, but there are no processes we could send a signal to that would give us root.
Our kernel seems practically invulnerable, it appears that almost all exploits are patched
Now, I am no great Android developer... I'm just someone who is technically inclined to piece together several different mods and tweaks from different sources... and I do it because I love getting the best out of my GTablet...
I pretty sure everyone reading this agrees that CyanogenMod is the best after-market AOSP-based community initiative ROM available... it's got dozens of new features, fixes, modifications and enhancements over pure AOSP Android... And thanks to the efforts of the entire CyanogenMod team, especially bekit, pershoot & mad-murdock, we have CyanogenMod for our GTablets...
I keep experimenting with the latest CyanogenMod build and the tonnes of other contributions by various people in the community (XDA, TabletRoms, SlateDroid, etc.)... trying to mix and match and find a combination which will give me the best of both worlds...
I started this off as a personal initiative... and decided to share it with the community... but this effort of merging various community contributions into CyanogenMod ROMs takes time and quite often needs thorough testing, it is not practical for me to release updates very frequently. But every so often, when I see commits in CyanogenMod or contributions in the community which would be nice to repack and share with the community, I will hope on board and create a new release.
Please read through the post thoroughy, especially the instructions, troubleshooting and known issues section and familarise yourself with NVFlash recovery.
Credit for most of the amazing features of this ROM goes to the CyanogenMod team (especially pershoot, bekit, mad-murdock) and contributors... and the various other members of the community who share their brilliant mods and tweaks...
Big thanks to dev-host.org team for hosting the files with no bandwidth restrictions...
LATEST RELEASE | CYANOGENMOD7.2.0-RC0-BUILD98-REPACK | ANDROID 2.3.7
REPACK DOWNLOAD [Bootloader 1.1]
MD5Sum = 9a038efaa6acd207868696c657a34cb4
REPACK DOWNLOAD [Bootloader 1.2]
MD5Sum = cd2041dd0fd2d8e2dbda9adb2fbe3025
FIX FOR MOBILE SIGNAL ICON IN STATUS BAR [Both bootloaders]
MD5Sum = 1fc03c6f05a8b9da43d4966c6ad42549
OFFICIAL CHANGELOG
NIGHTLIES CHANGELOG
REPACK CHANGELOG:
Code:
1. All features of the official CM7.2.0-RC0 Build 98 [credits to CM team]
2. Android Gingerbread 2.3.7 along with all 2.3.7 GWK74 Google Apps [credits to Google]
3. Latest Android Market 3.3.12 [credits to Google]
4. Superuser 3.0.7 [credits to ChainsDD]
5. QuickOffice Tablet from Notion Ink Adam
6. Google Music 4.0.9 with Google Music cloud sync [credits to Google]
7. Demotivators Protips (hilarious de-motivational sayings) [credits to david1171]
8. Updated the build fingerprint to 2.3.6 GRK39F [based on the latest Nexus One OTA]
9. Changed display density to 120 (was 160) which means more real estate
10. Uses latest libs, jars & other proprietary from the latest 1.2-5274 TnT ROM (BL1.2 release only) [credits to TnT team]
11. Separate releases for bootloaders 1.1 & 1.2
12. Switchable internal & external storage mount points [credits to CM team]
13. Kernel 2.6.32.48 – OC-UV-VFP_FP (up to 1.400GHz) [credits to pershoot]
14. Several stagefright (Android Media Framework) fixes and tweaks to improve audio and video decoding [credits to CM team]
15. Latest stock camera with all CM tweaks and fixes and no pixelated still photographs [credits to CM team]
16. New GoogleTalk with voice & video (only one way video, GTablet video broken) [credits to britoso, B3ATTY]
17. Fixed assert checks in update script for Clockwork recovery for BL 1.1 & 1.2
18. Removed ROMManager since it does not play nice with the GTablet
19. Hand-picked tweaks for performance, battery life & internet from a collection by knzo [credits to knzo]
20. Tweaked minfree (low memory killer) for performance improvement
21. Increased internal & external (if present) storage read cache to 2048 to improve storage access speed
22. Hardware decoding for MP4 h264 Baseline videos upto 720p [credits to CM team]
23. Pandora and other internet radio application playback no more slow [credits to CM team]
24. Browser default bookmarks modified to include GTablet specific bookmarks
25. Full working Android Market with tablet recognisation (no Market fixes needed)
INSTALLATION INSTRUCTIONS:
1. Download the ROM from the appropriate bootloader.
2. Verify the MD5Sum of the downloaded ROM.
3. Clear cache & dalvik cache using Clockwork recovery if you were not using a CM7 2.3.7 ROM prior to flashing this
4. Flash using Clockwork recovery.
RECOMMENDED:
1. If you are using the 1.2 bootloader version, use the latest 1.2 bootloader from the 1.2-5274 ROM.
2. Wipe data/factory reset is recommended if you were not using a CM7 2.3.7 ROM prior to flashing this.
3. Since most newer ROMs are based on the 1.2 bootloader, it is recommended that you upgrade to the 1.2-5274 ROM so that you have more freedom to switch to other newer ROMs.
ADD-ONS:
1. Extra kernel modules for pershoot's kernel 2.6.32.48 (lib-2632.48_gb.tar.gz) [For advanced users only]
2. Possible SOD (sleep of death) fixes
TIPS & TWEAKS:
1. You can enable and disable the lockscreen from Settings -> CyanogenMod settings -> Tablet tweaks -> Disable lockscreen.
2. You can switch the mount points of the internal & external memory. You can mount the internal memory as /mnt/sdcard or as /mnt/emmc. Go to Settings -> CyanogenMod settings -> Application -> Use internal storage. This is not part of the CyanogenMod-7.1.0-RC1 build.
3. Since hardware decoding of videos is not working, use MX Video Player or Mobo Player which have software rendering for videos. I recommend one of these players since they have ARMv7 (Tegra) optimised software codecs (FFMPEG).
4. If you want to change the LCD density, download & install PropEditor. Click the "Backup" button to create a backup in case you need to revert back. Then click the "Open" button and in the file manager which opens, tap ".." till you reach the system root. Then tap "system" and the tap "build.prop" to open the editor. Look for "ro.sf.lcd.density" and tap it to change the value. Press the "Menu" key and tap "Save". Reboot.
5. Increasing the DalvikVM memory size will improve performance of the bigger high-graphics Tegra games. Go to Settings -> CyanogenMod settings -> Performance -> VM heap size and set it as 64m.
6. To overclock or underclock your device, go to Settings -> CyanogenMod settings -> Performance -> CPU settings and set the Min CPU frequency and Max CPU frequency to a value of your choice. Click Set on boot to make the frequency setting persistent after reboot.
7. If the Clock app opens every time you press the Home button, it's because Android thinks you GTablet is docked (I don't know why yet!). Install Dock No-Op to fix it.
8. If you wish to use Market Enabler, use the one by For2w. It has many more providers to fake and works properly with the Android Marker 3.x.
KNOWN ISSUES:
1. Due to lack of official drivers and/or OpenGL issues, the video camera does not work and stagefright (media framework) FCs.
2. Due to lack of official drivers & codecs, hardware decoding for videos does not work for most video formats other than MP4. Use a video player with software rendering.
3. If audio from the loudspeaker suddenly stops, plug in a headset and then unplug it.
4. Since the video camera does not work, any video apps which use the stock video camera will not work. Users have reported Fring & Oovoo video chat works.
5. GoogleTalk and Skype now support ARMv7 without neon. This version of GoogleTalk is included in this ROM. But due to lack of official drivers and/or OpenGL issues, both GoogleTalk and Skype cannot broadcast video from the GTablet. The reciepent's video is visible on the GTablet.
6. If you have a problem downloading applications from the Android Market and all/most apps show as "not available for device", try wiping Market data and cache and rebooting. If that does not work, edit build.prop and change the resolution 160 DPI and wipe Market data and cache and reboot.
7. Some user may face SODs (Sleep of Death) wherein the device does not wake after sleep until a hard-reboot. Some possible workarounds are
a. Enabling the lockscreen (see Tips & Tweaks)
b. Setting the device to wake using volume keys (CyanogenMod setting -> Input -> Volume rocker wake)
c. Setting the Min CPU frequency to 312 MHz or 456 MHz (see Tips & Tweaks)
d. Visit this thread for more solutions
8. Google Maps 6.x force closes due to openGL issues with Gingerbread on the GTablet. Use Google Maps 5.x.
TROUBLESHOOTING STEPS:
1. Try a data/factory reset
2. Use ClockworkMod recovery and try a data/factory reset and format the boot and system partitions
3. Use ClockworkMod recovery and partition the internal SD card as 2048MB ext, 0MB swap, remaining FAT32
4. nvFlash to the stock image
DISCLAIMER:
While this has been branded a "stable" release, do note that it is not 100% perfect. I will do my best to help you out if you have any problems, but I take no responsibility if you land up with a brick. Much of the actual hard-work behind the functionality of this ROM belongs to the various developers and teams credited in the changelogs above. Throw a nice thanks to them for their hard work.
ARCHIVED RELEASE:
1. CYANOGENMOD7.1.0.1-REPACK | ANDROID 2.3.7
2. CYANOGENMOD7.1-RC-Build52-REPACK | ANDROID 2.3.7
3. CYANOGENMOD7.1-RC-Build21-REPACK | ANDROID 2.3.5
4. CYANOGENMOD-7.1.0-RC1 | ANDROID 2.3.4
More details and download links for archived releases
I got installation of 7.1.0 RC "aborted"
Same here using 1.2 BL & CW.
The usual asserts error, expecting HARMONY as system type. Also, are those the right GAPPS, or should it be gapps-gb-20110613?
MC
Disabling assert doesn't get this installed. Was really hoping for an rc1 for 1.2...
MicroChip said:
The usual asserts error, expecting HARMONY as system type. Also, are those the right GAPPS, or should it be gapps-gb-20110613?
MC
Click to expand...
Click to collapse
This is the 2.3.4 Google Apps with the new Google Talk with Voice & Video... the one you noted is the 2.3.3 Google Apps... this was created using the official GRJ22 firmware...
And for those having problems with the asserts, try removing the assert line (the line mentioned below) from the update-script in the ROM zip...
Code:
assert(getprop("ro.product.device") == "harmony" || getprop("ro.build.product") == "harmony" || getprop("ro.product.board") == "harmony" ||
getprop("ro.product.device") == "smb_a1002" || getprop("ro.build.product") == "smb_a1002" || getprop("ro.product.board") == "smb_a1002");
I've managed to set up CM7.1 RC1 on both the BL1.1 & BL1.2 after removing the above line.
craigacgomez said:
And for those having problems with the asserts, try removing the assert line (the line mentioned below) from the update-script in the ROM zip...
Code:
assert(getprop("ro.product.device") == "harmony" || getprop("ro.build.product") == "harmony" || getprop("ro.product.board") == "harmony" ||
getprop("ro.product.device") == "smb_a1002" || getprop("ro.build.product") == "smb_a1002" || getprop("ro.product.board") == "smb_a1002");
I've managed to set up CM7.1 RC1 on both the BL1.1 & BL1.2 after removing the above line.
Click to expand...
Click to collapse
I didn't try it but have in the past and I'm pretty sure it doesn't work because changing that line makes the rom fail md5 test if I recall?
Check with zyhong, he's packaged 1.1 CM for 1.2 bl successfully. Wish somebody would write up how to do it, I'd do it myself.
Thanks!
MC
MicroChip said:
The usual asserts error, expecting HARMONY as
system type.
Click to expand...
Click to collapse
+1 for me.
craigacgomez said:
And for those having problems with the asserts, try removing the assert line (the line mentioned below) from the update-script in the ROM zip...
Code:
assert(getprop("ro.product.device") == "harmony" || getprop("ro.build.product") == "harmony" || getprop("ro.product.board") == "harmony" ||
getprop("ro.product.device") == "smb_a1002" || getprop("ro.build.product") == "smb_a1002" || getprop("ro.product.board") == "smb_a1002");
I've managed to set up CM7.1 RC1 on both the BL1.1 & BL1.2 after removing the above line.
Click to expand...
Click to collapse
This results in an immediate "Installation Aborted" error for me - sans the "assert failed" notice.
First, Thanks for your efforts, but just like the several other threads created for the same topic (with its slight variations) this need to be moved to General section.
The development section is kept for those ROMs developed by the XDA contributors.
craigacgomez said:
This is the 2.3.4 Google Apps with the new Google Talk with Voice & Video... the one you noted is the 2.3.3 Google Apps... this was created using the official GRJ22 firmware...
Click to expand...
Click to collapse
Strange, I thought it was 2.3.4 too.
20110613: This package is designed for Android 2.3.4, and will not work on 2.3.3. It contains all of the applications updated for 2.3.4, but does not include the new Google Talk with video chat due to there being no compatible library available for non-ARM7 and non-neon board devices, from Google or another OEM. This package should work on all 2.3.4 ROMs, and has the latest Android Market update in it, which includes in-app purchase support. This package is listed in the above table, ROM Manager, and latest/7/universal. It should be used with ROMs such as CyanogenMod 7.1.0 (though at the time that I'm updating this, 20110307 is still listed in the ROM Manager manifest for the CyanogenMod Nightlies).
Click to expand...
Click to collapse
That said, does video chat work on your tablet ?!
MicroChip said:
I didn't try it but have in the past and I'm pretty sure it doesn't work because changing that line makes the rom fail md5 test if I recall?
Check with zyhong, he's packaged 1.1 CM for 1.2 bl successfully. Wish somebody would write up how to do it, I'd do it myself.
Thanks!
MC
Click to expand...
Click to collapse
I have put an instruction on the second post of my GB for BL1.2 post, and someone in slatedroid have successfully build the cm7.1 RC1, which is confirmed by some users that works well. I have put a link for that build on my post as well. Hope this help.
I think I know the answer, but I'm no expert - does CM7.1 for the G-tab have hardware acceleration? If no, I see reports of Flash working so do problems with HD video still exist?
I'm considering moving from Vegan (Froyo) to see if it clears up a couple minor annoyances but I need a (mostly) fully functional tablet. That being said, I use the MoboPlayer so I can soft-decode when needed.
Thanks!
zyhong said:
I have put an instruction on the second post of my GB for BL1.2 post, and someone in slatedroid have successfully build the cm7.1 RC1, which is confirmed by some users that works well. I have put a link for that build on my post as well. Hope this help.
Click to expand...
Click to collapse
I was able to find, and able to get 7.1RC1 on 1.2 bootloader.. Thank you.
For those looking for a flashable update for the 1.2 bootloader:
CM 7.1.0 RC1 for 1.2
md5: 3c22f7acc3dd9f82bd3e5a64915d27d4
Hope it helps.
Edit: Btw, this includes the pershoot kernel.
Hmm things worked fine until I added the pershoot kernel, then I lost wifi
I tried CM 7.1.0 RC1 for 1.2, I'm just sitting at the birds screen.
Did you do a factory reset before rebooting? It fixes the bootloop usually.
Yes I did and it just sat at the birds but will try again. I can't seem to get Clockwork to install alone either
I will re-create the CM7.1 RC 1 for both bootloader versions in a day or two so that it will work with any bootloader and even the stock recoveries.
I am using CWR 3.0.2.8 and used install zip from sdcard to flash the rom. Did you flash it that way?
I have Omni booting and running on a E210K (It is a SGS3 Korean variant, only changes are LTE, 2GB and DMB antenna), but some major bugs need fixing. There not much if any device trees for these out there so I have just been modifying the i9300 and it works.
These are probably the major two issues I have for now:
1. without manually adding ro.zygote.disable_gl_preload=1 to the build prop, it won't boot. I noticed this line wasn't in the i9300 builds either, but it's definitely referenced in my builds:
/android/omni/device/samsung/smdk4412-common/common.mk
# Set default USB interface
PRODUCT_DEFAULT_PROPERTY_OVERRIDES += \
persist.sys.usb.config=mtp \
ro.zygote.disable_gl_preload=true
Click to expand...
Click to collapse
2. Can't adjust the vibration in advanced settings, when I do I get the logcat message below, there is no (very light) feedback because it seems the value is set very low.
If I manually edit the values (by putting it up to 10+) I can get feedback, so it is working.
Code:
I/ActivityManager( 2466): Displayed org.omnirom.device/.DeviceSettings: +428ms
W/DeviceSettings_Utils_Read( 5375): file /sys/vibrator/pwm_val: 2
W/DeviceSettings_Utils( 5375): file /sys/vibrator/pwm_val not found: java.io.FileNotFoundException: /sys/vibrator/pwm_val: open failed: EACCES (Permission denied)
W/DeviceSettings_Haptic( 5375): key: vibrator_tuning
but I have no idea where/how to proceed.
My device tree is up over at:
https://github.com/kaijura/android_device_samsung_e210k
I am using the same omni sources for smdk4412-common and kernel.
Thanks in advance
kaijura said:
I have Omni booting and running on a E210K (It is a SGS3 Korean variant, only changes are LTE, 2GB and DMB antenna), but some major bugs need fixing. There not much if any device trees for these out there so I have just been modifying the i9300 and it works.
These are probably the major two issues I have for now:
1. without manually adding ro.zygote.disable_gl_preload=1 to the build prop, it won't boot. I noticed this line wasn't in the i9300 builds either, but it's definitely referenced in my builds:
2. Can't adjust the vibration in advanced settings, when I do I get the logcat message below, there is no (very light) feedback because it seems the value is set very low.
If I manually edit the values (by putting it up to 10+) I can get feedback, so it is working.
Code:
I/ActivityManager( 2466): Displayed org.omnirom.device/.DeviceSettings: +428ms
W/DeviceSettings_Utils_Read( 5375): file /sys/vibrator/pwm_val: 2
W/DeviceSettings_Utils( 5375): file /sys/vibrator/pwm_val not found: java.io.FileNotFoundException: /sys/vibrator/pwm_val: open failed: EACCES (Permission denied)
W/DeviceSettings_Haptic( 5375): key: vibrator_tuning
but I have no idea where/how to proceed.
My device tree is up over at:
https://github.com/kaijura/android_device_samsung_e210k
I am using the same omni sources for smdk4412-common and kernel.
Thanks in advance
Click to expand...
Click to collapse
LTE screams "qcom modem" to me - perhaps look at the i9305 tree?
Figured it out, for anyone searching for this problem - the issue has to do with the ramdisk portion of a (custom) kernel as it wasn't matching up omni's init setups.
Entropy512 said:
LTE screams "qcom modem" to me - perhaps look at the i9305 tree?
Click to expand...
Click to collapse
Tried a i9305 build it was a little worse off (no mobile connection), haha. I'm thinking of submitting for an official build after I figure out the build for a working stock omni kernel.
Since this device gets few attention (maybe less than 50 in the sgs3 forum) is it possible that you guys could set the jenkins buildbot to build like every week or other week?
kaijura said:
Figured it out, for anyone searching for this problem - the issue has to do with the ramdisk portion of a (custom) kernel as it wasn't matching up omni's init setups.
Tried a i9305 build it was a little worse off (no mobile connection), haha. I'm thinking of submitting for an official build after I figure out the build for a working stock omni kernel.
Since this device gets few attention (maybe less than 50 in the sgs3 forum) is it possible that you guys could set the jenkins buildbot to build like every week or other week?
Click to expand...
Click to collapse
Hmm, that might be a possibility...
kaijura said:
I have Omni booting and running on a E210K (It is a SGS3 Korean variant, only changes are LTE, 2GB and DMB antenna), but some major bugs need fixing. There not much if any device trees for these out there so I have just been modifying the i9300 and it works.
These are probably the major two issues I have for now:
1. without manually adding ro.zygote.disable_gl_preload=1 to the build prop, it won't boot. I noticed this line wasn't in the i9300 builds either, but it's definitely referenced in my builds:
2. Can't adjust the vibration in advanced settings, when I do I get the logcat message below, there is no (very light) feedback because it seems the value is set very low.
If I manually edit the values (by putting it up to 10+) I can get feedback, so it is working.
Code:
I/ActivityManager( 2466): Displayed org.omnirom.device/.DeviceSettings: +428ms
W/DeviceSettings_Utils_Read( 5375): file /sys/vibrator/pwm_val: 2
W/DeviceSettings_Utils( 5375): file /sys/vibrator/pwm_val not found: java.io.FileNotFoundException: /sys/vibrator/pwm_val: open failed: EACCES (Permission denied)
W/DeviceSettings_Haptic( 5375): key: vibrator_tuning
but I have no idea where/how to proceed.
My device tree is up over at:
https://github.com/kaijura/android_device_samsung_e210k
I am using the same omni sources for smdk4412-common and kernel.
Thanks in advance
Click to expand...
Click to collapse
This says u r building a rom.Is it working fine?
thanks
Hello,
I am interested in trying to port sumire to Lineage 16.0, the problem is I couldn't find any guide that seemed to help me get started.
In IRC someone told me I had to:
1. Fork the cm-14.1 branch to lineage-16.0, change the required config files, and build in a 16.0 build env.
2. Wait for it to error out, fix error, repeat. Eventually once it builds, attempt booting, check logs to see why it isn't booting, fix error, repeat.
But as you can see, its not much.
I have been taking a look into the first commits for sumire on cm-14.1, https://github.com/LineageOS/androi...mmit/7be9d2e5edf6f7ea1f399febbeee9d9fbdc122e1
But I do not know if its the best way to learn.
Where could I find some guides?
Best regards
algui91 said:
Hello,
I am interested in trying to port sumire to Lineage 16.0, the problem is I couldn't find any guide that seemed to help me get started.
In IRC someone told me I had to:
1. Fork the cm-14.1 branch to lineage-16.0, change the required config files, and build in a 16.0 build env.
2. Wait for it to error out, fix error, repeat. Eventually once it builds, attempt booting, check logs to see why it isn't booting, fix error, repeat.
But as you can see, its not much.
I have been taking a look into the first commits for sumire on cm-14.1, https://github.com/LineageOS/androi...mmit/7be9d2e5edf6f7ea1f399febbeee9d9fbdc122e1
But I do not know if its the best way to learn.
Where could I find some guides?
Best regards
Click to expand...
Click to collapse
It's not really a guide, but the guy in this thread tried to port LOS 15 to the Z5, so it's probably the best place to start. He ran into issues with the camera so take a look at the last few pages too see what's going on. The people in that thread are willing to help.
https://forum.xda-developers.com/z5...erimental-lineageos-15-1-z5c-suzuran-t3894617
Devo7v said:
It's not really a guide, but the guy in this thread tried to port LOS 15 to the Z5, so it's probably the best place to start. He ran into issues with the camera so take a look at the last few pages too see what's going on. The people in that thread are willing to help.
https://forum.xda-developers.com/z5...erimental-lineageos-15-1-z5c-suzuran-t3894617
Click to expand...
Click to collapse
Thanks, although its not for the same device (Mine is sumire) it may be helpful.
I have also found this guide, it seems interesting:
https://fat-tire.github.io/porting-intro.html
algui91 said:
Thanks, although its not for the same device (Mine is sumire) it may be helpful.
I have also found this guide, it seems interesting:
https://fat-tire.github.io/porting-intro.html
Click to expand...
Click to collapse
Is there any progress at porting LOS 16?
BrazzerHead said:
Is there any progress at porting LOS 16?
Click to expand...
Click to collapse
I'm still on it. Advancing slowly as I am a newbie on this and only have a few hours/week to do it.
I will keep you updated
I have successfully come to execute brunch sumire, but I am having problems with open jdk-9:
Code:
/run/media/hkr/BackUp/out/soong/make_vars-lineage_sumire.mk:644: warning: JAVAC does not match between Make and Soong:
/run/media/hkr/BackUp/out/soong/make_vars-lineage_sumire.mk:644: warning: Make : /home/hkr/.gentoo/java-config-2/current-user-vm/bin/javac
/run/media/hkr/BackUp/out/soong/make_vars-lineage_sumire.mk:644: warning: Soong: prebuilts/jdk/jdk9/linux-x86/bin/javac
/run/media/hkr/BackUp/out/soong/make_vars-lineage_sumire.mk:1044: error: Soong variable check failed.
I have copied the prebuild version of java that comes with android into my own local version in gentoo, but still getting the same error.
Any ideas?
I have set up android_device_sony_sumire from sony-msm8994 in the included .repo/local_manifest. Setting ROOMSERVICE_BRANCHES=cm-14 as it functions as a fallback branch was suggested in the console output while i was getting familiar and this is a helpful feature worth noting.
There is an incompatibility in https://github.com/sony-msm8994/android_device_sony_sumire and kitakami-common, the lineage.dependencies file needs to be moved or it will try and download dependencies for the sumire files from the LineageOS Github (http://github.com/LineageOS). Next there are two easy defines, SND_AUDIOCODEC_ALAC and SND_AUDIOCODEC_APE to deal with before an untimely error because of a typo present in the Xperia kernel, content_interprtation_type instead of content_interpretation_type.
Code:
hardware/qcom/media-caf/msm8994/mm-video-v4l2/vidc/vdec/src/omx_vdec_msm8974.cpp:9377:60: error: no member named 'content_interprtation_type' in 'msm_vidc_s3d_frame_packing_payload'; did you mean 'content_interpretation_type'?
if (s3d_frame_packing_payload->content_interprtation_type == 1)
^~~~~~~~~~~~~~~~~~~~~~~~~~
content_interpretation_type
out/target/product/sumire/obj/KERNEL_OBJ/usr/include/media/msm_vidc.h:109:15: note: 'content_interpretation_type' declared here
unsigned int content_interpretation_type;
^
hardware/qcom/media-caf/msm8994/mm-video-v4l2/vidc/vdec/src/omx_vdec_msm8974.cpp:9379:65: error: no member named 'content_interprtation_type' in 'msm_vidc_s3d_frame_packing_payload'; did you mean 'content_interpretation_type'?
else if (s3d_frame_packing_payload->content_interprtation_type == 2)
^~~~~~~~~~~~~~~~~~~~~~~~~~
content_interpretation_type
out/target/product/sumire/obj/KERNEL_OBJ/usr/include/media/msm_vidc.h:109:15: note: 'content_interpretation_type' declared here
unsigned int content_interpretation_type;
^
hardware/qcom/media-caf/msm8994/mm-video-v4l2/vidc/vdec/src/omx_vdec_msm8974.cpp:9394:89: error: no member named 'content_interprtation_type' in 'msm_vidc_s3d_frame_packing_payload'; did you mean 'content_interpretation_type'?
s3d_frame_packing_payload->fpa_type, s3d_frame_packing_payload->content_interprtation_type, stereo_output_mode);
^~~~~~~~~~~~~~~~~~~~~~~~~~
content_interpretation_type
It compiled, but gives a black boot screen both from early boot, a kernel issue, adb seems to be communicating, I'm meddling with the boot image atm so i will know more later (Later: The updated mdss code broke for our case somewhere. I will also need to work on the local_manifest) (Later: New Manifest attached) . Last I tested the kernel a few moons ago it worked on the Z1, so issue this was a surprise... I will also import the changes from the sony-msm8994 project, who is doing a great job, i see quite a lot of work to the sdcardfs code.
threader said:
It compiled, but gives a black boot screen both from early boot, a kernel issue, adb seems to be communicating, I'm meddling with the boot image atm so i will know more later (Later: The updated mdss code broke for our case somewhere. I will also need to work on the local_manifest) (Later: New Manifest attached) . Last I tested the kernel a few moons ago it worked on the Z1, so issue this was a surprise... I will also import the changes from the sony-msm8994 project, who is doing a great job, i see quite a lot of work to the sdcardfs code.
Click to expand...
Click to collapse
How did you managed to compile it? I am finding a lot of problems, for example, in system/core/init/util.h
Code:
#include <android-base/chrono_utils.h>
#include <selinux/label.h>
were not found, so I had to comment them out, but I do not know if this its going to be the best approach...
@algui91
Im about to test what built tonight. I suspect i need to port the binder from sony-msm8994 though, it lookst tasty anyway. But does your build by any chance warn against building with a pre compiled kernel? I guess or simply some headers might have new names maybe or some feature needs to be introduced into the kernel.
The .repo/local_manifest/oss.xml contains some qcom opensource projects, to compile for 16.1 change opensource-location from revision=o-mr to p-mr. Also add https://github.com/sonyxperiadev/transpower/commits/android-8.1.0_r35, for 15.1 or probably master for 16.1, i missed that yesterday.
threader said:
@algui91
Im about to test what built tonight. I suspect i need to port the binder from sony-msm8994 though, it lookst tasty anyway. But does your build by any chance warn against building with a pre compiled kernel? I guess or simply some headers might have new names maybe or some feature needs to be introduced into the kernel.
The .repo/local_manifest/oss.xml contains some qcom opensource projects, to compile for 16.1 change opensource-location from revision=o-mr to p-mr. Also add https://github.com/sonyxperiadev/transpower/commits/android-8.1.0_r35, for 15.1 or probably master for 16.1, i missed that yesterday.
Click to expand...
Click to collapse
Hello,
Thanks for your quick reply, How did your test went? this are the only warnings I get when running brunch sumire:
Code:
build/make/core/combo/TARGET_linux-arm.mk:43: warning: cortex-a53.a57 is armv8-a.
build/make/core/combo/TARGET_linux-arm.mk:45: warning: TARGET_2ND_ARCH_VARIANT, armv7-a-neon, ignored! Use armv8-a instead.
Trying dependencies-only mode on a non-existing device tree?
I applied the required binder changes from sony-msm8994 for AOSP 8.1 and it turns out it results in a locked kernel that fails to even boot, so i'm looking that problem now. So for instant results instead of my Z1 to Z5 kernel, use https://github.com/sony-msm8994/android_kernel_sony_msm8994 in , .repo/local_manifests/LA.BR.1.3.3_rb2.14.xml , you need to comment out common-headers common-kernel, also i see i commented out my kernel, a good place to add sony-msm8994, i realize my project to update the unified kernel is riddled with mines., and we really need 15.1 and 16.1 yesterday.
I've come around to testing the whole Sony-msm8994 project that's up on Z5c, Lineage 15.1 is up with wifi, location, nfc available at least, so is the usb otg switch, not working is fingerprint and gsm services, camera.
Spotted this in logcat.
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
TARGET_CPU_VARIANT in device/sony/kitakami-common/BoardConfigCommon.mk is set to generic, it's supposed to be TARGET_CPU_VARIANT := cortex-a53
threader said:
I've come around to testing the whole Sony-msm8994 project that's up on Z5c, Lineage 15.1 is up with wifi, location, nfc available at least, so is the usb otg switch, not working is fingerprint and gsm services, camera.
Spotted this in logcat.
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
TARGET_CPU_VARIANT in device/sony/kitakami-common/BoardConfigCommon.mk is set to generic, it's supposed to be TARGET_CPU_VARIANT := cortex-a53
Click to expand...
Click to collapse
Have the same problem, spotted the same Fatal message, Did the change in TARGET_CPU_VARIANT solved the problem?
Best
I've got a problem with librmnetctl, vendor/qcom/opensource/dataservices, not building, netmgrd is complaining about that missing now, I'm trying the version on Xperiadev, but now I've messed up the build i built earlier and need to rebuild all of it...
threader said:
I've got a problem with librmnetctl, vendor/qcom/opensource/dataservices, not building, netmgrd is complaining about that missing now, I'm trying the version on Xperiadev, but now I've messed up the build i built earlier and need to rebuild all of it...
Click to expand...
Click to collapse
I am trying to detect where the error
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
comes from.
I am guessing its some makefile which has a SHARED_LIBRARY link to _ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj missing, but do not know where to find it. I've searched on the LineageOS repos without luck.
algui91 said:
I am trying to detect where the error
Code:
Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf2io16CodedInputStream20ReadVarint32FallbackEPj" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
Click to expand...
Click to collapse
It seems to be called from protobuf, maybe a missing link to it somewhere?
threader said:
It seems to be called from protobuf, maybe a missing link to it somewhere?
Click to expand...
Click to collapse
It seems so, the question is where that 'Somewhere' is. . Will keep searching.
algui91 said:
It seems so, the question is where that 'Somewhere' is. . Will keep searching.
Click to expand...
Click to collapse
I see its in prebuilt compiler also.
But maybe?
Code:
external/protobuf/src/google/protobuf/io/coded_stream.cc :
Los 14.1
bool CodedInputStream::ReadVarint32Fallback(uint32* value) {
if (BufferSize() >= kMaxVarintBytes ||
// Optimization: We're also safe if the buffer is non-empty and it ends
// with a byte that would terminate a varint.
(buffer_end_ > buffer_ && !(buffer_end_[-1] & 0x80))) {
const uint8* end = ReadVarint32FromArray(buffer_, value);
if (end == NULL) return false;
buffer_ = end;
return true;
} else {
// Really slow case: we will incur the cost of an extra function call here,
// but moving this out of line reduces the size of this function, which
// improves the common case. In micro benchmarks, this is worth about 10-15%
return ReadVarint32Slow(value);
}
}
Los.15.1
int64 CodedInputStream::ReadVarint32Fallback(uint32 first_byte_or_zero) {
if (BufferSize() >= kMaxVarintBytes ||
// Optimization: We're also safe if the buffer is non-empty and it ends
// with a byte that would terminate a varint.
(buffer_end_ > buffer_ && !(buffer_end_[-1] & 0x80))) {
GOOGLE_DCHECK_NE(first_byte_or_zero, 0)
<< "Caller should provide us with *buffer_ when buffer is non-empty";
uint32 temp;
::std::pair<bool, const uint8*> p =
ReadVarint32FromArray(first_byte_or_zero, buffer_, &temp);
if (!p.first) return -1;
buffer_ = p.second;
return temp;
} else {
// Really slow case: we will incur the cost of an extra function call here,
// but moving this out of line reduces the size of this function, which
// improves the common case. In micro benchmarks, this is worth about 10-15%
uint32 temp;
return ReadVarint32Slow(&temp) ? static_cast<int64>(temp) : -1;
}
}
The function ReadVarint32Fallback is used in the following libraries :
vendor/sony/kitakami-common/proprietary/vendor/lib64/libsettings.so
vendor/sony/kitakami-common/proprietary/vendor/lib64/libcneapiclient.so
vendor/sony/kitakami-common/proprietary/vendor/lib/libsettings.so
vendor/sony/kitakami-common/proprietary/vendor/lib/libcneapiclient.so
vendor/sony/kitakami-common/proprietary/vendor/lib/mediadrm/libwvdrmengine.so
So i rolled back the functions required by the libraries in external/protobuf/src/google/protobuf/io/coded_stream.h, external/protobuf/src/google/protobuf/io/coded_stream.cc, attached a patch to get a bit farther .
I get the following error now.
Code:
520 F DEBUG : Abort message: 'CANNOT LINK EXECUTABLE "/system/bin/netmgrd": cannot locate symbol "_ZN6google8protobuf8internal14WireFormatLite10ReadStringEPNS0_2io16CodedInputStreamEPNSt3__112basic_stringIcNS6_11char_traitsIcEENS6_9allocatorIcEEEE" referenced by "/system/vendor/lib64/libcneapiclient.so"...'
I think the correct thing to do now is call ReadStringEPNS0_2io16CodedInputStreamEPNSt3__112basic_stringIcNS6_11char_traitsIcEENS6_9allocatorIcEEEE
░█████╗░██╗░░░██╗██████╗░░█████╗░░█████╗░░██████╗
██╔══██╗██║░░░██║██╔══██╗██╔══██╗██╔══██╗██╔════╝
███████║██║░░░██║██████╔╝███████║██║░░██║╚█████╗░
██╔══██║██║░░░██║██╔══██╗██╔══██║██║░░██║░╚═══██╗
██║░░██║╚██████╔╝██║░░██║██║░░██║╚█████╔╝██████╔╝
╚═╝░░╚═╝░╚═════╝░╚═╝░░╚═╝╚═╝░░╚═╝░╚════╝░╚═════╝░
By arnav-web
AuraOS Is A HTML Based Operating system made by Arnav-web on GitHub
// DETAILS //
This Operating system is based on Tiny10 by NTDEV which is a stripped-down version of windows 10 build 1809
It has an overlay of electron on the top
And yes this is also based on electron.js
// FEATURES //
• It Is As Lite as 4GB!
• It can be run on as lowest as a 10 year old PC (As Per My Testing)
• Very Modern UI
• Takes As little as 1GB RAM
• Its Open Source For Everyone!
// SCREENSHOTS //
ARE POSTED BELOW
// LINKS //
Website: https://arnav-web.github.io/arnavsoftwares.net
Repository: https://GitHub.com/arnav-web/auraos
GitHub profile: https://GitHub.com/arnav-web