Database Users

[WIP][Testing]Possible Ubuntu On our Tab Native (Not Phone ver)

To: Admin/Mods
Even Though I did not Develop this I chose not to Put it in DEV section due to that fact... However if it is DEV section Worthy I will Gladly Mantain it. If it is DEV section worthy Please Feel Free to Move it there Thank You.
-----------------------------------------------------------------------------
Prelude
Hi Fellow XDAers I had decided to start Start a Project to Adapt The Ubuntu Nexus 7 Installer For The Tab 2 10.1" and 7" but seeing as the tab does not support fastboot the installer and possibly the OS image would have to be recoded so i decide to post pone the conversion of the installer program and Research if there was a more "Manual" Method...
-----------------------------------------------------------------------------
Now:
After Researching I came across a section on the Ubuntu Site Label as ARM/OMAP Server Pre-installed-Build Images For ARM and OMAP CPU's.
Supported OMAP CPU's were as follows
OMAP 3 - Server / Desktop (Limited SGX Drivers) Image
OMAP 4 - Server / Desktop Images :victory:
Now the issue is Not Sure If Your Device recovery will be lost.. if a total device format and or repartion is needed or what Simple because the site states:
With the Ubuntu 12.10, ARM desktop images are now standard Ubuntu live images as known from other architectures. To install these images you should have a USB disk as target device.
dd omap4 image on to sd-card
plugin sd-card & usb-stick
boot & install on to usb-stick
-----------------------------------
Writing the image
You should write the raw image to a blank SD card. Make sure you're using at least a 4G SD card (desktop image is 2G uncompressed).
Linux
Steps:
Place the SD card at your host computer.
Make sure the SD card is not mounted (just umount it if needed)
Identify the correct raw device name (like /dev/sde - not /dev/sde1)
Run the following command to write it:
--(Removed Until I fully test it)--
(replacing omap4 and sde with the right values i.e. just omap for a beagle image.)
-----------------------------------------------------------------------------
Second Instructions were for server based install but may easier for our device:
Copy the image to SD card
You should write the raw image to a blank SD card. Make sure you're using at least a 2 Gig SD card so that you have enough room for the image.
Steps:
Insert the SD card in your host computer's SD card reader.
Make sure the SD card is not mounted (just umount it if needed).
Identify the correct device name (like /dev/mmcblk0 or /dev/sdb).
Run the following command to write it:
---------------------------------------------------------------------------
Like I said I dont know where the block is that has the recovery in it or the download mode as if this will overwrite it not sure if we can revert it back to android so atm the project no is at a stand still if anyone has info on the block mapping and where recovery and download mode is it would help greatly.

UPDATE: because i am not as familiar with the android/device block and file structure aside from whats visible i will post all the links i have at my current disposal hopefully someone can make heads or tails of it and get us ubuntu native
Link 1: "Graphics" https://wiki.ubuntu.com/ARM/OMAP/Graphics
Link 2: "Desktop Install" https://wiki.ubuntu.com/ARM/OmapDesktopInstall
Link 3: "Server Install" https://wiki.ubuntu.com/ARM/Server/Install?action=show&redirect=ARM%2FOMAPHeadlessInstall
I suggest reading info in all 3 links as there is some key info in all three

samsung recovery fstab, if was that what you were looking for
# mount point fstype device device2
/system ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/FACTORYFS
/cache ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/CACHE
/data ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS length=-16384
/efs ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/EFS
/misc emmc misc
/boot emmc /dev/block/platform/omap/omap_hsmmc.1/by-name/KERNEL
/recovery emmc /dev/block/platform/omap/omap_hsmmc.1/by-name/RECOVERY
/bootloader emmc /dev/block/platform/omap/omap_hsmmc.1/by-name/SBL1
/preload ext4 /dev/block/platform/omap/omap_hsmmc.1/by-name/HIDDEN
/sdcard vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1
ps: I tryied too these images on my 5110, but it didn't boot (i dont know if the images FS was different from Android)
---------- Post added at 03:11 PM ---------- Previous post was at 03:00 PM ----------
I tried these by extracting the images for OMAP4, and
making a boot.img with kernel+ramdisk
making a system.img with the rootfs
flashed them and no booting (doesn't work ???) the bootloader left a blackscreen without executing the kernel
(maybe the image format is not supported and I had to use the android one)

http://forum.xda-developers.com/showthread.php?t=2691477

Hi, I would be interested in the developing of a ubuntu/other_linux versions for the galaxy-tab2

<*spoiler*>
Like I said I dont know where the block is that has the recovery in it or the download mode as if this will overwrite it not sure if we can revert it back to android so atm the project no is at a stand still if anyone has info on the block mapping and where recovery and download mode is it would help greatly.
<*/spoiler*>
On my Italian gt-p5110 I use heimdall to flash directly the images ( recovery.img, boot.img, factory.img data ..etc) w/o the necessity to make a zip, everything is redoable and restore it to android is very easy unless you brick the 2 bootloaders, (only boot and system.img), I don't know about your american models
2. I have the mappings
major minor #blocks name
(emmc)
179 0 15388672 mmcblk0
179 1 20480 mmcblk0p1
179 2 2048 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 8192 mmcblk0p4
179 5 8192 mmcblk0p5
179 6 8192 mmcblk0p6
179 7 716800 mmcblk0p7
259 0 20480 mmcblk0p8
259 1 1433600 mmcblk0p9
259 2 12640239 mmcblk0p10
259 3 524288 mmcblk0p11
179 16 2048 mmcblk0boot1
179 8 2048 mmcblk0boot0
(sd)
179 24 31166976 mmcblk1
179 25 31165440 mmcblk1p1

[DEV Discussion]Moto X variants *partition dumps*

I don't know how many of us have access to multiple Moto X devices let alone have physical access to more then one vendor release. It seems that all moto x devices are physically identical apart from any custom decorations done by Motorola (the made in the US ones) and the model identifier on the back bottom "Model: XT1056" (as mine shows) they even lack carrier markings on the phone like most have.
But there are differences between the Models and that's what this thread is being made to investigate. I've noticed both from examining the open source releases on github and poking around the memory that there is a lot of sprint-specific modifications including what appears to be set aside partitioning for sprint's... well, er... ****. We don't really know exactly what kind of operation sprint has going on where they need their own partition but it's likely related their funky LTE implementation (remember they were late-adopters since they placed their chips on wimax initially and had cut some corners to deploy LTE on a wide enough scale to compete with carriers that had been building their LTE infrastructure for a year or two at least. There is even a system app completely devoted to this). I've pretty much figured out all the sprint specific system apps and their purposes but I'll post that later since the selfish ulterier motive of the thread is to get partition tables and partition dumps from other models so I can start comparing them and figuring out where the UICC lock implementation really is. People going for VZ/AT&T bootloader unlock solutions may benefit from using these dumps similarly.
Here is the partition table for the XT1056 (bootloader unlocked although that shouldn't make any difference in the partition table)
Model: MMC 016G92 (sd/mmc)
Disk /dev/block/mmcblk0: 15.8GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 131kB 105MB 105MB ext4 modem
2 105MB 107MB 1536kB sbl1
3 107MB 108MB 1536kB sbl2
4 108MB 109MB 526kB sbl3
5 110MB 111MB 524kB aboot
6 112MB 112MB 145kB rpm
7 112MB 112MB 215kB tz
8 113MB 113MB 524kB utags
9 113MB 114MB 1049kB logs
10 114MB 117MB 3150kB padA
11 117MB 119MB 1536kB sbl2Backup
12 119MB 121MB 2097kB sbl3Backup
13 121MB 123MB 1536kB abootBackup
14 123MB 123MB 512kB rpmBackup
15 123MB 124MB 512kB tzBackup
16 124MB 124MB 524kB utagsBackup
17 124MB 126MB 1671kB padB
18 126MB 129MB 3146kB modemst1
19 129MB 132MB 3146kB modemst2
20 132MB 134MB 2097kB mbl
21 134MB 135MB 655kB hob
22 135MB 135MB 8192B dhob
23 135MB 143MB 8389kB ext4 persist
24 143MB 143MB 8192B ssd
25 143MB 147MB 3146kB ext2 fsg
26 147MB 148MB 1049kB sp
27 148MB 148MB 524kB misc
28 148MB 151MB 3146kB ext3 pds
29 151MB 151MB 131kB cid
30 151MB 156MB 4194kB logo
31 156MB 160MB 4194kB clogo
32 160MB 161MB 1049kB devtree
33 161MB 171MB 10.5MB boot
34 171MB 182MB 10.5MB recovery
35 182MB 190MB 8389kB kpan
36 190MB 1257MB 1067MB ext4 cache
37 1257MB 1258MB 1049kB padC
38 1258MB 2869MB 1611MB ext4 system
39 2869MB 2982MB 113MB customize
40 2982MB 15.7GB 12.8GB userdata
I'll provide dumps of any of these partitions on request, I am requesting partition tables from any other models and some speicific partition dumps from other models and any 1056 that hass been UICC unlocked by sprint. cid, tz, misc, utags, persist, kpan, mbl, any of the little odd partitions.
Notes- misc partition is all zeros on mine,
cid partition includes some binary data and some phone-speicific identifiers like the serial number. Most of these partitions I request don't appear to be written to during rsd flashes or most zip flashes so all theinformation contained in these should be preserved between flashes, that is why I am interested in them and why these partitions are the difference between the models.
I will reserve the next post because I'll include some more of the model specific info like the sprint specific system apps and descriptions as i promised, later.

Reserved for thread ****.

Which command I need to use to get partition table?

Al936 said:
Which command I need to use to get partition table?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=2450045

I have written a small utility to hopefully assist in the analysis of this information. It is based on the same idea as the cat command in POSIX, but with the added benefit of allowing you to effectively 'cast' the file as a collection of chars, 8-bit ints, unsigned 8-bit ints, 16-bit ints, unsigned 16-bit ints, 32-bit ints, unsigned 32-bit ints, 64-bit ints or unsigned 64-bit ints and print to the console. I wrote it because I want to modify the factory 4.4 update files to inject root.
I have attached the .cpp file to this post (simply rename it from "catAll.c" to "catAll.cpp"). It can be compiled with mingw using the following command: g++ catAll.cpp -o catall
I hope this is helpful!

Using the catAll utility I wrote, I have performed the following dumps of gpt.bin and motoboot.bin from the factory 4.4 firmware for the T-Mobile variant (XT1053):
>char
>8-bit signed integer
>8-bit unsigned integer
>16-bit signed integer
>16-bit unsigned integer
>32-bit signed integer
>32-bit unsigned integer
>64-bit signed integer
>64-bit unsigned integer
I will also post the dump of factory 4.2.2's gpt.bin for the XT1053 shortly. I would like to compare them to understand why the phone "detects" trying to downgrade the firmware when flashing from factory 4.4 to factory 4.2.2

The model numbers indicate unique hardware variants - XT1053, ZT1058, XT1060 etc all have different *radio* hardware internally.

I have an XT1049 from hybrid Wi-Fi/cell MVNO Republic Wireless. My phone is not rooted so I can't push parted onto the system and get a partition table readout like the one you have posted.
I do have the out put of 'ls -al /dev/block/platform/msm_sdcc.1/by-name' and 'cat /proc/partitions' which may provide useful information. Here are chunks of these two files (in the order I have listed them above):
lrwxrwxrwx root root 2014-03-14 15:32 aboot -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2014-03-14 15:32 abootBackup -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2014-03-14 15:32 boot -> /dev/block/mmcblk0p33
lrwxrwxrwx root root 2014-03-14 15:32 cache -> /dev/block/mmcblk0p36
lrwxrwxrwx root root 2014-03-14 15:32 cid -> /dev/block/mmcblk0p29
...
and
major minor #blocks name
7 0 3150 loop0
7 1 17703 loop1
179 0 15388672 mmcblk0
179 1 102400 mmcblk0p1
179 2 1500 mmcblk0p2
179 3 1500 mmcblk0p3
179 4 514 mmcblk0p4
...
Would full listings of these commands be useful to you?

OP, I have an XT1056 as well, currently running 4.4.2. It is the stock ROM with stock recovery. I am preparing to unlock the BL and flash TWRP, but would prefer a copy of the stock recovery image for the purposes of returning to stock for OTA updates in the future. A search lead me to this thread. Can you tell me the proper command to pull the stock recovery, or if it's easier for you, can you pull it and post it?
Thanks in advance!

I'm not the OP but in case he doesn't respond ...
You may find the stock Sprint 4.4.2 ROM here:
http://sbf.droid-developers.org/phone.php?device=0
Scroll down to the listing marked --
"Android 4.4.2
Blur_Version.161.44.32.ghost_sprint.Sprint.en.US"
The link to download it is on the far right side of that line on the page.
The recovery image is in the zip file. No special commands are needed to extract it from the archive. Just do 'unzip ghost_sprint-user-4.2.2-13.9.0Q2.X-116-MX-17-57-1-1-release-keys-cid9.xml.zip' and it will be extracted into a new directory wherever you are in the file hierarchy. So be sure you have write permission there.
If you need help flashing it there are many, many [better] places in these forums to find it.

Brilliant! Thank you very much!
glarepate said:
I'm not the OP but in case he doesn't respond ...
You may find the stock Sprint 4.4.2 ROM here:
http://sbf.droid-developers.org/phone.php?device=0
Scroll down to the listing marked --
"Android 4.4.2
Blur_Version.161.44.32.ghost_sprint.Sprint.en.US"
The link to download it is on the far right side of that line on the page.
The recovery image is in the zip file. No special commands are needed to extract it from the archive. Just do 'unzip ghost_sprint-user-4.2.2-13.9.0Q2.X-116-MX-17-57-1-1-release-keys-cid9.xml.zip' and it will be extracted into a new directory wherever you are in the file hierarchy. So be sure you have write permission there.
If you need help flashing it there are many, many [better] places in these forums to find it.
Click to expand...
Click to collapse

[SOLVED] Need help with Froyo partition table

I am in the process of flashing a custom rom. My phone is an original unlocked Consumer Cellular which had 2.2.1 installed and later on got an OTA update to 2.2.2.
I rooted the Bravo, made a system dump, installed 2nd-init and created a nandroid backup. As a final check I wanted to look at the partition table and that's when things got interesting. I tried parted but parted terminated with an error message about a partition "beyond" the device's last sector.
Looked around a bit and found out that fdisk is preinstalled in /system/xbin. So I used fdisk and this is what I found:
fdisk's info about the device:
Code:
Disk /dev/block/mmcblk1: 1958 MB, 1958739968 bytes
16 heads, 16 sectors/track, 14944 cylinders
Units = cylinders of 256 * 512 = 131072 bytes
That sounds about right, it is a 2 GByte flash rom. The problem is partition p4 (the "extended" partition) and partition p25 (aka "userdata"). Partition p4 is listed in the partition table as:
Code:
Device Boot Start End Blocks Id System
/dev/block/mmcblk1p4 13 122496 15677952 5 Extended
Well, "start" and "end" are cylinders, so the "end" being 122496 is waaaay beyond 14944! Partition p25 also seems to be messed up the same way:
Code:
Device Boot Start End Blocks Id System
/dev/block/mmcblk1p25 4633 122496 15086592 83 Linux
However, a "cat /proc/partitions" shows this:
Code:
cat /proc/partitions
major minor #blocks name alias
179 32 1912832 mmcblk1
179 33 128 mmcblk1p1
179 34 512 mmcblk1p2
179 35 512 mmcblk1p3
179 36 1 mmcblk1p4
179 37 512 mmcblk1p5
179 38 512 mmcblk1p6
179 39 4096 mmcblk1p7 pds
179 40 512 mmcblk1p8
179 41 512 mmcblk1p9
179 42 1024 mmcblk1p10
179 43 2048 mmcblk1p11
179 44 512 mmcblk1p12
179 45 512 mmcblk1p13
179 46 4096 mmcblk1p14
179 47 8192 mmcblk1p15 boot
179 48 8192 mmcblk1p16 recovery
179 49 14336 mmcblk1p17 cdrom
179 50 512 mmcblk1p18 misc
179 51 512 mmcblk1p19 cid
179 52 4096 mmcblk1p20 kpanic
179 53 334848 mmcblk1p21 system
179 54 512 mmcblk1p22 prek
179 55 512 mmcblk1p23 pkbackup
179 56 204800 mmcblk1p24 cache
179 57 1319936 mmcblk1p25 userdata
179 0 1931264 mmcblk0
179 1 1930240 mmcblk0p1
So besides the partition data which I seem to not understand the size of userdata seems to be 1319936 blocks which is ~1.3 GByte.
This leads to my 2 questions:
Is there a problem here or do I simply misunderstand fdisk's partition list (parted says that is something wrong though!)?
Do I have to try to "fix" this before installing a custom rom (planning on trying cm-10.2-20131030-NIGHTLY-mb520.zip)?
Thanks,
Markus

Ok ... I'm answering my own question here, just in case someone else is interested in the solution:
General Information:
Historically (pc compatible) partitions used to be aligned on cylinder boundaries. Nowadays partitions are usually aligned on a sector number which is a multiple of 2048. For standard 512 sectors this evaluates to a 1 MByte boundary - which is also compatible with drives with a larger sector size (4096 bytes for drives > 2 TByte).
Logical volumes within the extended partition do not use the first head of the first cylinder (or the first 2048 sectors) because the area holds the volume's EBR - which is only a 512 byte record, similar to a MBR.
Implementation in the Motorola Bravo:
The Linux kernel reports 16 heads per cylinder and 16 tracks per head, resulting in 128 kByte per cylinder.
Partitions are aligned to this "virtual" disk geometry.
Digging through the list of EBRs (using dd and hexdump) I found that the partitioning utility used by Motorola creates volumes in the extended partition in a different (but still compatible) way: instead of wasting the first "track" (for the volume's EBR) in each volume, it consolidates all the EBRs in the disk space wasted by the partition entry for the extended partition itself (which usually is 1 cylinder or 2048 sectors).
Motorola actually allocated 512 kByte (1024 sectors) for the extended partition itself, giving the system the theoretical limit of 1024 volumes.
The question still unanswered though is: why does the extended partition (and the last volume in that partition) extend way beyond the end of mmcblk1?
Findings:
I searched around and I discovered that the tool Motorola used to create the partition table was most likely something like nand-part (part of the sunxi tools, please look it up on Wikipedia, I am not allowed yet to post links outside this forum).
This tool creates the EBRs for logical volumes in the same way as they appear in the Bravo's partitions. And most important, this tools also allows to create partitions which extend beyond the end of the device!
Ok ... on with the story: whenever a file system utility like mkfs wants to format a partition, it asks the kernel for information about that partition. The kernel is smart enough to correct partition definitions which extend beyond the end of device in order to avoid a failure or crash of the file system formatting utility. This "correction" is not permanent (partition table stays as it is) but done on the fly.
Conclusions:
nand-part's lack of parameter checking together with the kernel's smartness about partitions exceeding the device made it possible for Motorola to create one common partition layout for devices with different flash capacities: the setup used in the Bravo would be sufficient for flash up to 8 GByte without even changing the partition tables. The last partition (userdata) would simply benefit from a higher flash capacity.
Having answered that question, I still wanted to know what happenes when I try to correct that error (I know, I just asked for trouble). So I went ahead and as a first step I corrected the size in userdata's (mmcblk1p25) EBR to the correct value (using dd and a hex editor). After the correction everything looked fine. The definition of mmcblk1p25 now matched the actual size. I rebooted the phone and ... boom! The bootloader obviously was extremely unhappy and I was forced to do my first "sbf" - which I managed to do and meanwhile my Bravo is happily running CM10.2.
Dear Moderator:
If this post is of any use for the "Dev" section, please move it over there. I do not have the permission (yet) to post in the dev section.
Happy hacking,
Markus

Partition problems, no ERI, Unknown IMEI, no USB

I was attempting to troubleshoot another phone I had and it was suggested somewhere on here that I back up my efs partition and gave directions to use the command "reboot nvbackup". Well the result was not good. I've searched the forums for over a week and have decided to finally post as I'm out of ideas.
I followed radionerd's thread here and was able to get the Baseband back but I still do not have anything in "Hardware Version", and show "0" in PRL version, "None" in ERI version, "Unknown" in IMEI. The kicker is that somehow my USB no longer works when connecting to the PC. The cord works fine with other phones and it charges this phone but gives a "USB device is not recognized" error when connecting, under device manager it shows up as "Device Descriptor Request Failed".
I have been able to flash back to a stock ROM using TWRP (RUEOF1 is what I've been flashing) but that hasn't helped at all. I've attempted to copy mmcblk1 from the sd but it always fails, both from TWRP file manager and from the ES File Explorer. I'm guessing if I was able to flash a new PIT file I'd be good but I have no idea how to do that without having USB support. I do have working WIFI and SD card access, along with a good operating system.
I've tried a lot of stuff over the past week so I apologize if I haven't already mentioned it but I'm looking for help to see if anyone has an idea about what can be done.
Thanks!

If you unlocked your bootloader using the "standard method" then the "debrick" image you created on the SD card has a backup of literally every partition EXCEPT the ones that you would normally flash with Odin (or a ROM, e.g. boot, system, userdata, cache etc).
The reason that that unlocking method created a debrick image is so that people could save it so they would have it for emergencies. Such as the one you created.
Even the PIT data is included in a hidden partition inside the debrick image. But having a PIT file only allows you to re-partition flash memory, which you don't need; it's partitioned already. Re-writing the PIT is not going to magically recreate data inside those partitions that you erased.
Here's the bottom line: factory images, just like ROM files have NEVER had 100% of the partitions needed to restore the phone back to working condition. So there's darn good reasons to have backups or avoid wiping all of memory.
I think that @hsbadr had posted some debrick images taken during older ROM releases (N* series, I think) on his AFH (androidfilehost.com) site. Whether or not substituting some subset of those partitions (e.g. efs, persist, etc) onto your device will work correctly or not, but it's certainly worth a try at this point.
Skills you need to learn: figuring out byte offsets from the GPT partition table at the beginning of the debrick file to get the partition offsets in the "debrick" blob, and "dd" command options for grabbing exactly the byte ranges you want out of a single large blob file containing many partitions. (e.g. "skip=", "bs=", "count=").
Note also that the Unix GPT partitioning tools "gdisk" will let you examine the Primary GPT (UEFI?) partition table in the debrick image even though the secondary GPT is not present. That way, you can figure out the exact length and initial offset of partitions that you want to copy out of the debrick image into your device. (The reason for the missing secondary GPT is that the GPT/UEFI partition table indicates the presence of very large partitions such as /system, /cache, and /userdata, and the secondary GPT is always near the very end of the disk. Because the "debrick" image is literally a byte-for-byte copy of only the first 256 MB of the mmcblk0 flash device, there is no secondary GPT some 32GB "later" then the beginning of the debrick image.
red indicates partitions in debrick not appearing in Odin factory Images
Code:
$ gdisk /tmp/mj7-debrick-unlocked.img
Command (? for help): p
Disk /tmp/mj7-debrick-unlocked.img: 524288 sectors, 256.0 MiB
Logical sector size: 512 bytes
Disk identifier (GUID): NNNNNNNN-NNNN-NNNN-NNNN-NNNNNNNNNNNN
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 61071326
Partitions will be aligned on 2-sector boundaries
Total free space is 8158 sectors (4.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 8192 38911 15.0 MiB 8300 apnhlos
2 38912 156543 57.4 MiB 0700 modem
3 156544 157567 512.0 KiB FFFF sbl1
4 157568 157631 32.0 KiB FFFF dbi
5 157632 157695 32.0 KiB FFFF ddr
6 157696 161791 2.0 MiB FFFF aboot
7 161792 162815 512.0 KiB FFFF rpm
8 162816 163839 512.0 KiB FFFF tz
[color=red] 9 163840 184319 10.0 MiB FFFF pad
10 184320 204799 10.0 MiB 8300 param
11 204800 233471 14.0 MiB 8300 efs
12 233472 239615 3.0 MiB FFFF modemst1
13 239616 245759 3.0 MiB FFFF modemst2[/color]
14 245760 268287 11.0 MiB FFFF boot
15 268288 294911 13.0 MiB FFFF recovery
[color=red] 16 294912 321535 13.0 MiB FFFF fota
17 321536 335853 7.0 MiB 8300 backup
18 335854 341997 3.0 MiB FFFF fsg
19 341998 341999 1024 bytes FFFF fsc
20 342000 342015 8.0 KiB FFFF ssd
21 342016 358399 8.0 MiB 8300 persist
22 358400 376831 9.0 MiB 8300 persdata [/color]
--------- debrick image ends ~72 MB into the start of the system partition --------
23 376832 5931007 2.6 GiB 8300 system
24 5931008 8028159 1024.0 MiB 8300 cache
25 8028160 61071326 25.3 GiB 8300 userdata
I would start by restoring as few partitions are necessary e.g. "efs" and "persist" before I would bother with the others.
Example using data given above. (You should check your own work.)
efs partition: blocks 204800 to 233471 in debrick image, blocks are 512 bytes.
check length:
(233471-204800+1)*512 = 14680064
14680064 / (1024 * 1024) = 14 O.K.
so:
# dd if=/sdcard/debrick.img bs=512 skip=204800 count=28672 of=/dev/block/platform/msm_sdcc.1/by-name/efs
(or get clever and faster)
# dd if=/sdcard/debrick.img bs=1048576 skip=100 count=14 of=/dev/block/platform/msm_sdcc.1/by-name/efs
You should be pretty sure what you are doing with byte offset calculations with the "dd" command. Fortunately you are relying on the partitioning already present on the output side of things, so the worst that you could do is write misaligned garbage to a partition. So long as you don't do something incredibly stupid like overwrite a bootloader partition you should be OK.
cheers

Thanks for the reply, I forgot to subscribe so I just saw the post.
I have been able to copy all of the partitions from another phone but it hasn't helped. I'm now wondering if I'm missing a hidden partition.

[SM-J500FN] Cannot resize partitions with parted - changes not saved

I booted to TWRP recovery and tried to shrink /system and extend /data in the following way:
Code:
parted /dev/block/mmcblk0
(parted) unit s
(parted) print free
The output (original partition table):
Code:
Model: MMC H8G4u! (sd/mmc)
Disk /dev/block/mmcblk0: 15269888s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
34s 8191s 8158s Free Space
1 8192s 38911s 30720s apnhlos msftdata
2 38912s 156543s 117632s modem msftdata
3 156544s 157567s 1024s sbl1
4 157568s 157631s 64s ddr
5 157632s 161727s 4096s aboot
6 161728s 162751s 1024s rpm
7 162752s 163775s 1024s qsee
8 163776s 164799s 1024s qhee
9 164800s 170943s 6144s fsg
10 170944s 170975s 32s sec
11 170976s 192511s 21536s pad msftdata
12 192512s 212991s 20480s param
13 212992s 241663s 28672s ext4 efs
14 241664s 247807s 6144s modemst1
15 247808s 253951s 6144s modemst2
16 253952s 280575s 26624s boot
17 280576s 311295s 30720s recovery
18 311296s 336897s 25602s fota
19 336898s 351215s 14318s backup legacy_boot
20 351216s 357359s 6144s fsc
21 357360s 357375s 16s ssd
22 357376s 373759s 16384s ext4 persist
23 373760s 374783s 1024s persistent
24 374784s 393215s 18432s ext4 persdata
25 393216s 4653055s 4259840s ext4 system
26 4653056s 5062655s 409600s ext4 cache
27 5062656s 5206015s 143360s ext4 hidden
28 5206016s 15269847s 10063832s ext4 userdata
15269848s 15269854s 7s Free Space
Then I removed last 3 partitions and resized /system:
Code:
(parted) rm 28
(parted) rm 27
(parted) rm 26
(parted) resizepart 25 3186687
(parted) mkpart physical ext4 3186688 3596287
(parted) name 26 cache
(parted) mkpart physical ext4 3596288 3602431
(parted) name 27 hidden
(parted) mkpart physical ext4 3602432 15269847
(parted) name 28 userdata
(parted) quit
Then you need to sync changes to be able to mount /system again:
Code:
sync
blockdev --flushbufs /dev/block/mmcblk0
partprobe
However, nothing is changed. All sizes remained old.
Code:
parted /dev/block/mmcblk0 print free
After mounting partitions in TWRP or after reboot to system the partition sizes remain old.
What am I doing wrong? Has Samsung Galaxy J5 (SM-J500FN) any hardware lock? Do I need to perform resizing in download mode?
One more think to mention. Util parted downloaded from there. All changes were visible after "print free" before "quit". But I also tried parted from another thread and changes were not appliedd after "print free".

Anyone tried to shrink /system partition with this util?
GitHub - Lanchon/REPIT: A Device-Only Data-Sparing Repartitioning Tool For Android
A Device-Only Data-Sparing Repartitioning Tool For Android - GitHub - Lanchon/REPIT: A Device-Only Data-Sparing Repartitioning Tool For Android
github.com
Script looks good but there are some questions:
resize2fs - does it defrag file system before shrinking it? Otherwise system would be lost.
is this chunk-by-chunk data moving in function processParMove() necessary in 2021? No Linux tools that perform partitioning with data move on eMMC drives?
If resize2fs defrags files before shrinking file system, then it should be safe to use REPIT.
Note: For anybody who want to repartition its device manually (in devices where you may do it via adb but in Samsung Galaxy you can't) - do not shrink partitions without resize2fs first.
resize2fs(8) - Linux man page
The resize2fs program will resize ext2, ext3, or ext4 file systems. It can be used to enlarge or shrink an unmounted file system located on device. If the ...
linux.die.net
Edit: and will it even work? AFAIK you need PIT file to repartition Samsung Galaxy in Odin.
Edit 2: Is this forum dead? I'm postponing REPIT on my J5 because GPT seems signed and this may lead to hard brick. Until any other J5 users confirm REPIT is safe, i will stick to soft linking apps from /system to /data and cron job to keep links.
Port Request for HUAWEI Honor 4X Che1-CL20 · Issue #28 · Lanchon/REPIT
Hi Lanchon, Can I have a REPIT configuration file for my HUAWEI Honor 4X Che1-CL20? Thanks. your exact device and device codename. http://www.phonemore.com/phone/huawei-honor-4x-che1-cl20/2184 HUAW...
github.com
Edit 3: Not tried REPIT yet but if you want to try it, you need busybox installed. It will NOT work with toybox that is installed by default in stock ROMs.