yashsingh1/xdaforums huggingface dataset:
[Android Head-Units] pdanders11:
Have you gotten the serial port up and talking?

Sounds like you need stock recovery to rebuild the system. Use CWM to mount system and undo anything to break stock recovery and then restore stock recovery in CWM or fastboot. I'm not sure if you can overwrite recovery in recovery. I assume you can but I guess fastboot it's easier for me.

If that didn't work

My experience is if you can't boot into Android your only options is connecting the serial port and interrupting boot with F and R and use fastboot and CWM and stock recovery and piece the partitions back together.

If the serial output says something like the mbr is gone it's FWDN or bust I think.

---------- Post added at 04:28 AM ---------- Previous post was at 04:22 AM ----------

This all assumes you still have adb and otg working.

---------- Post added at 04:39 AM ---------- Previous post was at 04:28 AM ----------

I guess the other question is did you put update.zip on a sdcard and install it.

I must say that I've had nothing but trouble with the sdcard in CWM. It didn't seem like what Dan said matched what I saw.

I'm not sure what your bench unit is setup as but something obvious I forgot was I had the DVD drive disconnected for forever. It wasn't until I swap units did I realise no DVD means no front panel operation which made me question if this or something else I did broke the sdcard.

This is where I left off and never got back to.
[Android Head-Units] chris.davis925:
Hmmm I never thought to try this, but it seems that inserting an SDCARD into the external slot (behind the screen) will actually populate the data in CWM, even though no partition is mounted. Furthermore, it seems to refer to this mount point as "SDCARD" and not ExtSdcard, like it does in Android.

Regardless, applying the update.zip file from Kenwood 1.5 and selecting "no" to the prompt which asks to bypass applying Kenwood recovery still results in the CWM recovery not being overwritten and the unit continues to boot only into CWM.

This makes me wonder if the mount point names from kenwood's update.zip file do not match the names that CWM refers to?

I can't get OTG to work on my unit. It's possible I've shorted the OTG port. With that being said, the only option I really have is to apply another update.zip to help fix the problem. What do you guys think?

Perhaps someone can help me craft an update.zip file that will fix my problem?

---------- Post added at 05:55 AM ---------- Previous post was at 05:51 AM ----------

Perhaps someone can create a backup from CWM so that I can try and apply it to my unit?
[Android Head-Units] pdanders11:
So your able to put a update.zip on a sd card and get cwm to kick off a update?

Sorry if this is a dumb question, but why or have you let cwm erase the recovery partition?
[Android Head-Units] chris.davis925:
correct. I did this in hopes that then the update would finish and boot android but this was not the case. It still bored back to cwm which means it's probably writing the recovery to the wrong partition.
[Android Head-Units] pdanders11:
I'm out of town but will be back tomorrow night. I can verify the mount then.
[Android Head-Units] chris.davis925:
thnx
[Android Head-Units] pdanders11:
I just got home to look at this.

So in CWM, I see no option to mount recovery to see if it maps to ndda6

in factory.fstab I see

more factory.fstab

# mount point fstype device [device2]

/boot mtd boot

/cache yaffs2 cache

/data yaffs2 userdata

/misc mtd misc

/recovery mtd recovery

/sdcard vfat /dev/block/mmcblk0p1 /dev/block/mmcblk0

/nand vfat /dev/block/ndda1 /dev/block/ndda

/sda vfat /dev/block/sda1 /dev/block/sda

/system yaffs2 system

/snapshot mtd snapshot

~ #

Now just thinking aloud, if I flash a kenwood update, there is no recovery.img in the update so the kenwood update could not fix ndda6 regardless.

The system updates seem to persist for me through a update so boot cant trigger rebuild of recovery.

Anyway if CWM doesn't do a sig check as dan says, what if you take the stock ndda6 posted early, rename it to recovery.img, and add it to the zip? Maybe then CWM would restore recovery??

Sorry if i last tack of the issue. Long day of driving.

probably will need [MENTION=5909218]radux.m.dan[/MENTION] 's help.

---------- Post added at 05:06 AM ---------- Previous post was at 04:18 AM ----------

I think my sdcard issues may have to do with a old version of busybox in CWM.

What is in the img doesn't like FAT. I replaced with a newer busy box and things seem better.

---------- Post added at 05:32 AM ---------- Previous post was at 05:06 AM ----------

with a updated busybox in recovery, i was able to install stock update.zip 1.5 from the SDCARD.

When it asked if I wanted to disable recovery overwrite or whatever it said, I said no and it kicked off rebuilding via stock

I now have the Kenwood GUI so I think CWM is fine.

What is odd to me is build.prop survives these updates. USB DEBUGGING always comes back. I would think a update would wipe that. still makes me wonder if your recovery-from-boot.p and install-recovery.sh are intact.
[Android Head-Units] chris.davis925:
I am going to try and create a backup from another DNN990HD that works using CWM custom recovery and then try to restore that backup on my unit that boot loops into recovery.

Perhaps this will correctly restore the data.

I'll report back how this works.
[Android Head-Units] Labgate:
Hi everyone

I have the same kind of problem with my dnn770hd unit, it boots a couple of time, then goes into recovery, then boots a couple of time, then goes into recovery, etc.

so if someone wants me to test something to recover I'm more than willing to try since my system is now useless. I'm thinking on buying another one...

Greetings

Labgate
[Android Head-Units] chris.davis925:
Update: I tried to flash CWM on the unit I have in my car. This unit is rooted with Gplay and apps installed - but the /system rw lock is present on the unit.

When I try to flash the recovery, I get the success message in the terminal prompt, but when I reboot recovery I quickly see the stock recovery say "waiting" followed by a triggering of "System Rebuilding". I have tried this three separate times, even redownloding the recovery.img in case it was corrupt.

It seems that perhaps the mount lock that's happening is also preventing writing to ndda6? If that's the case that might also explain why flashing custom kernels don't appear to actually make any changes, despite the success message?

Any thoughts on this? Experience anything similar?
[Android Head-Units] pdanders11:
Let me try that. I'm fastbooting recovery

In other news sometimes I just try random stuff to see what happens.

today I blew away all the KW . apks and went in bin and blew away all the kw* executables. After doing this I can get stock rebuilds to fire on modified update.zip 's

Obviously it generates a unstable system but the rebuild is somehow tied to the KW binaries or APK's in normal mode? I sort of assume rebuild skipped normal mode but that doesn't seem to be the case. So the theory that the bootloader is checking may not be true or I'm missing something. I'll look at the binaries closer.

02/29/2008 11:33 AM 5,656 kwclient

02/29/2008 11:33 AM 5,512 kwdellost

02/29/2008 11:33 AM 14,352 kwplayer

02/29/2008 11:33 AM 5,680 kwresetter

02/29/2008 11:33 AM 5,628 kwupdatecheck

02/29/2008 11:33 AM 5,764 kw_lostdel

02/29/2008 11:33 AM 5,708 kw_mkqb_timeinit

02/29/2008 11:33 AM 5,696 kw_mountnotf

02/29/2008 11:33 AM 5,652 kw_qbcounter

02/29/2008 11:33 AM 5,648 kw_qbwd

02/29/2008 11:33 AM 5,640 kw_vbusctrl
[Android Head-Units] chris.davis925:
Can you confirm if /system rw is still locked after removing all of kenwood s apk and bins?
[Android Head-Units] chris.davis925:
Can someone please post the stock recovery.img file?
[Android Head-Units] chris.davis925:
Also, if someone could post a CWM backup in its entirety for me (of a working unit) this would be very helpful to me.

Thanks
[Android Head-Units] pdanders11:
Stock recovery is already posted back a few pages. Ndda6.zip
[Android Head-Units] chris.davis925:
I don't see it posted on previous pages.

I've got a dilemma now.

I have two units and both do not boot up.

Unit #1: On my bench is booting only into recovery. Attempting to restore a backup (provided by Dan) does not fix the problem. It's worth noting that the restore says that .android_secure.img is not found, so it skips it. Also it says that /snapshot cannot be mounted. Is this expected?

Can someone help me craft an update.zip file that will fix the unit? I am no longer sure what is going on and why it only boots directly into recovery, unless for some reason the mount points are wrong.

Unit #2 is in my car: this unit is booting up and restarting after 3 seconds of showing the Android launcher. After a few reboots the unit does a system rebuild and the problem starts again. I have stock recovery on this unit, and USB OTG doesn't work. The only hope I have is that I can adb via wifi to work with root for about one min during the "Rebuilding phase". I think this is the part where quickboot image is created or dalvik-cache is built, I am not sure. Either way, I can execute commands during this window.

My thought is that I could run an adb command to execute Update.kw from usb_sda1, but I can't really test how to do this. I see there is a kwupdater binary and an applypatch binary, but I don't have a unit to test the syntax of these commands.

Can someone please test if there is a way to trigger reboot into stock recovery to apply the Kenwood update.kw file? This would be very helpful to me.

Thanks guys!!!
[Android Head-Units] pdanders11:
http://xdaforums.com/showpost.php?p=54309750&postcount=521

---------- Post added at 06:08 AM ---------- Previous post was at 05:38 AM ----------

On unit #1 where are you reading " .android_secure.img is not found" message? dmesg or serial? Haven't seen that.

I've mucked stuff up enough that several mount points won't mount. Sometimes a format in CWM and then a clean re-write of the image works. I guess I should say a format should get it to mount. Then DD should restore the data. I don't remember the format of snapshot (fat, raw, or ext4) so that matter.

Do you have the test connector hooked up? I find fastbooting images to be efficient and the serial port info to be helpful.

On unit #2

Maybe this would help

wifi adb the unit to run the update.kw ?

cache up the recovery update.zip?

http://xdaforums.com/showthread.php?t=1353234

FWDN would be a last resort on Unit #1 but i don't think it's necessary unless your MBR is blown away.
[Android Head-Units] chris.davis925:
So I was able to fix unit #2 (in my car) via wifi ADB by deleting dalvik-cache and removing all apps from /data/app. It seems to me that Google Play tried to auto update an app and somehow got corrupted. Probably related to our journal corruption problem that we are still trying to fix.

Unit #1 is still booting only into recovery. I tried to format /snapshot and this got rid of the /snapshot error. The .android_secure message was coming up on the recovery prompt, but I haven't seen this come up since I formatted /snapshot.

Restoring a CWM backup and attempting to execute update.zip after formatting /snapshot still does not work and the unit is still rebooting only into CWM recovery.

I don't have a serial connection to the unit. Any recommendations on what USB/ serial device to use?

What should I try if I had a serial connection going? It seems to me that perhaps an update.zip file can be crafted to replicate the same thing?
[Android Head-Units] chris.davis925:
I tried to create an update.zip file containing the stock kenwood recovery.img file, but my CWM doesn't like it. I can't quite figure out what is wrong. It complains with a status 6 error, which I think means I didn't write something right.

Can anyone take a look and shine some light?

The goal is to create a flash-able zip file that restores the stock Kenwood recovery image.

Update:

I think I found the problem. Missing a close bracket and double quote.

I guess that's what happens when you write these things at midnight. :p
[Android Head-Units] chris.davis925:
[MENTION=4791431]pdanders11[/MENTION]s - Since you have serial connection working and can fix a problem with CWM with it, do you think you can try the following CWM?

It was created by Dan to run fsck on /system on boot. It should be identical to the previously posted CWM with only that one exception. I am wondering if you can test it to see if you also run into the same problem I am having after trying to flahs update.zip from Kenwood's 1.5 update using this CWM version. That will help me rule out if my problem is this build of CWM or keep looking for other problems.
[Android Head-Units] pdanders11:
I think I'm on the path to /system ro trip mechanism

I think Kenwood is using nothing more the the linux kernel option fsnotify/inotify to monitor the partitions.

reading this and google translate this to English you'll find app in inotifywait_bin_android.zip that will interface to the kernel and let you monitor certain directories.

In the example

# ./inotifywait -r -m /data /cache /system
Setting up watches. Beware: since -r was given, this may take a while!
Watches established.

will monitor data cache and system which it does. I was hoping to trigger the lock running this but guess what (so far) the lock hasn't tripped. My baseless theory is inotifywait make a direct link to the kernel and doesn't release it so whatever kenwood app goes out to look for system changes is essentially blocked from the kernel

so booting and running the command

# ./inotifywait -r -m /data /cache /system > /dev/null &

will run the app in the background and as long as it doesn't crash, I assume the lock won't trip.

So I guess I need to find an init script to launch this on boot and maybe we will have the lock disabled. Probably better/cleaner ways then piping to /dev/null put right now that's the best I got.

Thoughts [MENTION=5909218]radux.m.dan[/MENTION] and [MENTION=5633894]chris.davis925[/MENTION] ?
[Android Head-Units] chris.davis925:
At first glance this would make sense because it fits the two observations

1) ***SYSTEM HAS BEEN MODIFIED*** gets displays in log very near init, which means however it knows this occurs early on or in the boot image.

2) The partitions are not locked immediately following the stock Kenwood update being applied. This means that the unit needs to time to establish a base to figure out what has and has not been changed?

If number 2 is correct, Android must somehow write information in memory indicating that a difference was found. I wonder where it is making this notation? Perhaps it's possible to track this down somehow.
[Android Head-Units] chris.davis925:
What do you mean by "toolbox does something around the lock"?
[Android Head-Units] chris.davis925:
I was able to fix my second unit that was booting only into recovery.

I created and applied a stock recovery .zip file in CWM. After it applied successfully I installed update.zip (The Kenwood Stock Update) from within CWM. When it reboot after the update, it reboot sin stock recovery with a "Waiting" screen.

At this point you can insert your USB stick with the same update.kw stock recovery file and it will continue with "System Rebuilding".

Note: It seems to know that the update was installed and it doesn't re-copy the files form USB, it just continues the second phase of building the quick boot image.

Stock recovery zip attached here in case it helps anyone.
[Android Head-Units] chris.davis925:
Anyone still around?

I've successfully remapped /sdcard to the ext-sd mount point - so that /sdcard is actually the external SD card. This is useful for apps that always store data to /sdcard.

I was thinking - since whatever protection is in place is to blame for the /system rw lock and also to blame for why installing new apps/upgrading existing apps results in corruption - can't we just remap the /data mount point to /sdcard? (Which I've now made the ext_sd)

I think it should be possible but I think it has to be done at init, and not after start up, right? I think Android would crash if /data wasn't mapped correctly early on in start up. So perhaps we have to create a custom boot.img since init.d scripts get overwritten on every boot?

My thought is that if the /data location is really on the external SD card, whatever protection that is locking/corrupting /data /data/davlik-cache etc will be bypassed.

Thoughts?
[Android Head-Units] khan.waqar:
DNN990 - Rooting

Hi I am getting "No Such file or directory" when I try to ftp or cp the kroot_temp.tar and ds_kroot.tar file. Steps prior to these go through. Please let me know what to do? I do not have any clue of the steps and just following steps. I am using Windows 7 Ultimate, and Metasploit Exploit and every thing works fine and it connect to the box but it does copy of ftp..

Is there a specific place or directory where kroot_temp.tar and ds_kroot.tar files should be? Currently they are in my download directory of my laptop. I copied it on sd card and inserted in Kenwood unit but no go..

Please help...
[Android Head-Units] Metoposcopy:
I guess the fight for root on this device is over?
[Android Head-Units] chris.davis925:
I've already rooted it. Only problem left unresolved is the file system lock.

I've ordered a UART device to serial to the unit. Still hasn't come in.
[Android Head-Units] Metoposcopy:
I am having numerous problems with blue tooth and other things. Would be nice to have permanent root
[Android Head-Units] chris.davis925:
Would be nice to have exact details on what you are seeing...
[Android Head-Units] Metoposcopy:
I have a Samsung Galaxy S4 that will not stay paired to the unit. I have hard reset both devices, have updated the firmware in the DNN990 for blue tooth and the unit itself to the latest versions, but every time I enter the vehicle, it does not pair automatically. I pair fine in my wife's Mazda every time with no issues
[Android Head-Units] chris.davis925:
Has nothing to do with the unit being rooted. I have two units and one of them has a similar problem with my Galaxy Note 3 - it connects fine sometimes, other times it connects then disconnected etc. The only way I can resolve that is to turn off Bluetooth on my phone then reconnect.

Bluetooth authentication is not handled by the Android system.
[Android Head-Units] Metoposcopy:
Oh, I understand that.. my biggest issue is with not being able to do things like change the home screens with my own widgets and install an app like weather bug eliye
[Android Head-Units] aplusmiami:
I've had issues with the Bluetooth and my s5 disconnecting on a rooted and a stock unit. It's inherent to the device. I believe they use parrot Bluetooth. Anyway loading apps is always going to be hit or miss.. it's an old android version.

---------- Post added at 04:11 AM ---------- Previous post was at 04:09 AM ----------

I should also mention I had disconnect issues with my HTC as well. More often than not it does work some what reliable.
[Android Head-Units] almalki2008:
a terrible problem

Hi there

I have a terrible problem on my screen

It's keeping show this message for me

And I don't know what I do

The message says (system rebuilding please wait)

I wait for it for 3 hours and nothing happened
[Android Head-Units] aplusmiami:
Are you rooted?
[Android Head-Units] almalki2008:
no i did not rooted
[Android Head-Units] chris.davis925:
[MENTION=4791431]pdanders11[/MENTION] - Can you post what serial settings you are using? Example: Baud Rate, start stop/ flor control etc?

I just bought a USB UART and when I hook up to what I think are UART_TX and UART_RX I get a constant flow of gibberish in my terminal session.

Perhaps you could also post more information on the pin out you are using? I saw what you posted before, but that does not match what I think is TX/RX.
[Android Head-Units] aplusmiami:
almalki2008

This thread topic is on rooting and development on the device. Try a Google search and there is a Kenwood forum with a lot of information.

One suggestion.... Get the latest firmware and boot the device with the stick installed. Press the Red triangle in the front of the machine if it gets stuck. I once had to do this three times before the rebuild would work.
[Android Head-Units] almalki2008:
Aplusmiami

Thanks for the useful information and iam sorry to write this thread

But I am wondering how I can make main rooted??!! And thanks again

أرسلت من SM-N9005 بإستخدام تاباتلك
[Android Head-Units] chris.davis925:
Update: I did get serial UART to work. Turned out to be a driver thing.

On my soft bricked unit I was able to get into the stock recovery for a moment by flooding "r" into the console, but it only quickly flashes "Waiting" then reboots.

I assume it looks for update.kw or update.zip but it doesn't take it from USB or external-SD.

Can anyone shine some light on how to get a shell on a soft bricked unit or make recovery look at USB/External-SD?

Thanks

---------- Post added at 05:18 PM ---------- Previous post was at 04:33 PM ----------

Update: I did get serial UART to work. Turned out to be a driver thing.

On my soft bricked unit I was able to get into the stock recovery for a moment by flooding "r" into the console, but it only quickly flashes "Waiting" then reboots.

I assume it looks for update.kw or update.zip but it doesn't take it from USB or external-SD.

Can anyone shine some light on how to get a shell on a soft bricked unit or make recovery look at USB/External-SD?

Thanks
[Android Head-Units] chris.davis925:
Update: I was able to get into fastboot, but my OTG port simply does not work. I get unidentified device on USB after triple checking my connections. I am not sure why my OTG port doesn't work, but it doesn't. :(

With that being said, does anyone have any ideas on how to get the unit to apply an update with only a serial connection? I am wondering if anyone has had any luck getting the unit to boot another partition like UPDATE or KPANIC?

I have concluded my unit is soft bricked because the quickboot image signature is mismatched / corrupt and for some reason the unit is not automatically recreating the unit. This is why I am hoping someone has figured out booting into another partition from one of the pins on the debug port since then I could boot into one of the other partitions.
[Android Head-Units] aplusmiami:
I applaud your determination..... I wish I had half your knowledge. Wish I could help.
[Android Head-Units] aplusmiami:
ADB - Unknown devices

I ran into something weird on my rooting computer - It has been sitting for a while doing nothing. I needed to root a phone and my adb was all out of wack.. I figured it was all that messing around with the Kenwood. Well I rebooted the phone into recovery and while it was started I Saw BRIEFLY Kenwood in Device Manager and it went away... So I think my device IDs are all out of wack. So I restarted the phone again and when ADB devices came up I noticed no Kenwood. So I quickly uninstalled the ADB Device found (which was not the correct phone) and re-installed the universal adb drivers and now everything works.... The key here is to do it while it shows ADB devices in device manager. Maybe that will get some of you back to seeing that Kenwood device again... I'm not about to pull my unit out so LMK if this helps at all...