yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] thagringo:
i see in the zip you removed your custom env stuff in the end but good news : it apparently worked and was quicker than expected !

I attach the repit.log and the reovery.log.

Here is how the partitions look like now :

Filesystem Size Used Free Blksize
/dev 498.4M 72.0K 498.3M 4096
/sys/fs/cgroup 498.4M 12.0K 498.4M 4096
/mnt 498.4M 0.0K 498.4M 4096
[b]/system 1010.3M 491.8M 518.4M 4096[/b]
/factory 19.7M 8.1M 11.6M 4096
[b]/cache 61.0M 4.1M 56.9M 4096[/b]
/data 13.3G 3.5G 9.9G 4096
/storage 498.4M 0.0K 498.4M 4096
/su 31.5M 7.8M 23.7M 4096
/system/xbin/su 31.5M 7.8M 23.7M 4096
/system/xbin 31.5M 7.8M 23.7M 4096
/storage/emulated 13.3G 3.5G 9.9G 4096

just a couple of things id like to mention :

- your script complains about no /sbin/sh ... no idea why it *****es about this, /sbin/sh is there of course. Minor nitpick, i know ...

- your script checks for "maguro" whereas my device was identified as "tuna". Not your fault i guess, i suppose this is related to the unified development tree we have for all three tuna variants now. I just manually commented out the check in device_init to continue with my testing. Would probably be a good idea to have a check for both maguro & tuna.

- had to manually copy the zip to /tmp, manually unmount all partitions and launch it from there, otherwise it complained all the time about not being able to unmount /sdcard and entered in a loop.

havent timed how long it needed but i think it was done in 10 or 12 minutes. Suprinsingly quick !

will run now a couple of speed tests, stress it a bit and trim all partitions.

thanks a lot for you efforts, impressive stuff !!
[Samsung Galaxy Nexus] Lanchon:
glad it worked, thanks for the detailed report, very useful.

first, this line is very bad news:

/tmp/updater: env/script: line 1: ï»¿#!/sbin/sh: not found

some incompatibility with your recovery... :(

about the unified tree:

where can i look at that? in:

https://download.cyanogenmod.org/?device=maguro

there seems to be 3 separate variants.

moreover, i took the checks from there. you mean to tell me that you can't flash a CM rom on your phone anymore?

thanks!
[Samsung Galaxy Nexus] aosp:
https://github.com/OMAP4-AOSP/android_device_samsung_tuna/tree/aosp-6.0-smc/variants

[MENTION=2633638]Ziyan[/MENTION]
[Samsung Galaxy Nexus] Lanchon:
so do all tuna have the exact same partition layout?
[Samsung Galaxy Nexus] thagringo:
dont know and cant test, wouldnt be surprised if there is different partition layout because of the lte firmware.

thanks !
[Samsung Galaxy Nexus] aosp:
We need toro users to copy paste the output of

cat /proc/partitions

sgdisk --print /dev/block/mmcblk0

https://github.com/Lanchon/REPIT/blob/master/device-dump/README.md

[MENTION=4544860]osm0sis[/MENTION] [MENTION=1048318]zzpianoman[/MENTION]
[Samsung Galaxy Nexus] Ziyan:
I think it's safe to say that they have the same partition layout until the userdata partition.

maguro, 16gb:

Disk /dev/block/mmcblk0: 30777344 sectors, 14.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 52444E41-494F-2044-4D4D-43204449534B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 30777310
Partitions will be aligned on 128-sector boundaries
Total free space is 735 sectors (367.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 256 511 128.0 KiB 0700 xloader
2 1024 8191 3.5 MiB 0700 sbl
3 8192 49151 20.0 MiB 0700 efs
4 49152 65535 8.0 MiB 0700 param
5 65536 73727 4.0 MiB 0700 misc
6 73728 81919 4.0 MiB 0700 dgs
7 81920 98303 8.0 MiB 0700 boot
8 98304 122751 11.9 MiB 0700 recovery
9 122880 155647 16.0 MiB 0700 radio
10 155648 1495039 654.0 MiB 0700 system
11 1495040 2379775 432.0 MiB 0700 cache
12 2379776 30777309 13.5 GiB 0700 userdata
13 122752 122879 64.0 KiB 0700 metadata

toro, 32gb:

Disk /dev/block/mmcblk0: 62324736 sectors, 29.7 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 52444E41-494F-2044-4D4D-43204449534B
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 62324702
Partitions will be aligned on 128-sector boundaries
Total free space is 735 sectors (367.5 KiB)

Number Start (sector) End (sector) Size Code Name
1 256 511 128.0 KiB 0700 xloader
2 1024 8191 3.5 MiB 0700 sbl
3 8192 49151 20.0 MiB 0700 efs
4 49152 65535 8.0 MiB 0700 param
5 65536 73727 4.0 MiB 0700 misc
6 73728 81919 4.0 MiB 0700 dgs
7 81920 98303 8.0 MiB 0700 boot
8 98304 122751 11.9 MiB 0700 recovery
9 122880 155647 16.0 MiB 0700 radio
10 155648 1495039 654.0 MiB 0700 system
11 1495040 2379775 432.0 MiB 0700 cache
12 2379776 62324701 28.6 GiB 0700 userdata
13 122752 122879 64.0 KiB 0700 metadata
[Samsung Galaxy Nexus] Lanchon:
just flashing the zip you linked and posting the log is enough.

---------- Post added at 02:27 PM ---------- Previous post was at 01:57 PM ----------

hi,

btw metadata is an afterthought, 64K stolen from the end the recovery partition, so it's not something i have to deal with (the end of the available "heap" is the end of the disk).

there seems to be two discreet radios with two independent firmwares, take a look:

Note: The device has two radios, radio (the LTE radio) and radio-cdma (the CDMA radio). Each radio image is named as such, as are their partitions.​

Flash the radios via the following commands, replacing (radio number) with the appropriate value for the name of the file being flashed:

LTE Radio: fastboot flash radio radio-toro-(radio number).img

CDMA Radio: fastboot flash radio-cdma radio-cdma-toro-(radio number).img​

(http://wiki.rootzwiki.com/Samsung_Galaxy_Nexus_(toro)#Flash_Radio_Updates)

so that partition dump seems incorrect.

confirmed here:

7) Flash the radio: fastboot flash radio radio-maguro-i9250xxla02.img (or whatever the name is of the radio image that you downloaded).

8) Reboot (not required if you did not do step 7): fastboot reboot-bootloader

8a) Verizon and Sprint devices only -- flash the LTE radio: fastboot flash radio-cdma radio-cdma-toro-i515.ek05.img (or whatever the name is of the radio image that you downloaded).

8b) Verizon and Sprint devices only -- reboot: fastboot reboot-bootloader​

(http://xdaforums.com/galaxy-nexus/general/how-to-return-to-stock-galaxy-nexus-t1626895)

also likely that these guys have a "efs-cdma" too.
[Samsung Galaxy Nexus] Lanchon:
so this is the relevant test code in CM (where i usually grab the test info from) for maguro:

assert(
getprop("ro.product.device") == "maguro" || getprop("ro.build.product") == "maguro" ||
abort("This package is for device: maguro; this device is " + getprop("ro.product.device") + ".");
);

for reference, this is the same code for i9100:

assert(
getprop("ro.product.device") == "galaxys2" || getprop("ro.build.product") == "galaxys2" ||
getprop("ro.product.device") == "i9100" || getprop("ro.build.product") == "i9100" ||
getprop("ro.product.device") == "GT-I9100" || getprop("ro.build.product") == "GT-I9100" ||
getprop("ro.product.device") == "GT-I9100M" || getprop("ro.build.product") == "GT-I9100M" ||
getprop("ro.product.device") == "GT-I9100P" || getprop("ro.build.product") == "GT-I9100P" ||
getprop("ro.product.device") == "GT-I9100T" || getprop("ro.build.product") == "GT-I9100T" ||
getprop("ro.product.device") == "SC-02C" || getprop("ro.build.product") == "SC-02C" ||
abort("This package is for device: galaxys2,i9100,GT-I9100,GT-I9100M,GT-I9100P,GT-I9100T,SC-02C; this device is " + getprop("ro.product.device") + ".");
);

the code is produced based on this data:

https://github.com/CyanogenMod/android_device_samsung_i9100/blob/cm-12.1/BoardConfig.mk#L32

and these are the generated build.props:

# ro.build.product is obsolete; use ro.product.device
ro.build.product=maguro
ro.product.device=maguro

# ro.build.product is obsolete; use ro.product.device
ro.build.product=GT-I9100
ro.product.device=GT-I9100

i'm willing to bet that your build has both of these set to 'tuna' and you set 'ro.product.subdevice' instead:

https://github.com/OMAP4-AOSP/android_device_samsung_tuna/search?q="ro.product.subdevice"&type=Code

if you do the same thing in your recovery, then you are unable to install CM from it -which is very odd-, and also affected are all zips that are based on CM checks (such as mine: https://github.com/Lanchon/REPIT/blob/master/device/maguro.sh#L41 ). it seems that this is the problem reported by thagringo (see quote above).

if this is the case, i suggest you set the obsolete 'ro.build.product' to the value of 'ro.product.subdevice' to gain compatibility with flashable zips out there. (of course i could also fix my script, but that wouldn't be a global solution.)

btw, it seems CM is doing the same thing for unified devices, check this commit:

"buildinfo: only set ro.build.product on non-unified devices"

http://review.cyanogenmod.org/#/c/79814/2/tools/buildinfo.sh
[Samsung Galaxy Nexus] osm0sis:
I found the PITs matched for the 16gb variants and then matched for the 32gb variants. They're posted in my old PIT Editor post.

Cool work! I'm interested to see how you got it to recognize the size changes when modified within recovery. :)
[Samsung Galaxy Nexus] Lanchon:
there are many userland tools for that and they all do the exact same thing: they message the kernel to reread the partition table. then some dependent stuff gets triggered by the refresh and after a bit all is ready.

i do it here:

https://github.com/Lanchon/REPIT/blob/master/repit.sh#L69

note that i've seen some races a few times. that's why i add the "sleep 1" after the command. actually, something like 50ms delay was enough to solve the races, but i didn't know what sleep command i was gonna get, so i used an integer.

EDIT: about the partitions... well i know they are different (radio-cdma), so these phones need porting; i can't simple accept 'tuna'.
[Samsung Galaxy Nexus] musical_chairs:
toro: http://pastebin.com/QkgBePQK

toroplus: http://pastebin.com/vGudpbyJ
[Samsung Galaxy Nexus] Lanchon:
thanks for the dumps!

ok, so the 3 devices have the same layout? so how can this be possible??? where is the 'radio-cdma' partition mentioned in this post?
[Samsung Galaxy Nexus] musical_chairs:
Does this post help? http://xdaforums.com/showpost.php?p=28755913&postcount=120

I think the cdma radio is in nvram rather than on the emmc.
[Samsung Galaxy Nexus] Lanchon:
amazing, thanks! right on spot, all clear now!
[Samsung Galaxy Nexus] Lanchon:
ok maguro check fixed, and added support for the tauri. thank you all!

now i wont be eating tuna for weeks
[Samsung Galaxy Nexus] musical_chairs:
Ran it on my crash-test-dummy toroplus, worked great and only took a minute...after I did it correctly. I did not read the instructions until after I was done. (I know what you're thinking, but I did this intentionally. Wanted to make sure it is fairly idiot-proof... it is.)

So yeah, take time to read the instructions, and follow them. Make sure you disable MTP before flashing, otherwise you'll have to reboot TWRP and start over. The repit zip needs to be flashed from /tmp. You can copy it there yourself; or just flash, in which case it will copy itself to /tmp on the first flash attempt, then instruct you to flash it from there.

Nice work!
[Samsung Galaxy Nexus] Lanchon:
thanks! on many devices, disabling MTP is not required: the partition is unmounted and the daemon gets the media swept under its feet. it may be that you used actually MTP and something was being locked. or that your platform automounts stuff. i use linux mint with automount disabled in nemo and i don't need to turn off MTP to repit. might be worth mentioning this though.
[Samsung Galaxy Nexus] bamtan2:
Latest update:

[MENTION=4141005]Lanchon[/MENTION] has added tuna support (maguro, toro, toroplus) to REPIT: https://github.com/Lanchon/REPIT/tree/master/device/tuna

[MENTION=2633638]Ziyan[/MENTION] has added automatic /system partition resizing support (upon flashing) to OMAP4-AOSP: http://xdaforums.com/showpost.php?p=66375415&postcount=275 (it's probably also on github somewhere ;))

I have thanked [MENTION=4141005]Lanchon[/MENTION] and the S2 community here: http://xdaforums.com/showpost.php?p=66377271&postcount=3911

The result of this latest effort is that users of Galaxy Nexus can flash their ROM and REPIT (lanchon-repit-20160415-system=1.0-cache=0.0605+wipe-data=same-maguro.zip) and gapps, and then they'll never have another worry. ;) At least about /system size on their phone. Thank you everyone. We've gone from an idea to a fool-proof solution very quickly!

I have a question for [MENTION=4141005]Lanchon[/MENTION]: is -cache=max+wipe equal to the default syntax? And maybe a feature request: can REPIT run when stored in /data if -data=same?

Thank you all again, especially [MENTION=4263181]mn.code[/MENTION] [MENTION=4544860]osm0sis[/MENTION] [MENTION=4141005]Lanchon[/MENTION] [MENTION=1369025]thagringo[/MENTION] [MENTION=4531957]musical_chairs[/MENTION] and [MENTION=2633638]Ziyan[/MENTION]!
[Samsung Galaxy Nexus] Lanchon:
it's a good question! so of course the intention is that the new system and cache sizes combined match the original combined sized. this is to avoid moving the really big /data partition, which would be extremely slow and a lot of mostly unwarranted work.

i can see myself actually defaulting the new system and cache sizes to explicit values for safety and convenience reasons:

-emmcs on actual devices might come from different suppliers. they might be of slightly different sizes. but typically devices come prepartitioned in a standard lowest-common-denominator way. depending on how this is done by the OEM, there *could* be extra unpartitioned space at the end of /data on *some but maybe not all* devices. using -cache=max would force a move of data backwards and an enlargement of cache, which is certainly not wanted.

-you may want to use -data=max to put whatever leftover space there might be at the end of the drive to good use.

-you may want bigger or smaller system for whatever reason, so -system=1.5-data=max would do the trick.

but actually, i dont remember if i saw free space at the end or not on this device :)

so to answer your question: it might be the same... but it's not a good idea not to be explicit in this particular case.
[Samsung Galaxy Nexus] bamtan2:
I agree! I expected the max command to go no further than the start of the next partition. I didn't realize it would look at the entire storage device, then move everything else too. :) That is certainly "max"! Two different kinds of maxes, depending on the context and scope :)
[Samsung Galaxy Nexus] Mimamau:
Thanks [MENTION=4141005]Lanchon[/MENTION] for your work on REPIT!

I use TWRP v2.8.7.0 and I can't run REPIT. I get this error:

flashize-ext: unable to extract package contents

[ERROR 1]

EDIT: With TWRP-3.0.2-0 it works...
[Samsung Galaxy Nexus] bamtan2:
[MENTION=4141005]Lanchon[/MENTION] I wanted to update you with feedback from users. I myself tested this to verify. First I flashed REPIT when my phone was connected to the computer and mounted. This apparently fails because REPIT script can't unmount that mounted file system. But then I disconnected from the computer and REPIT would still not flash from /tmp. So I manually unmounted, and then flashing worked fine. So: 1) maybe there is a bug in the automatic unmounting, and 2) maybe the error messages can be changed to make clear "please manually unmount all file systems and flash REPIT from /tmp instead."

Another observation: My flashing of REPIT took some extra time (10+ minutes?) because my /data is full and it needed a long file system check and TRIM of /data. But because data=same is the default, I expected no work to be done on /data. I guess my question is: should REPIT be leaving /data alone when set to =same? I worry we will cause users trouble by running long unnecessary scans of their file system, because there will always be someone who flashes on low battery and then crashes.

Thanks for all your work. :)
[Samsung Galaxy Nexus] the.gangster:
Check if this commit doesn't already makes it clearer to users, once it is part of a new release.

Maybe take a look at Repit's ReadMe once more.

A "=same" value is only a definition of the size of a partition. Depending on any change of the sizes of one of the partitions before such a partition in the heap it will nevertheless allow such a partition to move forward or backward. If on top the content-handling for such a partition is set to "+keep", the full partition data (not only the content but also free space) would then be moved accordingly. If content-handling of such a partition is set to "+wipe" it would be formatted instead.

This is, why for all partitions that are not set to wiped a filesystem-check (and Trim on Trim-enabled kernels) is performed first, before any possibly invasive operation is started on the partitions. Knowing that I hope you now also won't consider the filesystem-checks to be unnecessary any longer.

The ReadMe also tells users to "make sure battery is mostly charged" and to "plug into a power source".

In my opinion you cannot protect users from everything. You could have the most important points of the ReadMe printed down upon flashing and still some users wouldn't read it or would ignore the advices.
[Samsung Galaxy Nexus] Lanchon:
i think the docs say dont mount anything via usb. by connecting to pc with auto mounting enabled u r mounting. docs say if trouble reboot and dont mount; the doc is fine IMHO.

unmounting code is fine too: it cant work if a live process has something mounted. i wont be killing processes that have mounts. you mounted, so then you unmount. and if you dont like twrp keeping processes alive that it shouldnt (it does sometimes), then file a twrp bug.

repartitioning a phone is a complex operation. i expect users to be able to follow docs: reboot and dont mount anything.

data=same: absolutely not. i wont touch a phone that hasnt got perfect partition or partitions that cant be automatically fixed.

a data=same partition might need to be moved around to make room for other partitions. or to fulfil alignment requirements.

sometimes the data=same partition can even be resized if the filesystem didnt fill the containing partition. or if the filesystem was too big and didnt provide space for the encryption footer.

even if the partition was entirely untouched, it could harbor errors. i dont want users blaming repit for data losses after repits, that happened because of preexisting corruption on some untouched partition that repit could have detected but didnt.

repit is overly zealous with checks and adept at error recovery. it is not entirely by chance that no events of corruption or data loss have been reported so far.

---------- Post added at 02:49 AM ---------- Previous post was at 02:42 AM ----------

im on the phone visiting madrid. i didnt see u had answered. yes, everything u say is true. and i made the new release u referred to (coded at the plane :) )
[Samsung Galaxy Nexus] bamtan2:
sorry I wasn't clear: I also tested booting TWRP with nothing plugged in and nothing manually mounted. REPIT will copy itself to tmp, but when run from tmp, it still won't work. that's why I suggested either REPIT should tell the user to manually unmount, or that automatic unmounting isn't working. I don't know if this is a TWRP bug or not.

I understand that a partition needs to be checked before it's changed. :) I was referring to when it's not changed.
[Samsung Galaxy Nexus] Lanchon:
i havent been able to replicate that behavior.
[Samsung Galaxy Nexus] thagringo:
well, it has always been like that for me too. IOW, you have to manually copy the script to /tmp and manually unmount everything.

What do you need to track this down ? Could it be a TWRP problem ?

Thanks !
[Samsung Galaxy Nexus] EirikrHinnRauthi:
A LOT late to this party. I have been struggling for two days trying to get a toroplus .zip file floating around work; and then more time messing with the maguro one easily available to try to make it work on toroplus.... the first one just doesn't work, the second gives me either ERROR 1 or tells me I'm on toroplus not maguro even though I changed all the references to toroplus. Not sure where it is even FINDING maguro.

Is there anything online that helps me actually build this package as a noob for toroplus? I see some random files on the github for it, but its not a flashable zip and I can't figure out what to do with the files on github because there is no guide... so I keep spinning my head in circles.
[ZenFone 2 Q&A, Help & Troubleshooting] Jhdoubleoseven:
I know with the bootloader unlocked theoretically any kernel built for the device should boot, but are there any specific requirements? Size, certain files, etc? I tried packing the stock Linux kernel and initramfs into a boot.img and it wouldn't boot, so I was looking for suggestions on what may be going wrong. Thanks!
[ZenFone 2 Q&A, Help & Troubleshooting] sorg:
http://xdaforums.com/zenfone2/development/tool-zenfone-2-boot-repack-t3146088
[ZenFone 2 Q&A, Help & Troubleshooting] Jhdoubleoseven:
I've noticed that, but thanks for the reference :)

I don't want to repack a stock ZF2 kernel, I want to pack an Arch Linux kernel and an initramfs
[ZenFone 2 Q&A, Help & Troubleshooting] sorg:
You need to compile Arch Linux kernel for Moorefield platform. If Arch Linux provides such hardware config, then it can boot.

Generally speaking, ASUS provides source code for Linux kernel already. So, you can tweak config to Ach Linux requirements, or port hardware specific patches to Arch Linux kernel.

I don't know about your experience, but porting Linux kernel for non-supported platform (i believe Arch Linux doesn't know about Moorefield Z35xx) is not trivial.
[ZenFone 2 Q&A, Help & Troubleshooting] TheSSJ:
One addition to sorg's post:

The size of the whole boot.img must not exceed 16MB, also make sure to include as much from stock initrd as possible: init, init.rcs, binaries in sbin, etc.

If you compile the drivers directly into the kernel, then you don't need the .ko files in the lib/modules folder, making your ramdisk size smaller (by a great degree).

Cheers
[ZenFone 2 Q&A, Help & Troubleshooting] Jhdoubleoseven:
[deleted]
[ZenFone 2 Q&A, Help & Troubleshooting] Jhdoubleoseven:
Ah, thank you very much! Now I'm curious though, the stock Arch kernel is compiled for generic x86-64 processors so why does it need to be platform-specific? I run the linux-ck-core2 kernel which is specifically compiled for the core2 processor series, but the generic one works fine as well on my laptop.
[ZenFone 2 Q&A, Help & Troubleshooting] Jhdoubleoseven:
Thank you very much! Very helpful info :)

So you suggest modifying the stock initramfs to then start Arch? Arch uses systemd so I will probably need to figure out what exactly the stock one does so I know where to give it Arch-specific instructions.

Also, do you think the drivers would work with a newer kernel? Would I need to compile them into 3.10 or if I used the latest 4.1 or so do you think it could work?

Never played too much with kernel hacking so I definitely can get some great experience here! Thanks!
[ZenFone 2 Q&A, Help & Troubleshooting] sorg:
x86 is only op.code standard - that's all.

Moorefield Z35xx SoC is like all-in-one PC with many devices inside, not just CPU. And every device requires specific driver. There are some devices in Z35xx are very specific and not supported by generic PC drivers.

Also, Z35xx has neither BIOS, nor UEFI. It has SFI which is not used in PC. Kernel has to have support booting process and parsing SFI tables (like PC parses ACPI tables) to get info about connected devices and their resources.

This is just brief platform differences (comparing to standard PC) overview. And you may find more differences if you will study the Moorefield platform.
[Galaxy Note 3 Q&A, Help & Troubleshooting] murtza4u:
My Samsung note 3 N9005 showing only 1.72 GB of RAM. It should be around 3 GB. What would be the problem. How to solve this as my phone is original running android 4.4.2

Please help
[Galaxy Note 3 Q&A, Help & Troubleshooting] galaxy16:
can you post some screenshot? where it shows your ram n about phone.
[Galaxy Note 3 Q&A, Help & Troubleshooting] mudasir13:
unfortunately your note 3 is fake..