How to Upgrade Smart Phone Memory with Linux Utilities

Upgrading Flash Memory Chips

We want to install a larger flash memory chip in an Android smart phone. We need to make sure that all of the data has been transferred. This must include all of our personal data — pictures, music, and other media — plus the data structures used by our apps. The tar utility in Linux makes this easy.

I originally added a 16 GB memory chip in the phone. Now I wanted to upgrade to 64 GB.

Plug the memory chip into a reader, and then plug the reader into a USB port on your computer. Below is what we find in the kernel ring buffer on Linux. I have several fixed disks in this system, sda through sdf, so this new device becomes sdg.

$ dmesg
[... many lines deleted ...]
[40643.503784] usb 2-1: new high-speed USB device number 3 using xhci_hcd
[40643.687226] usb 2-1: New USB device found, idVendor=05e3, idProduct=0723
[40643.687229] usb 2-1: New USB device strings: Mfr=3, Product=4, SerialNumber=2
[40643.687230] usb 2-1: Product: USB Storage
[40643.687231] usb 2-1: Manufacturer: Generic 
[40643.687231] usb 2-1: SerialNumber: 000000009451
[40643.689039] usb-storage 2-1:1.0: USB Mass Storage device detected
[40643.692802] usb-storage 2-1:1.0: Quirks match for vid 05e3 pid 0723: 8000
[40643.696786] scsi host9: usb-storage 2-1:1.0
[40644.747626] scsi 9:0:0:0: Direct-Access     Generic  STORAGE DEVICE   9451 PQ: 0 ANSI: 0
[40644.945620] sd 9:0:0:0: [sdg] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)
[40644.946657] sd 9:0:0:0: [sdg] Write Protect is off
[40644.946659] sd 9:0:0:0: [sdg] Mode Sense: 03 00 00 00
[40644.947590] sd 9:0:0:0: [sdg] No Caching mode page found
[40644.947594] sd 9:0:0:0: [sdg] Assuming drive cache: write through
[40644.961245]  sdg: sdg1
[40644.965507] sd 9:0:0:0: [sdg] Attached SCSI removable disk
[40723.791333] usb 2-1: USB disconnect, device number 3
[40733.941295] usb 2-1: new high-speed USB device number 4 using xhci_hcd
[40734.122805] usb 2-1: New USB device found, idVendor=05e3, idProduct=0723
[40734.122808] usb 2-1: New USB device strings: Mfr=3, Product=4, SerialNumber=2
[40734.122809] usb 2-1: Product: USB Storage
[40734.122810] usb 2-1: Manufacturer: Generic 
[40734.122811] usb 2-1: SerialNumber: 000000009451
[40734.124990] usb-storage 2-1:1.0: USB Mass Storage device detected
[40734.134314] usb-storage 2-1:1.0: Quirks match for vid 05e3 pid 0723: 8000
[40734.139308] scsi host9: usb-storage 2-1:1.0
[40735.181143] scsi 9:0:0:0: Direct-Access     Generic  STORAGE DEVICE   9451 PQ: 0 ANSI: 0
[40735.379108] sd 9:0:0:0: [sdg] 31116288 512-byte logical blocks: (15.9 GB/14.8 GiB)
[40735.380235] sd 9:0:0:0: [sdg] Write Protect is off
[40735.380238] sd 9:0:0:0: [sdg] Mode Sense: 03 00 00 00
[40735.381293] sd 9:0:0:0: [sdg] No Caching mode page found
[40735.381297] sd 9:0:0:0: [sdg] Assuming drive cache: write through
[40735.395823]  sdg: sdg1
[40735.400704] sd 9:0:0:0: [sdg] Attached SCSI removable disk
[40737.576590] FAT-fs (sdg1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

I could have done this on OpenBSD. The only difference is that the device names are different. Let's say it's on my laptop, which has just one fixed disk, sd0. The new USB device would be sd1, and /dev/sd1i would be the relevant slice and device name to use in the following.

Back on my Linux desktop, the KDE graphical environment has mounted the new device under /run/media. The automatically generated mount point within that is the user name and then the volume ID of the file system.

$ df -hT
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  3.9G     0  3.9G   0% /dev
tmpfs          tmpfs     3.9G  377M  3.5G  10% /dev/shm
tmpfs          tmpfs     3.9G   18M  3.9G   1% /run
/dev/sde3      btrfs     111G   33G   76G  31% /
tmpfs          tmpfs     3.9G     0  3.9G   0% /sys/fs/cgroup
tmpfs          tmpfs     3.9G   75M  3.8G   2% /tmp
/dev/sde2      xfs       1.1G  289M  751M  28% /boot
/dev/sde1      vfat      499M  132K  498M   1% /boot/EFI
/dev/sda1      ext4      917G  563G  354G  62% /home2
/dev/sdb1      xfs       930G  458G  472G  50% /home3
/dev/sdd1      xfs       3.7T  2.1T  1.7T  56% /home
/dev/sdc1      ext4      1.8T  1.6T  243G  87% /home4
tmpfs          tmpfs     791M   12K  791M   1% /run/user/1000
/dev/sdg1      vfat       15G  1.7G   14G  11% /run/media/cromwell/6139-3733

I change to the newly mounted file system to see what's there.

$ cd /run/media/cromwell/6139-3733/
$ ls -lah
total 182M
drwx------  9 cromwell cromwell  32K Dec 31  1969 .
drwxr-x---+ 3 root     root       60 Apr  8 21:24 ..
drwx------  2 cromwell cromwell  32K Dec  6  2014 .android_secure
drwx------  3 cromwell cromwell  32K Dec  6  2014 Android
drwx------  4 cromwell cromwell  32K Mar 11  2014 DCIM
drwx------  2 cromwell cromwell  32K Mar  2 16:27 LOST.DIR
-rw-r--r--  1 cromwell cromwell  20M Jun 28  2013 SGH-T989_UVMC6_radio.zip
drwx------  2 cromwell cromwell  32K May 11  2016 System Volume Information
drwx------  3 cromwell cromwell  32K Dec 31  2011 clockworkmod
-rw-r--r--  1 cromwell cromwell  11M Jan 10  2013 cwm6012touch_v12.5_hercules.zip
-rw-r--r--  1 cromwell cromwell 151M Dec  6  2014 gapps-kk-20140606-signed.zip
drwx------  4 cromwell cromwell  32K Jan 10  2013 media

Now I make an archive in my home directory. The archive is of the current directory, ".", and therefore all the contents of this file system. If you simply copy or archive the contents while referring to them as "*", that will not match those with names starting with "." such as .android_secure in this example.

$ tar cf ~/phone.tar .
$ cd
$ ls -lh phone.tar 
-rw-rw-r-- 1 cromwell cromwell 1.7G Apr  8 21:26 phone.tar

Now swap the memory chips. The new one may have an exFAT file system. The FAT32 file system cannot have files larger than 4 GB.

Note that FAT32 or exFAT is the file system, thus the total volume size, number of files, and maximum file size. VFAT has to do with supporting long file names.

If a file system is FAT32 it probably includes the VFAT extension, but VFAT might be used with FAT12 or FAT16.

You will need the exFAT tools to support exFAT. On Linux the packages are probably exfat-utils and fuse-exfat, on OpenBSD it is the single package exfat-fuse.

# rpm -ql exfat-utils fuse-exfat | grep bin
/usr/sbin/dumpexfat
/usr/sbin/exfatfsck
/usr/sbin/exfatlabel
/usr/sbin/fsck.exfat
/usr/sbin/mkexfatfs
/usr/sbin/mkfs.exfat
/usr/sbin/mount.exfat
/usr/sbin/mount.exfat-fuse

With those tools in place, the system can mount the device. The new mount point will be an essentially random file system volume ID.

# file -s /dev/sdg
/dev/sdg: DOS/MBR boot sector
# file -s /dev/sdg1
/dev/sdg1: DOS/MBR boot sector
# fdisk -l /dev/sdg 

Disk /dev/sdg: 59.7 GiB, 64087916544 bytes, 125171712 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdg1       32768 125171711 125138944 59.7G  7 HPFS/NTFS/exFAT

# df -hT /run/media/cromwell/FC54-7B8F
Filesystem     Type      Size  Used Avail Use% Mounted on
/dev/sdg1      fuseblk    60G  2.7M   60G   1% /run/media/cromwell/FC54-7B8F

Now I can extract the archive into the empty file system on the new memory chip.

$ cd /run/media/cromwell/FC54-7B8F
$ tar xvf ~/phone.tar
[... many lines deleted ...]
$ df -hT .
Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sdg1      vfat   60G  1.7G   59G   3% /run/media/cromwell/FC54-7B8F

Almost 60 GB of free space for pictures and other media!