Booten in den ClockworkMod klappt nicht

[kocki]

Hallo,
nachdem ich heute mein Medion Lifetab P9516 gerootet habe, möchte ich jetzt über den Rom Manager und clockworkmod backup & recovery ein Backup machen.

Habe ROM Manager Premium v5.0.0.9 und clockworkmod recovery 5.8.3.4 installiert.

Bei Auswahl <Sicherung des aktuellen ROMs> kann ich noch den Dateinamen eingeben, drücke in dann ok, rebootet das Lifetab in den Normalmodus, ohne das Backup zu machen.

Beim Versuch <Neustart ins Recovery-System> passiert das gleiche, reboot in den Normalzustand.

Scheint so, dass das lifetab nicht in den recovery modus versetzt werden kann, oder ich habe es bisher nicht gefunden.

Weiss jemand weiter?

LG
kocki

 

[dirkw01]

Scheint so, dass das lifetab nicht in den recovery modus versetzt werden kann, oder ich habe es bisher nicht gefunden.

Hat meines Wissens nach bisher keiner gefunden.
War allerding angesichts fehlendem Root wohl auch noch kein ernsthaftes Thema.

Gruß
Dirk

 

[-MaD-]

Ich kam bisher nicht zum Rooten des LT. Über den Rom Manager kannst du aber ev. ein CWM-Recovery einspielen. Einen Versuch ist es wert. Sonst: Titanium Backup im Playstore kaufen...

 

[kocki]

Hi,
Titanium Backup habe ich schon lange im Einsatz. CWM-Recovery hat den Charme ein komplettes Gerät mit allen Daten usw. zu sichern und ggf. wieder herzustellen. Habe es schon öfters bei meinem HTC Sensation angewendet um z.B. verschiedene ROMs zu testen.

LG

kocki

Ich kam bisher nicht zum Rooten des LT. Über den Rom Manager kannst du aber ev. ein CWM-Recovery einspielen. Einen Versuch ist es wert. Sonst: Titanium Backup im Playstore kaufen...

 

[YLG80]

I've successfully built a recovery.img with CWM Recovery via Recovery Builder this morning .
It qualifies the build as successful and stable.

Build details :
[FONT=&quot]Made from a Lifetab P9516 3G 64Gb (ICS 4.0.3 rooted) recovery.img
[/FONT]
[FONT=&quot]input files :
[/FONT]
[FONT=&quot]recovery.fstab and graphic.c from the P9516 DVD sources disk. [/FONT]
[FONT=&quot]recovery.img generated from the mmcblk0p1 partition of a working ICS 4.0.3 P9516 tablet.[/FONT]

The builds can be found in Recovery Builder under 5923 and 5926 (touch recovery builds)
(build details : [FONT=&quot]8a4b7534a057f5cceb1ed9f5ba1eb141[/FONT]
I did it twice with the same input because I was unable to edit the information on that build (still have no permission to edit despite of login)

Now what ? How to test it without bricking the device ?

PS : The build (CWM Touch) was erased after 24h so here is the download link : http://www.avi-plus.com/download/MEDION_P9516_CWM_Recovery_Build_output.zip

 

[kocki]

Now what ? How to test it without bricking the device ?

Hello YLG80,
I've tried cwm with other device settings, after that I wasn't able to change the mobile settings. When trying to repair this, I bricked my LT. So be careful with testing.

LG

kocki

 

[YLG80]

Hello Kocki,

Thanks for the warning.
It's too bad for your LT.
Do you still have access to the recovery mode (APX) or to adb ?

Prior to test my build, I'm trying to compare the original recovery.img with the cwm recovery.img .
I'm trying to split the recovery kernel from the ramdisk and compare both files.
But I need to transfer my files to my Linux laptop to continue with specific tools.
What I can see so far, is that the generated cwm recovery.img looks very similar (in structure) to the one recently generated and working by El_Fuego in the same forum, S9512 topics.

More on that later.

Yves

 

[YLG80]

I've triple checked the cwm image build for the P9516 made on builder.clockworkmod.com.

To check the images, I've mounted them (original and patched one) under Linux and both image looks to have the same structure.
Only the structure can be checked, as most directories are empty when mounted in Linux.

So I've decided to flash it in the P9516 tab:

su
  cd /sdcard
  cat /dev/zero > /dev/block/mmcblk0p1   -> returns write: No space left on device :blink:

  dd if=recovery.img of=/dev/block/mmcblk0p1 -> returns 10540+0 records in
10540+0 records out
5396480 bytes transferred in 3.087 secs (1748130 bytes/sec)

As far as I see, it does not work.
I can still boot normally, but when I boot in recovery mode, I get the same normal black screen with the two LED's ON. No menu.
There is nothing displayed on the screen.
In the meantime I've reinstalled the original recovery.img w/o any problem.

Any suggestion ?
Thanks
Yves

 

[YLG80]

Follow up:
Despite of the fact that it returns

5396480 bytes transferred in 3.087 secs (1748130 bytes/sec)

nothing has been moved to /dev/block/mmcblk0p1.
If I transfer the recovery.img back to the sdcard it keeps the size of the original stock recovery.img and not the new size.

That's likely the reason why I don't see any difference after flashing a cwm recovery.img.

I've also tried unsuccessfully to use the script install-recovery.sh from /system/etc

./..

 

[Ameisentaetowierer]

Maybe because it's a blockdevice.
I think, that you need to set the blocksize.

Check this out
http://en.m.wikipedia.org/wiki/Dd_(Unix)

Micky

Gesendet von meinem MD_LIFETAB_P9516 mit der Android-Hilfe.de App

 

[YLG80]

Hello Mickey,
Thank you for your suggestion.
However the link looks not good.
It refers to a Wiki on the Dd ?
Yves

 

[YLG80]

Followup on CWm
I've made several trials ... unsuccessful.

In fact the cwm-recovery.img build is indeed uploaded to /dev/block/mmcblk0p1 .
Only the block partition size remains the same when read back with dd .

I've also tried several different cwm builds from the Lenovo K1 and the Thinkpad .(khanning builds)

I've renamed the /system/etc/install.recovery.sh which forces a stock recovery.img reload if the partition has a different SHA-1 checksum.

I've also renamed /system/recovery-from-boot.p to be sure ! (this is the image that is reloaded in /dev/block/mmcblk0p1 if the SHA-1 calculated is found to be different.

I've also made tests with adding an update.zip file in the /sdcard/Download directory just in case it would be impossible to enter the recovery mode if an update.zip file is absent.
That fake update.zip file is simply erased. No warning/error icon in the recovery screen.

So I cannot get any cwm menu 'till now.

I'm wondering if my builds on Koush website are correct as the builder is now building images for Jelly Bean.

The only conclusion is that the device is not bricked when changing the recovery.img.
But this does not help setting up CWM for the P9516 ...

The recovery screen remains black despite of the fact that the APX driver is correctly loaded with the different cwm images.

Anyone knows how to read the recovery log file ?
I cannot find that file in the cache directory.

Yves

 

[Ameisentaetowierer]

Hi Yves,

I follow this thread with interest.
Unfortunately I don't know nothing about flashing ROMs and I'm not keen on bricking my LT.

But maybe I can help a bit with reading and interpreting shell-scripts like install-recovery.sh.

So here's my idea about it.
applypatch -c /partition:size:hash checks, if the /partition has a specific size and hash. The size is a bit confusing, because it does not refer to the partition, but to the image, that resides on the partition. So if we want to read the image from the partition, we have to use the dd-command:
dd if=/partition of=/sdcard/filename bs=2048 count=(the size from above, divided by 2048)
to get only the image.
If the there's not count specified, I assume the partition is padded with zeros.
But then the image is too big and -more important- the sha1sum will be different.

The second form of applypatch in install-recovery.sh mixes the patch from /system/recovery-from-boot.p with the image from blockdevice p2 and writes the result to blockdevice p1.

Patching an image sounds a bit strange, what do you think?

But it can be confirmed by taking the command from install-recovery.sh and replacing the second blockdevice (EMMC:/dev/block/platform/sdhci-tegra.3/by-num/p1) in the parameterlist with a filename. The file then will be of the size 4061184 and contain exactly the same image as blockdevice p1.
It can then be verified using the command
applypatch -c filename size sha1sum-hash

A little bit strange, that for a device you have to separate the 3 parameters with colons, but for a file with spaces.

Actually I've unpacked both images (p1,p2) to understand the difference between them.
But I think theres indeed a patch to a previous image, since I can find the image from p2 in the previous build (MD_LIFETAB_P9516_21_21_120604_M_DES).

I've also unpacked the image you have uploaded. It looks like the init.rc has been changed an there are lots of commands (could be busybox) installed in the new image.
Did you try "adb logcat" or "adb shell" when the screen was black?

Micky

 

[YLG80]

Hi Mickey,
Thanks 1.10E6 times for your very interesting post ! Be sure that I do not want to brick my LT either.
I would prefer to use JTAG for that as I 'm much more used to use JTAG.

It's good to receive comments likes yours as I was feeling to have reached the end of my cwm search.
You brought to me very important things :

So here's my idea about it.
applypatch -c /partition:size:hash checks, if the /partition has a specific size and hash. The size is a bit confusing, because it does not refer to the partition, but to the image, that resides on the partition. So if we want to read the image from the partition, we have to use the dd-command:
dd if=/partition of=/sdcard/filename bs=2048 count=(the size from above, divided by 2048)
to get only the image.
If the there's not count specified, I assume the partition is padded with zeros.
But then the image is too big and -more important- the sha1sum will be different.

You are right. I've also inspected the install-recovery.sh in order to try to understand it.
This is what I've done :
I took the recovery.img and use an hexeditor to edit the file.
I kept only the first 4061184 bytes (converted in hex) and saved the file under another name.
I've used an sha-1 calculator.

Bingo, it gave the correct sha-1 value referenced in install-recovery.sh.

Your second point looks even more interesting to me. I did not consider the use of applypatch like that. This could explain why cwm is not working.

The second form of applypatch in install-recovery.sh mixes the patch from /system/recovery-from-boot.p with the image from blockdevice p2 and writes the result to blockdevice p1.

Patching an image sounds a bit strange, what do you think?

In the Thinkpad they install cwm like this :

   [I][COLOR=#474747][FONT=&quot]adb push cwr_ventana_2.img /data/local/ [/FONT][/COLOR][/I]
  [I][COLOR=#474747][FONT=&quot]adb shell su mount -o rw,remount /system [/FONT][/COLOR][/I]
  [I][COLOR=#474747][FONT=&quot][COLOR=Red][B]echo "#!/system/bin/sh" > /system/etc/install-recovery.sh [/B][COLOR=Black]
[/COLOR][/COLOR][/FONT][/COLOR][/I]
[I][COLOR=#474747][FONT=&quot][COLOR=Red][COLOR=Black]dd[/COLOR][/COLOR]if=/data/local/cwr_recovery_2.img of=/dev/block/mmcblk0p1[/FONT][/COLOR][/I]

They launch install-recovery.sh prior to copy the image.
What bothers me, is that I've not found any information telling me that they were changing the sha-1 hashes and byte counts in the recovery-install.sh.
When I use the same method in the LT the install-recovery.sh does not output any error nor any warning.
I'm going to explore your point on the second applypatch application.

Actually I've unpacked both images (p1,p2) to understand the difference between them.
But I think theres indeed a patch to a previous image, since I can find the image from p2 in the previous build (MD_LIFETAB_P9516_21_21_120604_M_DES).

Thanks for that key information. I will do some other experiments.

Did you try "adb logcat" or "adb shell" when the screen was black?

Although I've used logcat to try to fetch some information, I even did not think to use it when the screen was black .
I'm afraid it will not work. I believe that the LT APX driver will be dropped down as soon as I issue an adb command.
If I understand well, the APX driver setup when the LT is put in recovery mode is to be used only with NvFlash. Not sure though.
But I will try and l will let you know.

BTW, How do you determine the block size for the dd command. You mentioned bs=2048 ... I was using bs=512 in my tests.
Not sure if that is related to the flash chip or simply how to the flash memory has been formatted.
Yves

Der ursprüngliche Beitrag von 08:35 Uhr wurde um 08:49 Uhr ergänzt:

adb logcat when in recovery mode with a black screen :

C:\adb>adb logcat
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
- waiting for device -

C:\adb>adb shell
error: device not found

As I expected adb as not the right driver to communicate with the LT.

Der ursprüngliche Beitrag von 08:49 Uhr wurde um 10:25 Uhr ergänzt:

On emmc partition block size :
I can reply to my own question.
When copying the partition to an img file, the number of records and the total byte count are displayed.
It's just a matter of dividing the second by the first and it gives the block size.
For example, the p2 partition (boot) has a bs=512 bytes.

On install-recovery.sh:
You've raised a very interesting point with your applypatch explanation.
I will try to modify that shell in order to combine p2 (boot) with the new cwm image.
I've never done that which could explain why the LT in recovery mode does never boot on cwm.
Before to modify install-recovery.sh, I've to calculate the correct byte count and hash for the cwm image.

Thanks again for your help.
Yves

 

[Ameisentaetowierer]

Hello Yves,

I think, that I found something about the 2k blocksize on the internet.
But that doesn't matter, as long as we know the actual imagesize.
Btw: 512 should be the blocksize dd uses, if you don't specify something different

In the link you can find information about images (not for the p9516, but I think, it's useful anyway) and a tool to unpack and repack an image.
The images (from p1, p2, and your upload) I've unpacked so far all contain non-zipped kernels, though the unpack script names them xyz-kernel.gz.
HOWTO: Unpack, Edit, and Re-Pack Boot Images - Android Wiki

The echo-command from the Thinkpad doesn't call install-recovery.sh!
Instead it overwrites install-recovery.sh with just one line, which is the shell-interpreter. Thats the same line as the very first you can find now in install-recovery.sh
They overwrite install-recovery.sh, so the script is still there and can be called, but actualy doesn't nothing more then starting and immediately exiting properly.
Sounds much better to me then deleting install-recovery.sh
And I think there's no need to patch the image.

When you press vol up/down and the power button for APX mode, have a look with the dmesg command on your linux system.
On my system it says:
[ 1358.036057] usb 2-1: new high speed USB device using ehci_hcd and address 6
[ 1358.150976] usb 2-1: New USB device found, idVendor=0955, idProduct=7820
[ 1358.150984] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1358.150990] usb 2-1: Product: APX
[ 1358.150995] usb 2-1: Manufacturer: NVIDIA Corp.

Which nvflash do you use?

Micky

 

[breeder]

Ich find das echt sche... was ihr hier macht. Das ist ein deutsches Forum, und es sollten alle User was davon haben. Wenn ihr englisch reden wollt dann macht das da wo auch englisch geredet wird. Ich als Admin hätte das schon unterbunden. Und wenn jemand kein deutsch kann ist er hier an der falschen Adresse.

…

 

[YLG80]

Hello Mickey
Thanks for that additional information especially on the echo command.
I will also try the unpack tools.
I do not have these tools so I simply mount the img on a linux laptop.
I can only see the structure as most of the directories are empty.

On your system log file, I can see that it is loading the APX driver as the vendor ID is 0955. Otherwhise it's 17EF with the standard adb .

I use a nvflash version dated from 07/01/2011.
But there is a Secure Boot Keey (sbk) enabled in the LT and we don't have that key.
Regards
Yves

 

[Ameisentaetowierer]

Hallo breeder,

Danke für den Hinweis!
Und ich dachte schon, die geringe Beteiligung hier läge am Desinteresse der anderen Forenteilnehmer. :banghead:

Yves und ich können ja in einem englischsprachigen Forum weitermachen.
Wenn wir dann eine Lösung für das Problem gefunden haben, kann jemand hier einen Link darauf posten


Micky


Gesendet von meinem MD_LIFETAB_P9516 mit der Android-Hilfe.de App

 

[YLG80]

Hello Mickey, Breeder

No problem.
I own a forum dedicated to Tips and Tricks and JTAG.
Tomorrow, I will open a thread on that LT in my forum so that we can continue to exchange our information.
I will copy a few posts from here to the other forum.
I will PM you a link a link as soon as the thread is opened.

Again sorry for the english usage.
Yves

Der ursprüngliche Beitrag von 22:02 Uhr wurde um 22:48 Uhr ergänzt:

I've not found the way to PM

Please go to and register : Medion Lifetab P9516 root and clockworkmod - Electronic repair tips website

If you want we'll continue the discussion over there.

Bye bye android-hilfe.de

Yves

 

[Ameisentaetowierer]

Great, I will register immediately!

Micky

Gesendet von meinem MD_LIFETAB_P9516 mit der Android-Hilfe.de App