WARNING: This won't work currently for the SM-G9730. I need a recovery.img(.lz4) from the latest firmware.
Here's a not-so-widely-tested fix for the spontaneous reboot that occurs after rooting the SM-G9750 and other Snapdragon S10 models.
tulth located this patch. If you read the description of that patch, it mentions a NULL pointer getting dereferenced in find_get_entry (such a thing tends to cause crashes in your average program, so when this happens in the kernel, it's not surprising that a crash and reset is the response). If you look at tulth's last_kmsg, my last_kmsg and G-ThGraf's last_kmsg from a G9730, you'll notice they all have one thing in common: SHTF at smaps_pte_range+0x29c. What's at that location on those devices' kernel? Why it's only find_get_entry(vma->vm_file. So yeah, it's the same bug, already known to Google and it's been fixed in their kernel tree since January. The bug is triggered externally by reading /proc/<pid>/smaps_rollup under certain conditions. You might be able to workaround this by disabling programs to get more free RAM, but The Only Way To Fix the Underlying Kernel Bug Is To Fix the Kernel Itself™.
We're probably not going to see a new kernel update until (if?) we get an update for the next major version of Android. We Snapdragon S10* users already have an older kernel compared to Exynos S10 owners (our 4.14.78 vs. their 4.14.85) and it's probably because of that they don't see this bug. So I think the idea of Samsung fixing this is a non-starter. While I did manage to build an SM-G9750 kernel from source (their instructions leave a lot to be desired) with that patch applied, I could not get my phone to boot the result.
I am not a programmer, but I do know just slightly enough to get the ball rolling and provide the fix that that aforementioned patch does in the opcode form that can be applied onto the existing kernel on the phone.
While I've not half-arsed it in the sense I took the easy way out (always having mss->check_shmem_swap set to zero is an easy one-liner workaround; however, freeing of unneeded SHM pages wouldn't happen, eventually causing your phone to crawl to a halt), I am not familiar with assembly language for any platform at all and, as such, I could not find a way to free up enough space in the show_smap function. So I jump quite far out into a chunk of the .text section where it's full of zeroes. I don't know anything about the ELF format to be able to tell you why this section of zeroes exists - I make the probably-wrong assumption it's perhaps a requirement of the ELF format if a linker that's very good at producing optimised code still bothers to output that or it's optimisation by alignment - but it's there and it's a good place to add extra code to on account of, you know, being empty and marked executable.
As far as I can see, where I have placed the code isn't referenced by anything else at all in the kernel but I can't be 100% certain on that. Nevertheless, I've been testing this on and off (I've had to manually initiate reboots in between for various reasons) myself for the past seven days or so and I've not noticed any adverse effects.
EDIT: Saying that, I think I'll try and move the code into load_module() when I get time because this kernel can't actually load modules (see below) thus much of the code there is pointless.The risk is yours, should you choose to apply this fix.
I would've liked to wrote this as a kernel module, being far easier to maintain, and hooked the relevant smap functions (in a similar vein to flar2's wp_mod and AleksJ's ric_mod) but thanks to the geniuses at Samsung, load_module() will always return early and the compiler accordingly realises it can optimise the function by excising all the code needed to actually load a module - there's no point in keeping unreachable code. Why Samsung bothered turning on mandatory module signing is beyond me because modules will never load! You can see this for yourself: insmod /system/vendor/lib/modules/wil6210.ko will always fail with "Exec format error", and that's a signed module built and shipped by Samsung themselves for their kernel. Anyway.
As long as the kernel version remains the same, it's likely, but not guaranteed, the same patches will work for future software updates from Samsung and all I'll have to do is update the compatibility list. If you try this on any other kernel version, the chances of not being able to boot are very high. The task of maintaining this doesn't enthuse me, but I'll continue to do so out of necessity, for I like having a rooted phone but not one that restarts at the worst of times.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I know people have reported longer uptimes than that on their phone before having a forced restart, but in my case, my phone has AOD enabled, the latest stable Magisk version installed and is running EdXposed. Before this fix, I've never seen an uptime longer than about 16 hours (usually less), regardless of whether the phone was in use or not, as getting multiple restarts in a day tends to have that effect.
As long as you only write to the recovery partition (and that's the only block device that this guide tells you to write to ), you should always be able to use Odin to reflash it to reverse this, the process being somewhat similar to flashing Magisk in the first place but with the notable exception of not needing to factory reset anything. The following flashing routine was adapted from Magisk, so my thanks to topjohnwu.
If someone has the bright idea of sharing their already-patched recovery.img because typing copy and pasting commands is hard, I'll point out the following: anybody flashing such an image should really make sure they're running the same firmware and Magisk version the image was designed for. (And after reading ianmacd's posts, topjohnwu supposedly doesn't like pre-patched images with Magisk being shared. I'll respect that, and so should you.)
I won't take any responsibility if this damages your phone. Perform the following at your own risk. If you agree, then:
If you haven't already, root the phone with Magisk. Make sure to keep a copy of the magisk_patched.tar somewhere on your computer so you can reflash it with ODIN if something goes wrong here. Always make sure Magisk is installed before modifying the recovery partition yourself. If you have a pending software update, install that with Odin and root that first before doing the following.
Set up ADB on your phone and computer
From your computer, adb shell into the phone
Run
Code:
uname -r
Only attempt to apply these patches if you get 4.14.78-16509050 back. For an older version, the bottom of this post has previous patches that may or may not apply. Or just update your phone.
Run
Code:
su
and then
Code:
rm -rf /data/local/tmp/q12kpwrk ; mkdir /data/local/tmp/q12kpwrk && cd /data/local/tmp/q12kpwrk
Run
Code:
mkdir recovery && cd recovery
Find the recovery partition on your phone by running:
Code:
recovery_blk="`readlink -f /dev/block/by-name/recovery`" ; [ -b "$recovery_blk" ] || echo "Eh, something's off here. Don't continue"
Dump it to a file by running:
Code:
dd if="$recovery_blk" of=recovery.img
Extract the kernel by running:
Code:
/data/adb/magisk/magiskboot unpack recovery.img || echo "Stop! Do not continue!"
If you see the warning message again on a new line, then stop.
Otherwise, if all went well with the step above (the message "Kernel is uncompressed or not a supported compressed type!" can be safely disregarded), then note that for any of these patches, if you don't get any matches or get more than one, then do not continue any further. Don't selectively apply any of these patches; it's all or nothing.
Apply the first patch by running:
Code:
/data/adb/magisk/magiskboot hexpatch kernel F7030032895240F9F64F00F9 F7030032FD10F997F64F00F9
Run
Code:
/data/adb/magisk/magiskboot hexpatch kernel 02000014C02E00F9E1630191 02000014ED10F997E1630191
If you have an SM-G9750/Snapdragon S10+: run
Code:
/data/adb/magisk/magiskboot hexpatch kernel F30300AAA1010035F40313AA750640F9890E41F83F7500F103010054AA02098BC10501B0407100D121B83191 F30300AA0D000014895240F9DF420239C0035FD600000000D22E40F94E02008BCE2E00F9C0035FD621B83191
OR if you have an SM-G9730/Snapdragon S10: there is currently no patch. Feel free to send me a recovery.img from the latest firmware and I'll adapt it
OR if you have an SM-G9700/Snapdragon S10e (thanks to Laikar_ for the recovery.img and testing): run
Code:
/data/adb/magisk/magiskboot hexpatch kernel F30300AAA1010035F40313AA750640F9890E41F83F7500F103010054AA02098BA10501D0407100D121B81D91 F30300AA0D000014895240F9DF420239C0035FD600000000D22E40F94E02008BCE2E00F9C0035FD621B81D91
Have the patched kernel placed into a new recovery image, new-boot.img, by running:
Code:
/data/adb/magisk/magiskboot repack recovery.img || echo "Stop! Do not continue!"
Check to see if new-boot.img isn't somehow larger than the recovery partition itself by running
Code:
[ `stat -c '%s' "new-boot.img"` -gt `blockdev --getsize64 "$recovery_blk"` ] && echo "Do not continue!"
Flash the new recovery image by running
Code:
cat new-boot.img /dev/zero >"$recovery_blk" 2>/dev/null
Run
Code:
sync ; sync ; sync ; reboot recovery
If the phone boots again, great! If you're stuck at the Samsung-only logo that fades in and out for many minutes, just restart the phone again whilst holding the recovery button combo to boot into Android with Magisk activated like normal.
You can rm -rf the /data/local/tmp/q12kpwrk folder afterwards to get some space back.
If your phone keeps restarting, or you automatically get put into semi-bootloader flashing mode, hold the bootloader button combo to get to the blue-background downloading mode and reflash magisk_patched.tar (and HOME_CSC) with Odin. If you didn't keep said file or a Magisk-patched recovery.img you can tar up with 7-Zip and get Odin to flash as AP, you'll need to download the latest firmware for your SM-G9750 with Frija or similar, reflash that and then follow the instructions to root your phone again with Magisk.
If you do get a reboot after applying this, looking at /proc/last_kmsg will indicate if it's something to do with this patch or something else entirely.
Q&A:
Q: Will I have to reapply this if I update Magisk from Magisk Manager with a direct install?
A: No.
Q: Will I have to reapply this if I update the phone's firmware?
A: Yes, but check the new kernel's version first and see if it's listed in the compatibility section. If not, then you'll need to wait for an update to this fix. And remember to make sure that Magisk is installed first before modifying the recovery partition yourself.
Q: I don't want to wait hours to see if my phone will restart out of the blue. How can I test for this bug?
A: A variation on the steps to reproduce here, you can do this:
Code:
su
dd if=/data/media/0/AP_G9750ZHU1ASF1_CL16082828_QB24224470_REV00_user_low_ship_MULTI_CERT_meta_OS9.tar.md5 of=/dev/shm # or any very large file (3-4 GB, /dev/urandom might work). This fills up the allocated space for shared memory
cat /proc/*/smaps_rollup
If your kernel isn't patched, restart your phone certainly does. (Of course, you should probably run reboot recovery anyway if not because a full SHM isn't really conducive to a well-running Android session.)
Q: Do you have any other kernel patches?
A: Just the one, only tested on the SM-G9750, and it seems to not be needed at all - it has no bearing on this specific reboot issue anyway. This one disables one aspect of RKP. Again, I don't think this is actually needed on the S10+ , but Magisk still attempts to patch for this issue indiscriminately (probably for the benefit of older devices), although its patch will not apply to our kernel.
Code:
/data/adb/magisk/magiskboot hexpatch kernel 1FA50F7143010054491540B93FA50F71E30000544B0940B97FA50F71830000544A1940B95FA10F7168090054 1FA10F71810A0054491540B93FA10F71200A00544B0940B97FA10F71C00900544A1940B95FA10F7161090054
Q: Are you a dirty GPL violator, qwerty12?
A: No! What I am providing is the compiled form of the patch linked to in the beginning of this thread. If you want to understand what this does in lovely C, just look at that patch. Of course, I have to deal with this on the assembler level, so there is no source per se, just dump all the hex strings into an online disassembler. The first two magiskboot hexpatch invocations replace two existing instructions with jumps into the new code I add. The third hexpatch invocation adds the additional code implementing the patch - the original replaced instruction is executed, along with the code I added to set mss->check_shmem_swap to zero before vma->vm_file is checked for != NULL and for shmem_swapped to be added to mss->swap instead of replacing it.
Patches for older kernels:
4.14.78-16082828:
Use Magisk Manager to install the Busybox Magisk module. No, this is not optional. You can use a version of Busybox from another source, but note that this is the version I have personally tested all this with. Restart your phone anyway if you already have it installed; you want your phone's running state to be as fresh as possible to avoid the possibility of running into this bug while attempting to fix it.
Code:
/data/adb/magisk/magiskboot hexpatch kernel F7030032895240F9F64F00F9 F70300327ED15494F64F00F9
Code:
/data/adb/magisk/magiskboot hexpatch kernel 02000014C02E00F9E1630191 020000146ED15494E1630191
Code:
printf '\x89\x52\x40\xF9\xDF\x42\x02\x39\xC0\x03\x5F\xD6\x00\x00\x00\x00\xD2\x2E\x40\xF9\x4E\x02\x00\x8B\xCE\x2E\x00\xF9\xC0\x03\x5F\xD6' | busybox dd of=kernel bs=1 seek="$((0x017F9AAC + 20))" conv=notrunc
The magiskboot hexpatch equivalent of this was too large, so I settled for writing to a hard coded offset.
I have random reboot... will try this patch tomorrow.
Sent from my SM-G9750 using Tapatalk
Hi... already doing your patches... i thinks succesfully, because i dont have any error, and boot normally after last command.
So.... i have to wait if random reboot appear right ? *to test*
Thank you... will report in about 3 days
Hi,
Vuska said:
So.... i have to wait if random reboot appear right ? *to test*
Click to expand...
Click to collapse
You can run the commands under "Q: I don't want to wait hours to see if my phone will restart out of the blue. How can I test for this bug?" in the first post. If your phone restarts automatically when running cat, then your phone is still susceptible to restarting itself during use.
If it doesn't restart, then you need to run reboot recovery yourself immediately, but it means the fix was successfully applied.
PS D:\S10+\ADB platform-tools> ./adb devices
List of devices attached
R28M31K3DNZ device
PS D:\S10+\ADB platform-tools> ./adb shell
beyond2q:/ $ su
Permission denied
1|beyond2q:/ $
?????
N1ldo said:
PS D:\S10+\ADB platform-tools> ./adb devices
List of devices attached
R28M31K3DNZ device
PS D:\S10+\ADB platform-tools> ./adb shell
beyond2q:/ $ su
Permission denied
1|beyond2q:/ $
?????
Click to expand...
Click to collapse
do you already install busybox via magisk ? also there will be a pop up in your device to request access from computer. accept it
already enable usb debugging in developer menu ?
permission denied .... [emoji848] .. strange... already rooted right ?
Sent from my SM-G9750 using Tapatalk
Vuska said:
do you already install busybox via magisk ? also there will be a pop up in your device to request access from computer. accept it
already enable usb debugging in developer menu ?
permission denied .... [emoji848] .. strange... already rooted right ?
Sent from my SM-G9750 using Tapatalk
Click to expand...
Click to collapse
Yes.
As you can see in the prints below.
i try install another busybox to.
N1ldo said:
beyond2q:/ $ su
Permission denied
1|beyond2q:/ $
?????
Click to expand...
Click to collapse
Check your Magisk settings to see if you haven't turned off ADB superuser access and your apps list for a denied Shell entry.
qwerty12 said:
Check your Magisk settings to see if you haven't turned off ADB superuser access and your apps list for a denied Shell entry.
Click to expand...
Click to collapse
Thank you all ...:good::good:
Yes Shell was unauthorized root on Magisk application list :victory:
3 days now.... i can say it successfully fixed.... [emoji106][emoji106]
Thank you.
hope you will update too when new firmware arrives....
because i dont understand some code mean.... just follow and copy paste
Sent from my SM-G9750 using Tapatalk
*ASG7 firmware is out
I can provide a recovery.img from s10e (smg9700), also any way i can contact you for some help about building the kernel? I have been trying to do with s10e's one and i'm not having much success
FlatOutRU said:
*ASG7 firmware is out
Click to expand...
Click to collapse
Downloading...
is ASG7 can use this patches ?
Sent from my SM-G9750 using Tapatalk
FlatOutRU said:
*ASG7 firmware is out
Click to expand...
Click to collapse
Vuska said:
s ASG7 can use this patches ?
Click to expand...
Click to collapse
I'll download the update later and give it a once-over; however, I'll quote myself:
qwerty12 said:
As long as the kernel version remains the same, it's likely, but not guaranteed, the same patches will work for future software updates from Samsung and all I'll have to do is update the compatibility list.
Click to expand...
Click to collapse
Laikar_ said:
I can provide a recovery.img from s10e (smg9700), also any way i can contact you for some help about building the kernel? I have been trying to do with s10e's one and i'm not having much success
Click to expand...
Click to collapse
That would be appreciated, thanks. I can move the S10e into the "Patch not tested" section of the compatibility list.
I wish you'd have asked me this a few days ago, I deleted the kernel tree I had on my disk because I thought a new source ZIP from Samsung would be forthcoming for the new firmware. I'd've just attached a diff...
I did get the kernel to build but I could not get the result to boot. Some of the compiler warnings displayed during build didn't make it seem like I was going to get a working kernel image. I'll get back to you soon with some steps
qwerty12 said:
That would be appreciated, thanks. I can move the S10e into the "Patch not tested" section of the compatibility list.
I wish you'd have asked me this a few days ago, I deleted the kernel tree I had on my disk because I thought a new source ZIP from Samsung would be forthcoming for the new firmware. I'd've just attached a diff...
I did get the kernel to build but I could not get the result to boot. Some of the compiler warnings displayed during build didn't make it seem like I was going to get a working kernel image. I'll get back to you soon with some steps
Click to expand...
Click to collapse
I can't post links yet, tinyurl(dot)com/y537462u for the drive download link
Does EdXposed work for G9750?
qwerty12 said:
I'll download the update later and give it a once-over; however, I'll quote myself:
Click to expand...
Click to collapse
Its changed a bit
kakahoho said:
Does EdXposed work for G9750?
Click to expand...
Click to collapse
Yes.
FlatOutRU said:
Its changed a bit
Click to expand...
Click to collapse
Good call; there's now code at 0x017F9AAC + 20, probably not a good idea to overwrite that...
I was hoping the newer build date might have meant that Samsung applied the patch, meaning I could abandon this thread, but no such luck: I did the quick writing to /dev/shm test and my phone kernel panicked. Lovely.
I've updated the first thread with an updated patch. I followed through with my plan of moving my extra code into load_module() instead of the empty section of zeros as, thanks to Samsung's kernel developers' ineptness, that function will always fail - may as well make it early return and then use the extra space gained to store my code in.
Laikar_ said:
I can't post links yet, tinyurl(dot)com/y537462u for the drive download link
Click to expand...
Click to collapse
Thanks for the S10e recovery image, Laikar_. I've checked the recovery image's kernel and moved the S10e into the "Patch not tested" section. I'll write up some steps soon on building a kernel that won't boot
Anyway,
The S10 and S10e recovery images are not from ASG7, however, so I don't know if my newer patch applies to it but my old ones do. I think my newer one will do, too, but that's an educated guess.
Just like with the S10, anybody's welcome to try this on their S10e and let me know of the result.
qwerty12 said:
Yes.
Good call; there's now code at 0x017F9AAC + 20, probably not a good idea to overwrite that...
I was hoping the newer build date might have meant that Samsung applied the patch, meaning I could abandon this thread, but no such luck: I did the quick writing to /dev/shm test and my phone kernel panicked. Lovely.
I've updated the first thread with an updated patch. I followed through with my plan of moving my extra code into load_module() instead of the empty section of zeros as, thanks to Samsung's brainiac developers, that function will always fail - may as well make it early return and then use the extra space gained to store my code in.
Thanks for the S10e recovery image, Laikar_. I've checked the recovery image's kernel and moved the S10e into the "Patch not tested" section. I'll write up some steps soon on building a kernel that won't boot
Anyway,
The S10 and S10e recovery images are not from ASG7, however, so I don't know if my newer patch applies to it but my old ones do. I think my newer one will do, too, but that's an educated guess.
Just like with the S10, anybody's welcome to try this on their S10e and let me know of the result.
Click to expand...
Click to collapse
so the first post already update to 050 kernel right ?
mean after i updated my s10+ magisk etc.. i can do that all steps right ?
cool...
still not yet finished my download since yesterday... my internet down.. [emoji2357]
Sent from my SM-G9750 using Tapatalk
Vuska said:
so the first post already update to 050 kernel right ?
mean after i updated my s10+ magisk etc.. i can do that all steps right ?
Click to expand...
Click to collapse
Yep, the first post is updated for ASG7. Those steps are working on my SM-G9750 running it, anyway
Laikar_ said:
[...]any way i can contact you for some help about building the kernel? I have been trying to do with s10e's one and i'm not having much success
Click to expand...
Click to collapse
I'll mention again that I couldn't get the result to boot. If you work it out, please let me know. I hate loading kernel images into a disassembler
I did this on a Ubuntu 18.04.2 minimal installation. I figure that if you want to build a kernel then you, like me, have at least a working familiarity with GNU/Linux, so I won't go too in-depth.
First, install the packages needed to build:
Code:
sudo apt install git-core gnupg flex bison gperf build-essential zip zlib1g-dev libxml2-utils xsltproc unzip python bc libssl-dev
Download the toolchain mentioned in README_kernel.txt:
Code:
git clone --depth=1 https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9
Download Snapdragon LLVM Compiler for Android v6.0.9 - Linux64 from https://developer.qualcomm.com/software/snapdragon-llvm-compiler-android/tools and untar it somewhere on your system. (This isn't actually the exact compiler Samsung use - if you look at /proc/version on your phone, you'll see it says 6.0.10 - but this is the closest we mere mortals will get.)
Download the source code zip from Samsung and untar Kernel.tar.gz into a newly-created folder. Inside said folder, run chmod 644 Makefile ; chmod 755 build_kernel.sh.
Open build_kernel.sh in your favourite editor. Make the following changes:
Set BUILD_CROSS_COMPILE to the folder where aarch64-linux-android-gcc, aarch64-linux-android-ld etc. are after cloning from git. Make sure to leave the aarch64-linux-android- suffix at the end. For me, this line looks like this:
Code:
BUILD_CROSS_COMPILE=/home/fp/x/aarch64-linux-android-4.9/bin/aarch64-linux-android-
KERNEL_LLVM_BIN needs to be set to the location of the Clang binary downloaded from Qualcomm. For me, this line looks like this:
Code:
KERNEL_LLVM_BIN=/home/fp/x/93270/toolchains/llvm-Snapdragon_LLVM_for_Android_6.0/prebuilt/linux-x86_64/bin/clang
After both REAL_CC=$KERNEL_LLVM_BIN instances add
Code:
CFP_CC=$KERNEL_LLVM_BIN
(although I think this is the wrong way to do it, consider just disabling CONFIG_RKP_CFP)
Open the Makefile in your favourite editor. Find the following line
Code:
@echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
$(stackp-flag) not supported by compiler >&2 && exit 1
Remove the "&& exit 1". The proper way to fix this would be to set CONFIG_CC_STACKPROTECTOR_STRONG to n in the config file; however if you run clang --help, you'll see that -fstack-protector-strong is actually supported. Why turn off a useful security feature?
Run build_kernel.sh and the kernel should build (albeit with a metric crap-ton of warnings, which is just one reason why it's not surprising the resulting kernel won't boot)
Related
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
The remainder of this post contains historical information. Please read the update. Thank you.
__________________
BotBrew is
a repository of *nix software (such as bzip2, curl, openssl, python, and ruby) for ARM-based Android
a package manager powered by Opkg, a lightweight program that feels like dpkg+apt
a service manager powered by runit
a build system for anyone looking to build and package his/her own scripts and programs
Thanks: mateorod and xela92 for testing the heck out of this thing; racks11479 for delicious artwork; you for using this project, reporting bugs, and making it better
If I missed anyone, let me know!
Warning: BotBrew has been used successfully on a variety of rooted ARM devices, and is developed using a Nook Color, but you should still make backups before trying, just in case.
Install BotBrew
[ Google Play | BotBrew.apk | BotBrew.debug.apk ]
Read the Quick-Start Guide & Manual
[ botbrew.com/manual.htm ]
Click to expand...
Click to collapse
Alternative (Command Line) Installation
If the BotBrew app fails to bootstrap, you might be able to bootstrap using the command line:
Code:
wget http://repo.botbrew.com/anise/bootstrap/install.sh -O- | su
Such a setup should be compatible with the app, though it may not work perfectly. The manual has more tips for command line usage.
Enjoy!
Install BotBrew+1
The next release of BotBrew, named basil, will be powered by Debian's Dpkg and Apt. This is a non-trivial update, so the app is being rewritten from scratch. I've posted some usage instructions, in case you are adventurous enough to try. Thanks! This app may be used in parallel with the current-stable BotBrew release, without conflict.
[ Google Play | GitHub ]
Click to expand...
Click to collapse
Changes
5/20: the next release of BotBrew is in development!
4/20: improve support for long package names; fix list of repairable packages
4/16: new UI for devices with wide-enough screens; experimental support for moving to /sd-ext
4/9: Google Play release of BotBrew "anise"; previous release is now BotBrew.oldstable.apk; lots of updates since oldstable
3/16: lots of installer and filesystem changes for cross-device compatibility, work started on multiuser support
3/10: installers now depend on botbrew-core, which will (in the future) pull in basic packages that everyone should have
3/4: swipe left and right to see all/installed/upgradable packages
3/3: added ability to start installation of *.opk files from file managers
3/2: added ability to start installation from browser after clicking *.opk link
3/1: fixed some BotBrew.apk bugs; updated command line installer
2/27: reworked BotBrew.apk; new packages in stable repo
2/18: testing repository now open; new opkg -- please read before upgrading
2/16: make BotBrew.apk display latest versions in the package list
2/2: bugfix release of BotBrew.apk
Well, I now have python, ncurses, openssl and a couple other packages running on my nook. I have indeed printed 42, and even wrote my own (proprietary) code to advance the project some that printed 43. Advanced scripting.
But seriously, this is sweet. I am all over anything that opens up this device. I don't think I have ever bought a piece of hardware that has so outstripped my expectations.
Thanks for the program. I will report back after I play with it some.
Wow, what a great idea! Looks like my Nook will be used for a bit more than entertaining my family with casual games; nice to have some productivity back I was thinking about installing Ubuntu on my Nook for this sort of thing, but there's no need anymore.
It would be great to get this a bit more recognition, and getting more useful things such as gcc or even the GNU toolchain installable with this package manager. Might put a link in my signature, if you don't mind.
Now to look for an affordable lightweight bluetooth keyboard...
You read my mind I got binutils, gmp, mpfr, and mpc working earlier today... and gcc is in the pipeline. My main reason for wanting a native gcc is that some software (such as python) do not like to be cross-compiled at all. I'm having a bit of trouble with gcc, but I'll keep hacking away at it.
Please, go right ahead and share this thread; this is a young project but I think it could be more useful. On the one hand, there's a whole lot of free software (such as the GNU stuff) just asking to be built and packaged; on the other hand, many people who hang out around here have a few scripts/programs of our own to distribute.
In case you're interested, here's where all the packages live. There are actually two more ways to install (remote and local) stuff using Opkg:
Code:
opkg install http://host/path/to/package.opk
Code:
opkg install path/to/package.opk
Very nice project !!!
I have python 2.7 standalone on android.
One problem, in python commandline i can't import hashlib, i can fix this?
Thanks.
So, I just got a working build of GCC+binutils and pushed the packages to the stable repo. Please keep in mind that for now, stable means I tested it a couple of times and it works, so be careful and use at your own risk.
To install gcc and binutils, make sure you have about 160mb of storage free in /system and run:
Code:
opkg update
opkg install gcc-4.6
That's about 70mb's worth of downloads, and my server's underpowered, so please wait patiently and retry if it fails (failure when receiving data from the peer). When that's done, you might want to compile something:
Code:
cd /cache
wget http://dl.dropbox.com/u/1213413/htdocs/agcc/hello.c
gcc -o hello hello.c
And if that completed successfully, you should have a new executable, which you could run for a classic greeting. I was not able to get the C++ libraries compiled, but C code should compile alright.
@Fritos2: I've been trying to fix this issue, but I'm not confident that I could do it without help. Python (and Perl) are very resistant to cross-compilation, and even after I hammered it into submission, some modules do not work. Another module that I'd really like is readline, which gives you enhanced editing capabilities in the interactive interpreter. I'm a Pythonista, but I've got to say: Ruby does cross-building right. Even sqlite3 supports readline. I suspect that Python might have to be compiled natively, and this is where native gcc comes in.
I'd appreciate any help, of course
I'll follow this project with great interesting.
Hey guys, there have been a few updates:
opkg's lock file has been moved to /cache/opkg/lock so there's no need for a read-write /system just to query packages
gnupg has been packaged, for those who like to sign their stuff
python... well, I'm still working on it >.<
Anyway, I thought I'd do something to make this project more accessible. I don't have any apk's for you yet, but I've attached a screenshot of the work-in-progress
I am very impressed with the progress. I am a super-noob but have enjoyed toying with the packages from your opening post. I haven't had time to do much but explore, but this sure does open up a whole new world for the nook, from an accessability stand point alone. I wouldn't be suorised to see an uptick in interest as some if the more experienced coders are able to turn their attention from cm9.
I will probably install those latest packages sometime this weekend. Just real strong stuff.
Edit. Ok, o I just went ahead and did it now. Obviously, I couldn't get it to work. Have downloaded the FCC and got the hello file fro the dropbox. I ran the gcc -o hello hello.c and was returned a hashtag only. If I ran gcc hello, it outputted the hello program code. I tried several things basically willynilly until I got tired of getting a fatal error and having the build canceled.
If this is too basic and will clog the thread, I would happily accept a pm with a good tutorial. Thanks a bunch.
The problem with python maybe relationed with python-devel package?
Sorry is the question is stupid, i'm so noob.
The Python build process has two steps: first, you get the main Python executable, and then you get the modules. The executable built in the first step is used to test the modules in the second step. So, naively cross-compiling Python would result in most modules not passing the test (because you cannot actually run the Python you just built), and these modules would be removed. As it turns out, you could patch the build scripts to run the tests using a host-native Python, but even then, there are a few modules with particular requirements that still don't pass. This is where we are now, but I think we could do better.
Okay, so more progress: BotBrew.apk is out in the wild! I decided to put it off until I got some basic functionality working. What is this?
a basic GUI for package management
lists all packages
searches for packages by name
shows package information
installs/upgrades/removes packages
manages list of repositories
I've only really tested it with CM7, but it works on the latest CM9 previews as well.
Screenshots
mateorod said:
Edit. Ok, o I just went ahead and did it now. Obviously, I couldn't get it to work. Have downloaded the FCC and got the hello file fro the dropbox. I ran the gcc -o hello hello.c and was returned a hashtag only. If I ran gcc hello, it outputted the hello program code. I tried several things basically willynilly until I got tired of getting a fatal error and having the build canceled.
Click to expand...
Click to collapse
No worries. If gcc did not complain and dropped you back in the shell, this means it's done! Just list the directory to find a new file named hello, which you could run:
Code:
# gcc -o hello hello.c
# ls
backup download hello.c opkg
dalvik-cache hello lost+found recovery
# ./hello
hello world
#
I hope this helps!
Sorry if this sounds ignorant but is there any future usage aside from being a very interesting project? Will we be able to distribute open source projects / software specifically made for Android devices like on common Linux distributions?
BobbyBest said:
Sorry if this sounds ignorant but is there any future usage aside from being a very interesting project? Will we be able to distribute open source projects / software specifically made for Android devices like on common Linux distributions?
Click to expand...
Click to collapse
A valid question, I think. BotBrew has the potential of becoming a Cydia of sorts, distributing system extensions, interface customizations, and other useful software for rooted Android devices. Android has a vibrant community of programmers and scripters, but there isn't any standard way to manage software that are not apps. And there's a large body of open source Linux software that might work well on Android. Of course, BotBrew is also able to handle root apps that live in /system/app (i.e. gapps); for user-level apps, the various app stores already work quite well.
In order for this to become a serious platform, we'll need a couple of things: a solid technical foundation, developer support, and a user base. I've been making progress mostly towards the first point; hopefully the rest would follow.
Well I'll be. Yeah it worked. Who knew?
Okay, so that's great! I have printed 43 (my own design) and now the standard greeting has been successfully built and ran as well. I must toodle with it some more. What would you recommend to try? Remember, i am slow-witted and totally inexperienced.
If you say print 44 i will totally understand. : )
How about this, i would like to learn and i would like to help you with your program. I will probably be of most use as a guinea pig, but since i spend a fair amount of time jiggering system files and databases, I have to complete wipe about once a week. failure or risk doesn't bother me.
---------- Post added at 02:27 AM ---------- Previous post was at 01:51 AM ----------
Okay, i just got the apk. I autoremoved all installed packages. I installed opkg, python, gcc (binutils came along as a dependency) and the hello executable. But when i went into a terminal once i cd cache, it only lists opkg out of the five packages. This worked when i did the wget through the terminal. The packages show as installed within the botbrew app (nice icon and UI, btw).
I known I am doing something very simple incorrectly. Do you have enough information to be able to tell me what that is?
Congrats on a successful build! Now that you have a working program, you could package it up for distribution
What's more, you could do it directly on Android. Let's call this package mateorod-hello, prefixing it with the vendor's (your) name to avoid conflicts with other variants. We'll also rename the executable itself.
We'll install the program to /system/bin, where it would feel at home with all the other programs; so we create a staging directory tree that mimics the structure of an Android system, but contains just the one program:
Code:
cd /cache
mkdir -p system/bin
cp hello system/bin/mateorod-hello
Next, we need a control file to describe what's in the package. It might be easier to create the file on a computer and push it over, but we could also create it using the command line:
Code:
echo "Package: mateorod-hello" > control
echo "Version: 1.0" >> control
echo "Architecture: armeabi" >> control
echo "Description: a greeting from mateorod" >> control
And, finally, a magic value to signify what kind of package this is:
Code:
echo -n "2.0" > debian-binary
Okay, now let's pack this up:
Code:
tar zcvf data.tar.gz system
tar zcvf control.tar.gz control
ar -r mateorod-hello.opk debian-binary data.tar.gz control.tar.gz
We now have mateorod-hello.opk, which we could test by installing:
Code:
opkg install mateorod-hello.opk
Now that it's installed, the program within is also available:
Code:
mateorod-hello
This is quite a bit of work for something that could just be pushed over adb, but it could be automated and it works tremendously well for more complex software. The control file helps keep track of versions, and lets you specify dependencies too.
Oh, and to clean up a bit: (the first command makes sure you're in /cache and do not accidentally erase /system)
Code:
cd /cache
rm -r system control data.tar.gz control.tar.gz debian-binary
/edit:
mateorod said:
But when i went into a terminal once i cd cache, it only lists opkg out of the five packages. This worked when i did the wget through the terminal. The packages show as installed within the botbrew app (nice icon and UI, btw).
Click to expand...
Click to collapse
What did you do, cd /cache then ls? If so, you're most likely looking at the /cache/opkg directory, which contains temporary data. If you want to see what's installed using the command line, try opkg list-installed
I uh... picked a random icon I had lying around, and I plan to swap it out when I have time to make one. Thanks, though :3
The amount of help you're offering is just staggering. I will put the above together tonight and will report back.
I have a bug here in the GUI.
Rotation makes the app start looking for updates again.
edit: Reentering does the same...
opkg has then problems with set locks.
(CM7 KANG by MiRaGe)
Currently trying to install gcc to compile and run a small program...
edit2: gcc-4.6 installed. Still trying to compile a small prog. Will continue tomorrow...
Edit3: Well, problem with GUI fixed itself somehow.
Still, maybe you should check out how the GUI behaves during the installation process when rotated.
Yes, I can see how this bug could occur, and it should only happen during the first run. When the package cache is empty, the app tries to update by itself, and it seems that rotation causes something to restart. I've uploaded an update, which hopefully fixes this issue. Thanks for the report.
/edit:
Bug fixed for real. You may now rotate with impunity. Man, why can't Android have sensible defaults?
Okay, took me awhile, but...
$ export PATH=/data/local/bin:$PATH:.
$su
# cd cache/
# wget http://dl.dropbox.com/u/1213413/htdocs/agcc/hello.c
Connecting to dl.dropbox.com (174.129.218.194:80)
hello.c 100% |************************************| 93 0:00:00 ETA
# gcc -o hello hello.c
#ls
dalvik-cache hello lost+found recovery
download hello.c opkg
# ./hello
hello world
#mkdir -p system/bin
# cp hello system/bin/mateo-hello
#echo "Package: mateo-hello" > control
#echo "Version: 1.0" >> control
#echo "Architecture: armeabi" >> control
# echo "Description: a word from Mateo" >> control
#echo -n "2.0" > debian-binary
# tar zcvf data.tar.gz system
system/
system/bin/
system/bin/mateo-hello
# tar zcvf control.tar.gz control
control
# ar -r mateo-hello.opk debian-binary data.tar.gz control.tar.gz
ar: creating mateo-hello.opk
#opkg install mateo-hello.opk
Installing mateo-hello (1.0) to root...
Collected errors:
Two sets of collected errors related to system not being mounted R/W excised
Installing mateo-hello (1.0) to root...
Configuring mateo-hello.
#mateo-hello
hello world
#
So there it is. I just followed your more-then-generous guide, with some phrasing changes to show i didn't just copy/paste.
Some notes from the inexperienced:
-As you can see, I had to use the wget command to work on the hello.c script. I had hello as an installed package through the Botbrew GUI already, but no matter what permutation of hello command I ran, gcc would not recognize it as an input file. Just to say that your guide to the initial build, as written, i don't think will work for anyone who installs the packages through the apk. I don't know the solution, but i bet it's simple.
Edit: I guess the package you get through your apk is a fully built executable? I hadn't gone through the later steps when I first tried to build it, so I never thought to simply enter "hello". Output a much fancier greeting then the one I built. Capital letters and an exclamation mark! Very nice.
- For other newbies- make sure that system is mounted R/W through root explorer or some such. And if you employ a firewall, if you intend to use the wget command, not only do you need to allow your terminal through, you also need to allow applications running as root! I am sure this is news to no one, but it cost me FOREVER!
I feel like this constitutes progress. Thanks for all the work!
Introduction:
The padfone X was released last friday and I wanted TWRP. As you may know; @Dees_Troy is on vacation. So, I hacked together this "repack" version which should have all features in order. One caveat with this version though, when launching recovery after it's installed, the screen must time out (2-minutes) before you can push power and see it.
Warning:
Even though you may simply be using your device and just running apps, you are modifying your device. There is no 100% back to stock. You can find a fastboot flashable stock recovery here, but there is no stock system. While this mod did not trigger a "modified status" on my device, I cannot guarantee the same for you. This is a very new device and unless you're one of the few, brave and anxious, it may be in your best interest to wait until a stock firmware update, back-to-stock flash, or even an official XDA-Developers forum has been created for this device.
you will need:
1.The Unofficial TWRP recovery image
2.SuperSU installed on your device
3.TowelRoot installed on your device. You will need to enable third-party sources.
4.Terminal access (pick the one you're more comfortable with)
4a.ADB
4b.Terminal emulator
installation:
If you chose to use ADB, then use these ADB Instructions. Otherwise skip down to Terminal Emulator Instructions.
ADB Instructions
Ensure you have installed SuperSU and TowelRoot.
Launch the TowelRoot app, follow instructions, and let it reboot your device.
navigate to the folder you downloaded ADB (and dll's if you're on windows) and execute the following command.
Code:
adb shell "curl 'https://builds.casual-dev.com/files/Asus/Padfone%20X/TWRP-Nexus5repack-AO1.img'>/sdcard/recovery.img; su -c 'dd if=/sdcard/recovery.img of=/dev/block/platform/msm_sdcc.1/by-name/recovery' bs=4096; sync; reboot recovery;"
check your device for any pop-ups and grant root access to shell.
wait 2 minutes after the screen is black, and then press power button. This is due to a difference between Nexus5 and PadfoneX which will be fixed in an official version later.
Terminal Emulator Instructions
Ensure you have installed SuperSU and TowelRoot.
Launch the TowelRoot app, follow instructions, and let it reboot your device.
Launch Terminal Emulator and copy-pasta the following into it.
Code:
curl 'https://builds.casual-dev.com/files/Asus/Padfone%20X/TWRP-Nexus5repack-AO1.img'>/sdcard/TWRPrecovery.img; su -c 'dd if=/sdcard/TWRPrecovery.img of=/dev/block/platform/msm_sdcc.1/by-name/recovery' bs=4096; sync; reboot recovery;
check your device for any pop-ups and grant root access to shell.
wait 2 minutes after the screen is black, and then press power button. This is due to a difference between Nexus5 and PadfoneX which will be fixed in an official version later.
Conclusion
Congratulations, you've got TWRP installed on your device. Now you can back up, restore, and install TWRP Flashable Zips. Please leave a comment and tell others how it worked. This worked great for me, Image below.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
@Dees_Troy has a helpful suggestion:
Might be worth mentioning Settings -> Screen and lower the screen timeout to help get the screen up and running sooner
Whatever you do, don't turn off the screen timeout though
Click to expand...
Click to collapse
By turning down the screen timeout you only need to wait for two minutes, one time. Turn it down to 30 seconds to reduce the wait time.
Again, this is temporary for this unofficial build. I will update these instructions later when we have a proper solution to perform the needed hardware reset.
I can't wait to see development for this phone!!!! Thank you for all your hard work.
This is great, now all we need is a device thread.
What do we need to do , in order to get that going ? this device has great potential !!!
Adam have you put on the screen protector i saw you bought from ATT? i can't figure out how to properly place it because very time i go into tablet mode and i pull the phone out the phone protector always has a bubble or two from sticking to the tablet ... not sure if that makes sense lol
AdamOutler said:
Introduction:
The padfone X was released last friday and I wanted TWRP. As you may know; @Dees_Troy is on vacation. So, I hacked together this "repack" version which should have all features in order. One caveat with this version though, when launching recovery after it's installed, the screen must time out (2-minutes) before you can push power and see it.
Warning:
Even though you may simply be using your device and just running apps, you are modifying your device. There is no 100% back to stock. You can find a fastboot flashable stock recovery here, but there is no stock system. While this mod did not trigger a "modified status" on my device, I cannot guarantee the same for you. This is a very new device and unless you're one of the few, brave and anxious, it may be in your best interest to wait until a stock firmware update, back-to-stock flash, or even an official XDA-Developers forum has been created for this device.
you will need:
1.The Unofficial TWRP recovery image
2.SuperSU installed on your device
3.TowelRoot installed on your device. You will need to enable third-party sources.
4.Terminal access (pick the one you're more comfortable with)
4a.ADB
4b.Terminal emulator
installation:
If you chose to use ADB, then use these ADB Instructions. Otherwise skip down to Terminal Emulator Instructions.
ADB Instructions
Ensure you have installed SuperSU and TowelRoot.
Launch the TowelRoot app, follow instructions, and let it reboot your device.
navigate to the folder you downloaded ADB (and dll's if you're on windows) and execute the following command.
Code:
adb shell "curl 'http://builds.casual-dev.com/files/Asus/Padfone%20X/TWRP-Nexus5repack-AO1.img'>/sdcard/recovery.img; su -c 'dd if=/sdcard/recovery.img of=/dev/block/platform/msm_sdcc.1/by-name/recovery' bs=4096; sync; reboot recovery;"
check your device for any pop-ups and grant root access to shell.
wait 2 minutes after the screen is black, and then press power button. This is due to a difference between Nexus5 and PadfoneX which will be fixed in an official version later.
Terminal Emulator Instructions
Ensure you have installed SuperSU and TowelRoot.
Launch the TowelRoot app, follow instructions, and let it reboot your device.
Launch Terminal Emulator and copy-pasta the following into it.
Code:
curl 'http://builds.casual-dev.com/files/Asus/Padfone%20X/TWRP-Nexus5repack-AO1.img'>/sdcard/TWRPrecovery.img; su -c 'dd if=/sdcard/TWRPrecovery.img of=/dev/block/platform/msm_sdcc.1/by-name/recovery' bs=4096; sync; reboot recovery;
check your device for any pop-ups and grant root access to shell.
wait 2 minutes after the screen is black, and then press power button. This is due to a difference between Nexus5 and PadfoneX which will be fixed in an official version later.
Click to expand...
Click to collapse
Didn't work for me. Just look like in TE it kept looking for a response back from the server. I tried to download the img manually and looks like the server is down or something.
FUZER384 said:
Didn't work for me. Just look like in TE it kept looking for a response back from the server. I tried to download the img manually and looks like the server is down or something.
Click to expand...
Click to collapse
It's working now. Server was, in-fact down earlier.
As they (nearly) share the same hardware, do you think it would be possible to compile a working recovery from Asus PadFone Infinity 2 (A86) sources?
Here is a link: http://www.asus.com/Tablets_Mobile/The_new_PadFone_Infinity/HelpDesk_Download/
(or: http://dlcdnet.asus.com/pub/ASUS/Mo...dFone_Infinity/PadFoneT004-1012394-kernel.zip for a direct link)
As Asus has not released PFX kernel sources on their site, I think it could be useful.
Demazda said:
As they (nearly) share the same hardware, do you think it would be possible to compile a working recovery from Asus PadFone Infinity 2 (A86) sources?
Here is a link: http://www.asus.com/Tablets_Mobile/The_new_PadFone_Infinity/HelpDesk_Download/
(or: http://dlcdnet.asus.com/pub/ASUS/Mo...dFone_Infinity/PadFoneT004-1012394-kernel.zip for a direct link)
As Asus has not released PFX kernel sources on their site, I think it could be useful.
Click to expand...
Click to collapse
Not without a device in-hand. I won't try to troubleshoot without it.
However, I use mkbootimg_tools and it requires a Linux system, not windows.
to get reccovery.img
Code:
adb shell su -C dd if=/dev/block/platform/*/by-name/recovery of=/sdcard/recovery.img
adb pull /sdcard/recovery.img
to uncompile original boot.img
Code:
mkboot recovery.img oringialoutput
this opens recovery.img and creates a ramdisk from it which you can freely edit. Now, do the same with TWRPRecovery.img
you will copy the following folders from the TWRP ramdisk to the originaloutput ramdisk. but heed the notes here.
/sbin -- replace only recovery, but copy all files over to the new device.
/res and /etc -- do not replace files, but add in TWRP files to this and its subdirectories.
/supersu -- this does not exist on the new ramdisk, so just copy it.
you will have to navigate to originalrecovery/ramdisk/system, then copy /system/bin into /sbin, then delete /system/bin, finally link /system/bin to /sbin. the positioning is important and you cannot use fully qualified paths to link the files here. it must be linked to ../sbin, specifying one folder up, a folder called "sbin", not /home/username/whatever...
Code:
cd originalramdisk/system/
cp ./bin/* ..//sbin
rm -rf ./bin
ln -s ../sbin
And then you're ready to repack.
Code:
mkboot originalramdisk myNewRecovery.img[code]
now you can copy myNewRecovery.img to your SDCard and flash it using the DD method I showed in the OP.
Oh, I thought you had the device, my bad.
Also, sorry, this may be off-topic (but still related to PadFone and development), but how hard do you think it would be to port CyanogenMod to a PadFone? Not for the PadFone X but for another one, knowing that I managed to build a recovery from source and that it's working, but that I've never managed to make the compiled rom itself boot?
Demazda said:
Oh, I thought you had the device, my bad.
Also, sorry, this may be off-topic (but still related to PadFone and development), but how hard do you think it would be to port CyanogenMod to a PadFone? Not for the PadFone X but for another one, knowing that I managed to build a recovery from source and that it's working, but that I've never managed to make the compiled rom itself boot?
Click to expand...
Click to collapse
This is a Padfone X forum. I can't help you any more than I have. Locate a developer with a Padfone 2 and ask him questions. I gave you instructions to try to create your own. I cannot do more.
AdamOutler said:
This is a Padfone X forum. I can't help you any more than I have. Locate a developer with a Padfone 2 and ask him questions. I gave you instructions to try to create your own. I cannot do more.
Click to expand...
Click to collapse
It's for the PadFone Infinity and I already have a CWM working, my question was about building a ROM. Also it seems that no developer has this device, as it's never beed released in the US.
But no problem, thanks anyway.
Also, sorry but I might not have said it properly in my first post: I did not ask you to build a recovery PadFone Infinity 2 (I don't have this device), I just gave you the kernel source because I thought it could help you build a PadFone X recovery from those sources, as they are both similar in hardware and from the same manufacturer.
Can anyone tell me how to build a cwm recovery for Asus Zenfone 5 ?
I cant take the recovery.img from my system ...
So I seem to have really screwed something up with a few features by trying to save space by integrating various GApps updates to the ROM. I cannot get a keyboard at all during boot-up for any purpose (eg encryption, which my employer requires to use this on their networks).
I don't suppose anyone has a stock nandroid of /system on hand I could download?
EDIT: I see there isn't one yet, but if you make one, anyone, I'd be willing to host it on my Mediafire account.
EDIT 2: Where might I find this flashable stock recovery? I must be overlooking it.
EDIT 3: I see. The link to the unofficial TWRP points to the stock DD pull. I already have a DD pull I just did so ignore that question aboug stock recoveries.
Anyone else having SERIOUS device issues after flashing this?
EDIT: Not demanding updates/etc, just asking/inquiring.
I have ADB installed but running "adb devices" does not show any device connected. My windows 7 shows the storage (internal and external SD card) but windows does not recognize the "ASUS Android Composite ADB Interface".
Any advice where to find drivers for windows 7 for my Padfone X ?
Thanks !
JD
dorj1234 said:
I have ADB installed but running "adb devices" does not show any device connected. My windows 7 shows the storage (internal and external SD card) but windows does not recognize the "ASUS Android Composite ADB Interface".
Any advice where to find drivers for windows 7 for my Padfone X ?
Thanks !
JD
Click to expand...
Click to collapse
LOL! did you ever plug it into the computer? It has the drivers on it.
AdamOutler said:
LOL! did you ever plug it into the computer? It has the drivers on it.
Click to expand...
Click to collapse
For me they installed automatically
Sent from my ASUS PadFone X using XDA Free mobile app
Does anyone have new download link for twrp recovery , link is dead
UPDATE 2: Tutorial and Patched Boot.imgs available here.
UPDATE: Chainfire's suggestion to patch sepolicy in the ramdisk for Samsung LL ROMS works perfectly. For unknown reasons, ODIN flash would not work, but flashing the patched boot.img with TWRP allowed me to successfully achieve root with a fully stock kernel and SEAndroid Enforcing. All the information you need is in the sources I quote below. Once I am confident that everything is working fine, I will create another thread with a concise guide and my patched boot.img for those who don't want to get their hands dirty. In the meantime, anybody who sees this should know that the same process can be done with the P605 as well, with your native ROM instead of a ROM from a different region. Also, stock kernel means no wifi dropping problems either!
@garyd9
This thread is to discuss the possibility of rooting the Samsung Note 10.1 (2014 Edition) without resorting to a permissive kernel. The background information for this thread can be found from the following posts:
http://forum.xda-developers.com/apps/supersu/wip-android-6-0-marshmellow-t3219344
Chainfire's method of patching the device's sepolicy with a reference device to give sudaemon the required permissions that open the doors for rooting and more.
http://forum.xda-developers.com/showpost.php?p=63250893&postcount=26
garyd9's application of Chainfire's idea to the Note 5, which appears to have worked successfully.
http://forum.xda-developers.com/showpost.php?p=63552454&postcount=2375
My attempt to replicate garyd9's method on the P607T, which failed.
http://forum.xda-developers.com/showpost.php?p=63555137&postcount=2376
garyd9's recommendation on how to troubleshoot.
And finally the results from following Gary's advice:
0 - Check
1 - Check
2 - Fail
Tools and Process: Listing all of them. The one I followed for this methodical approach is the first one. Including the others for context, in the hopes that it will indicate what the next step should be.
1) Carliv's Kitchen
Followed instructions, placed boot.img in the boot_resources folder, unpacked it with the tool, changed nothing, repacked with the same tool, made tar using "tar -cf boot_stock_repack.tar bootxxx.img" bootxxx.img is what Carliv generated, of course. To compare, made tar of the stock boot.img as well, naming it boot_stock.tar. Flashing boot_stock.tar works, device boots, no problems. Flashing the boot_stock_repack.tar fails with "Unsupport dev_type" on the device.
Additional Info:
------------------------------------------------
2) bootimg_tools
split_boot to extract the kernel and ramdisk and unpack the ramdisk. No warnings are issued, nothing suggests there is any problem.
repack_ramdisk to repack ramdisk, no problems here either.
mkbootimg to create new boot.img; no arguments are specified since apparently it would automatically create the right image.
tar -cf to create ODIN flashable tar.
Flashing this would succeed in ODIN, but the device would reboot in Download Mode with "Unable to boot normal mode" showing on the device. 3 suggests an explanation why.
3) To extract the kernel and ramdisk, used umkbootimg instead of split_boot from the same toolset. This time, it issued a warning about the original img being created with a non-standard mkbootimg, said I should edit mkbootimg.c before making the new image. Despite the warning, it also provided a mkbootimg command to use to ensure the new img is created correctly. Googling the warning suggested downloading android source code to get the mkbootimg.c file, but nothing beyond that on what needs to be done.
While not optimistic, I still tried the mkbootimg command it gave me, as well as with extra arguments to correct the addresses till boot_info in the toolkit matched for the stock and new images. SAME outcome as with 2.
4) Modding_My_Mind/SHM's toolset
This one claimed to automatically make the necessary corrections for a non-standard boot image and definitely did something different. Unlike the other generated images which were smaller in size than the original, this one was the same size. Making a tar and flashing it though failed with Unsupport dev_type showing on the device. I have contacted SHM to see if he can shed some light on this.
NOTE: In the thread where I got this from, when dealing with a non-standard image, his output seems to show this warning. BUT, I got no such warning when I did this on my image.
5) Carliv's as in the first item here. It generated a boot.img that matched in size and failed with the same error as the previous, suggesting it is definitely making SOME changes to the mkbootimg arguments to work with the 'non-standard stock image', BUT I have no idea what these changes are, nor where to look for them.
Next Step?
I never tried a full manual repacking of the ramdisk and generation of the image. Not sure if the error could be in the way the ramdisk is being repacked (which seems improbable, since its a gzip + cpio command that does this, not much to mess up there), or if its the way in which the new img is being created (seems probable, given that many arguments need to be passed here and Im using binaries that I do not know and understand at all).
I tried to look for other ways to create the img file, BUT pretty much everything keeps pointing to these same toolsets and binaries. With regards process, I have not been able to find anything on how to make 'manual adjustments' to the addresses/offsets.
Any advice on where to go/look next?
Click to expand...
Click to collapse
This thread is started to continue exploring this option specifically for the Note 10.1 (2014 Edition). The idea is to achieve root by modifying only the ramdisk and not touching the kernel, and definitely NOT going to the extreme step of using a permissive kernel.
Can you post a boot.img that's known good? I don't use kitchens, dining rooms, or even bathrooms. I use my own compiled tools... (Are you doing all this work in linux or using win-blows?)
I've attached "imgtools.zip." Within are the linux binaries I use for unpacking and repacking boot images. They should work under ubuntu 64-bit 14.04.
Here's some idea of how you might use them (again, linux..)
Code:
# assumes "boot.img" in the cwd is the original boot image.
mkdir stockboot
# unpack the boot image into a new directory called "stockboot"
unpackbootimg -i boot.img -o stockboot
That will dump a bunch of files into that new directory...
Now, to remake it:
Code:
cd stockboot
mkbootimg --kernel boot.img-zImage --ramdisk boot.img-ramdisk.gz --base `cat boot.img-base` --pagesize `cat boot.img-pagesize` --kernel_offset `cat boot.img-kerneloff` --ramdisk_offset `cat boot.img-ramdiskoff` --tags_offset `cat boot.img-tagsoff` --dt boot.img-dtb -o ../newboot.img
What that does is goes into the directory we unpacked the original image to, and then just puts it back together in the original directory under a new name (newboot.img.) For all the parameters, we just re-use the values and items extracted from the stock boot image. The new image won't be identical to the old one, but the sizes should be close.
garyd9 said:
Can you post a boot.img that's known good? I don't use kitchens, dining rooms, or even bathrooms. I use my own compiled tools... (Are you doing all this work in linux or using win-blows?)
Click to expand...
Click to collapse
tar of stock boot.img attached. Until Carliv's kitchen, all attempts were on Slackware 14.1. Only Carliv's was done on Win 10.
garyd9 said:
I've attached "imgtools.zip." Within are the linux binaries I use for unpacking and repacking boot images. They should work under ubuntu 64-bit 14.04.
Click to expand...
Click to collapse
Will take a shot at it tomorrow with your binaries and post results.
karthikrr said:
tar of stock boot.img attached. Until Carliv's kitchen, all attempts were on Slackware 14.1. Only Carliv's was done on Win 10.
Click to expand...
Click to collapse
I'm not going to talk about that. I have a semi-religious belief that anyone using windows to manipulate linux kernel images is BEGGING for trouble. (It's not that I'm anti-windows. I'm just against mixing the platforms.)
Anyway, followed my own directions to unpack and repack your boot.img. I took the resulting newboot.img and zip'd it up (and attached it here.) This is NOT a TWRP/CWM flashable zip. It's just archived to save space (and make XDA's file manager happy.)
I didn't see any strange messages about non-standard images or anything like that. In fact, the process was outright boring.
(FYI, I might not be capable of responding to messages again until late tomorrow night or Sunday...)
Code:
~/temp$ unpackbootimg -i boot.img -o stockboot
BOARD_KERNEL_CMDLINE console=null androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3
BOARD_KERNEL_BASE 00000000
BOARD_PAGE_SIZE 2048
BOARD_KERNEL_OFFSET 00008000
BOARD_RAMDISK_OFFSET 02000000
BOARD_TAGS_OFFSET 01e00000
BOARD_DT_SIZE 1574912
oh, that might not boot for you. my repack cmdline doesn't pull in the cmdline from the kernel unpack. Add something like this to the mkbootimg cmdline:
Code:
--cmdline "`cat boot.img-cmdline`"
(You might have to actually type out the cmdline inside the quotes instead)
garyd9 said:
I didn't see any strange messages about non-standard images or anything like that. In fact, the process was outright boring.
Click to expand...
Click to collapse
Not surprised . Most tools available won't give this information. Its typically only available as a cosmetic feature. My work is derived from Xialou's as seen here but modified to work for Linux and ARM alike.
I have attached images showing me unpacking and repacking his stock boot.img from my device.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
With that said, I have been researching this error, "unsupported dev_type", and most of what I have came across points to it being a specific issue with Odin itself. However, I can't really rule this out because his device does not have root so I presume he can't write the boot image to his boot partition using the dd command in a terminal to verify if it will boot up using this method. If it were to boot up then it would clearly point the problem towards the Odin program being used.
Sent from my Ascend Mate 2 using Tapatalk
---------- Post added at 02:21 PM ---------- Previous post was at 01:59 PM ----------
@karthikrr, when making an Odin compatible package you are using the command:
Code:
tar -cf
I don't own a Samsung device but I have helped build TWRP for some so given my experience shouldn't the command actually be:
Code:
tar -H ustar -c boot.img > Odin_boot.tar
Where Odin_boot.tar is the package used to install via Odin.
Please use that command i just shared with you and try again.
Sent from my Ascend Mate 2 using Tapatalk
garyd9 said:
oh, that might not boot for you. my repack cmdline doesn't pull in the cmdline from the kernel unpack. Add something like this to the mkbootimg cmdline:
Code:
--cmdline "`cat boot.img-cmdline`"
(You might have to actually type out the cmdline inside the quotes instead)
Click to expand...
Click to collapse
SHM said:
I don't own a Samsung device but I have helped build TWRP for some so given my experience shouldn't the command actually be:
Code:
tar -H ustar -c boot.img > Odin_boot.tar
Where Odin_boot.tar is the package used to install via Odin.
Please use that command i just shared with you and try again.
Click to expand...
Click to collapse
Short version: No luck!
Long version:
In all cases, just unpack stock boot.img and make new stock boot.img, no changes.
Gary, everything except for the ODIN flash was done on Linux for the following.
SHM, all tars created using your command.
1) Used Gary's tools following all instructions including cmdline to create garyboot.img and then .tar
2) Used SHM's tools to try again, this time with his tar cmd to create shmboot.tar
3) Found a mkbootimg binary in the P607T KK Source from Samsung's opensource portal. Used that to create P607Tboot.tar from the img unpacked by Gary's tools.
4) This might have been completely off-base, but ... Used xialou's mkboot-master source code; edited mkbootimg.c with the Non-Standard addresses from SHM's image above. Ran make to compile a new binary, used it to create recboot1.tar
5) umkbootimg from another toolset gave me a different set of addresses to change in the mkbootimg.c file, this time to change kernel offset, ramdisk offset and second offset. New binary again, after make clean and make, used it to create recboot2.tar
ODIN 3.10.6 failed with the same unsupport dev_type error with ALL of these images.
Tried the first two with ODIN 3.09, no difference, same error again.
Questions:
SHM, your image above, as well as the warning on umkbootimg both say Modify mkbootimg.c and try again ... Should I look into this more?
Is there ANY chance that the problem is not with mkbootimg, but with unpackbootimg?
SHM, you mentioned unsupport dev_type in context with ODIN problems. Where can I find more info on this? FWIW, I have never had ODIN problems before, flashing firmware updates and twrp on this tablet, as well as on my Note 2 phone. Can't think why only in this case, it should fail like this.
What are my alternatives to ODIN? Can I flash using twrp? I have never created a twrp flashable zip, so will go read up on that some now, but do you think it makes sense to try that? If not, are there any other methods of flashing to try before being absolutely sure the problem is with mkbootimg?
@karthikrr, if you have the latest twrp for your device than there is something you need to try to see if in fact this is a problem with Odin specifically. I want you to take your boot.img that has been unpacked and repacked but don't make it into a tar. Leave it as an image. Boot up TWRP then select Install. At the bottom right of your screen will be a button that says, zip. If you click on it you will see it change to, image. This allows you to install either a flashable zip or flash a boot/recovery.img. Select to install the boot.img. The next screen will ask you to select either the boot or recovery partition based upon the image you chosen. In this case, choose the boot partition. Swipe to proceed. When done, reboot your system. If your device boots up successfully then your problem lays with Odin. Let me know if these instructions are a bit confusing.
Sent from my Ascend Mate 2 using Tapatalk
SHM said:
@karthikrr, if you have the latest twrp for your device than there is something you need to try to see if in fact this is a problem with Odin specifically.
Click to expand...
Click to collapse
No confusion, I even have all the imgs loaded on the device to try this. Two reasons I did not try it yet, perhaps you can clarify whether these are legitimate concerns:
1) TWRP is formally not out for LL on my device yet. I, like everybody else out there, is using the latest KK img on this device and it SEEMS to be working properly. The only noticeable difference I have seen is that it seems to take a lot longer to get into twrp than usual. But I made some 5 backups of the device yesterday and all of them seemed to be fine. Given this is not official for LL, I wasn't sure if it was wise to try to flash an image from twrp.
2) I was also concerned that PERHAPS Odin is doing me a favour and aborting the flash because there was something wrong, and that if I went with twrp and it flashed it without any problems, I might find that it killed my device. I was discussing this with a friend (no experience with Android flashing, but a developer who knows these things) and he said it was highly unlikely that this would happen, as long as the img I was flashing was within the size limit for my device, which I believe is 11mb. All the images are 10.5mb. Thoughts?
karthikrr said:
No confusion, I even have all the imgs loaded on the device to try this. Two reasons I did not try it yet, perhaps you can clarify whether these are legitimate concerns:
1) TWRP is formally not out for LL on my device yet. I, like everybody else out there, is using the latest KK img on this device and it SEEMS to be working properly. The only noticeable difference I have seen is that it seems to take a lot longer to get into twrp than usual. But I made some 5 backups of the device yesterday and all of them seemed to be fine. Given this is not official for LL, I wasn't sure if it was wise to try to flash an image from twrp.
2) I was also concerned that PERHAPS Odin is doing me a favour and aborting the flash because there was something wrong, and that if I went with twrp and it flashed it without any problems, I might find that it killed my device. I was discussing this with a friend (no experience with Android flashing, but a developer who knows these things) and he said it was highly unlikely that this would happen, as long as the img I was flashing was within the size limit for my device, which I believe is 11mb. All the images are 10.5mb. Thoughts?
Click to expand...
Click to collapse
If the partition table between KK and LP does not vary on your device then it will be fine.
As for flashing a boot image to your boot partition via twrp, this will not brick your device. Worse case, device doesn't get past the bootloader or the boot animation. In this case, use twrp to install your stock boot.img to your boot partition.. If you have a backup of your boot image then restore that. Either way you will be OK.
Sent from my Ascend Mate 2 using Tapatalk
SHM said:
If the partition table between KK and LP does not vary on your device then it will be fine.
As for flashing a boot image to your boot partition via twrp, this will not brick your device. Worse case, device doesn't get past the bootloader or the boot animation. In this case, use twrp to install your stock boot.img to your boot partition.. If you have a backup of your boot image then restore that. Either way you will be OK.
Sent from my Ascend Mate 2 using Tapatalk
Click to expand...
Click to collapse
IT WORKS!!!
Flashed a stock boot.img using TWRP to be safe, was fine. Patched the ramdisk again, created a new patchedboot.img using the binary I pulled from the P607T sources, crossed my fingers and flashed it with TWRP, the device booted successfully. There was a SEAndroid Not Enforcing; Set Warranty Bit Kernel message while it booted, but I don't care about Knox. Once I confirmed that it booted and worked alright, back to recovery, flashed SuperSU Beta 2.52, rebooted, and I HAVE ROOT!!!
No idea why Odin would fail to flash, but confirmed working with TWRP. Do you know what the policy is on me creating a thread and uploading my patchedboot.img for others to use? I am no developer, and I have no idea if the rules prohibit me from putting this up. I do know though that not everybody is going to go through this whole manual process to get root, and too many are resorting to permissive kernels to get root. Ideally, I will also repeat this process is someone sent me a P605 boot.img, so they too can have root with stock kernel. Just not sure where this thread should go, and if I can even make one.
In anycase, THANK YOU SO MUCH BOTH OF YOU FOR TAKING THE TIME TO WALK ME THROUGH THIS! Much appreciated
Glad you got it working. If you want to post the image, I'd suggest posting in the dev section for the device. (If it's just a repack of the stock kernel, don't use the original dev...) Yes, it is allowed to do that. Being that you aren't recompiling anything, there's no need for you to post any source code (but it might be nice to link to the source from samsung's site. We all know that Samsung doesn't update that anyway.)
Take care
Gary
Thanks for the suggestions on how and where to post. I think I will take the time to write out a decent tutorial and then post it with this image in the dev forum. Im sure the P605 users will also want to do this with theirs, so they are not stuck with an unsecure kernel!
karthikrr said:
Thanks for the suggestions on how and where to post. I think I will take the time to write out a decent tutorial and then post it with this image in the dev forum. Im sure the P605 users will also want to do this with theirs, so they are not stuck with an unsecure kernel!
Click to expand...
Click to collapse
Good luck with your future endeavors. I'm currently fighting with sepolicy right now with my CM13 builds lol. Whole other battle right there haha.
Sent from my Ascend Mate 2 using Tapatalk
If you're in a hurry and just want to know the latest news, follow this link:
https://forum.xda-developers.com/showpost.php?p=80393641&postcount=58
Keep reading for some background info.
Hi there!
So... I'm trying to port LineageOS (version 15.1) from OnePlus - OnePlus2 device to the LeEco LeMax 1 phone.
Why I've chosen this device to port from?
It has the MSM8994 (Qualcomm Snapdragon 810) SoC, which is the same as Max1, so (supposedly) a kernel compile would not be too much hassle. Besides it also has many similarities in terms of hardware.
What I did for device dir:
I took the tree from https://github.com/LineageOS/android_device_oneplus_oneplus2 and modified it to meet max1 requirements.
Current tree: https://github.com/alexsmithbr/android_device_letv_max1
What I did for vendor dir:
I compared the tree with Max1 tree, excluding everything that was not found in Max1. The plan is to add more vendor stuff if necessary.
Current tree: https://github.com/alexsmithbr/android_device_letv_max1
What I did for kernel dir:
I downloaded Le_Max_OpenSource.zip from opensource.le.com (in fact, as the site is down, I got a copy from http://web.archive.org/web/20180626053054/http://opensource.le.com:80/ and, from there, I found the file I needed was named Le_Max_OpenSource.zip. I got it from here.
The kernel config in this zip file is exactly the same I get from the device itself, with adb pull /proc/config.gz.
Current tree: https://github.com/alexsmithbr/android_kernel_letv_max1
Interesting related threads:
https://forum.xda-developers.com/showpost.php?p=78690008&postcount=7
https://forum.xda-developers.com/le.../cm-14-1-android-7-1-unofficial-letv-t3530173
Other possibly useful resources:
http://web.archive.org/web/20180626053054/http://opensource.le.com:80/
https://forum.xda-developers.com/showpost.php?p=78676206&postcount=2402
These are thanks to @rico69310, specifically this post:
https://www.mediafire.com/folder/ff7hbpa62ivsg/
https://yadi.sk/d/RPfdh3glmhzarw
https://cloud.mail.ru/public/GP9g/cWpyeYbuK/
Another useful resource, in case you brick your X900. This is thanks to @Phsh:
https://forum.xda-developers.com/showpost.php?p=75157516&postcount=2375
Current status
I can build LineageOS 15.1 completely, but, once flashed, the kernel doesn't boot and phone enters bootloader (the penguin screen) and stay there.
What I need
It's pretty obvious I need the ROM working...
But the focus now would be to have a working boot.img. I really don't know what I'm doing wrong.
I can't get any logs, as LeEco patched the kernel so that we don't have a last_kmsg. Instead, they apparently put last_kmsg into another partition in /dev/block/platform/soc.0/f9824900.sdhci/by-name/letvconfig2. You can check this in the kernel, file kernel/printk/last_kmsg.c, line 124:
Code:
#define DEFAULT_KERNELLOG_FILENAME "/dev/block/bootdevice/by-name/letvconfig2"
char *kernlog_file = DEFAULT_KERNELLOG_FILENAME;
Well, I tried to give an overview of all steps I took. Please feel free to ask anything or give hints.
Together we can make LeEco LeMax 1 live longer!
Thought it would be nice to describe my build process.
Basically I'm following these instructions: https://wiki.lineageos.org/devices/oneplus2/build
Of course these instructions are for oneplus2, but the step-by-step is pretty much the same for any device.
I'm using Ubuntu 18.04.1 LTS, in which I created a user specifically for building LineageOS.
I followed all steps on the above link until breakfast oneplus2, since, at this point, I had to create my own device/vendor/kernel tree, so that I can breakfast it.
To do this, I did:
Code:
# clone max1 device
cd ~/android/lineage/device
mkdir letv
cd letv
git clone https://github.com/alexsmithbr/android_device_letv_max1.git max1
# clone max1 vendor
cd ~/android/lineage/vendor
mkdir letv
cd letv
git clone https://github.com/alexsmithbr/android_vendor_letv_max1.git max1
# setup kernel
cd ~/android/lineage/kernel
mkdir letv
cd letv
# change <path_to_file> to the correct path to Le_Max_OpenSource.zip
# you downloaded from the link on the previous post.
unzip <path_to_file>/Le_Max_OpenSource.zip -d max1
# as the zip has unnecessary subfolders, I just moved them
# to their correct names and deleted other rubbish.
mv max1/LeMax_kernel/kernel/ max1/msm8994
rm max1/LeMax_kernel/ -R
In the end, you need a structure like this:
Code:
~/android/lineage/device/letv/max1
~/android/lineage/vendor/letv/max1
~/android/lineage/kernel/letv/msm8994
Finally, put config.gz in its dir:
Code:
adb pull /proc/config.gz /tmp
gunzip /tmp/config.gz -c > ~/android/lineage/kernel/letv/msm8994/arch/arm64/configs/msm8994-max1-perf_defconfig
Okay, now everything is set up for the build to start.
Code:
source build/envsetup.sh
breakfast max1
export USE_CCACHE=1
ccache -M 50G
export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"
croot
Just before start building, I choose which kind of build I want:
Code:
choosecombo
Build type choices are:
1. release
2. debug
Which would you like? [1] 1
Which product would you like? [lineage_max1]
Variant choices are:
1. user
2. userdebug
3. eng
Which would you like? [eng]
Now, if you want a normal build, you can enter:
Code:
brunch max1
But, if you want a really verbose log (very useful to debug build errors), you can enter:
Code:
mka -j 4 showcommands
Note that -j 4 means 4 simultaneous jobs. You can specify another number. A rule of thumb is to use <number_of_cpus> * 2.
Now the system should build...
At this point:
https://github.com/alexsmithbr/andr...tree/0f9134dd09c269b2da9008c5598060b9d19ac2ef
https://github.com/alexsmithbr/andr...tree/9ece561a945867ab2af733c5ef890b6df5438a8b
The system builds and mka -j 4 showcommands bacon will build flashable lineage-15.1-20190128-UNOFFICIAL-max1.zip.
Unfortunately, when flashing this zip, and restarting the phone, it will vibrate twice when showing the LeEco first screen, then it vibrates twice again and shows me the penguin screen (bootloader).
No luck up to now.
Keep up with the good work... I hope you get the kernel working.
Spunkination said:
Keep up with the good work... I hope you get the kernel working.
Click to expand...
Click to collapse
Me too!
It's so hard to get any help... I've been to freenode as well and nobody wanted to help there. :/
So it feels like a very lonely path. But I'm still on to it.
Currently I'm recompiling everything, now getting "my" tree a bit closer to @ABM30 tree, adapted to LineageOS, instead of CyanogenMod.
Let's see what happens next.
No luck. Boots to penguin (bootloader) screen again.
---------- Post added at 09:37 AM ---------- Previous post was at 09:33 AM ----------
I'm cheering for you. I would very much like 8.1 Good luck ! Good work!
htimsxela said:
Me too!
It's so hard to get any help... I've been to freenode as well and nobody wanted to help there. :/
So it feels like a very lonely path. But I'm still on to it.
Currently I'm recompiling everything, now getting "my" tree a bit closer to @ABM30 tree, adapted to LineageOS, instead of CyanogenMod.
Let's see what happens next.
No luck. Boots to penguin (bootloader) screen again.
Click to expand...
Click to collapse
Hope you are good friend?
How is the build going?
I updated the git repositories. The current version compiles as well and I get a ROM at the end, but unfortunately it doesn't boot. I'm probably missing something in the kernel build. I'm still investigating, but I don't even get to the LineageOS logo. When I turn on the phone, it goes straight to bootloader (penguin) screen.
I'll keep trying. Since a build involves a lot (really!) of variables, there's always something new to try.
And it's good that we keep this thread active. Maybe someone with more knowledge shows up and is able to help.
My biggest issue is I can't find a way of seeing what's wrong, since LeEco patched the kernel in a way there is no /proc/last_kmsg file, nor /sys/fs/pstore/console-ramoops. LeEco implemented it in a way the logs would be written to a partition called letvconfig2, but even there I cannot see any logs.
I read another way of seeing kernel logs would be to use the phone's serial port, but then I'd have to reach its main board, which is not an option currently, since this is my only phone.
In other words, my options now resume to keep trying.
Tomorrow I expect to have some time to resume the work. Will give it some more tries. I'm even thinking about checking out a previous version of LineageOS (when it was still called CyanogenMod), then, once I get it working, try to make my way to newer versions.
Stay tuned!
And again: any hints are more than welcome!
I really believe this thread may become kind of a roadmap to compile android for any unsupported device.
Update: by looking at recovery.img and comparing to the recovery partition on device, I noticed the kernel being built by LineageOS doesn't contain any DTBs. Without DTBs, the kernel won't be able to identify the phone's hardware.
How I checked this:
Code:
$ mkdir /tmp/boot
$ cd /tmp/boot
$ unpackbootimg -i ~/android/lineage/out/target/product/max1/recovery.img -o .
BOARD_KERNEL_CMDLINE console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 boot_cpus=0-5 androidboot.selinux=permissive buildvariant=userdebug
BOARD_KERNEL_BASE 00000000
BOARD_PAGE_SIZE 4096
$ split-appended-dtb-master/split-appended-dtb recovery.img-zImage
ERROR: Appended Device Tree Blob not found!
I'll try to find out how to automatically add DTBs to the images.
I know there was a variable called TARGET_KERNEL_APPEND_DTB, which should be set to true on older (cyanogenmod) versions, but it is now deprecated. So deprecated that even the "deprecated" messages have been removed by now.
As far as I could figure out, now the action of appending/not appending DTBs to the kernel image is guessed by variable BOARD_KERNEL_IMAGE_NAME. For example:
To add dtb to kernel image, one would do:
Code:
BOARD_KERNEL_IMAGE_NAME := Image-dtb
To don't add dtb to kernel image, one would do:
Code:
BOARD_KERNEL_IMAGE_NAME := Image
I was hoping this would change something, as for me that variable was defined without the -dtb suffix, but I figured out I broke the kernel build:
Code:
make[1]: *** No rule to make target 'Image-dtb'. Stop.
I guess this is because the original kernel is too old (3.10.84) and it's AndroidKernel.mk still relies on TARGET_KERNEL_APPEND_DTB, as we can see on line 68:
Code:
ifeq ($(TARGET_KERNEL_APPEND_DTB), true)
$(info Using appended DTB)
TARGET_PREBUILT_INT_KERNEL := $(TARGET_PREBUILT_INT_KERNEL)-dtb
endif
Patch the kernel? Wow! This is going deep...
* unpackbootimg is part of the android_bootimg_tools. I got it from here: wget https://storage.googleapis.com/goog...d-serialport-api/android_bootimg_tools.tar.gz
* split-appended-dtb is this tool: https://github.com/dianlujitao/split-appended-dtb
Turns out there are two ways of adding DTBs.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
By checking my current recovery partition, I noticed DTBs are attached to partition, not to kernel. I also noticed it is not using a compressed kernel. So I'll configure BoardConfig.mk as:
Code:
BOARD_KERNEL_IMAGE_NAME := Image
If I wanted it gzipped, I'd make it Image.gz. If I wanted the DTBs attached to kernel (not to image), I'd do Image.gz-dtb.
Apparently no kernel patch will be needed... Anyway I created a git repository for it, just in case I need to change something.
Again, the build works, but it doesn't boot.
As I'm focusing on testing the kernel, I'm using the recovery partition.
I just dumped a copy of it with:
Code:
host$ adb shell
phone$ su
phone# cp /dev/block/bootdevice/by-name/recovery /sdcard
phone# exit
phone$ exit
host$ adb pull /sdcard/recovery
and I'm flashing it over and over to test.
To do this, I do
Code:
host$ adb reboot bootloader
# phone reboots
host$ fastboot flash recovery /path/to/recovery.img
# it flashes, then, holding volume-up, I type:
host$ fastboot reboot
Phone will reboot into recovery and test my image (up to now, I only get back to penguin screen (bootloader)).
To flash back my working recovery image, I do the same as above, just changing the path to recovery image.
Bless you and your work
Dude, I would definitely-definitely liked to help; I understand and root for your hard work. But unfortunately I don't possess any knowledge in this area. Yeah, I can flash using manual, but I'm lamer in terms of programming, not even close to IT.
htimsxela said:
Hi there!
Click to expand...
Click to collapse
I rarely meet such wonderful and persistent people like you. I sincerely hope you will succeed and achieve your goal! :good:
Santey Maas said:
Dude, I would definitely-definitely liked to help; I understand and root for your hard work. But unfortunately I don't possess any knowledge in this area. Yeah, I can flash using manual, but I'm lamer in terms of programming, not even close to IT.
Click to expand...
Click to collapse
Thanks, mate! I didn't give up yet. Each try brings more knowledge and I hope I'm able to share all I'm learning. Sort of paving the road for newcomers.
Tircon said:
I rarely meet such wonderful and persistent people like you. I sincerely hope you will succeed and achieve your goal! :good:
Click to expand...
Click to collapse
Thanks! My hope is that - if I succeed - more people can benefit from my work and give these phones a longer life.
LeEco Le Max (max1/x900) Secret Codes
A bit off-topic, but here it goes... While looking for a way to debug kernel boot, I came across those famous secret codes you can type on phone screen to access secret/test menus... This site, for example, says you can use code *#*#76937#*#* to have access to a menu where you can enable/disable some log, debug and AT commands options. I tested and it worked with my phone. Not happy enough, I did a
Code:
grep 76937 / -rl
on the phone and found out system/app/LetvDebugUtil/oat/arm64/LetvDebugUtil.odex was the only place where it occurred. Inspecting the file, I found, right next to the occurrence, the code 9439. Just to test, I entered *#*#9439#*#* on the phone and got to a Chinese menu (see attached picture). The translation of these Chinese stuff is "Launch China Telecom Network (CDMA)". I didn't check that box to see what happens.
Current known codes
*#*#76937#*#* - Menu where you can enable/disable some log, debug and AT commands options.
*#*#9439#*#* - Launch China Telecom Network (CDMA)
*#*#8888#*#* - Advanced settings. Here you can turn on logging of App, Modem, Net, Kernel, Bluetooth, GPS and WiFi. Logs are stored in /sdcard
*#0000# - About phone. Information about each card slot.
*#06# - MEID & IMEI numbers.
If you're having this error while trying to build LineageOS:
Code:
FAILED: /bin/bash -c "prebuilts/misc/linux-x86/flex/flex-2.5.39 -o/home/android_build/android/lineage/out/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:151: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
make: Leaving directory '/home/android_build/android/lineage'
You're probably having the same issue I'm having with Flex. The easiest option is to recompile it. And it's easy.
Code:
$ cd prebuilts/misc/linux-x86/flex
$ mkdir flex-2.5.39-src
$ cd flex-2.5.39-src
$ tar zxvf ../flex-2.5.39.tar.gz
$ ./configure
$ make
$ cp flex ../flex-2.5.39
$ cd ..
$ rm flex-2.5.39-src -R
The above commands will recompile Flex for your architecture and everything should be fine (with Flex).
Some news regarding the overall progress with LineageOS.
I checked out the repo from cm-14.1 (cyanogenmod 14.1) and am now trying to build for it. If it builds, at least we'll have Android 7.1.x running on device. And - I believe - it could bring some light to start a port to a newer version (Lineage 15.1).
Up to now, I faced the same compile errors I got when compiling for 15.1, so it's being straight forward. I'm anxious to see if it'll boot. :fingers-crossed:
As usual, I'll keep you posted.
htimsxela said:
Some news regarding the overall progress with LineageOS.
I checked out the repo from cm-14.1 (cyanogenmod 14.1) and am now trying to build for it. If it builds, at least we'll have Android 7.0.1 running on device. And - I believe - it could bring some light to start a port to a newer version (Lineage 15.1).
Up to now, I faced the same compile errors I got when compiling for 15.1, so it's being straight forward. I'm anxious to see if it'll boot. :fingers-crossed:
As usual, I'll keep you posted.
Click to expand...
Click to collapse
Thanks for your effort!
This phone is great and it's pity that it was left without support..
htimsxela said:
Some news regarding the overall progress with LineageOS.
I checked out the repo from cm-14.1 (cyanogenmod 14.1) and am now trying to build for it. If it builds, at least we'll have Android 7.0.1 running on device. And - I believe - it could bring some light to start a port to a newer version (Lineage 15.1).
Up to now, I faced the same compile errors I got when compiling for 15.1, so it's being straight forward. I'm anxious to see if it'll boot. :fingers-crossed:
As usual, I'll keep you posted.
Click to expand...
Click to collapse
BTW if someone is curious out there, here's the CyanogenMod 14.1 branch I'm working on: https://github.com/alexsmithbr/android_device_letv_max1/tree/cm-14.1
It was based on CyanogenMod 12.1 and the code is almost three years old (last commit), so I'm spending some time updating obsolete code, etc.
Donnie2Darko said:
Thanks for your effort!
This phone is great and it's pity that it was left without support..
Click to expand...
Click to collapse
Yeah, let's see if I can help changing this scenario.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I present to you: Kali NetHunter for the OnePlus One LineageOS 17.1 Q
This is the latest (experimental) version for the OnePlus One.
Kali NetHunter is an Android ROM overlay that turns an ordinary phone into the ultimate Mobile Penetration Testing Platform.
The overlay includes a custom kernel, a Kali Linux chroot, an accompanying Android application, which allows for easier interaction with various security tools and attacks, as well as a client to the Kali NetHunter App Store.
Beyond the penetration testing tools arsenal within Kali Linux and the Kali NetHunter App Store, NetHunter also supports several additional classes, such as HID Keyboard Attacks, BadUSB attacks, Evil AP MANA attacks, and much more. For more information about the moving parts that make up NetHunter, check out our NetHunter Components page.
NetHunter is an open-source project developed by Offensive Security and the community.
~ Prerequisites ~
- Lineage 17.1 - https://download.lineageos.org/bacon
- Gapps if needed - https://opengapps.org
- TWRP - https://twrp.me/oneplus/oneplusone.html
- Magisk – https://forum.xda-developers.com/apps/magisk
~~ Downloads ~~
- NetHunter: https://www.androidfilehost.com/?fid=17248734326145736621
~~ How to Install ~~
Assuming you have unlocked bootloader
- Flash TWRP
- Copy Lineage, Magisk and NetHunter image to USB drive
- Boot into TWRP, insert USB drive.
- Flash Lineage, and Gapps if needed, reboot and do initial setup
- Reboot into TWRP
- Some old devices with new ROMs doesn't have a TWRP with system_root prop set, therefore do
Code:
adb shell setprop ro.build.system_root_image true
- Flash Magisk, NetHunter
- Reboot
- Run NetHunter app
- Reboot
~~~ Notes & Updates ~~~
- wlan1 unplug reboot is solved
- Y-cable is still supported, just need to have it as a Custom Command or in a script (AndroidSU)
Code:
bootkali ycable start
To stop:
Code:
bootkali ycable stop
- Bluetooth Arsenal is supported, but you need to downgrade Bluez to 4.101 by compiling it in Kali chroot and installing "on top of" current Bluez so the bluetooth service will be able to run
- Mana is being replaced, for the time being you can downgrade iptables with the following :
Code:
wget http://old.kali.org/kali/pool/main/i/iptables/iptables_1.6.2-1.1_armhf.deb
wget http://old.kali.org/kali/pool/main/i/iptables/libip4tc0_1.6.2-1.1_armhf.deb
wget http://old.kali.org/kali/pool/main/i/iptables/libip6tc0_1.6.2-1.1_armhf.deb
wget http://old.kali.org/kali/pool/main/i/iptables/libiptc0_1.6.2-1.1_armhf.deb
wget http://old.kali.org/kali/pool/main/i/iptables/libxtables12_1.6.2-1.1_armhf.deb
dpkg -i *.deb
apt-mark hold iptables
apt-mark hold libip4tc0
apt-mark hold libip6tc0
apt-mark hold libiptc0
apt-mark hold libxtables12
- To downgrade to bluez-4.101:
Code:
apt-get update && apt-get install libdbus-1-dev libglib2.0-dev
apt-mark hold bluez
wget http://www.kernel.org/pub/linux/bluetooth/bluez-4.101.tar.gz
tar xvf bluez-4.101.tar.gz && cd bluez-4.101
./configure --prefix=/usr --mandir=/usr/share/man --sysconfdir=/etc --localstatedir=/var --libexecdir=/lib --build=arm
make && make install
Please not that BLE is not supported in bluez-4.x. If you prefer to use that, keep bluez-5.x
Credits: The Offensive Security Team and the NetHunter community
Android Version: 10.0
XDA: DevDB Information
Kali Nethunter, Kernel & ROM for the OnePlus One
Contributors
@yesimxev
Source Code: https://gitlab.com/kalilinux/nethunter/
Kernel Source: https://github.com/yesimxev/android_kernel_oppo_msm8974
Follow me on Twitter!
Well done! I'm personally not interested in NetHunter but it's nice to see some development still happening for our good old Oneplus One
Thank you very much for keeping up with new Releases for our beloved OPO...
I wiped up my OPO completely and started from scratch...
But after sticking to your tutorial and setting up chroot I get the following:
Code:
[-] sdcard /lib/modules/3.4.113-yesimxev-g4885cdc67a2 doesn't exist or isn't mounted. .
Is this related to the new kernel?
JERKBALL said:
Thank you very much for keeping up with new Releases for our beloved OPO...
I wiped up my OPO completely and started from scratch...
But after sticking to your tutorial and setting up chroot I get the following:
Code:
[-] sdcard /lib/modules/3.4.113-yesimxev-g4885cdc67a2 doesn't exist or isn't mounted. .
Is this related to the new kernel?
Click to expand...
Click to collapse
Thanks for mentioning, the modules dir wasn't in the correct place in the zip. It will be fine in the next release. I'll update the links once they are released.
For now, update to the latest app and you can ignore that message, it will remain as a warning only.
Didn't work for me at all. Back to LOS 16.0.
Ween Dwijler said:
Didn't work for me at all. Back to LOS 16.0.
Click to expand...
Click to collapse
Have you updated the NH ap from the store? I'll build a kernel flasher so you have it before release
yesimxev said:
Have you updated the NH ap from the store? I'll build a kernel flasher so you have it before release
Click to expand...
Click to collapse
Hmmm...... I just spent about a full week to get Nethunter functional on an Oneplus One. It was a very revealing journey, lots of flashing, bricking, flashing, upgrading, downgrading,I've learned a lot.
Tried CM and LOS 16 and 17 with NH for Marshmallow and for Pie. Used the ones from Kali's download site and the ones you linked above. Followed all instructions to the letter and comma, and all variations on it that I could imagine.
The end result is always the samel No bluetooth, no usb.
And since the whole idea is to have a compact mobile to do pentesting on wireless setups and devices in the field, for which we need usb and bluetooth, it seems to be pretty useless. It really puzzles me why the Oneplus One is the preferred device, other than it is a nice Mr. Robot gadget to show of in the bar?
However, I truly want to be proven wrong in my conclusion and work with you to get this sorted out. If you like. I get the idea there are many with similar problems that never got solved and they might have given up and moved on to another device. But I am not afraid of a good challenge, so....... lets do it.
This is what I have:
Oneplus One 16GB
Alfa AWUS036ACH with Realtek rtl8812au chip (have the latest drivers)
Can we make it really work?
(mind you, pentesters at $ 200K a year are probably not willing to spent so much time on getting a tool to work. I'm just a student in pentesting and still learning, so economics are not that much of an issue, yet).
I realise this is all free, open source software. But that doesn't mean it shouldn't be working perfect after proper installing everything.
I hope I can help to make it better.
I have a OPO with the above install but an updated kernel which not released yet. But I'll provide you tonigh for testing. Although the above should be fully functional other than the modules dir (which is ignored by the latest NH app).
I'm happy to help you as I know how frustrating is to get used to this kind of version vs device specific fight
Just to confirm:
No usb or bluetooth? usb hid? Or wlan1? What's your busybox version? Internal or external bluetooth?
JERKBALL said:
Thank you very much for keeping up with new Releases for our beloved OPO...
I wiped up my OPO completely and started from scratch...
But after sticking to your tutorial and setting up chroot I get the following:
Code:
[-] sdcard /lib/modules/3.4.113-yesimxev-g4885cdc67a2 doesn't exist or isn't mounted. .
Is this related to the new kernel?
Click to expand...
Click to collapse
I got that, too. But did the whole thing again and than it was gone.
I noticed that a good way to make sure all reinstalling happens in a "clean" way is to follow this method of working:
1.
TWRP recovery - Wipe all, except USB-OTG. ---> Reboot.
2.
Repeat that 1 more time!!! (counting for residual voltage, causing bits to be persistent in memory, contaminating new install)
3.
Flash LOS 16 or 17 with TWRP from attached USB stick. (If data doesn't show up on USB-OTG, touch it for 5 seconds, release, phone vibrates and the data will be visible. If that doesn't work, unplug the OTG cable, wait 5 seconds and replug it. Repeat previous touch, vibrate etc. If that doesn't work, unplug USB, 5 seconds wait, replug, go to mount and try to mount USB-OTG, return to Install, select Storage and repeat the first step of this no.3 part)
4.
After flash is complete, reboot, setup CM or LOS, activate Developers options by tapping 7x on Build number (you can find that under Settings/about phone). One step back, under settings you find Developer options. Go in there, check Advanced reboot, uncheck Update Cyanogen recovery, check Android debugging. Press right power button shortly, Power options pops up. Choose Reboot, next screen pops up, choose Recovery, confirm with tapping ok.
5.
Back in TWRP, unplug the USB, wait 5 seconds and replug the USB in. Follow the steps I described in 3. to get the data visible. Choose to install Magisk or SuperSU (whatever you like and have). Let it run, when finished reboot again. After reboot is completed, reboot again from LOS to make sure Magisk or SuperSU are completely installed and ready.
6.
Reboot into TWRP Recovery again, do the USB mount trick thing, choose the right version NH zip (you might have, like me, different versions on it) and install NH. When finished, reboot.
7.
Pay attention here!
Back in LOS, check that Magisk or SuperSU are properly installed and working.
Start NH Terminal, popup asks for Superuser rights. You have 10 seconds to grant them! Do it! Follow the further screen instructions, allow for all.
Next, start up NH itself, 10 seconds only for granting SU right!!! Allow all. After this, reboot system.
8.
Start NH terminal, command sudo apt update && sudo apt full-upgrade. Follow the instructions. During that, you get a white window asking for yes or no. Chose Yes and confirm with enter. Another one like that will pop up again a little later, choose the second line (keep present config etc.) and confim with yes and enter.
Let the process run its course. When finished, reboot system again.
9.
Start up NH (if it is not already started), go to Kali Chroot Manager and start it. All should be green now and ready to go.
Happy Hunting!
yesimxev said:
I have a OPO with the above install but an updated kernel which not released yet. But I'll provide you tonigh for testing. Although the above should be fully functional other than the modules dir (which is ignored by the latest NH app).
I'm happy to help you as I know how frustrating is to get used to this kind of version vs device specific fight
Just to confirm:
No usb or bluetooth? usb hid? Or wlan1? What's your busybox version? Internal or external bluetooth?
Click to expand...
Click to collapse
After trying to install above twice, with red warning in TWRP that something failed to mount, I abandoned it and switched back to CM and the Marshmallow NH. But that doesn't work either.
At least I got to see lsusb in LOS 16 with NH and your kernel update ten. Before I updated your kernel, lsusb didn't show anything in LOS 16 NH.
Here goes:
Installed 2020.4 Pie. No lsusb readout, no bluetooth.
Next:
TWRP installed your ...ten.zip, rebooted and after 2 attempts (unplug and plug in again) lsusb in NH terminal registered the OTG as hub, on 001.002 was my USB stick. Unplugged the stick, plugged in the AWUS036ACH, and 001.002 became 0bda Realtek 802.11.
Checked in terminal of Android, got the same reading.
So Android sees it on the USB, NH sees it too. However, no wlan1 shows up when I do iwconfig, ifconfig or run airmon-ng.
Are the Realtek rtl8812au drivers already patched into the kernel? (Do I say that right?).
If yes, what prevents NH from getting wlan1?
The wifi adapter is not powered (I thought it could get power from the OPO?). Has that anything to do with it?
Bluetooth is the internal one from OPO. Busybox was installed with the NH version. I'm now back at CM 13 again, so I donno which version in the LOS install I had. I will go back to the machines and get the LOS 16 installed.
Or do you prefer LOS 17?
yesimxev said:
I have a OPO with the above install but an updated kernel which not released yet. But I'll provide you tonigh for testing. Although the above should be fully functional other than the modules dir (which is ignored by the latest NH app).
I'm happy to help you as I know how frustrating is to get used to this kind of version vs device specific fight
Just to confirm:
No usb or bluetooth? usb hid? Or wlan1? What's your busybox version? Internal or external bluetooth?
Click to expand...
Click to collapse
Ok, I am ready to go.
- Wiped the OPO completely
- Flashed and installed lineage-17.1-20210128-nightly-bacon-signed.zip
- Did the setup, developers options etc.
- flashed and checked proper install of Magisk
Next step?
NB. I have 2 hours more today. After that it is bedtime for me. We probably have a time difference. For me it will be 3AM in 2 hours.
yesimxev said:
I have a OPO with the above install but an updated kernel which not released yet. But I'll provide you tonigh for testing. Although the above should be fully functional other than the modules dir (which is ignored by the latest NH app).
I'm happy to help you as I know how frustrating is to get used to this kind of version vs device specific fight
Just to confirm:
No usb or bluetooth? usb hid? Or wlan1? What's your busybox version? Internal or external bluetooth?
Click to expand...
Click to collapse
Ok, I thought to go on with installing the NH fs from your link. Got the same error:1 again. Error installing zip file 'usb_otg/nethunter-2020.4-generic-armhf-kalifs-full.zip'.
Get the same message for the other one.
Ween Dwijler said:
Ok, I thought to go on with installing the NH fs from your link. Got the same error:1 again. Error installing zip file 'usb_otg/nethunter-2020.4-generic-armhf-kalifs-full.zip'.
Get the same message for the other one.
Click to expand...
Click to collapse
Seems like you haven't done the
Code:
adb shell setprop ro.build.system_root_image true
Haven't you flashed the zips from here yet? What did you use? This version is not released yet anywhere, it's here for testing.
yesimxev said:
Seems like you haven't done the
Code:
adb shell setprop ro.build.system_root_image true
Haven't you flashed the zips from here yet? What did you use? This version is not released yet anywhere, it's here for testing.
Click to expand...
Click to collapse
I used the zips you provided in the links above. But, indeed, I didn't do the setprop. Busy getting it back up again....hahaha. Next install will be after the setprop command. Try to do it now. Stay tuned.
A 5 years old phone is NOT going to beat a 60 year old man.
Ween Dwijler said:
After trying to install above twice, with red warning in TWRP that something failed to mount, I abandoned it and switched back to CM and the Marshmallow NH. But that doesn't work either.
At least I got to see lsusb in LOS 16 with NH and your kernel update ten. Before I updated your kernel, lsusb didn't show anything in LOS 16 NH.
Here goes:
Installed 2020.4 Pie. No lsusb readout, no bluetooth.
Next:
TWRP installed your ...ten.zip, rebooted and after 2 attempts (unplug and plug in again) lsusb in NH terminal registered the OTG as hub, on 001.002 was my USB stick. Unplugged the stick, plugged in the AWUS036ACH, and 001.002 became 0bda Realtek 802.11.
Checked in terminal of Android, got the same reading.
So Android sees it on the USB, NH sees it too. However, no wlan1 shows up when I do iwconfig, ifconfig or run airmon-ng.
Are the Realtek rtl8812au drivers already patched into the kernel? (Do I say that right?).
If yes, what prevents NH from getting wlan1?
The wifi adapter is not powered (I thought it could get power from the OPO?). Has that anything to do with it?
Bluetooth is the internal one from OPO. Busybox was installed with the NH version. I'm now back at CM 13 again, so I donno which version in the LOS install I had. I will go back to the machines and get the LOS 16 installed.
Or do you prefer LOS 17?
Click to expand...
Click to collapse
8812au is not supported on this device.
Btw are you trying both pie and ten zips on lineage-17.1 rom?
Ween Dwijler said:
A 5 years old phone is NOT going to beat a 60 year old man.
Click to expand...
Click to collapse
Keep it up! Flash this kernel https://www.androidfilehost.com/?fid=17248734326145730243
Ok, used setprop ro.build.system_root_image true, got message "failed to map file and error installing.
This is a new one for me!!
I think TWRP is somehow damaged. Will brick it now and do a full setup again, starting with Color. Tomorrow more about this saga.
Ween Dwijler said:
Ok, used setprop ro.build.system_root_image true, got message "failed to map file and error installing.
This is a new one for me!!
I think TWRP is somehow damaged. Will brick it now and do a full setup again, starting with Color. Tomorrow more about this saga.
Click to expand...
Click to collapse
I went back to TWRP 3.4 but 3.5 also flashed everything. The zip might got corrupted? Installs for me fine. I'll make the revert to bluez-4.101 because bluez 5.x is not working on this device
yesimxev said:
I went back to TWRP 3.4 but 3.5 also flashed everything. The zip might got corrupted? Installs for me fine. I'll make the revert to bluez-4.101 because bluez 5.x is not working on this device
Click to expand...
Click to collapse
I used both TWRP 3.4 and 3.5, same result. Sideload didn't work either. Managed to get Magisk flashed. That first had the same error as the rest. Last it went well. So, I thought, lets go for NH too. Nope. Error again.
Tomorrow I will download everything fresh again from the web, and see if it works. Maybe the USB stick got corrupted somehow? Got another one to try.
Which chipset is supported on the OPO, if not 8812au?