View Single Post
Old 05-23-2013, 08:21 AM   #14
knc1
Going Viral
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 17,212
Karma: 18210809
Join Date: Feb 2012
Location: Central Texas
Device: No K1, PW2, KV, KOA
Quote:
Originally Posted by dsmid View Post
Yes, it can be perceived as a problem that came from the Kubrick flash, but Kubrick has no chance to avoid it.
As I wrote, there is some connection between pcbID and serial (I don't know the exact way how to check if these two match or not). A reference to pcbID seems to be stored somewhere in the diags partition, thus flashing a diags image from a different device will always get the diags tools into inconsistent state when pcbID referenced from the diags partition does not match the serial.

The only way how to fix it would be to find the location of pcbId reference in diags and overwrite it with the genuine pcbId of your device.

AFAIK this inconsistency does not have any side effects besides problems with exiting the diags mode that can be worked around by methods I mentioned above.
None of my devices has any problems with registering and firmware updates.
The relationship may well be maintained in /var/local (mmcblk0p3) which kubrick does not touch (unless you tell it to).

destroy the filesystem on mmcblk0p3 by writing 15 blocks of 512 bytes of 0 to it - - re-boot.
The boot process will re-build /var/local filesystem to match the device.
knc1 is offline   Reply With Quote