[ROM][WIP][4.4.2] CyanogenMod 11 KitKat for Optimus S/V

[brotherswing]

K

This is zvd based right? And where do we find the recoveries for this.

Sent from my SCH-I535 using Tapatalk

I'm running this on ZV9. Then again, there are functions I can't test as I have no service right now...

VM670 on 4.4.2? Yes, indeed.

 

[bigsupersquid]

I have tried several different VM APNs (all different MCC and MIN) and none of them broke data on yesterday's build from thekraven's repo.
they don't show up in the apns list, but still deselect the default Sprint one.
none of them send mms, either.

 

[skinbark]

OS2SD Recovery Info
I'm linking to this post to help explain issues related to using the os2sd version of CM11. The regular CWM from post #1 is adequate to flash the os2sd rom, gapps and button fix, but doesn't know how to properly wipe, backup or restore the partitions, so we need alternate methods of doing so. One way to handle wiping is to use CWM to flash zip files which execute a script that removes all files from the sd-ext partitions. I added a set of wipe zips to the os2sd folder. Put them in a folder on your sd card and flash them from the regular recovery to clear external /data, /system, /cache, or all three.

CWM_6.0.4.6-thunderc-sd.zip is a special version of ClockWorkMod recovery that assumes that you are using sd-ext partitions for /data, /system and /cache. This version of CWM will correctly format, backup and restore the os2sd partitions, but not the regular internal partitions. I changed the colors on the os2sd version to help remember which is installed. Just flash the appropriate zip file to switch between the two versions. If you know you'll just be using the os2sd rom use this recovery.

Another option is bigsupersquid's "fake flash" recovery. You flash the zip from your regular recovery and it restarts the recovery with new temporary partition settings. If you switch back and forth between normal and os2sd roms or backups use this. cwm-sd_fakeflash.zip can be downloaded here.

Experienced linux users can use the dd command to backup and restore the os2sd partitions on their pc.

 

[cammykool]

long time no see, cammy.

regular NAND recovery linked in first post (in the mediafire folder.)
experimental SD recovery fakeflash is here. For the run-from-sd rom version in the second post.
The experimental requires the regular NAND recovery to be installed first. The regular recovery remains there while using the experimental one.

//edit: I forgot, it runs fine on ZV4.
has 3g and wifi. sms works fine. no mms. no bluetooth. if installed with the fakeflash recovery, it remembers wifi passwords.

My moms friend had a ls670 she didn't need so I got it now

Sent from my SCH-I535 using Tapatalk

 

[thewraith420]

All zvd based basebands should work fine this includes zvd, 4,5 and 9. Zvh and j work with a patch

Sent from my XT907 using Tapatalk

 

[skinbark]

To fix the wifi password issue replace /data/misc/wifi/wpa_supplicant.conf with a new copy containing just these lines:

ctrl_interface=/data/misc/wifi/sockets
update_config=1
device_name=lge_thunderc
manufacturer=LGE
model_name=LS670
model_number=LS670
serial_number=0123456789ABCDEF
device_type=
config_methods=physical_display virtual_push_button
p2p_no_group_iface=1

chown system wpa_supplicant.conf; chgrp wifi wpa_supplicant.conf; chmod 660 wpa_supplicant.conf
Make sure wifi is off when you change files.

 

[skinbark]

Anybody else think the keypad in Dialer is a little too small on our phone?

 

[brotherswing]

Thanks for the WiFi fix! As soon as my daughter logs out of Wizards 101, I'll get that set up!
With regards to the dialer, it looks okay to me....

VM670 on 4.4.2? Yes, indeed.

 

[bigsupersquid]

as far as md5 I've had no issues with multiple backups and restores with the fake flash recovery. i did get the failed cache restore, but unmounting all partitions in the recovery menu before making a backup or restoring took care of that.

 

[skinbark]

as far as md5 I've had no issues with multiple backups and restores with the fake flash recovery. i did get the failed cache restore, but unmounting all partitions in the recovery menu before making a backup or restoring took care of that.

It's working for me too after unmounting cache. Is there a way the unmount cache command could be placed in the updater script or executed somehow so it's ready to go when it loads?

 

[bigsupersquid]

It's working for me too after unmounting cache. Is there a way the unmount cache command could be placed in the updater script or executed somehow so it's ready to go when it loads?

I tried putting it both in updater-script and the shell script but neither seemed to work right. Thought putting it in killrecovery.sh fixed it but obviously not.
I'm trying now:
maybe umount -l in the script instead of just umount and a sleep command before killing processes.
If it works I'll update the file here.
//edit: yep, it seemed to work. my file links are now updated.

 

[skinbark]

I tried putting it both in updater-script and the shell script but neither seemed to work right. Thought putting it in killrecovery.sh fixed it but obviously not.
I'm trying now:
maybe umount -l in the script instead of just umount and a sleep command before killing processes.
If it works I'll update the file here.

We could maybe hack the cwm source to make it work. The best solution is probably a 'smart' cwm that can handle 2 installations on one phone.
Or a bootloader on the recovery partition that lets you pick either the standard recovery or a recovery that you load off the sd card.

 

[bigsupersquid]

We could maybe hack the cwm source to make it work. The best solution is probably a 'smart' cwm that can handle 2 installations on one phone.

umount -l and a 5-second sleep seemed to work. I'll re-upload, you can test too. You'll have to fix the link in your previous post after I re-upload because the attachment # changes. here's the new one
I agree, a smarter version would be nice. You'd probably need a menu selector for NAND/EMMC which swapped out the recovery.fstab file, then calls the killrecovery.sh to restart it with the correct partition label/device combination. the killrecovery.sh should be copied over first, or it'd have to be included in the regular recovery source. I modified it quite a bit from the default. Part of the problem is that it need two sets of .pngs for the color change, and a way to tell which one is needed. Or two different scripts, one for each partition type. The script can copy over the fstab, but it doesn't seem to be recognized before killing/restarting init, recovery, and adbd . That method isn't much simpler than the fakeflash from a user perspective, though. The user would still have to be aware which version is being installed and make at least one selection first.
It'd take a bit of recoding and multiple fstab's to get it to work automagically, and that's a little beyond me right now.
I figured the fakeflash was easier than source modification... somewhat less user friendly though. It is good because the color change you incorporated makes it pretty clear which version is being used.
I wonder if the fstab can handle multiple links to /system and so on with one set NAND and one set EMMC? Kinda doubt it. //edit: nope. not at least the way I tried it.
by the way, OS2SD is a cool label for what's being done. I hadn't thought of anything like that.

 

[hfl12]

thank you skinbark.

 

[bigsupersquid]

Or a bootloader on the recovery partition that lets you pick either the standard recovery or a recovery that you load off the sd card.

the recovery partition is identical in size and format to the boot partition, so it might be possible. So far though, the new security features in android seem to be preventing the old tricks I had from working on startup, like running a busybox script as init which transfers control to android init. It just dies at that point now. Most likely it sees that as an exploit or something. Which I suppose it is.
I can make suggestions on bits to be done in recoding to make it work... but the easiest way for me to deal with it is the zip file. Either way it takes at least one extra step the user has to deal with unless it's somehow automagic.
I suspect init would need changes to detect which partition type is being asked for and to use the appropriate fstab file... like sdrecovery.fstab or recovery.fstab maybe. Or perhaps it's the update-binary, I haven't looked much into recovery code yet or I'd've patched a terminal into CWM like TWRP has. I bet it's in either init or the recovery binary though.

 

[skinbark]

the recovery partition is identical in size and format to the boot partition, so it might be possible. So far though, the new security features in android seem to be preventing the old tricks I had from working on startup, like running a busybox script as init which transfers control to android init. It just dies at that point now. Most likely it sees that as an exploit or something. Which I suppose it is.
I can make suggestions on bits to be done in recoding to make it work... but the easiest way for me to deal with it is the zip file. Either way it takes at least one extra step the user has to deal with unless it's somehow automagic.
I suspect init would need changes to detect which partition type is being asked for and to use the appropriate fstab file... like sdrecovery.fstab or recovery.fstab maybe. Or perhaps it's the update-binary, I haven't looked much into recovery code yet or I'd've patched a terminal into CWM like TWRP has. I bet it's in either init or the recovery binary though.

Well with the wrinkles worked out the fake flash is a nice solution, but having a fixed recovery makes the whole approach seem like less of a hack. Init or whatever it is could look at the sd card and if it sees the os2sd partitions offer up extra menu items to handle flash, backup/restore, format etc. Being able to run 2 android installs conveniently is another incentive to work on this. I'm very glad you're involved in this, we should start calling it the OPTIMAXX project or something Maybe there should be a separate thread for this stuff and just have this thread for the basic install. We're probably scaring off noobs with all this linux talk Also it's not actually specific to kitkat. Feel free to start one up if you want since you came up with it. Either you or I (or whoever?) can build the roms.

 

[skinbark]

umount -l and a 5-second sleep seemed to work. I'll re-upload, you can test too.

Worked for me too.

Edit: you probably noticed there's a little glitch where when you try to reboot to system it takes you back to the recovery and you have to select reboot again. I know recovery uses cache to write some info about rebooting so it might be that when you switch to sd-ext cache the info cwm wants isn't there and it has to re-write it to the new cache.

 

[brotherswing]

This is exciting stuff! Granted, deeper into Linux than I've been in years, but still....

VM670 on 4.4.2? Yes, indeed.

 

[bigsupersquid]

Worked for me too.

Edit: you probably noticed there's a little glitch where when you try to reboot to system it takes you back to the recovery and you have to select reboot again. I know recovery uses cache to write some info about rebooting so it might be that when you switch to sd-ext cache the info cwm wants isn't there and it has to re-write it to the new cache.

could be. I have to press reboot twice in the regular CWM as well, else it just reboots into itself. And not a true reboot, it just respawns.

Well with the wrinkles worked out the fake flash is a nice solution, but having a fixed recovery makes the whole approach seem like less of a hack. Init or whatever it is could look at the sd card and if it sees the os2sd partitions offer up extra menu items to handle flash, backup/restore, format etc. Being able to run 2 android installs conveniently is another incentive to work on this. I'm very glad you're involved in this, we should start calling it the OPTIMAXX project or something Maybe there should be a separate thread for this stuff and just have this thread for the basic install. We're probably scaring off noobs with all this linux talk Also it's not actually specific to kitkat. Feel free to start one up if you want since you came up with it. Either you or I (or whoever?) can build the roms.

well, actually, to get this kind of boot process on anything lower than kitkat, it's a LOT more hassle. Though I didn't look into ICS or JB booting this way, I tried multiboot the *old* way and the security stops it. So it is kinda applicable to the thread, but I support the idea of a second thread for the OS2SD stuff, your statement about scaring away the fish is probably accurate.
Since it's your build and my mod, you can OP it and I'll help support. I'm not releasing binaries of anything but the kernel at this point and can't commit the time for this one, though I'll aid with what I can. So far I've had more free time than expected.

 

[skinbark]

Sounds good. KitKat OS2SD thread coming soon.