Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #181433 > unrolled thread

unable to repartition SD card from Android phone

Back to article view | Back to linux.debian.user

Contents

  unable to repartition SD card from Android phone Mark Copper <mlcopper@gmail.com> - 2017-05-26 22:00 +0200
    Re: unable to repartition SD card from Android phone Fungi4All <fungilife@protonmail.com> - 2017-05-27 00:30 +0200
      Re: unable to repartition SD card from Android phone David Christensen <dpchrist@holgerdanske.com> - 2017-05-27 03:00 +0200
        Re: unable to repartition SD card from Android phone Fungi4All <fungilife@protonmail.com> - 2017-05-27 19:20 +0200
          Re: unable to repartition SD card from Android phone JPlews <jw@plews.org.uk> - 2017-05-27 20:30 +0200
          Re: unable to repartition SD card from Android phone David Christensen <dpchrist@holgerdanske.com> - 2017-05-27 21:50 +0200
    Re: unable to repartition SD card from Android phone David Christensen <dpchrist@holgerdanske.com> - 2017-05-27 03:00 +0200
      Re: unable to repartition SD card from Android phone Mark Copper <mlcopper@gmail.com> - 2017-05-27 20:40 +0200
        Re: unable to repartition SD card from Android phone David Christensen <dpchrist@holgerdanske.com> - 2017-05-27 23:00 +0200
          Re: unable to repartition SD card from Android phone Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-05-28 11:40 +0200
            Re: unable to repartition SD card from Android phone David Christensen <dpchrist@holgerdanske.com> - 2017-05-28 18:30 +0200
    Re: unable to repartition SD card from Android phone JPlews <jw@plews.org.uk> - 2017-05-27 20:20 +0200

#181433 — unable to repartition SD card from Android phone

Maybe I should just toss it, but I'm curious why none of my tools can
recover an SD card previously used for Android internal storage.

Here's how gdisk sees it:
gdisk -l /dev/sdc

GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 62333952 sectors, 29.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 7DA17515-4FE8-43DF-A424-86C8EA090235
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 62333918
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048           34815   16.0 MiB    FFFF  android_meta
   2           34816        62333918   29.7 GiB    FFFF  android_expand

Utilities like dd, fdisk, parted, wipefs, gdisk all report success in
modifying the partition table none actually do.

Here's an example:

 wipefs -a /dev/sdc
/dev/sdc: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20
50 41 52 54
/dev/sdc: 8 bytes were erased at offset 0x76e47fe00 (gpt): 45 46 49 20
50 41 52 54
/dev/sdc: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/sdc: calling ioctl to re-read partition table: Success

But nothing is actually affected:

partx --show /dev/sdc
NR START      END  SECTORS  SIZE NAME           UUID
 1  2048    34815    32768   16M android_meta
ea26c4a2-1eb3-4dd3-90b4-a2f4c6e2d993
 2 34816 62333918 62299103 29.7G android_expand
43ad70ab-2890-fa97-93a1-ae5e86950d19

Can anything return this card to a single ext4 partition for external
storage/data transfer?

Thanks.

[toc] | [next] | [standalone]

#181443

[Multipart message — attachments visible in raw view] — view raw

From: mlcopper@gmail.com

Maybe I should just toss it, but I'm curious why none of my tools can
recover an SD card previously used for Android internal storage.

Is it still functional in android?
I think google locks the mbr so no other system can ever use it again.
But while it gives you a long error message in another system it notifies
google of what that system is and which android user is attempting it.
Then it returns and burns up your android device.
Maybe I can write a novel on it, so you will have to pay google to read
the rest :)

[toc] | [prev] | [next] | [standalone]

#181461

On 05/26/2017 03:23 PM, Fungi4All wrote:
> I think google locks the mbr so no other system can ever use it again.

How?  Please provide citation(s).


> But while it gives you a long error message in another system it notifies
> google of what that system is and which android user is attempting it.

How?  Please provide citation(s).


> Then it returns and burns up your android device.

How?  Please provide citation(s).


> Maybe I can write a novel on it, so you will have to pay google to read
> the rest :)

Please do, but release it under a license that allows us to read it 
on-line for free and then decide if we want to buy it.


David

[toc] | [prev] | [next] | [standalone]

#181509

[Multipart message — attachments visible in raw view] — view raw

From: dpchrist@holgerdanske.com

On 05/26/2017 03:23 PM, Fungi4All wrote:
> I think google locks the mbr so no other system can ever use it again.

How? Please provide citation(s).

I am kidding, but you may want to try this straight off your debian repository or
the latest from its developers http://www.embedded-projects.net/usbprog/
USBprog, it may give hints of whether something may be fixible. I don't have
much experience on it, I tried to see once whether you can read and/or write
firmware on something. I was wondering whether the diference between a
manufacturers usb-sticks was firmware and the rest was identical between 8GB
and 128GB. So I had identical models of the same issue of 2 different sizes and
was trying to compare. It seemed a bit more complex than programming eprom
chips.

> But while it gives you a long error message in another system it notifies
> google of what that system is and which android user is attempting it.

How? Please provide citation(s).

That's my shot on science fiction, but you wouldn't think they are that evil, do you?

>Please do, but release it under a license that allows us to read it
>on-line for free and then decide if we want to buy it.

Only Greeks provide you with free gifts if you are a heroic Thracian city. For
everything else there is always a cost.

Have you by any chance read The Bourne Identity by Robert Ludlum, or anything else
by him. Some were made into movies but as always, read the book first.

(AK)

[toc] | [prev] | [next] | [standalone]

#181514

On 27/05/17 18:18, Fungi4All wrote:

>> > But while it gives you a long error message in another system it 
>> notifies
>> > google of what that system is and which android user is attempting it.
>>
>> How? Please provide citation(s).
> 
> That's my shot on science fiction, but you wouldn't think they are that 
> evil, do you?

It would be naive to think they are not logging card and phone info, 
does the Google PDF reader actually need a phone ID for the purposes of 
displaying a file or storing IDs for everything you open with it on 
their systems?

[toc] | [prev] | [next] | [standalone]

#181519

On 05/27/2017 10:18 AM, Fungi4All wrote:
> From: dpchrist@holgerdanske.com
>
>> Please do, but release it under a license that allows us to read it
>> on-line for free and then decide if we want to buy it.
>
> Only Greeks provide you with free gifts if you are a heroic Thracian city. For
> everything else there is always a cost.

You are incorrect:

     https://mitpress.mit.edu/sicp/

     http://hop.perl.plover.com/


David

[toc] | [prev] | [next] | [standalone]

#181462

On 05/26/2017 12:52 PM, Mark Copper wrote:
> Maybe I should just toss it, but I'm curious why none of my tools can
> recover an SD card previously used for Android internal storage.

Does you SD card and/or SD card adapter have a write-protect tab or 
other such mechanism?  If so, put it in the unlocked position.


Have you tried using dd to wipe the first megabyte (including the 
partition table)?

# dd if=/dev/zero of=/dev/sdc count=2048; sync


David

[toc] | [prev] | [next] | [standalone]

#181515

>
> Does you SD card and/or SD card adapter have a write-protect tab or other
> such mechanism?  If so, put it in the unlocked position.

The micro SD cards used in phones don't appear to have such
mechanisms, but your point is well taken; viz. I've not adequately
checked the hardware path (MB, card reader, etc. red-faced here...)

>
> Have you tried using dd to wipe the first megabyte (including the partition
> table)?
>
> # dd if=/dev/zero of=/dev/sdc count=2048; sync
>

Yes, but no effect. Even count=1 gets to non-zero bytes:

dd if=/dev/sdc count=1 | od -b
0000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
*
0000700 002 000 356 377 377 377 001 000 000 000 377 043 267 003 000 000
0000720 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
*
0000760 000 000 000 000 000 000 000 000 000 000 000 000 000 000 125 252
1+0 records in
1+0 records out
0001000
512 bytes (512 B) copied, 0.00365101 s, 140 kB/s

dd if=/dev/zero of=/dev/sdc count=1; sync
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.0170507 s, 30.0 kB/s

 dd if=/dev/sdc count=1 | od -b
0000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
*
0000700 002 000 356 377 377 377 001 000 000 000 377 043 267 003 000 000
0000720 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
*
0000760 000 000 000 000 000 000 000 000 000 000 000 000 000 000 125 252
, 0.00290682 s, 176 kB/s
1+0 records in
1+0 records out
512 bytes (512 B) copied
0001000

Maybe I'm not looking at this right...

The idea that a card could be locked up by the OS is titillating but
improbable. There would have to be an (apparently) unpublished trap
door or a back door to the disk controller in a generic disk.  So it's
gotta be hardware and this has all been noise.

[toc] | [prev] | [next] | [standalone]

#181523

On 05/27/2017 11:30 AM, Mark Copper wrote:
>>
>> Does you SD card and/or SD card adapter have a write-protect tab or other
>> such mechanism?  If so, put it in the unlocked position.
>
> The micro SD cards used in phones don't appear to have such
> mechanisms, but your point is well taken; viz. I've not adequately
> checked the hardware path (MB, card reader, etc. red-faced here...)

I bought a SanDisk 32GB Micro SDHC card for my Android phone a while 
back.  It came with a Micro SDHC to SD adapter, and the adapter has an 
unmarked switch in the same style and location of the write-protect 
switches on my other SD cards.  I'm not sure if the switch actually does 
anything.


>> Have you tried using dd to wipe the first megabyte (including the partition
>> table)?
>>
>> # dd if=/dev/zero of=/dev/sdc count=2048; sync
>>
>
> Yes, but no effect. Even count=1 gets to non-zero bytes:
>
> dd if=/dev/sdc count=1 | od -b
> 0000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
> *
> 0000700 002 000 356 377 377 377 001 000 000 000 377 043 267 003 000 000
> 0000720 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
> *
> 0000760 000 000 000 000 000 000 000 000 000 000 000 000 000 000 125 252
> 1+0 records in
> 1+0 records out
> 0001000
> 512 bytes (512 B) copied, 0.00365101 s, 140 kB/s
>
> dd if=/dev/zero of=/dev/sdc count=1; sync
> 1+0 records in
> 1+0 records out
> 512 bytes (512 B) copied, 0.0170507 s, 30.0 kB/s
>
>  dd if=/dev/sdc count=1 | od -b
> 0000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
> *
> 0000700 002 000 356 377 377 377 001 000 000 000 377 043 267 003 000 000
> 0000720 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
> *
> 0000760 000 000 000 000 000 000 000 000 000 000 000 000 000 000 125 252
> , 0.00290682 s, 176 kB/s
> 1+0 records in
> 1+0 records out
> 512 bytes (512 B) copied
> 0001000
>
> Maybe I'm not looking at this right...

I think you are looking at it correctly.  Your console session indicates 
that the drive appears to accept writes, but is actually discarding them.


> The idea that a card could be locked up by the OS is titillating but
> improbable. There would have to be an (apparently) unpublished trap
> door or a back door to the disk controller in a generic disk.  So it's
> gotta be hardware and this has all been noise.

Perhaps the drive firmware has decided the device is failing, and has 
forced read-only mode so that you have a chance to recovery any viable 
data (?).


Have you tried contacting technical support for the drive manufacturer?


David

[toc] | [prev] | [next] | [standalone]

#181535

Le 27/05/2017 à 22:58, David Christensen a écrit :
>
> I bought a SanDisk 32GB Micro SDHC card for my Android phone a while
> back.  It came with a Micro SDHC to SD adapter, and the adapter has an
> unmarked switch in the same style and location of the write-protect
> switches on my other SD cards.

It is not a switch. It is a lock. Its physical position is sensed by a 
switch inside the card reader, just like the lock on floppy disks was 
sensed by a switch inside the floppy disk drive.

[toc] | [prev] | [next] | [standalone]

#181550

On 05/28/2017 02:35 AM, Pascal Hambourg wrote:
> Le 27/05/2017 à 22:58, David Christensen a écrit :
>>
>> I bought a SanDisk 32GB Micro SDHC card for my Android phone a while
>> back.  It came with a Micro SDHC to SD adapter, and the adapter has an
>> unmarked switch in the same style and location of the write-protect
>> switches on my other SD cards.
>
> It is not a switch. It is a lock. Its physical position is sensed by a
> switch inside the card reader, just like the lock on floppy disks was
> sensed by a switch inside the floppy disk drive.

Thanks for the clarification.  :-)


David

[toc] | [prev] | [next] | [standalone]

#181512

On 26/05/17 20:52, Mark Copper wrote:
> Maybe I should just toss it, but I'm curious why none of my tools can
> recover an SD card previously used for Android internal storage.
> 

I have returned 2 cards from this state, dd has never failed me but 
needs extra steps to remove both places GTP is storing data, should 
fdisk or similar fail

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web