Asus Nexus 7 (2012) (grouper)
jambonmcyeah opened this issue · 20 comments
Device: Asus Nexus 7 (2012 WIFI)
Device Codename: grouper
Recovery: TWRP official 3.1.0
Kernel: 3.1.10-krassermench-g1cb11d3
Rom: Resurrection Remix Unofficial (RR-N-v5.8.4-20170810-grouper-Unofficial): https://forum.xda-developers.com/nexus-7/development/rom-resurrection-remix-5-8-0-nexus-7-t3537968)
Partition Layout: Unmodified
hi,
thanks! this is an old device, and as such it might work, its GPT might not be locked.
please read: #55
and decide whether u'd like to take the risk of testing a port to grouper.
thanks again!
I'll take the risk
btw, I ran strings bootloader-grouper-4.23.img | grep -i gpt (bootloader-grouper-4.23.img is in the factory image) and the output is:
gpt_sector=%d
gpt
So I don't think the gpt is locked down
I don't think the gpt is locked down
good work there! i'll try to do this port soon. might take a bit cause i'm travelling in europe at the moment.
thanks!!
wtf!!! this comes from your dump, there seems to be no partition table there...
==========================================================================================================
ls -l /sys/block/mmcblk0
----------------------------------------------------------------------------------------------------------
lrwxrwxrwx 1 root root 0 Jan 1 04:59 /sys/block/mmcblk0 -> ../devices/platform/sdhci-tegra.3/mmc_host/mmc0/mmc0:0001/block/mmcblk0
==========================================================================================================
parted -s /dev/block/mmcblk0 unit MiB print free unit s print free
----------------------------------------------------------------------------------------------------------
Error: /dev/block/mmcblk0: unrecognised disk label
==========================================================================================================
sgdisk /dev/block/mmcblk0 --set-alignment 1 --print
----------------------------------------------------------------------------------------------------------
Unsupported GPT version in backup header; read 0x00000000, should be
0x00010000
Creating new GPT entries.
Disk /dev/block/mmcblk0: 30535680 sectors, 14.6 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 371B8E31-021E-4BAB-9E5E-BEA3596B4539
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30535646
Partitions will be aligned on 1-sector boundaries
Total free space is 30535613 sectors (14.6 GiB)
Number Start (sector) End (sector) Size Code Name
==========================================================================================================
but regardless, the partitions are found by linux, dont know how/why
/dev/block/platform/sdhci-tegra.3:
drwxr-xr-x 2 root root 220 Jan 1 04:59 by-name
drwxr-xr-x 2 root root 220 Jan 1 04:59 by-num
lrwxrwxrwx 1 root root 18 Jan 1 04:59 mmcblk0 -> /dev/block/mmcblk0
lrwxrwxrwx 1 root root 23 Jan 1 04:59 mmcblk0boot0 -> /dev/block/mmcblk0boot0
lrwxrwxrwx 1 root root 23 Jan 1 04:59 mmcblk0boot1 -> /dev/block/mmcblk0boot1
lrwxrwxrwx 1 root root 20 Jan 1 04:59 mmcblk0p1 -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 Jan 1 04:59 mmcblk0p2 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 Jan 1 04:59 mmcblk0p3 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 Jan 1 04:59 mmcblk0p4 -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 Jan 1 04:59 mmcblk0p5 -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 20 Jan 1 04:59 mmcblk0p6 -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 20 Jan 1 04:59 mmcblk0p7 -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 20 Jan 1 04:59 mmcblk0p8 -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 Jan 1 04:59 mmcblk0p9 -> /dev/block/mmcblk0p9
/dev/block/platform/sdhci-tegra.3/by-name:
lrwxrwxrwx 1 root root 20 Jan 1 04:59 APP -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 Jan 1 04:59 CAC -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 Jan 1 04:59 LNX -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 Jan 1 04:59 MDA -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 Jan 1 04:59 MSC -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 20 Jan 1 04:59 PER -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 20 Jan 1 04:59 SOS -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 Jan 1 04:59 UDA -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 20 Jan 1 04:59 USP -> /dev/block/mmcblk0p6
/dev/block/platform/sdhci-tegra.3/by-num:
lrwxrwxrwx 1 root root 20 Jan 1 04:59 p1 -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 Jan 1 04:59 p2 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 Jan 1 04:59 p3 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 20 Jan 1 04:59 p4 -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 Jan 1 04:59 p5 -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 20 Jan 1 04:59 p6 -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 20 Jan 1 04:59 p7 -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 20 Jan 1 04:59 p8 -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 Jan 1 04:59 p9 -> /dev/block/mmcblk0p9
so this device, i dont know why it's working, but it's not compatible with REPIT.
sorry!
rip, but seriously though. How did linux even find the partitions. (I suspect dark magic) I'm going to flash the stock kernel and try again tomorrow.
no, don't do that. what you can do is dmsg and try to figure out how the kernel found the partitions.
in THEORY, they could even be compiled into the kernel, but sooooo improbable... who would even do that? in any case, REPIT only supports GPT, which is not there. so further experimentation is valuable in terms of knowledge, but expectation is that REPIT wont ever work on that device.
I'm looking to resize partitions on my 2012 N7, and found this issue. Not sure if this is useful information at this point, but it looks like for some reason the primary GPT doesn't exist, but the backup/alternate GPT does. At boot time:
[ 5.686175] mmc0: new high speed DDR MMC card at address 0001
[ 5.686379] mmcblk mmc0:0001: Card claimed for testing.
[ 5.686751] mmcblk0: mmc0:0001 HBG4e. 29.1 GiB
[ 5.687006] mmcblk0boot0: mmc0:0001 HBG4e. partition 1 2.00 MiB
[ 5.687307] mmcblk0boot1: mmc0:0001 HBG4e. partition 2 2.00 MiB
[ 5.689635] Primary GPT is invalid, using alternate GPT.
[ 5.689806] mmcblk0: p1 p2 p3 p4 p5 p6 p7 p8 p9
[ 5.695790] mmcblk0boot1: unknown partition table
[ 5.698853] mmcblk0boot0: unknown partition table
And if we look at /proc/cmdline, we see gpt_sector=61079551 in there, which is the last sector of the device. Unfortunately it doesn't look like fdisk or parted have options to specify its location. Reading the parted source, it looks like it does check the last sector for a partition table, but only if the read of the first sector fails. If the first sector read succeeds, but they don't find a valid partition table there, they bail.
hey thanks for this info... interesting.
the secondary GPT is kinda swapped in format, i mean header and content:
source: https://en.wikipedia.org/wiki/GUID_Partition_Table
in the GPT headers you can find:
-
location of headers:
- 24 (0x18) | 8 bytes | Current LBA (location of this header copy)
- 32 (0x20) | 8 bytes | Backup LBA (location of the other header copy)
-
partition pool:
- 40 (0x28) | 8 bytes | First usable LBA for partitions (primary partition table last LBA + 1)
- 48 (0x30) | 8 bytes | Last usable LBA (secondary partition table first LBA − 1)
-
partition entries:
- 72 (0x48) | 8 bytes | Starting LBA of array of partition entries (always 2 in primary copy)
- 80 (0x50) | 4 bytes | Number of partition entries in array
- 84 (0x54) | 4 bytes | Size of a single partition entry (usually 80h or 128)
it'd be interesting to see whats on your disk. the idea would be fixing the main GPT (if possible), then porting REPIT.
we need a dump of the start and end of the disk. unfortunately 32-bit dd incuded with busybox id buggy and dangerous: byte addresses are 32-bit, wrapping around at 4GiB. i trashed a phone by dd-ing into the middle of the disk: dd wrapped around and killed the bootloader and partition table. (but yes, i fully recovered that hardware, believe it or not.)
so the easiest way for you to get the disk segments would be:
- connect to PC
- boot TWRP
- adb pull the entire
/dev/mmcblk0
you can later cut the start and end (in a documented position) of the pulled file and post.
we can probably edit the backup GPT to create a good main GPT. and if partitions are not there, and if data is not there, we can try writing the main GPT and see if the device still boots.
alternatively we can use a GPT recovery tool and point to the pulled file as if it were a device, and have it recover the main GPT instead of doing it manually. we still need to take a look at everything though.
if the start of the disk is used somehow (if not, why is the GPT not there?) then a kernel could be modded to fail reading the first blocks of the device and discard data written to them.
i'd like to provide a block device in userland solution (similar to FUSE) or filtering lookback device that could do this trick without a custom kernel but i know little of linux to know if it is possible.
Nexus 7 2012 isn't only t30 device. All devices, based on this soc have same partitions handle system. Some of them have workarounds for repartition, and some, like N7 doesn't. At least yet.
ok, and which are the workarounds? do you plan to pull and follow this up?
@Lanchon It is not that simple. I have Asus Transformer device on t30 and N7. They both have partition table in PT partition (pretty obvious). I observed images of this partitions and used hex editing in both devices to change partition sizes. Additionally PT image can be flashed only in APX mode. Currently only experiments with Transformer were successful. I've managed to increase system volume, decrease cache volume and change partition lable (made vendor partition). Same time changes to some partition cause device to brick, even permanent.
P. S. Transformer has a proprietary flashing system that alloved me to create a binaries which I can flash via recovery and fastboot.
the exynos 4 devices (i9100 etc) have a custom partitioning system called PIT involving a partition where the PT info is stored, a custom binary format for this PT called PIT, a custom flashing tool, etc
original attempts to repit had tweaked the PIT and flashed it using the proprietary tool and download mode. that is necessary if you want to change partitions used by the bootloader. but most partitions arent, and i realized that you could simply mod the GPT mirror for those (system, data, cache...), which is what repit does.
many thousands of decives have used repit and never had issues.
so the custom TegraPT shit is placed at the beginning of the devices, so we cant fix the GPT.
more info about the custom PT:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-TegraPT-Patches
https://lkml.org/lkml/2020/5/16/404
https://lkml.org/lkml/2020/2/24/1358
if i were you, id create a GPT through a manual process and flashed that to the backup GPT.
manual process could be: pull the mmc file, operste on the file as a device (maybe loop mounted), fix the missing GPT copy with standard tools, mod the GPT with standard tools, write back only the backup GPT to the device.
or you could mod a kernel to change the userland view of the mmc so that standard gpt tools in repit work. possible if enough motivation is there, but too much work IMO.
Sorry for the delayed response. I pulled the last 33 sectors off and have dropped it here.
I tried to make a dummy disk image with a valid primary GPT on my laptop like so:
truncate -s 31272730624 n7-mmc.img # make sparse file same size as N7 storage
dd if=n7-alt-gpt.img of=n7-mmc.img conv=notrunc bs=512 seek=1 skip=32 # copy alt GPT header to sector 1
dd if=n7-alt-gpt.img of=n7-mmc.img conv=notrunc bs=512 seek=2 count=32 # copy alt GPT entries to sectors 2-33I tried leaving sector 0 as all zeroes, but that just gave me:
GNU Parted 3.3
Using /home/brian/src/nexus7/n7-mmc.img
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: /home/brian/src/nexus7/n7-mmc.img: unrecognised disk label
Model: (file)
Disk /home/brian/src/nexus7/n7-mmc.img: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
I also tried cheating and copying the protective MBR off my laptop's NVMe drive. But that just gave me:
GNU Parted 3.3
Using /home/brian/src/nexus7/n7-mmc.img
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Error: Both the primary and backup GPT tables are corrupt. Try making a fresh table, and using Parted's rescue feature to recover partitions.
Model: (file)
Disk /home/brian/src/nexus7/n7-mmc.img: 31.3GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
A hexdump makes it seem like it looks like a normal GPT just from a cursory visual inspection, and not the proprietary TegraPT, but I can't be sure. Although, hmm, if I try sgdisk:
Unsupported GPT version in main header; read 0x00000000, should be 0x00010000
Creating new GPT entries in memory.
So even though it superficially looks like GPT, maybe it is TegraPT since the version field is wrong? Also the reserved field is not all zeroes like it should be. However, a quick look through the kernel source that I'm running on the N7 doesn't reveal any Tegra-specific GPT parsing code. And it looks like the stock kernel GPT parsing code doesn't validate the GPT version field like sgdisk does. Hmm...
- create a same size empty sparse file.
- create a GPT inside the files using the tool of your choice.
- copy over the 32 sectors of the actual table (not the header) dumped from the device to both GPT copies in the file.
now you should be able to alter the table with usual tools.
later you can copy those altered 32 sectors back into the device.
WARNING:
- if you alter any critical partition, you'll brick.
- if the GPT is signed, you'll brick. (but you already said some people modded the PT, right?)
@kelnos Did you resize your partitions in the end? I'm currently looking to do the same
@alanplatt I haven't. My interest in messing with the hardware has faded a bit. I put PostmarketOS on it (which doesn't require the system partition; you can install it on the user-data partition), so my need to resize has also mostly gone away.