Port Request for Xiaomi Redmi Note 4G (Dior)

[jerryhou85]

Hi Lanchon, May I have REPIT file for Xiaomi Redmi Note 4G (Dior)?

your exact device and device codename http://www.gsmarena.com/xiaomi_redmi_note_4g-6561.php

your recovery (version? official? if not where did you get it?). https://twrp.me/devices/xiaomiredminote4gsinglesim.html Offical TWRP 3.0.2 for Dior

your kernel. your rom. I haven't got any ROM yet, just installed TWRP and wipe the phone, but I was trying to install this ROM from here: http://forum.xda-developers.com/redmi-note/development/rom-aicp-11-dior-t3273430 ROM OS Version: 6.0.x Marshmallow ROM Kernel: Linux 3.4.x Based On: CyanogenMod

is your device running the stock partition layout or is it already modified? Yes, it is still running the stock partition layout.

The reason I want to do a REPIT is that the current /system is too small for me, only 800MB. I was trying to install a CM13 and Micro Gapps but resulted in a Error Code 70: insufficient space, so I'm wondering maybe I can get more from REPIT? Thanks.

27 320MiB 1120MiB 800MiB ext4 system 28 1120MiB 1504MiB 384MiB ext4 cache 1504MiB 1536MiB 32.0MiB Free Space 29 1536MiB 7456MiB 5920MiB ext4 userdata 7456MiB 7456MiB 0.01MiB Free Space

repit-dump.zip

[Lanchon]

thanks for this extremely complete port request. unfortunately I'm travelling through europe at the moment, so please be patient. thanks!

[Lanchon]

so i'm looking at this. i found a strange thing: most partitions on this device are misaligned, making it slower and less reliable. this includes /system and /cache, but fortunately not /data, which would have been a total fail. (partitions are misaligned even to 2KB boundaries!)

but the good news is that there is some unallocated space between /cache and /data (a little less than 32MB) that i can use to align everything up without shrinking partitions. i will force a 4MB alignment on this device.

[Lanchon]

hi, sorry for the wait.

you'll find a build in the downloads section: lanchon-repit-20160922-system=same-cache=0.03125+wipe-data=max-dior.zip

the default configuration is to shrink cache to 32MB and use the recovered space to grow /data by around 350MB. because the start of /data will move, the operation will take a long time (30 minutes?).

i did not grow /system in the default config as you wanted! there are several reasons for this:

• the space issue: if you grow /system to install more google apps, when google updates them they will eat TWICE as much space: once in /system for the flashed version, and again in /data for the updated version. in small flash devices, it is always better to install the absolute minimum in /system and install the rest in /data (ie: from the play store). my recommendation is that you use nano gapps on a standard-sized /system.
• the flashing issue: recent androids are flashed by writing an image of the complete /system partition file system, instead of writing its files one-by-one. this means that:
  • if you shrink /system, the flash will fail because the image does not fit the partition (even though the imaged file system might have a lot of free space within).
  • if you grow /system, flashing a standard rom will write a smaller file system within the partition. the extra space will then not be immediately available for writing files. in order to recover the space you would need to run the resize2fs tool (for example by using TWRP's "resize partition" function) after every rom flash (and before flashing gapps).

because of the way the "gapps save and restore during flash" mechanism in roms works, and because the restore happens before you have a chance to resize, the gapps restore will fail for lack of space. so you would need to manually format /system, flash rom, resize /system, and flash gapps for every rom upgrade!

the solution to this problem is asking the rom developer to include a /system resize step after the flash in their roms. there is a standard commit that can be added for this. this commit is used in official i9100 CM, in several galaxy nexus roms, and in other devices.

due to these issues, i suggest you take my advice: use nano gapps on a standard-sized /system. this easier to maintain and technically superior.

if against my advice you still want to test a larger /system, i suggest you use this configuration: system=1.133-cache=0.031+wipe-data=same this will give you a shrunken 32MB /cache and an enlarged /system to match, so that the combination leaves the start address of /data unchanged. because /data does not need to be moved, the resize operation will be quite fast and should finish in a minute or two.

please report on your testing if any.

[Lanchon]

note that i've closed this issue but you can still reply here.

[jerryhou85]

Great! Thanks a lot. It's not exactly what I wanted. But it's better than nothing, huh? I'll download it and see how it works. Currently there is some error with download host and it always says cannot find a mirror, I'll try to download at another time.

Thanks again for your help!

[Lanchon]

with the latest changes published yesterday, the above mentioned config becomes: system=1160M-cache=32M+wipe-data=same

the caveats about growing system remain.

oops! yeah, just checked, i can't download from AFH either :( ok, here's a mirror for you then: lanchon-repit-20160923-system=same-cache=32M+wipe-data=max-dior.zip

[jerryhou85]

Hi Lanchon, Just want to feedback that the REPIT file works wonderfully on my device. And now I have a 32M cache and 6300M userdata. Appreciate your work!

[Lanchon]

thanks! :)