LG Viper roms?

[Edward McInnish]

brandonabandon@beast:~$ adb logcat --------- beginning of /dev/log/main D/QSEE - Pastebin.com <cm9, got to splash

thats greta progress! i think understand what you meant. i understand the process now (eerily similar to how i can build a wii homebrew application from source code), just dont understand why your getting the errors your getting. if i had the source code, i might be able to take a look at it in conjunction with a build log, possibly fixing the issue on code level (especially since you believe it may be cpp). i cannot guarentee anything however even if you did provide me with the source and log. since i cannot git, i cannot pull the source.

fortunately for me, i understand why you have to pretty much build the rom from source as from experimenting with the compiled system has shown me to an extent that the device relies on links to files in code, thus simply replacing some files will break things as i have proven lol. linux itself is quite different from windows, as if you have the right file names, and the right file structure, it doesnt take much modification to alter the way the system functions.

and from diving into this log, if you can, please deodex the rom from the begining. it will cause quite a bit less of a headache later, and could help in simplifying the process of figuring out the things that are truly broken.

quote: DexOpt: VM build version mismatch (28 vs 27)
was this really necessary? maybe you forgot to fix something here? or am i just overlooking something?

and here is the killer right here:
Could not stat dex cache directory '/cache/dalvik-cache': No such file or directory

many many files are erroring simply due to this. I would resolve this issue.

 

[brandonabandon]

brandonabandon@beast:~$ adb logcat --------- beginning of /dev/log/main D/QSEE - Pastebin.com logcat for miui rom by progranade and various dev

 

[brandonabandon]

brandonabandon@beast:~$ adb logcat --------- beginning of /dev/log/main E/Ther - Pastebin.com cm10.1 logcat

 

[Edward McInnish]

Its unusual for this thread to be silent for more than a day with my posts as an exception. i was chatting with a good friend of mine yesterday. he agrees that the biggest canidate to your error is that for whatever reason, your device is not able to create the dalvik cache which in return means many critical files will fail to load into the system properly resulting in a splash screen form of a bootloop. when he noted TWRP was the recovery, he showed me one of his older phone logs which looked eerily similar (it was another lg device of some kind that isnt very common except among prepaid users that he was working on), along with a log of the flash with CWM. in this case however, he had to semi dirty hack the vendor drivers and was using AOKP as a base. WHile this doesnt mean that TWRP is to blame, a test with multiple recoveries should be made. since i cannot GIT, i cannot ask for source and compile myself. I can however share you my email in pm in order to test your "nightlies" on my device. I have a TWRP backup of my current system, as well as a CWM backup, so i can simply wipe my device, re dd my recoveries, and restore backups no problem. another thing that was discussed was the fact you were restoring backups from another persons device. while the general rule of thumb is this will typically work, other issues arise in doing so, such as device dependait files get flashed in the process sometimes, rendering you with partially working restores, or in worst case scenarios, bootloops due to device inconsistancies.

When we are sucessful in building a bootable CM( rom, I would like to request a tablet style version that strips the phone capabilities of this device in favor of wifi, gps, NFC, and bluetooth only (disableing the radio entirely to avoid battery loss due to not being able to disable the phone signal only, as currently the only way i know to stop cell tower communication is through airplane mode that disables all wireless communications). I will also add a few additional tweaks and modifications to CM9 that would be very useful in a final build to make this phone really shine, some of which work very well on stock, and some that only partially work due to LG modifications. Some you can even view immediately: xposed framework which adds quite a few power tools that normally have to be hard coded in a developing rom, the viper audio driver which has massively improved the audio quality on my phone, a few resource scripts, one of which is the "supercharger" script that tweaks many setting that improve performance (has been useful in doubleing the battery life of my phone and the responsiveness of apps).

Edit: nice to see some new logs. MIUI i will have to go over later as it is quite different. as for CM 10.1, it is to be expected on some of those errors, but the main persistance is the lack of dalvik cache once again. other errors aside, this is killing the boot.

Edit 2: im quite tired of scratching my head all over this. im taking the splash screen cm9 log into a cyanogenmod irc chat room and gonna fish for answers. its better to get answers from the horses mouth than to try to pick my brain and my friends brain since we are both better on internal mods than core mods. (internal being working on a compiled system vs making a rom)

Edit 3: Brandon i need a copy of the cm9 rom. we might have a CM dev who is going to look at it.

Edit 4: Search Playfulgod on github, and pull his lucid or connect repos. he mentioned that would be our best bet to smoothing some issues out. DUE NOTE THAT the screens are shared between lucid and connect, but our viper is the oddball. this will need to be tread cautiously. if you dont pull the screen related files from our little viper, it probably wont work. also, he suggested using CM 10 instead of CM 9 and CM 10.1

 

[brandonabandon]

Lol. Im ahead of the game bro lmao. Already been picking at both lucid and connect roms. For whatever reason, my builds dont compile system/bin and xbin properly, compiling as xsharedlibs rather than executables. Forking from pgs roms is how i can get the logcats. Interesting enough, when i reboot after an install (zvi) i get fastboot mode on all mentioned roms. After flasing loki'd kernels im able to get a reading. Now that pg is on the prowl, if its possible at all for any of these rom to sicceed shall be soon known! He has helped with loki, and some other issues i was experiencing before and is the lg dev monster. I will post more at my pc texting is unnecessary.

could be an issue, my recovery on zvk seems to bootloop recovery after installing cm1o, however, i merged the connects frameworks before doing so. i think my recovery may have an issue with restoring backups to joshs recovery on zvi or possibly roms altogether, i will remove my recovery until further notice. im testing on cm10 and will upload it once i remember which kernel i dd'd and checking the connects frameworks' compatibilty also. i merged the qcom inits from my cm10.1 build to system/etc and the qcom iso file to /system also some of the conf. files in system/etc. actually my cm10 rom is already available lol. scroll the thread. note the rom is premodified/virgin-state. lol i will reupload once i remodify.

 

[Edward McInnish]

If i can get this darn vm to work, i may take a stab at it myself. compiling a rom from source wont be very hard on my end, but modifying vendors and whatnot on the other hand? im scratching my head.

 

[brandonabandon]

If i can get this darn vm to work, i may take a stab at it myself. compiling a rom from source wont be very hard on my end, but modifying vendors and whatnot on the other hand? im scratching my head.

i modified the cm10 rom unreadable :facepalm: a few factors im considering, 1. the capability of my recovery to joshs-on a backup-on different android versions. 2. flashing with adb sideload vs. via sdcard. 3. if i remember correctly, i achieved the reading before adding the qcom init files to the system/vendor folder. 4. the dynamics of why after flashing multiple kernels to the same rom will occasionally boot the dreaded 'enter the fastboot'. anyhow. the reading was achieved after merging the connects system/xbin and system/bin and possibly frameworks. and i believe i dd'd joshs kernel after reboot to 'enter the fastboot'. THE PLAN-the cm10 kernel source's for pg's roms are iproj based, im syncing jb currently and i will compile the rom using lucids iproj source, split w/ kitchen, and merge the ramdisk with my iproj viper source, then add boot to cm10. {i experimented this theory with a fresh dl of my rom, merging pgs rom as mentioned, and merging the boot as mentioned. the booting results before merging the boot was either hang at logo, or splash not reading. i flashed via adb sideload each flash, and upon merging the boot, the booting result was hang at logo, adb reads device, no logcat, and after loki same kernel- logo to blank "i think."} (im pretty sure i compiled the cm10 rom using nigels kernel.) anyhow, my syncs take from 12 hrs. to 24 hrs. and full builds take 5 to 7 hrs. (not considering prep time+errors) might be sometime until complete. syncing kang btw


^may or may not be necessary, i have reason to believe the logs are due to failure of booting zvk. when merging the zvk system files i didnt delete the lg files i now realize after peeking at the roms. which makes sense the bootloader would allow reading with joshs kernel and not booting fastboot like my roms w/o zvk merges. after my repo i will reflash @gb. i flashed a cm10 rom and dd'd a iproj loki'd kernel whilst recovery and rebooted to logo/hang. device reads as 7be831device but no logcat. which leads to one of three (or all/some) possibilities 1. my roms are just broke 2.were unable to flash custom roms yet due tothe fact the bootloader is actually locked still which even loki'ing the kernel will not bypass 3. its a cm kernel issue. if its just the bootloader issue, i spoke with pg a while ago and also quoted on the loki git request the gb bootloader could be flashed @ ics but i was unable to fashion this way. will need to look some more into his idea. anyhow, curl: (18) transfer closed with 694721648 bytes remaining to read anyone get this repo error?


@ed i have some exp. with vm if you need pointers

 

[brandonabandon]

unable to restore a zvi/zvk backup via gb

 

[thenameisnigel]

unable to restore a zvi/zvk backup via gb

ICS requires a newer bootloader than GB. You can't flash a ICS ROM on GB.

Sent from my SPH-L710 using Tapatalk

 

[brandonabandon]

ICS requires a newer bootloader than GB. You can't flash a ICS ROM on GB.

Sent from my SPH-L710 using Tapatalk

the connect/lucid team was flashing the gb bootloader to ics for unlocking reasons. my idea was as i stated at my previous to last post, was that custom roms are unable to be flashed and that loki merely enables recovery. i read quite a few threads for misc. devices where users are flashing loki'd recoveries as well as unlocked bootloaders, since im unable to flash the gb bl, i flashed stock gb to try first hand, no success yet.

 

[brandonabandon]

i compiled twrp2.4 with joshs zvk kernel on aokp jb branch. boots to blank screen and wipes os. adb reads recovery, able to push but unable to shell.

 

[thenameisnigel]

i compiled twrp2.4 with joshs zvk kernel on aokp jb branch. boots to blank screen and wipes os. adb reads recovery, able to push but unable to shell.

What does it say when you do adb shell?

Sent from my SPH-L710 using Tapatalk

 

[brandonabandon]

What does it say when you do adb shell?

Sent from my SPH-L710 using Tapatalk

exec blah blah bin/sh...no file exists or something. i just realized my recovery is def faulty when i attempted to flash my update.zip, which flashes @joshs recovery just verified. probably the reason behind many pastebin visits.lol


an aokp jb rom built on joshs zvks kernel boots to logo,splash, logo again, then recovery.

 

[Edward McInnish]

why not try CWM for a moment?
And despite the previous thinking, we might look into loking the rom if possible. loking the kernel supposedly is supposed to eliminate the kernel/rom security checks, and loking the recovery is suposed to eliminate checks on recovery.

 

[thenameisnigel]

why not try CWM for a moment?
And despite the previous thinking, we might look into loking the rom if possible. loking the kernel supposedly is supposed to eliminate the kernel/rom security checks, and loking the recovery is suposed to eliminate checks on recovery.

Loki isn't for ROMs. Josh already stated this earlier in this thread.

Sent from my SPH-L710 using Tapatalk

 

[brandonabandon]

Starting recovery on Fri Jan 2 07:01:47 1970 framebuffer: fd 4 (480 x 800) CW - Pastebin.com <4.1.2 cwm not mounting sdcard? however brandonabandon@beast:~$ adb devices List of devices attached 7be831 recovery - Pastebin.com the rom is flashing now according to ls because typically ls has ueventd.cayman i believe and system/bin not system/etc etc etc. yah boy.

edit nm. since sdcard wont mount no flash occured. the reason i thought system/bin was because twrp isnt mounting system! and i was ls recovery. darn.lol any suggestions on the sdcard fix? im thinking format to fat32.

after mounting and formating, an ls/system shows brandonabandon@beast:~$ adb shell
~ # ls system
app build.prop etc framework media usr xbin
bin core fonts lib tts vendor

proving the flash occured. the reboot hangs after splash and adb recognizes. i rebooted recovery via factory reset and now im unable to mount any partition, and the system appears empty!???

ls system
bin

i think i know a workaround. gotta reflash josh twrp, format sdcard, make a backup of sdcard, rereflash my cwm, make a backup of rom etc etc. a few flashes in twrp after formating i discovered restoring a backup can resolve the not mounting issue. lol i flashed via sideload if anyone is wondering. the search home key is reboot recovery

 

[Edward McInnish]

i followed for the most part, and lost you on some.
when flashing a rom, every thread i ever used as a guide suggested a FAT32 format. to be honest, i prefer a FAT32 format since i rarely use an sd card larger than 16gb, which means NTFS is not nessicary. I sometimes swear that the FAT32 format is faster. Just a blind shot in the dark, are you always trying to flash the rom through ADB? has anyone considered that maybe due to the nature of loki that one must place the rom on the SD card to make it flash? it is a theory, and even if that shouldnt be the case, neither should our current situation if the phone was truly lokied. since we have a fully working recovery, are able to flash custom kernels, etc., there is no doubt we have sucessfully killed LG's little tricks. at the same time though, due to the very nature of this phone from working with it, this isnt your typical device, and it does seem to function a tiny bit differently. I wouldnt be surprised if the answer all along was flash the rom from either external, or internal sd storage because loki is ding something that adb isnt able to cope with. just a theory, probably useless and probably something you already tried. as i explained before, i am willing to work with your tests if you would be willing to host them and shoot a link. another factor one should consider: the psp had 3 major revisions and many minor revisions. my brand new 3000 series likely has a newer board than your launch day one, and could mean a big difference in how much my modifications can go compared to yours, even if we use the exact same source. whats to say the viper isnt the same way, where multiple revisions could affect your milage? another factor to consider in the long run. I personally have seen a GS3 with slightly different hardware under the hood, despite being from the same manufacturer, and from the same company (at&t in this case). one would brick if you used the recovery of the other one, despite them both being the same device.

 

[thenameisnigel]

i followed for the most part, and lost you on some.
when flashing a rom, every thread i ever used as a guide suggested a FAT32 format. to be honest, i prefer a FAT32 format since i rarely use an sd card larger than 16gb, which means NTFS is not nessicary. I sometimes swear that the FAT32 format is faster. Just a blind shot in the dark, are you always trying to flash the rom through ADB? has anyone considered that maybe due to the nature of loki that one must place the rom on the SD card to make it flash? it is a theory, and even if that shouldnt be the case, neither should our current situation if the phone was truly lokied. since we have a fully working recovery, are able to flash custom kernels, etc., there is no doubt we have sucessfully killed LG's little tricks. at the same time though, due to the very nature of this phone from working with it, this isnt your typical device, and it does seem to function a tiny bit differently. I wouldnt be surprised if the answer all along was flash the rom from either external, or internal sd storage because loki is ding something that adb isnt able to cope with. just a theory, probably useless and probably something you already tried. as i explained before, i am willing to work with your tests if you would be willing to host them and shoot a link. another factor one should consider: the psp had 3 major revisions and many minor revisions. my brand new 3000 series likely has a newer board than your launch day one, and could mean a big difference in how much my modifications can go compared to yours, even if we use the exact same source. whats to say the viper isnt the same way, where multiple revisions could affect your milage? another factor to consider in the long run. I personally have seen a GS3 with slightly different hardware under the hood, despite being from the same manufacturer, and from the same company (at&t in this case). one would brick if you used the recovery of the other one, despite them both being the same device.

Loki has nothing to do with the recovery not flashing, it just bypasses the signature checks on the bootloader. And all GS3 variants in the US are the same hardware, that's why ROMs built by cyanogenmod for the US GS3 can be flashed on any US carrier's GS3.

Sent from my SPH-L710 using Tapatalk

 

[brandonabandon]

@ed i flashed sideload because cwm sdcard wouldnt mount.

 

[Edward McInnish]

ah! ok, makes sense then. i guess they had gotten one of the international gsm variants somehow (i dont trust our at&t store despite a good friend working there). as for CWM, it seems to mount my sd card just fine. i could just be lucky though. ill try it again. atm, i reflashed the TWRP to restore an old backup. the reason i asked what i did, is im not sure if it monuts the sd card through the same process during a rom flash and a restore backup. if it works differently, it might explain a lot. TBH, im doing the best i can to rake my brain on experiences i have had with other devices including non android devices, but in the end, i am feeling a bit useless. after this experience, i doubt i will ever get another LG device lol.
as for yesterday nigel, i was refering to integrating lokied kernel and recovery into a rom during build if possible (a few sources state it is) which could resolve a few issues, but thats probably just another thing im suggesting that will waste time.