Project

General

Profile

Actions

Issue #531

closed

error during restoring data from the recovery for Galaxy S (GT-I9000)

Added by Ivan Zakharyaschev almost 11 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Category:
Framework
Target version:
-
Start date:
05/19/2013
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed
Device:
Galaxy S (I9000)
Grant:
Type of work:

Description

I'm using the recovery.img for Galaxy S (GT-I9000) from http://redmine.replicant.us/projects/replicant/wiki/ReplicantImages (the last one, from 2013-04-06), on two such devices.

I've created a backup on one of them, copied the clockworkmod/ directory to the other one, and want to restore it there.

But an error happens when restoring data. The log is attached.

(My main system is CyanogenMod 10.)

Of course, it'd be nice if the error got fixed, so that the restore process succeeds.

As a prerequisite to fixing this error, it'd be helpful, if the error message was more informative: what went wrong.

Also, I could try to figure out what is wrong and debug the restore process myself, but for this, a prerequisite is for me to be able to study the source code of the restore program and to run it under tracing/debugging tool (the first simplest thing would be for me to run it under strace, in an emulator of Android perhaps). Since the Replicant project is known to pay special attention to being free software, I'm expecting to have the freedom to study the source code and to debug. But unfortunately, this is not very clear how to do: the page where I've got the recovery.img from (http://redmine.replicant.us/projects/replicant/wiki/ReplicantImages) doesn't point me to the source code of the image, and doesn't explain how I can peek inside the image on another system for studying it. This is hindering us exploiting the benefits of the freedoms of free software.

Well, some additional information, so that you perhaps are able to think about a reason for the error:

the backup I've made on the same device before can be restored without such an error. So, I'm attaching the 2 data backups (without the blobs) -- to be able to compare them. I've also extracted the list of filenames from the 2 backups (with cut) to diff them.

BTW, the process seems to interrupt around the files xt.*, uid.*, uid_tag.* from system/netstats/ . Does this give you a clue about what can be wrong?

I'm struggling to restore that backup. If you give an advice how to overcome the error, I'd be grateful.


Files

report.log (57.8 KB) report.log the log wehn I did the restore with error Ivan Zakharyaschev, 05/20/2013 12:12 AM
zwerg_data.ext4.dup (93.4 KB) zwerg_data.ext4.dup the backup that caused the error Ivan Zakharyaschev, 05/20/2013 12:12 AM
peipsi_data.ext4.dup (66 KB) peipsi_data.ext4.dup the backup that caused no error Ivan Zakharyaschev, 05/20/2013 12:12 AM
zwerg_fnames_data.ext4.dup (38.7 KB) zwerg_fnames_data.ext4.dup filenames cut from the backup that caused the error Ivan Zakharyaschev, 05/20/2013 12:12 AM
peipsi_fnames_data.ext4.dup (26.6 KB) peipsi_fnames_data.ext4.dup filenames cut from the backup that caused no error Ivan Zakharyaschev, 05/20/2013 12:12 AM
Actions #1

Updated by Paul Kocialkowski almost 11 years ago

First, I'd like to make an overall statement about recovery: the Replicant project is not the author of it, it is simply ClockworkMod recovery as released on CyanogenMod CM source tree, on top of which we added a menu for flashing images (that directly uses the nandroid restore function). So your request would be more relevant upstream.

Since the Replicant project is known to pay special attention to being free software, I'm expecting to have the freedom to study the source code and to debug. But unfortunately, this is not very clear how to do: the page where I've got the recovery.img from (http://redmine.replicant.us/projects/replicant/wiki/ReplicantImages) doesn't point me to the source code of the image, and doesn't explain how I can peek inside the image on another system for studying it. This is hindering us exploiting the benefits of the freedoms of free software.

Obviously, the recovery image is made of free software that you can study, modify, debug, etc. You just didn't look for the instructions in the right place: GalaxySBuild gives clear indications on how to rebuild the images we distribute (recoveryimage is one of the targets listed on that page). Check out the prerequisites and you're good to go!

More specifically, the relevant repo is https://gitorious.org/replicant/bootable_recovery/commits/replicant-4.0

The real error, that is clearly stated in the log is: "Unable to copy file ./system/netstats/xt.1366492225193-1367788526285".
That may be because there was an error during the copying of this file to the 2nd device or that your device's mtd has an issue. You can probably exclude that one (by modifying the list of files I guess). I also guess that rebooting even after that error would work since most of /data seems to have been brought back in place.

Actions #2

Updated by Ivan Zakharyaschev almost 11 years ago

Paul Kocialkowski wrote:

First, I'd like to make an overall statement about recovery: the Replicant project is not the author of it, it is simply ClockworkMod recovery as released on CyanogenMod CM source tree, on top of which we added a menu for flashing images (that directly uses the nandroid restore function). So your request would be more relevant upstream.

Thank you very much for your reply!

Now I understand that the upstream for the recovery is the CyanogenMod project -- previously, I couldn't understand where the upstream for ClockworkMod recovery is. I could even report the bug to nandroid developers -- is nandroid an individual project separate from CyanogenMod with its own upstream?

More specifically, the relevant repo is https://gitorious.org/replicant/bootable_recovery/commits/replicant-4.0

Thanks, I'll look inside it.

The real error, that is clearly stated in the log is: "Unable to copy file ./system/netstats/xt.1366492225193-1367788526285".

Oh, I simply wasn't attentive enough to notice this error message not at the very end of the log! (I actually had a similar error before -- when I didn't copy all the blobs to the new device, but that time it appeared at the very end of the log, so it was easy to notice.)

That may be because there was an error during the copying of this file to the 2nd device or that your device's mtd has an issue. You can probably exclude that one (by modifying the list of files I guess). I also guess that rebooting even after that error would work since most of /data seems to have been brought back in place.

Yes, rebooting did work. But AFAIU, since the process of copying /data was interrupted, the next substage of restoring data (datadata) didn't complete, and perhaps because of that the apps in the new system behaved strange.

Also, if I simply deleted the file from the list, I'm afraid, the checksum test wouldn't pass, and the restore procedure wouldn't run. (Just a guess, not tried, because I didn't notice the error message.)

(So, a more fine-grained advanced restore would help in this case, with more substages.)

I'll look into possible mtd issues, thanks!

Actions #3

Updated by Paul Kocialkowski almost 11 years ago

I could even report the bug to nandroid developers -- is nandroid an individual project separate from CyanogenMod with its own upstream?

AFAIK ClockworkMod recovery is developed by the CyanogenMod team, so their bug tracker would be fine. However the error here is plainly I/O and is not related to ClockworkMod itself (ClockworkMod behaves normally facing this error), so there is nothing to fix there.

But AFAIU, since the process of copying /data was interrupted, the next substage of restoring data (datadata) didn't complete, and perhaps because of that the apps in the new system behaved strange.

That's very likely indeed (I forgot that Galaxy S has a separate /data/data partition). You can then restore /datadata separately as a workaround.

Also, if I simply deleted the file from the list, I'm afraid, the checksum test wouldn't pass, and the restore procedure wouldn't run. (Just a guess, not tried, because I didn't notice the error message.)

There is no global checksum of the whole partition, so if you remove the file from all the lists where it is referred to (including the ones involving checksums), it should go just fine.

I think the real issue is about that I/O error and the only way to fix would be to understand why it happened, hence the two leads I gave previously (either a bad copy or a damaged mtd).

Actions #4

Updated by Ivan Zakharyaschev almost 11 years ago

Yes, for some reason, a few blobs were simply not copied correctly to the new device.

(It's not a valid bug report thus.)

Actions #5

Updated by Ivan Zakharyaschev almost 11 years ago

Sorry for the buzz. Thanks a lot for your help!

Actions #6

Updated by Ivan Zakharyaschev almost 11 years ago

Paul Kocialkowski wrote:

But AFAIU, since the process of copying /data was interrupted, the next substage of restoring data (datadata) didn't complete, and perhaps because of that the apps in the new system behaved strange.

That's very likely indeed (I forgot that Galaxy S has a separate /data/data partition). You can then restore /datadata separately as a workaround.

As a sidenote: the advanced restore menu doesn't have separate items for restoring individually datadata (.android_secure), so this wouldn't be possible through the menu in recovery.

Also, if I simply deleted the file from the list, I'm afraid, the checksum test wouldn't pass, and the restore procedure wouldn't run. (Just a guess, not tried, because I didn't notice the error message.)

There is no global checksum of the whole partition, so if you remove the file from all the lists where it is referred to (including the ones involving checksums), it should go just fine.

I think the real issue is about that I/O error and the only way to fix would be to understand why it happened, hence the two leads I gave previously (either a bad copy or a damaged mtd).

Actions #7

Updated by Paul Kocialkowski almost 11 years ago

  • Status changed from New to Closed
  • Resolution set to fixed
Actions #8

Updated by Denis 'GNUtoo' Carikli about 8 years ago

  • Category changed from 69 to Framework
  • Device Galaxy S (I9000) added
Actions

Also available in: Atom PDF