Hello,
today as i was accessing my email on Opera Mobile, the SuperSU window popped up by itself and asked me for root acces for a program called "debuggerd.exynosabuse". I dont know what this debuggerd.exynosabuse is and i didnt open any apk before the SU window suddenly popped up..so naturally i denied it root access...then I went into the SuperSU log file and I saw that it kept trying to get root access for two minutes continuously and about 15 tries... also it doesnt have any icon in the apps section of SuperSU. Any ideas what this is about?
Thanks
Look for the app in app drawer named exynos abuse.
Sent from my GT-N7100 using xda app-developers app
Ok. So I m looking for what exactly? I have already mentioned that it is called debuggerd.exynosabuse. it is not the exynos abuse apk, which I used to root my phone and patch the exploit. It is a different app that has no icon in the SU logfile. This debuggerd is always trying to get root access to modify some root files but I have it denied in SU. It tries to get root access 50 times a day or more. What is this program and where did it come from and what should I do with it. Thanks.
Maybe clear data...
Sent from my GT-N7100 using xda app-developers app
You are not alone
http://www.chainfire.eu/articles/126/ExynosAbuse_APK_released_/
may be malware
Try a full wipe including system cache and dalvik and data.
Then flash latest stock rom and root via cfautoroot.
Also backing up anything using any software is not recommended as malware might have infected it.
Sent from my GT-N7100 using xda app-developers app
I just had the same experience for the first time, unfortunately seeing it was a part of ExynosAbuse, I authorized it...
I then saw a lot going on, and in between SuperSU notifications, I saw Adblock Plus notifications too... Maybe related?
As I said try full wipe and flash latest stock rom.
Sent from my GT-N7100 using xda app-developers app
Well, I'd like to know before I wipe, it's not an easy thing to do for me right now, plus if it's something in the app and I reinstall the app after wiping, I'll have the same problem...
Than you for your input Dr Ketan. I see that this is a relatively new problem and its got people wondering/worried, I appreciate that this issue has come to your attention.
Dear UtkarshGupta, Sure anyone can nuke their phone and wipe all and flash new, but thats not what the xda community is about. We are here to share, communicate, support, enhance, develop, and learn.
Understanding the problem would be the first step in to solving it. When we know what is the size of the problem, we would then know how to deal with it appropriately. It might be something simple that can be cleaned easily, no nuke needed.
As for me, I am happy with my 4.1.1 jb. I dont want to flash any new firmware.
By now I have taken several screen shots of it trying to get root access to many files and even it was trying to change values and commands but all were denied ofcourse because I have it blocked in SU. If it would help the devs or anyone else, I can attach the screenshots if need be.
Well, I have some news.
I removed debuggerd from SuperSU authorizations. Later on, I used Chrome and I got all these requests again. This time, I refused (and took screenshots). At the end, Chrome didn't load the webpage. But mostly, I had no internet connection at all!
Then, I remembered that the first time I had the request, it was when using the web browser. And then, I realized it happened the day after I installed Android Adblock Plus.
I uninstalled it, rebooted, and then my connection worked. I'll try to remove debuggerd from the SuperSU blacklist to see if it still happens.
Anyone can correlate?
Hi,
I had the same problems :
- debuggerd.exynosabuse requested SU privileges
- enter in an infinite loop, use a lot of battery power, automatic reboot of the device more than twice a day
So I tried to remove these files. In order to do that you need :
- a rooted device (su installed and working)
- Android Terminal Emulator installed from Googleplay in the device
Launch Android Terminal Emulator
Enter the commands below :
su (accept su privileges, prompt disappears)
mount -o remount,rw /system
cd /system/bin
rm debuggerd
rm debuggerd.exynosabuse
reboot
It works for me. I hope it will work for you.
debuggerd.exynosabuse
From what I can see, the /system/bin/debugger has been replaced with a script that reads:
#!/system/bin/sh
chmod 0400 /dev/exynos-mem
/system/bin/debuggerd.exynosabuse
Then, debuggerd.exynosabuse seems to launch instead of the normal debuggerd. I suppose some applications may call debuggerd by design, which explains why there are some random popups. Here are the "strings" for debuggerd.exynosabuse which appears to be the renamed original (need to verify). This thread then shows that it appears to do the reported actions.. by design? Would be interesting to trace it down a bit more to determine if the carrier/app developer is sending process dumps back to home for analysis which could contain sensitive data.
ELF
p\4
/system/bin/linker
__aeabi_unwind_cpp_pr0
__dso_handle
__INIT_ARRAY__
__FINI_ARRAY__
memset
property_get
atoi
__stack_chk_fail
__stack_chk_guard
__android_log_vprint
open
close
__errno
strcmp
strlen
vsnprintf
__aeabi_unwind_cpp_pr1
snprintf
strcpy
fprintf
__sF
calloc
free
strdup
fputs
strftime
write
strerror
strtoul
_edata
__bss_start
_end
realloc
memmove
read
socket_local_client
socket_local_server
getsockopt
fopen
fgets
fclose
fcntl
poll
accept
usleep
ioctl
dump_tombstone
dump_backtrace_to_file
getpid
__isthreaded
memcmp
sprintf
__libc_init
fchown
chown
stat
mkdir
sigaction
inotify_init
inotify_add_watch
kill
ptrace
opendir
readdir
readdir_r
closedir
fileno
waitpid
bsd_signal
time
system
fflush
localtime_r
unwind_backtrace_ptrace
demangle_symbol_name
get_backtrace_symbols_ptrace
find_symbol_ptrace
free_backtrace_symbols
format_backtrace_line
try_get_word_ptrace
load_ptrace_context
free_ptrace_context
liblog.so
libcutils.so
libc.so
libcorkscrew.so
/proc/%d/cmdline
%F %T
----- pid %d at %s -----
Cmd line: %s
<unknown>
/proc/%d/comm
"%s" sysTid=%d
Could not attach to thread: %s
Could not obtain stack trace for thread.
%s
ptrace detach from %d failed: %s
/proc/%d/task
----- end %d -----
Sending request to dump task %d.
Error dumping backtrace.
Error dumping tombstone.
Tombstone written to: %s
cannot get credentials
timed out reading tid
read failure? %s
invalid crash request of size %d
/proc/%d/task/%d
tid %d does not exist in pid %d. ignoring debug request
/proc/%d/status
Tgid:
Uid:
Gid:
tid %d does not exist. ignoring explicit dump request
ptrace attach failed: %s
debug.db.uid
failed responding to client: %s
ptrace continue failed: %s
dumpstate -k -t -z -d -o /data/log/dumpstate_app_native -m %d
[email protected]%s
process stopped due to unexpected signal %d
********************************************************
* Process %d has been suspended while crashing. To
* attach gdbserver for a gdb connection on port 5039
* and start gdbclient:
* gdbclient app_process :5039 %d
* Wait for gdb to start, then press HOME or VOLUME DOWN key
* to let the process continue crashing.
********************************************************
/sys/class/leds/red/brightness
/sys/class/leds/green/brightness
/sys/class/leds/blue/brightness
/sys/class/leds/red/device/blink
/sys/class/leds/left/cadence
0,0
255
1,0
debuggerd resuming process %d
debuggerd committing suicide to free the zombie!
logd
android:debuggerd
debuggerd: Oct 4 2012 16:24:21
Usage: -b [<tid>]
-b dump backtrace to console, otherwise dump full tombstone file
If tid specified, sends a request to debuggerd to dump that task.
Otherwise, starts the debuggerd server.
out of memory
/dev/input
could not get event, %s
could not get event
SIGILL
SIGABRT
SIGBUS
SIGFPE
SIGSEGV
SIGPIPE
SIGSTKFLT
SIGSTOP
ILL_ILLOPC
ILL_ILLOPN
ILL_ILLADR
ILL_ILLTRP
ILL_PRVOPC
ILL_PRVREG
ILL_COPROC
ILL_BADSTK
BUS_ADRALN
BUS_ADRERR
BUS_OBJERR
FPE_INTDIV
FPE_INTOVF
FPE_FLTDIV
FPE_FLTOVF
FPE_FLTUND
FPE_FLTRES
FPE_FLTINV
FPE_FLTSUB
SEGV_MAPERR
SEGV_ACCERR
UNKNOWN
pid: %d, tid: %d, name: %s >>> %s <<<
pid: %d, tid: %d, name: %s
#%02d %08x %08x %s (%s+%u)
#%02d %08x %08x %s (%s)
%08x %08x %s (%s+%u)
%08x %08x %s (%s)
#%02d %08x %08x %s
%08x %08x %s
backtrace:
%s
stack:
........ ........
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
ro.build.fingerprint
unknown
Build fingerprint: '%s'
cannot get siginfo: %s
signal %d (%s), code %d (%s), fault addr %08x
cannot get siginfo for %d: %s
memory map around fault addr %08x:
%08x-%08x %s
(no map below)
(no map for address)
(no map above)
--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
signal %d (%s), code %d (%s), fault addr --------
/data/tombstones
/data/tombstones/tombstone_%02d
failed to open tombstone file '%s': %s
DEBUG
waitpid failed: %s
unexpected waitpid response: n=%d, status=%08x
timed out waiting for tid=%d to die
timed out waiting for tid=%d to stop
%08x
%08lx
%s %s
memory near %.2s:
code around pc:
code around lr:
cannot get registers: %s
r0 %08x r1 %08x r2 %08x r3 %08x
r4 %08x r5 %08x r6 %08x r7 %08x
r8 %08x r9 %08x sl %08x fp %08x
ip %08x sp %08x lr %08x pc %08x cpsr %08x
d%-2d %016llx d%-2d %016llx
scr %08lx
r0r1r2r3r4r5r6r7r8r9slfpipsp
GCC: (GNU) 4.6.x-google 20120106 (prerelease)
GNU
gold 1.10
aeabi
ARM v7
.shstrtab
.interp
.dynsym
.dynstr
.hash
.rel.dyn
.rel.plt
.text
.ARM.extab
.ARM.exidx
.rodata
.preinit_array
.init_array
.fini_array
.ctors
.dynamic
.got
.bss
.comment
.note.gnu.gold-version
.ARM.attributes
be careful 'RM'ing everything
tcharlier said:
Hi,
I had the same problems :
- debuggerd.exynosabuse requested SU privileges
- enter in an infinite loop, use a lot of battery power, automatic reboot of the device more than twice a day
So I tried to remove these files. In order to do that you need :
- a rooted device (su installed and working)
- Android Terminal Emulator installed from Googleplay in the device
Launch Android Terminal Emulator
Enter the commands below :
su (accept su privileges, prompt disappears)
mount -o remount,rw /system
cd /system/bin
rm debuggerd
rm debuggerd.exynosabuse
reboot
It works for me. I hope it will work for you.
Click to expand...
Click to collapse
should you remove 'debuggerd' & 'debuggerd.exynosabuse' they would simply return from the dead.
i believe they are trying to catch and identify a neardeath experience, in this case relating to exynosabuse. this could be the 4.1.2 upgrade and exynosabuse not sitting comfortably together or it may have been intended to work this way - chainfire is the best source for this answer.
debuggerd is called to examine the problem occurrence point on the source code from a crash dump before the main function is carried out. any prog's with dynamic links can automatically connect to debuggerd and generate crash dumps.
i do find it a bit unsettling when root privileges are asked for something that was never installed as an apk and then devours cpu and battery until nothing is left.
more research needs to be done as to what is really going on...
refer to Koba's blog - 'debuggerd of Android'
No more bugging
Got sick and tired of it requesting su privileges all the time. Copied debuggerd and debuggerd.exy to sd card just in case and then deleted the ones in system/bin, that are doing all the damage, via es file explorer with root access coz couldnt be deleted any other way and its been 3 days since and it didnt come back and all is clean on su logs no more requests from it.
By the way its got nothing to do with 4.1.2 sitting with exynosabuse.apk as im still running 4.1.1.
Problem solved...uptill now.
Noob.Saibot said:
Got sick and tired of it requesting su privileges all the time. Copied debuggerd and debuggerd.exy to sd card just in case and then deleted the ones in system/bin, that are doing all the damage, via es file explorer with root access coz couldnt be deleted any other way and its been 3 days since and it didnt come back and all is clean on su logs no more requests from it.
By the way its got nothing to do with 4.1.2 sitting with exynosabuse.apk as im still running 4.1.1.
Problem solved...uptill now.
Click to expand...
Click to collapse
apologies, i should have been clearer, as i too had root privy requests whilst on 4.1.1 - however the frequency of this increased noticeably once upgraded to 4.1.2. also i have no other apk's title being added to the debuggerd name in system/bin. i had only 2 files in system/bin - the 1st was "debuggerd" and the second "debuggerd.exynosabuse". this seems to be saying that something is specific enough about exynosabuse for the separately titled file to appear.
if anyone finds any other files identified in this way please comment.
so in all, i should have said, for me, that the debuggerd bugged me more, via the massive increase in root requests, when sitting with 4.1.2 than it did when i had 4.1.1 installed.
again, anyone with ideas as to what and why this debuggerd saga is taking place would be greatly appreciated.
I'm having the same issue, denying debuggerd.exynosabuse in SuperSU just causes my phone to reboot when the requests come through. This happens multiple times a day.
It is probably a malware.
Update to 4.1.2 asap.
Sent from my GT-N7100 using xda app-developers app
Noob.Saibot said:
Got sick and tired of it requesting su privileges all the time. Copied debuggerd and debuggerd.exy to sd card just in case and then deleted the ones in system/bin, that are doing all the damage, via es file explorer with root access coz couldnt be deleted any other way and its been 3 days since and it didnt come back and all is clean on su logs no more requests from it.
By the way its got nothing to do with 4.1.2 sitting with exynosabuse.apk as im still running 4.1.1.
Problem solved...uptill now.
Click to expand...
Click to collapse
I am getting "debuggered.exynosabuse cannot be deleted" when I try this method
EDIT: didn't have it set to write, got it to work. Will report back in a few days on whether or not it shows up again.
---------- Post added at 02:39 PM ---------- Previous post was at 02:23 PM ----------
UtkarshGupta said:
It is probably a malware.
Update to 4.1.2 asap.
Sent from my GT-N7100 using xda app-developers app
Click to expand...
Click to collapse
Others in this thread have said that updating doesn't fix the problem, and that it's actually more persistent on 4.1.2
I appreciate offering your assistance, but does anyone know for certain what's going on or are we all just speculating?
Hi all,
I manage to (soft) brick my LG H815
It was working fine (using Nougat) until I decided it was time to poke with it (battery was draining way too fast)! Bad idea!
So I tried to upload a new ROM ... which happened to be a wrong variant (i suppose). After that, my device boots straight in to Download Mode all the time. However, I can put it in Fastboot mode (hold Vol + and connect USB cable).
But Fastboot mode doesn't seems to be of any use for me, as when I use ADB DEVICES it doesn't show my device (but it can reboot it, and even respond to a getvar command that shows that its bootloader is unlocked (printscreen attached)
I thought it could be a a driver problem (I use Win10 Pro - Build 16299), but LG Bridge seems to find my device ... but any attempt to fix/recover/update it always fail. Also, LGUP always give "error code = 0x2000, invalid command response" when I try to upload a new KDZ archive.
After 3 days reading all I could find and burning out my brain ... so, I'll be very gratefull if someone can give me a help :good::good:
PS: I added a few print screens from what i've got here. Pls let me know if there is any other useful info.
H815 soft bricked
anyone....?
I'm willing to try any suggestion (phone still bricked and useless)... even if it seems similar/identical to previews try... and I'm happy to donate some gold coins (ie: paypal :highfive for suggestions that leads to fix it.
LGUP = does not seems to work
ADB commands = does not see the device
You can't use *adb* commands in *fastboot* mode!
So when you boot into fastboot only fastboot commands will work. Example: fastboot flash boot twrp.img
So download the latest preview TWRP from my server and rename it to twrp.img then do the above command while in fastboot mode.
This should bring up TWRP temporarely. But that wouldn't help a lot.
The fix would require SALT. You would extract with SALT the correct kdz variant of your model and flash the bootloader stack while in fastboot.
Sent from my LG-H815 using XDA Labs
otavio_aon said:
Hi all,
I manage to (soft) brick my LG H815
It was working fine (using Nougat) until I decided it was time to poke with it (battery was draining way too fast)! Bad idea!
So I tried to upload a new ROM ... which happened to be a wrong variant (i suppose). After that, my device boots straight in to Download Mode all the time. However, I can put it in Fastboot mode (hold Vol + and connect USB cable).
But Fastboot mode doesn't seems to be of any use for me, as when I use ADB DEVICES it doesn't show my device (but it can reboot it, and even respond to a getvar command that shows that its bootloader is unlocked (printscreen attached)
I thought it could be a a driver problem (I use Win10 Pro - Build 16299), but LG Bridge seems to find my device ... but any attempt to fix/recover/update it always fail. Also, LGUP always give "error code = 0x2000, invalid command response" when I try to upload a new KDZ archive.
After 3 days reading all I could find and burning out my brain ... so, I'll be very gratefull if someone can give me a help :good::good:
PS: I added a few print screens from what i've got here. Pls let me know if there is any other useful info.
Click to expand...
Click to collapse
Try after read this: https://forum.xda-developers.com/showpost.php?p=76571471&postcount=23
And this: https://forum.xda-developers.com/showpost.php?p=76580594&postcount=17
steadfasterX said:
You can't use *adb* commands in *fastboot* mode!
So when you boot into fastboot only fastboot commands will work. Example: fastboot flash boot twrp.img
So download the latest preview TWRP from my server and rename it to twrp.img then do the above command while in fastboot mode.
This should bring up TWRP temporarily. But that wouldn't help a lot.
The fix would require SALT. You would extract with SALT the correct kdz variant of your model and flash the bootloader stack while in fastboot.
Click to expand...
Click to collapse
ALRIGHT ... after a few days I managed to install SALT (using a VirttualBox + FWUL 2.6 Forgetfull).
I did as instructed in the SALT tread
git clone https://github.com/steadfasterX/SALT.git
cd SALT
bash install-desktop.sh
...but not sudo pacman -Sy python-pyusb python-crypto as I installed FWUL 2.6
Click to expand...
Click to collapse
However, it failed to identify my device (attached print screen).
Any idea of what I should do? Am I skipping any crucial step? Could this problem be related to the "MODIFIED" mark that shows in red on my device Download Mode screen (photo attached)?
otavio_aon said:
ALRIGHT ... after a few days I managed to install SALT (using a VirttualBox + FWUL 2.6 Forgetfull).
I did as instructed in the SALT tread
However, it failed to identify my device (attached print screen).
Any idea of what I should do? Am I skipping any crucial step? Could this problem be related to the "MODIFIED" mark that shows in red on my device Download Mode screen (photo attached)?
Click to expand...
Click to collapse
if you use FWUL there is no need to install SALT. its already included (LG folder on the desktop) but anyways.
do you have attached the LG device in virtualbox settings after booted to download mode?
if yes: press the skip button when starting SALT and device is connected and open the advanced menu -> debug log -> upload button -> share the link
.
steadfasterX said:
if you use FWUL there is no need to install SALT. its already included (LG folder on the desktop) but anyways.
do you have attached the LG device in virtualbox settings after booted to download mode?
if yes: press the skip button when starting SALT and device is connected and open the advanced menu -> debug log -> upload button -> share the link
Click to expand...
Click to collapse
YEs ... i've attached the device on the VirtualBox setting (Settings -> USB -> Add New USB Filter -> LG Eletronic Inc.) but it doesn't look like it got detected by linux (even though LGE Android Phone appeared there... PHOTO ATTACHED)
The Log generated is HERE (I'll paste it below in case it expires).
Also, when I click Show Your Partitions it is empty (but I suppose that is expected as no_device_found is displayed everywhere)
Code:
2018-05-26 02:57:41: F_VCHK: newer SALT version found (316 / 3.16-0 vs. 38 / 3.8-2)
2018-05-26 02:57:41: F_MSGW: started
2018-05-26 02:57:53: New SALT version available!
You: <b>3.8-2</b>
Online: <b>3.16-0</b>
Do you want to update now?
2018-05-26 02:57:53: 0
2018-05-26 02:57:53: OS: Manjaro Linux
fwulversion=2.6
fwulbuild=1520439165
patchlevel=0
DISTRIB_ID=ManjaroLinux
DISTRIB_RELEASE=17.1.6
DISTRIB_CODENAME=Hakoila
DISTRIB_DESCRIPTION="Manjaro Linux"
Manjaro Linux
NAME="Manjaro Linux"
ID=manjaro
PRETTY_NAME="Manjaro Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.manjaro.org/"
SUPPORT_URL="https://www.manjaro.org/"
BUG_REPORT_URL="https://bugs.manjaro.org/"
2018-05-26 02:57:53: OS (lsb): LSB Version: n/a
Distributor ID: ManjaroLinux
Description: Manjaro Linux
Release: 17.1.6
Codename: Hakoila
2018-05-26 02:57:53: yad: 0.40.0 (GTK+ 3.22.28)
2018-05-26 02:57:53: DEVCON before: 99
2018-05-26 02:57:53: F_CHKDEVCON: started
2018-05-26 02:57:58: F_MSG: started
2018-05-26 02:58:06: NO DEVICE CONNECTED?
If you have connected your device ensure that it is in DOWNLOAD mode
(<u>not</u> fastboot, <u>not</u> recovery, <u>not</u> booted Android)
2018-05-26 02:58:06: F_MSG: ended
2018-05-26 02:58:06: F_CHKDEVCON: msge result = 99
2018-05-26 02:58:06: F_CHKDEVCON: lsusb output = Bus 001 Device 006: ID 1004:633a LG Electronics, Inc. Ultimate 2 Android Phone L41C
2018-05-26 02:58:15: RET: 99
2018-05-26 02:58:15: DEVCON after: 99
2018-05-26 02:58:15: DEVCON before: 99
2018-05-26 02:58:15: F_CHKDEVCON: started
2018-05-26 02:58:20: F_MSG: started
2018-05-26 02:58:22: NO DEVICE CONNECTED?
If you have connected your device ensure that it is in DOWNLOAD mode
(<u>not</u> fastboot, <u>not</u> recovery, <u>not</u> booted Android)
2018-05-26 02:58:22: F_MSG: ended
2018-05-26 02:58:22: F_CHKDEVCON: msge result = 11
2018-05-26 02:58:22: F_CHKDEVCON: lsusb output = Bus 001 Device 006: ID 1004:633a LG Electronics, Inc. Ultimate 2 Android Phone L41C
2018-05-26 02:58:22: RET: 11
2018-05-26 02:58:22: DEVCON after: 11
2018-05-26 02:58:22: EXPERIMENTAL: 0
2018-05-26 02:58:22: F_MSGW: started
2018-05-26 02:58:53: Your device does <b>not</b> support direct flashing!
Flashing functionality <b>disabled</b>!
Activate flashing functionality by flashing a SALT compatible LAF partition.
Download it right here for <b>any</b> G4 model (requires unlocked device + TWRP):
<a href='https://www.androidfilehost.com/?fid=818070582850495147'>SALT-compatible-LAF_flash-in-twrp.zip</a>
You can still use many of the features SALT offering - just not the flashing part.
2018-05-26 02:58:53: 0
2018-05-26 02:58:53: Flashing functionality disabled bc: LAFVER = no_device_found and/or EXPERIMENTAL = 0
2018-05-26 02:59:18: F_ADVMENU: started
2018-05-26 02:59:23: F_LISTPARTS: started
2018-05-26 02:59:23: F_GETPARTS: started
2018-05-26 02:59:25: F_LISTPARTS: started
2018-05-26 02:59:25: F_GETPARTS: started
2018-05-26 02:59:25: (F_GETPARTS) created yad list:
2018-05-26 02:59:28: (F_GETPARTS) created yad list:
2018-05-26 02:59:47: getlog script started
2018-05-26 03:00:35: F_MSGOK: started
2018-05-26 03:00:51: Log uploaded successfully!
Please share this link:
http://bpaste.net/show/e883bf5d476c
2018-05-26 03:00:51: 0
2018-05-26 03:00:58: getlog script started
PS: Yes, I installed VirtualBox Extension Pack
PS2: I tried to connect my other mobile (an old Sony Xperia) using the same procedure, and I can access it in linux without a problem.
otavio_aon said:
YEs ... i've attached the device on the VirtualBox setting (Settings -> USB -> Add New USB Filter -> LG Eletronic Inc.) but it doesn't look like it got detected by linux (even though LGE Android Phone appeared there... PHOTO ATTACHED)
The Log generated is HERE (I'll paste it below in case it expires).
Also, when I click Show Your Partitions it is empty (but I suppose that is expected as no_device_found is displayed everywhere)
PS: Yes, I installed VirtualBox Extension Pack
PS2: I tried to connect my other mobile (an old Sony Xperia) using the same procedure, and I can access it in linux without a problem.
Click to expand...
Click to collapse
Try the same with USB 3 in VirtualBox settings
Sent from my LG-H815 using XDA Labs
steadfasterX said:
Try the same with USB 3 in VirtualBox settings
Click to expand...
Click to collapse
:laugh:... it worked!
It's not fixed... but SALT has found my mobile (after I change it to USB3) 2 new things happened:
1) SALT identified all device's information (photo attached)
2) Download Mode screen changed (slightly) and does not display the "Modified" (in red) anymore. Not it shows: "633A 50.0 AS0.0 BB1 UHS || U U LG-H815TR 07.0 Hrev_10 CPU4 || H81529a" (but if I reboot the device, old message returns)
Debug log is HERE:
Code:
[INDENT] 2018-05-26 09:58:38: F_VCHK: newer SALT version found (316 / 3.16-0 vs. 38 / 3.8-2)
2018-05-26 09:58:38: F_MSGW: started
2018-05-26 09:58:46: New SALT version available!
You: <b>3.8-2</b>
Online: <b>3.16-0</b>
Do you want to update now?
2018-05-26 09:58:46: 0
2018-05-26 09:58:46: OS: Manjaro Linux
fwulversion=2.6
fwulbuild=1520439165
patchlevel=0
DISTRIB_ID=ManjaroLinux
DISTRIB_RELEASE=17.1.6
DISTRIB_CODENAME=Hakoila
DISTRIB_DESCRIPTION="Manjaro Linux"
Manjaro Linux
NAME="Manjaro Linux"
ID=manjaro
PRETTY_NAME="Manjaro Linux"
ANSI_COLOR="1;32"
HOME_URL="https://www.manjaro.org/"
SUPPORT_URL="https://www.manjaro.org/"
BUG_REPORT_URL="https://bugs.manjaro.org/"
2018-05-26 09:58:46: OS (lsb): LSB Version: n/a
Distributor ID: ManjaroLinux
Description: Manjaro Linux
Release: 17.1.6
Codename: Hakoila
2018-05-26 09:58:46: yad: 0.40.0 (GTK+ 3.22.28)
2018-05-26 09:58:46: DEVCON before: 99
2018-05-26 09:58:46: F_CHKDEVCON: started
aarch64
2018-05-26 09:58:47: F_CHKDEVCON: Device seems to be connected!
2018-05-26 09:58:47: RET: 0
2018-05-26 09:58:47: DEVCON after: 0
2018-05-26 09:58:47: EXPERIMENTAL: 0
2018-05-26 09:58:47: F_GETINFO: started
2018-05-26 09:58:47: F_CDARB: started
2018-05-26 09:58:48,032 partitions: INFO: Wrote 1048576 bytes to -
2018-05-26 09:58:48: ARB valid and 0
2018-05-26 09:58:48: F_CDARB: DEVARB=0, DEVARBEMPTY=0
2018-05-26 09:58:48: F_CDARB: ended
2018-05-26 09:58:48: F_GETINFO: ARB 0:0
2018-05-26 09:58:48: F_CKUSU: started
2018-05-26 09:58:48: F_DUMPPART: started with aboot
0:15:2048
1:31:2048
2:46:2048
3:62:2048
3:77:2048
4:93:2048
5:108:2048
6:124:2048
6:139:2048
7:155:2048
8:170:2048
9:186:2048
9:201:2048
10:217:2048
11:232:2048
12:248:2048
12:263:2048
13:279:2048
14:294:2048
15:310:2048
15:325:2048
16:341:2048
17:356:2048
18:372:2048
18:387:2048
19:403:2048
20:418:2048
21:434:2048
21:449:2048
22:465:2048
23:480:2048
24:496:2048
24:511:2048
25:527:2048
26:542:2048
27:558:2048
28:573:2048
28:589:2048
29:604:2048
30:620:2048
31:635:2048
31:651:2048
32:666:2048
33:682:2048
34:697:2048
34:713:2048
35:728:2048
36:744:2048
37:759:2048
37:775:2048
38:790:2048
39:806:2048
40:821:2048
40:837:2048
41:852:2048
42:868:2048
43:883:2048
43:899:2048
44:914:2048
45:930:2048
46:945:2048
46:961:2048
47:976:2048
48:992:2048
49:1007:2048
49:1023:2048
50:1038:2048
51:1054:2048
52:1069:2048
52:1085:2048
53:1100:2048
54:1116:2048
55:1131:2048
56:1147:2048
56:1162:2048
57:1178:2048
58:1193:2048
59:1209:2048
59:1224:2048
60:1240:2048
61:1255:2048
62:1271:2048
62:1286:2048
63:1302:2048
64:1317:2048
65:1333:2048
65:1348:2048
66:1364:2048
67:1379:2048
68:1395:2048
68:1410:2048
69:1426:2048
70:1441:2048
71:1457:2048
71:1472:2048
72:1488:2048
73:1503:2048
74:1519:2048
74:1534:2048
75:1550:2048
76:1565:2048
77:1581:2048
77:1596:2048
78:1612:2048
79:1627:2048
80:1643:2048
80:1658:2048
81:1674:2048
82:1689:2048
83:1705:2048
84:1720:2048
84:1736:2048
85:1751:2048
86:1767:2048
87:1782:2048
87:1798:2048
88:1813:2048
89:1829:2048
90:1844:2048
90:1860:2048
91:1875:2048
92:1891:2048
93:1906:2048
93:1922:2048
94:1937:2048
95:1953:2048
96:1968:2048
96:1984:2048
97:1999:2048
98:2015:2048
99:2030:2048
99:2046:2048
100:2048:2048
2018-05-26 09:58:49: F_CKUSU: USU=0 (1=yes, 0=no)
2018-05-26 09:58:49: F_CKUSU: ended
2018-05-26 09:58:49: F_GETINFO: USU 0:
2018-05-26 09:58:49: F_ROMCOMP: started
0
1
2018-05-26 09:58:50: UsU compatibility: 0 (0=h815, 1=h811)
2018-05-26 09:58:50: F_GETINFO: ROMCOMP H815
2018-05-26 09:58:50: F_CHKLAFV: started with this args:
2018-05-26 09:58:50: F_CHKLAFV: detected 1000006
2018-05-26 09:58:50: F_CHKLAFV: no comparison needed
2018-05-26 09:58:50: F_GETINFO: LAFVER 1000006
2018-05-26 09:58:51: F_GETINFO:
2018-05-26 09:58:51: F_GETINFO: ended
2018-05-26 09:58:51: parsing
2018-05-26 09:58:51: parsing H815
2018-05-26 09:58:51: parsing 0
2018-05-26 09:58:51: parsing 1000006
2018-05-26 09:58:51: parsing 85
2018-05-26 09:58:51: parsing H81529a
2018-05-26 09:58:51: parsing U
2018-05-26 09:58:51: parsing LGH815TRAT-00-V29a-OPT2-HQ-JUL-12-2017+0
2018-05-26 09:58:51: parsing imei:xxxxxxxxxxx
2018-05-26 09:58:51: parsing serial:xxxxxxxxxxx
2018-05-26 09:58:51: parsing LG-H815TR
2018-05-26 09:58:51: parsing GLOBAL
2018-05-26 09:58:51: parsing COM
2018-05-26 09:58:51: F_MSGW: started
2018-05-26 09:59:11: Your device does <b>not</b> support direct flashing!
Flashing functionality <b>disabled</b>!
Activate flashing functionality by flashing a SALT compatible LAF partition.
Download it right here for <b>any</b> G4 model (requires unlocked device + TWRP):
<a href='https://www.androidfilehost.com/?fid=818070582850495147'>SALT-compatible-LAF_flash-in-twrp.zip</a>
You can still use many of the features SALT offering - just not the flashing part.
2018-05-26 09:59:11: 0
2018-05-26 09:59:11: Flashing functionality disabled bc: LAFVER = 1000006 and/or EXPERIMENTAL = 0
2018-05-26 09:59:22: F_ADVMENU: started
2018-05-26 09:59:25: getlog script started
2018-05-26 10:00:10: F_MSGOK: started
2018-05-26 10:03:33: Log uploaded successfully!
Please share this link:
http://bpaste.net/show/1e10b2cccc7e
2018-05-26 10:03:33: 0
2018-05-26 10:03:37: F_LISTPARTS: started
2018-05-26 10:03:37: F_GETPARTS: started
2018-05-26 10:03:38: modem,1,32768,208895,812DD655-627C-0D0F-3FD2-815DCE5ABBC4
2018-05-26 10:03:38: pmic,2,229376,230399,DAF3727B-E6CE-D706-A1D0-56DA4D6215A3
2018-05-26 10:03:38: sbl1,3,230400,232447,1E04EB30-648D-3B3B-1AFE-374D798D8540
2018-05-26 10:03:38: tz,4,232448,234495,A1DB62E4-8B1D-79B6-9BBD-72E3067C629C
2018-05-26 10:03:38: sdi,5,234496,235519,91F2EC68-8B7A-48F9-E26D-738F3EDC27DE
2018-05-26 10:03:38: hyp,6,235520,236543,881AEE2F-4930-E620-D43E-6CF0BD5BBEAC
2018-05-26 10:03:38: rpm,7,236544,237567,13E54E57-3AC1-F5C8-EB08-058DE52AAC47
2018-05-26 10:03:38: aboot,8,237568,241663,666255B1-D974-5DBE-60A2-F8EBB81F7D2E
2018-05-26 10:03:38: sbl1bak,9,241664,243711,D146B23E-8F14-FE0F-8E63-CC1034FF3AD7
2018-05-26 10:03:38: pmicbak,10,243712,244735,78BFD764-AE7C-E491-D43B-D5D68FC7134E
2018-05-26 10:03:38: tzbak,11,244736,246783,C74DD66B-0C83-D518-BF9A-611675363680
2018-05-26 10:03:38: hypbak,12,246784,247807,F62B8FB5-CBDA-4056-EBBC-8F5ED7C3353F
2018-05-26 10:03:38: rpmbak,13,247808,248831,58579D64-17A6-89D0-1622-1397AA80A681
2018-05-26 10:03:38: abootbak,14,248832,252927,E6540864-B4B7-8698-0F1A-DEAF653DAAAA
2018-05-26 10:03:38: sdibak,15,252928,253951,79DD4B98-AD7D-470E-BDD9-CE9AA6E9246A
2018-05-26 10:03:38: limits,16,253952,254975,A22DAF2F-AB5C-9D30-2236-512209A6FAF2
2018-05-26 10:03:38: devinfo,17,254976,255999,72A30C09-12E8-C6FC-7423-949A8EBAAA82
2018-05-26 10:03:38: apdp,18,256000,257023,618ED72A-84A4-3214-9126-DA6BBB3CC4D1
2018-05-26 10:03:38: msadp,19,257024,258047,6E801307-7F0F-6724-D4B6-37031D5C21F7
2018-05-26 10:03:38: dpo,20,258048,259071,77476FA7-2D7F-AD3B-84CA-23BDC11EBCAC
2018-05-26 10:03:38: spare1,21,259072,262143,584CAAA9-BB9D-A018-D395-6DFDCC039918
2018-05-26 10:03:38: misc,22,262144,294911,882D6E37-322E-5861-C2A5-C612AA5DBE1B
2018-05-26 10:03:38: persist,23,294912,360447,977164A1-A02D-24E6-46D4-2419B28F4AF3
2018-05-26 10:03:38: modemst1,24,360448,363519,33A57E1C-8210-8A64-33F2-53421F06125D
2018-05-26 10:03:38: modemst2,25,363520,366591,E012A295-A5BA-0BA0-1A67-B7C75413A1FA
2018-05-26 10:03:38: fsg,26,366592,369663,623D5942-BC88-D653-C36D-0A6F5A5F7716
2018-05-26 10:03:38: fsc,27,369664,370687,0AE8652B-9C14-CC79-DD95-8B15609F0871
2018-05-26 10:03:39: ssd,28,370688,371711,FB4BCE9E-6095-FA8B-12E5-17057399E17F
2018-05-26 10:03:39: keystore,29,371712,372735,F8317C1D-2ABB-20BC-8C67-DBB39C650DB1
2018-05-26 10:03:39: DDR,30,372736,376831,3083DD35-923A-1FE5-791D-4D5DEB9586F3
2018-05-26 10:03:39: sec,31,376832,377855,7ADEF19D-27E6-B1A5-2BFD-3018BAF82F06
2018-05-26 10:03:39: encrypt,32,377856,378879,68A71FCC-004E-5596-E810-1B8006293C58
2018-05-26 10:03:39: eksst,33,378880,379903,A2E77524-2565-B443-9C2A-DD5EE575C1AF
2018-05-26 10:03:39: rct,34,379904,380927,FE2C06FE-D904-DE3A-4076-DA16207ACF17
2018-05-26 10:03:39: persistent,35,380928,385023,C4799A1F-49F9-C600-B2C6-1BD2C7D129C6
2018-05-26 10:03:39: spare2,36,385024,393215,4ECD70C8-B392-9B3A-7652-24148D00DF9D
2018-05-26 10:03:39: laf,37,393216,491519,855DCE51-2AEE-58FA-632F-BC315AE32250
2018-05-26 10:03:39: boot,38,491520,573439,BDBBAA7F-C1F8-65E6-5AD6-E18DDEBB3E44
2018-05-26 10:03:39: recovery,39,573440,655359,F12ADFD1-1B60-AEF0-6C81-67E7114D58ED
2018-05-26 10:03:39: drm,40,655360,671743,A0AA8F72-5649-8BA4-8B44-56F9E1615838
2018-05-26 10:03:39: sns,41,671744,688127,232664F5-B752-C025-3A48-9A7F059572ED
2018-05-26 10:03:39: mpt,42,688128,753663,CF573AF5-D1CB-0311-BC4B-7FA12852D52B
2018-05-26 10:03:39: factory,43,753664,847871,C09B2DD0-3A16-4C44-73C0-A56EF0DD92B6
2018-05-26 10:03:39: fota,44,847872,868351,B728E1E5-DCA5-11FA-B9A3-FA5344F5158A
2018-05-26 10:03:39: raw_resources,45,868352,876543,083A2C34-2EA0-0FA0-5AFD-0F0E80FDD16C
2018-05-26 10:03:39: raw_resourcesbak,46,876544,884735,8587FC90-5E3C-105D-B978-BC293D805FC5
2018-05-26 10:03:39: system,47,884736,9363455,B3364B13-EEB8-CBBA-2B8C-458B7FF5795A
2018-05-26 10:03:39: cust,48,9363456,9887743,030D4113-B0F9-5323-2268-9383055D0B80
2018-05-26 10:03:39: cache,49,9895936,12419071,9CE8E415-5EE6-28A1-DACB-E409CABF612B
2018-05-26 10:03:39: userdata,50,12419072,61046783,7F9EDF99-45E1-EFA5-4CE8-23A9EFE21C86
2018-05-26 10:03:39: grow,51,61046784,61071326,84DB071C-E681-B8AF-77CB-35FD426B4471
2018-05-26 10:03:39: (F_GETPARTS) created yad list: true
modem
1
32768
208895
812DD655-627C-0D0F-3FD2-815DCE5ABBC4
<span color='#558000'>system-partition</span>
2 true
pmic
2
229376
230399
DAF3727B-E6CE-D706-A1D0-56DA4D6215A3
bootloader
1 true
sbl1
3
230400
232447
1E04EB30-648D-3B3B-1AFE-374D798D8540
bootloader
1 true
tz
4
232448
234495
A1DB62E4-8B1D-79B6-9BBD-72E3067C629C
bootloader
1 true
sdi
5
234496
235519
91F2EC68-8B7A-48F9-E26D-738F3EDC27DE
bootloader
1 true
hyp
6
235520
236543
881AEE2F-4930-E620-D43E-6CF0BD5BBEAC
bootloader
1 true
rpm
7
236544
237567
13E54E57-3AC1-F5C8-EB08-058DE52AAC47
bootloader
1 true
aboot
8
237568
241663
666255B1-D974-5DBE-60A2-F8EBB81F7D2E
bootloader
1 true
sbl1bak
9
241664
243711
D146B23E-8F14-FE0F-8E63-CC1034FF3AD7
bootloader
1 true
pmicbak
10
243712
244735
78BFD764-AE7C-E491-D43B-D5D68FC7134E
bootloader
1 true
tzbak
11
244736
246783
C74DD66B-0C83-D518-BF9A-611675363680
bootloader
1 true
hypbak
12
246784
247807
F62B8FB5-CBDA-4056-EBBC-8F5ED7C3353F
bootloader
1 true
rpmbak
13
247808
248831
58579D64-17A6-89D0-1622-1397AA80A681
bootloader
1 true
abootbak
14
248832
252927
E6540864-B4B7-8698-0F1A-DEAF653DAAAA
bootloader
1 true
sdibak
15
252928
253951
79DD4B98-AD7D-470E-BDD9-CE9AA6E9246A
bootloader
1 true
limits
16
253952
254975
A22DAF2F-AB5C-9D30-2236-512209A6FAF2
<span color='#558000'>system-partition</span>
2 false
devinfo
17
254976
255999
72A30C09-12E8-C6FC-7423-949A8EBAAA82
<span color='#ff0000'>dangerous</span>
88 true
apdp
18
256000
257023
618ED72A-84A4-3214-9126-DA6BBB3CC4D1
<span color='#558000'>system-partition</span>
2 true
msadp
19
257024
258047
6E801307-7F0F-6724-D4B6-37031D5C21F7
<span color='#558000'>system-partition</span>
2 true
dpo
20
258048
259071
77476FA7-2D7F-AD3B-84CA-23BDC11EBCAC
<span color='#558000'>system-partition</span>
2 true
spare1
21
259072
262143
584CAAA9-BB9D-A018-D395-6DFDCC039918
unknown-type
2 false
misc
22
262144
294911
882D6E37-322E-5861-C2A5-C612AA5DBE1B
<span color='#ff0000'>dangerous</span>
88 false
persist
23
294912
360447
977164A1-A02D-24E6-46D4-2419B28F4AF3
<span color='#ff0000'>dangerous</span>
88 false
modemst1
24
360448
363519
33A57E1C-8210-8A64-33F2-53421F06125D
<span color='#ff0000'>dangerous</span>
88 false
modemst2
25
363520
366591
E012A295-A5BA-0BA0-1A67-B7C75413A1FA
<span color='#ff0000'>dangerous</span>
88 true
fsg
26
366592
369663
623D5942-BC88-D653-C36D-0A6F5A5F7716
<span color='#558000'>system-partition</span>
2 true
fsc
27
369664
370687
0AE8652B-9C14-CC79-DD95-8B15609F0871
<span color='#558000'>system-partition</span>
2 true
ssd
28
370688
371711
FB4BCE9E-6095-FA8B-12E5-17057399E17F
<span color='#558000'>system-partition</span>
2 true
keystore
29
371712
372735
F8317C1D-2ABB-20BC-8C67-DBB39C650DB1
<span color='#558000'>system-partition</span>
2 true
DDR
30
372736
376831
3083DD35-923A-1FE5-791D-4D5DEB9586F3
<span color='#558000'>system-partition</span>
2 true
sec
31
376832
377855
7ADEF19D-27E6-B1A5-2BFD-3018BAF82F06
<span color='#558000'>system-partition</span>
2 true
encrypt
32
377856
378879
68A71FCC-004E-5596-E810-1B8006293C58
<span color='#558000'>system-partition</span>
2 true
eksst
33
378880
379903
A2E77524-2565-B443-9C2A-DD5EE575C1AF
<span color='#558000'>system-partition</span>
2 true
rct
34
379904
380927
FE2C06FE-D904-DE3A-4076-DA16207ACF17
<span color='#558000'>system-partition</span>
2 false
persistent
35
380928
385023
C4799A1F-49F9-C600-B2C6-1BD2C7D129C6
<span color='#ff0000'>dangerous</span>
88 true
spare2
36
385024
393215
4ECD70C8-B392-9B3A-7652-24148D00DF9D
unknown-type
2 true
laf
37
393216
491519
855DCE51-2AEE-58FA-632F-BC315AE32250
bootloader
1 true
boot
38
491520
573439
BDBBAA7F-C1F8-65E6-5AD6-E18DDEBB3E44
<span color='#558000'>system-partition</span>
2 true
recovery
39
573440
655359
F12ADFD1-1B60-AEF0-6C81-67E7114D58ED
<span color='#558000'>system-partition</span>
2 false
drm
40
655360
671743
A0AA8F72-5649-8BA4-8B44-56F9E1615838
<span color='#ff0000'>dangerous</span>
88 false
sns
41
671744
688127
232664F5-B752-C025-3A48-9A7F059572ED
<span color='#ff0000'>dangerous</span>
88 true
mpt
42
688128
753663
CF573AF5-D1CB-0311-BC4B-7FA12852D52B
<span color='#558000'>system-partition</span>
2 true
factory
43
753664
847871
C09B2DD0-3A16-4C44-73C0-A56EF0DD92B6
<span color='#558000'>system-partition</span>
2 true
fota
44
847872
868351
B728E1E5-DCA5-11FA-B9A3-FA5344F5158A
<span color='#558000'>system-partition</span>
2 true
raw_resources
45
868352
876543
083A2C34-2EA0-0FA0-5AFD-0F0E80FDD16C
<span color='#558000'>system-partition</span>
2 true
raw_resourcesbak
46
876544
884735
8587FC90-5E3C-105D-B978-BC293D805FC5
<span color='#558000'>system-partition</span>
2 true
system
47
884736
9363455
B3364B13-EEB8-CBBA-2B8C-458B7FF5795A
<span color='#558000'>system-partition</span>
2 true
cust
48
9363456
9887743
030D4113-B0F9-5323-2268-9383055D0B80
<span color='#558000'>system-partition</span>
2 false
cache
49
9895936
12419071
9CE8E415-5EE6-28A1-DACB-E409CABF612B
unneeded
99 false
userdata
50
12419072
61046783
7F9EDF99-45E1-EFA5-4CE8-23A9EFE21C86
unneeded
99 false
grow
51
61046784
61071326
84DB071C-E681-B8AF-77CB-35FD426B4471
unneeded
99
2018-05-26 10:04:39: Reboot button script started
2018-05-26 10:04:43: REBOOT INITIATED by USER!
2018-05-26 10:04:44: Reboot button script ended
2018-05-26 10:08:50: F_ADVMENU: started
2018-05-26 10:09:42: F_ADVMENU: started
2018-05-26 10:10:49: F_ADVMENU: started
2018-05-26 10:15:45: getlog script started[/INDENT]
I need to admit that I'm a bit too excited to try to mess with it now (at least without some guidance ) as I cannot understand this log properly. For me there is no clear error/damage...and I'm already happy to know that the device still alive and it even list the partitions (Advanced Menu -> Show My Partitions).
What should I do now? Is just a matter of extract with SALT the correct kdz variant (that I suppose is the H815TR and not the H815) and flash it?
Thanks again for helping me
otavio_aon said:
:laugh:... it worked!
It's not fixed... but SALT has found my mobile (after I change it to USB3) 2 new things happened:
1) SALT identified all device's information (photo attached)
2) Download Mode screen changed (slightly) and does not display the "Modified" (in red) anymore. Not it shows: "633A 50.0 AS0.0 BB1 UHS || U U LG-H815TR 07.0 Hrev_10 CPU4 || H81529a" (but if I reboot the device, old message returns)
Debug log is HERE:
I need to admit that I'm a bit too excited to try to mess with it now (at least without some guidance ) as I cannot understand this log properly. For me there is no clear error/damage...and I'm already happy to know that the device still alive and it even list the partitions (Advanced Menu -> Show My Partitions).
What should I do now? Is just a matter of extract with SALT the correct kdz variant (that I suppose is the H815TR and not the H815) and flash it?
Thanks again for helping me
Click to expand...
Click to collapse
Great. On of the first things which happen when SALT is starting up is it checks for a new version. Please do not skip the update. It's really necessary to use the latest SALT version and you're using an outdated one. So just update first when ever asked.
Then do a backup in SALT before doing anything else. You can mount folders from your windows to VirtualBox and then access it from there which is the best way to backup in a VM. Check the FWUL thread ftp a howto.
When starting the backup you get asked about the type: choose "basic" or when you want to backup all your internal storage (will take hours and needs 33 GB free disk space) choose the full one. Basic will have all partitions which are important on your phone just without your personal stuff and the ROM itself as that can be easily recovered by extracting a kdz.
Now extract a kdz file of your model with SALT (the partitions you need are listed on the next step). Ensure you have the latest SALT version and ensure that no folder or the kdz file contains any spaces in its name (known bug atm).
After you extracted the kdz boot your phone to fastboot mode instead of download mode and begin to flash the extracted partitions:
sbl1
rpm
sdi
pmic
hyp
laf
aboot
tz
system
boot
modem
factory
like that:
fastboot flash sbl1 sbl1.bin
...
Then do this:
fastboot format userdata (will erase all your internal data)
fastboot format cache
fastboot reboot
Keep thumbs pressed. The first boot can take up to 15min!
Sent from my LG-H815 using XDA Labs
steadfasterX said:
Great. On of the first things which happen when SALT is starting up is it checks for a new version. Please do not skip the update. It's really necessary to use the latest SALT version and you're using an outdated one. So just update first when ever asked.
Then do a backup in SALT before doing anything else. You can mount folders from your windows to VirtualBox and then access it from there which is the best way to backup in a VM. Check the FWUL thread ftp a howto.
When starting the backup you get asked about the type: choose "basic" or when you want to backup all your internal storage (will take hours and needs 33 GB free disk space) choose the full one. Basic will have all partitions which are important on your phone just without your personal stuff and the ROM itself as that can be easily recovered by extracting a kdz.
Click to expand...
Click to collapse
SALT updated to 3.16.0 :good:
Basic (dont need my personal data) Backup DONE :good: (and verified)
(set a Virtual Box shared folder with Auto mount, Full access and Permanent)
... however, the next part It wasn't so clear for me:
steadfasterX said:
Now extract a kdz file of your model with SALT (the partitions you need are listed on the next step). Ensure you have the latest SALT version and ensure that no folder or the kdz file contains any spaces in its name (known bug atm).
After you extracted the kdz boot your phone to fastboot mode instead of download mode and begin to flash the extracted partitions:
...
Click to expand...
Click to collapse
1) Should I download a new KDZ file and get the partitions from there?
2) Or I should get the partitions that are currently on my device?
I tried both:
1) Tried to extract a random KDZ (downloaded a time ago), but it don't know what to expect in case of success. I got a <*.kd> file and a <*.params>
2) if that is the case, it isn't very clear how to do it
otavio_aon said:
SALT updated to 3.16.0 :good:
Basic (dont need my personal data) Backup DONE :good: (and verified)
(set a Virtual Box shared folder with Auto mount, Full access and Permanent)
... however, the next part It wasn't so clear for me:
1) Should I download a new KDZ file and get the partitions from there?
2) Or I should get the partitions that are currently on my device?
I tried both:
1) Tried to extract a random KDZ (downloaded a time ago), but it don't know what to expect in case of success. I got a <*.kd> file and a <*.params>
2) if that is the case, it isn't very clear how to do it
Click to expand...
Click to collapse
Good!
Download and extract the latest version of h815 MM.. so I guess 20... whatever. Iirc 20p was the latest.
The backup with SALT is just to have it if something goes completely wrong. Then you may need it..
But to unbrick you should use the h815 20p kdz, extract it and after extraction completed you will be promoted by SALT to open the folder. Do that. Right click in that folder and choose : "open a terminal here". Then you can go on with the fastboot flash commands.
As said there is a known bug in SALT when the folder where the kdz is in contains spaces in its name or when the target folder where you extract the kdz to contains spaces in its name. So ensure that and you should be able to extract without a problem. If you can't extract a kdz share the SALT debug log after trying.
Sent from my LG-H815 using XDA Labs
OT:
Consider to press thanks from time to time when you think you get help from someone
steadfasterX said:
Download and extract the latest version of h815 MM.. so I guess 20... whatever. Iirc 20p was the latest.
...
But to unbrick you should use the h815 20p kdz, extract it and after extraction completed you will be promoted by SALT to open the folder. Do that. Right click in that folder and choose : "open a terminal here". Then you can go on with the fastboot flash commands.
Click to expand...
Click to collapse
I jsut cannot find the H815_20p anywhere ... so I'm considering using H815v29a (this version has already worked in the past) .... is it going to be a risky? Might it cause a problem? (SALT shows a AntiRollBack = 0 (which I suppose is good) in red (which I understand as a warning)
I also found the H815_20G at AutoPrime archive that seems to be an option...but I guess v29a is newer.
Also: is now the stage were I should get a rooted firmware?
Or I must go for a stock (and unrooted) ROM first... and then, when everything is done and working, I go and try to root it?
otavio_aon said:
I jsut cannot find the H815_20p anywhere ... so I'm considering using H815v29a (this version has already worked in the past) .... is it going to be a risky? Might it cause a problem? (SALT shows a AntiRollBack = 0 (which I suppose is good) in red (which I understand as a warning)
I also found the H815_20G at AutoPrime archive that seems to be an option...but I guess v29a is newer.
Also: is now the stage were I should get a rooted firmware?
Or I must go for a stock (and unrooted) ROM first... and then, when everything is done and working, I go and try to root it?
Click to expand...
Click to collapse
H815 20p is on my server, extracted or as a zip:
http://leech.binbash.it:8008/stock/LG/h815/20p/
Antirollback is in red because it's important not in general good or bad. If you would flash an ARB of anything higher then 0 to a h815 you will never be able to fully recover it.
Don't do any special things like rooting. First thing is to get back to normal and that's just pure stock.
Every side path may lead to issues.
Sent from my LG-H815 using XDA Labs
steadfasterX said:
H815 20p is on my server, extracted or as a zip: http://leech.binbash.it:8008/stock/LG/h815/20p/
[...]
Click to expand...
Click to collapse
So I've downloaded the H81520p_00 stock ROM from your server.
In topic #10 you said that I should get files as ".bin" but in your servers they are all ".image". Should I just rename it to change the file extension? Or do I need to convert it somehow?
steadfasterX said:
After you extracted the kdz boot your phone to fastboot mode instead of download mode and begin to flash the extracted partitions:
sbl1
rpm
sdi
pmic
hyp
laf
aboot
tz
system
boot
modem
factory
like that: fastboot flash sbl1 sbl1.bin
...
Click to expand...
Click to collapse
I also tried to flash the "sdb1.bin" (assuming I just needed to rename the .image file) file into it ... but it didn't worked.
FIRST try:
rebooted in Fastboot mode
using FWUL 2.6 (same setup on VirtualBox), I started a terminal and entered command "fastboot flash sbl1 sbl1.bin "
Got Message "< waiting for any device >" ... and it was only this, even after waiting 10min.
SECOND try:
rebooted in Fastboot mode
using Win10, I started a CMD (as Admin) and entered command "fastboot flash sbl1 sbl1.bin " (PS: fastboot.exe in system path)
Got error message: FAILED (remote: cannot flash this partition in unlocked state)
Code:
target reported max download size of 536870912 bytes
sending 'sbl1' (1024 KB)...
OKAY [ 0.058s]
writing 'sbl1'...
FAILED (remote: cannot flash this partition in unlocked state)
finished. total time: 0.080s
So I decided to perform a simple test.
At Win10 CMD window, entered "fastboot getvar unlocked" ... and got "unlocked: yes || finished. total time: 0.008s"
At FWUL 2.6 Terminal, entered "fastboot getvar unlocked" ... and got same msg "< waiting for any device >". So apparently linux is connecting to the device while it's in download mode but cannot do it in fastboot mode.
Code:
For the records: how to reboot LG G4 in Fastboot mode:
[LIST=1]
[*] Turn OFF device
[*]remove battery
[*]hold Volume DOWN key
[*]insert battery back
[*]connect USB cable
[/LIST]
otavio_aon said:
So I've downloaded the H81520p_00 stock ROM from your server.
In topic #10 you said that I should get files as ".bin" but in your servers they are all ".image". Should I just rename it to change the file extension? Or do I need to convert it somehow?
I also tried to flash the "sdb1.bin" (assuming I just needed to rename the .image file) file into it ... but it didn't worked.
FIRST try:
rebooted in Fastboot mode
using FWUL 2.6 (same setup on VirtualBox), I started a terminal and entered command "fastboot flash sbl1 sbl1.bin "
Got Message "< waiting for any device >" ... and it was only this, even after waiting 10min.
SECOND try:
rebooted in Fastboot mode
using Win10, I started a CMD (as Admin) and entered command "fastboot flash sbl1 sbl1.bin " (PS: fastboot.exe in system path)
Got error message: FAILED (remote: cannot flash this partition in unlocked state)
So I decided to perform a simple test.
At Win10 CMD window, entered "fastboot getvar unlocked" ... and got "unlocked: yes || finished. total time: 0.008s"
At FWUL 2.6 Terminal, entered "fastboot getvar unlocked" ... and got same msg "< waiting for any device >". So apparently linux is connecting to the device while it's in download mode but cannot do it in fastboot mode.
[/LIST]
Click to expand...
Click to collapse
For the bin/image question read FAQ #11 here: https://forum.xda-developers.com/g4/general/tool-salt-lg-revolution-t3717864/post74811095
FWUL detects fastboot mode without any problems but when entering fastboot the USB id changes. That means when using VirtualBox you need to add that new USB device to FWUL. normally named android phone or similar.
But anyways the error you get in fastboot mode indicates that you can't flash anything useful in that firmware version. FWUL or windows makes no difference here.
So the only option is to flash in download mode then. Either come to IRC ( http://webchat.freenode.net/?channels=Carbonfusion-user ) or write me a PM with subject "SALT flashing mode".
Sent from my LG-H815 using XDA Labs
I have the same problem "Got error message: FAILED (remote: cannot flash this partition in unlocked state)". Please help how to flash in downloaded mode.
I have also tried "[GUIDE] Proper H815 unbrick through QFIL (Files included) by inteLzzz". Flashed different roms by LGUP. All went well, but nothing changed. Pls help.