Introduction:
This guide will explain the different partition layouts for the Streak5.
It's purpose is to help users decide which custom recovery varient to flash for their device.
The purpose of multiple device branches is to block users from flashing the wrong rom onto their device.
Roms are build with the assumption of a specific partition layout, using a rom ment for a different layout will result in it bootlooping/brick/loss of data.
Technical details:
While roms are able to mount ext3 partitions in ext4 mode, they CANNOT mount ext4 partitions in ext3 mode.
Doing so will result in a bootloop/brick as the partition will not be accessable.
The initial fs format used does affect the characteristics of the partition, otherwise it would be possible to mount ext4 partitions in ext3 mode.
(This also completely ignores the compability mode for ext4 that would otherwise allow it to be mounted in ext3 mode, this compability mode is not supported under android)
While users are free to determine the size of the partitions they wish to use, these are the standardized sizes for the purposes of custom recoveries.
Custom recoveries are like roms in that they require knowing the size and location of partitions ahead of time to work.
If a user wishes to use a custom layout, they will need to build their own recoveries and modify their own roms for them to work properly.
Thusly it will not be supported by rom makers or custom recovery makers (unless stated otherwise)
Click to expand...
Click to collapse
Layout details:
See Dell Streak 5/Partition Layout - XDA wiki
Click to expand...
Click to collapse
Basics:
There are 5 layouts total, with 3 of them being relevent for most users.
streak <original layout for unmodified devices>
Original version used by all stock roms
Uses yaffs2 for /firstboot and /system; ext3 for /cache and /data
Layout used on stock devices
streak5ex <ext4 mod>
Uses yaffs2 for /firstboot and /system; ext4 for /cache and /data
ext4 mod for devices with unmodified innerSD partitions
streak5dm <layout for MTP users>
Uses ext4 for /cache, /data, /system
/cache is expanded to 512mb
/system is moved onto innerSD and expanded to 512mb
/data is moved to last partition and expanded to maximum size of innerSD
/sdcard is symlinked to /data/media
outerSD is linked as /sdcard2
Not yet implemented!
streak5sd8 <layout for devices with 8-16gb innerSDs>
Uses ext4 for /cache, /data, /system, /sdcard
/cache is expanded to 512mb
/data is expanded to 4096mb
/system is moved onto innerSD and expanded to 512mb
/sdcard is moved onto innerSD and expanded to maximum size of innerSD
outerSD is linked as /sdcard/external_SD or /sdcard2 (dependant on android version)
Dual SD card support not yet implemented!
streak5sd32 <layout for devices with 32-64gb innerSDs>
Uses ext4 for /cache, /data, /system, /sdcard
/cache is expanded to 512mb
/data is expanded to 16384mb
/system is moved onto innerSD and expanded to 512mb
/sdcard is moved onto innerSD and expanded to maximum size of innerSD
outerSD is linked as /sdcard/external_SD or /sdcard2 (dependant on android version)
Dual SD card support not yet implemented!
Not yet implemented!
Click to expand...
Click to collapse
Changelog:
Sep 15 2012: Created initial guide
Click to expand...
Click to collapse
2char
question for streak5ex <ext4 mod>
does that one support ext3 by default too or you have to use specifically for it?
ive created a boot.img maybe someone can try and report back - in theory it should speed up /data /system and /cache partitions by the fstab flags set.
also uploaded the default boot.img from oxygen 4-7-5 (please make sure you're on 4-7-5) maybe someone can help fix this if it doesnt work.
please note this may wipe all storage / etc etc take all necessary precautions (external backup etc) until we get it working 100% as i havent tested
this work is open to anyone who'd like to use it.
Cliffs
- ive modified boot.img to try and disable verity and force encrypt - also enabling / disabling certain IO functions to improve throughput
- i need someone to go into twrp > flash the modifiedboot.img then format /data and check if it boots (i.e boots into OS if it does please report back)
-please make all necessary backups incase it doesnt work
-attached stock boot.img incase it doesnt work (please make external backup too)
here are my attempts:
Modified boot.img:
https://drive.google.com/open?id=154jrUAQ1oq7Fpjw7PgBKCJ_E6yBCxvaQ
stock boot.img
https://drive.google.com/open?id=17JU_OiEGdGm_9K1TcYlFtEkiiTJmODve
please report back if it works or not (i.e does it boot into OS or hang?)
background
my previous android phones ive created a perfect boot image whereby i edit the fstab in the boot.img
to disable force encryption and apply other android attributed in the fstab.
however i do not yet have my 1+5T as of yet so i can not try the edits as the boot.img is alittle different from my previous android phones.
The stock boot.img for the oneplus 5T (extracted from 4-7-5)
has two fstab files
the first fstab.qcom, and the second fstab_nodata.qcom
both these fstab are alittle different.
fstab.qcom looks like this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1,discard,errors=panic wait,verify
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,nodiratime,inline_xattr wait,check,forceencrypt=footer,resize
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=panic wait,check,fileencryption=ice,resize
#/devices/soc/c0a4900.sdhci/mmc_host* /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/zram0 none swap defaults zramsize=536870912
/dev/block/bootdevice/by-name/misc /misc emmc defaults defaults
/dev/block/bootdevice/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/bluetooth /bt_firmware vfat ro,shortname=lower,uid=1002,gid=3002,dmask=227,fmask=337,context=u:object_r:bt_firmware_file:s0 wait
/dev/block/bootdevice/by-name/cache /cache ext4 rw,nosuid,nodev,barrier=1 wait,check
/devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto/usb* auto auto defaults voldmanaged=usbotg:auto
and fstab_nodata.qcom looks like this:
Code:
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1,discard wait,verify
#/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=panic wait,check,forceencrypt=footer,resize
tmpfs /data tmpfs defaults defaults
#/devices/soc/c0a4900.sdhci/mmc_host* /storage/sdcard1 vfat nosuid,nodev wait,voldmanaged=sdcard1:auto,encryptable=footer
/dev/block/zram0 none swap defaults zramsize=536870912
/dev/block/bootdevice/by-name/misc /misc emmc defaults defaults
/dev/block/bootdevice/by-name/modem /firmware vfat ro,shortname=lower,uid=1000,gid=1000,dmask=227,fmask=337,context=u:object_r:firmware_file:s0 wait
/dev/block/bootdevice/by-name/bluetooth /bt_firmware vfat ro,shortname=lower,uid=1002,gid=3002,dmask=227,fmask=337,context=u:object_r:bt_firmware_file:s0 wait
/dev/block/bootdevice/by-name/cache /cache ext4 rw,nosuid,nodev,barrier=1 wait
/devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto/usb* auto auto defaults voldmanaged=usbotg:auto
as you can see these two files are alittle different - previous android devices have only had one fstab file.
so my first question why are there two fstab files? - anywho ive added my modifications to both where applicable.
secondly the modified fstab id like to introduce is the following:
Code:
/dev/block/bootdevice/by-name/system /system ext4 ro,noatime,noauto_da_alloc,nodev,nodiratime,barrier=0,data=writeback,nobh wait
/dev/block/bootdevice/by-name/userdata /data f2fs nosuid,nodev,noatime,nodiratime,discard,inline_data,inline_xattr wait,check,encryptable,resize
/dev/block/bootdevice/by-name/userdata /data ext4 noatime,nosuid,nodev,nodiratime,barrier=0,data=writeback,noauto_da_alloc,discard,nobh wait,check,encryptable,resize
/dev/block/bootdevice/by-name/cache /cache ext4 rw,nosuid,nodev,noatime,noauto_da_alloc,nodiratime,barrier=0,data=writeback,nobh wait,check
virtyx said:
Hi guys
my previous android phones ive created a perfect boot image whereby i edit the fstab in the boot.img
to disable force encryption and apply other android attributed in the fstab.
however i do not yet have my 1+5T as of yet so i can not try the edits as the boot.img is alittle different from my previous android phones.
The stock boot.img for the oneplus 5T (extracted from 4-7-5)
has two fstab files
the first fstab.qcom, and the second fstab_nodata.qcom
both these fstab are alittle different.
fstab.qcom looks like this:
and fstab_nodata.qcom looks like this:
as you can see these two files are alittle different - previous android devices have only had one fstab file.
so my first question why are there two fstab files? - anywho ive added my modifications to both where applicable.
secondly the modified fstab id like to introduce is the following:
ive created a boot.img maybe someone can try and report back - in theory it should speed up /data /system and /cache partitions by the fstab flags set.
also uploaded the default boot.img from oxygen 4-7-5 (please make sure you're on 4-7-5) maybe someone can help fix this if it doesnt work.
please note this may wipe all storage / etc etc take all necessary precautions (external backup etc) until we get it working 100% as i havent tested
this work is open to anyone who'd like to use it.
here are my attempts:
Modified boot.img:
https://drive.google.com/open?id=1BYH4J3Du9VBRyxM1hyTQhs_hKNLgOU0W
stock boot.img
https://drive.google.com/open?id=1IpByGusbuWXKOXGKamHHEwax3aSnsvfm
please report back if it works or not (i.e does it boot into OS or hang?)
Click to expand...
Click to collapse
You also need to make the kernel compatible, without verity. Otherwise won't boot
jgcaap said:
You also need to make the kernel compatible, without verity. Otherwise won't boot
Click to expand...
Click to collapse
please read OP again as ive done this
by default force encryption on /data is enabled, and dm-verify is enabled...boot.img needs to be modified to disable. also /data will have to be formatted to flash ROMS.
with dm-verify enabled, any changes to /system will cause no boot
to modify boot.img:
Code:
open /ramdisk/fstab.qcom
change:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait,verify
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=continue wait,check,formattable,forceencrypt=/dev/block/bootdevice/by-name/extra
to:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=continue wait,check,formattable,encryptable=/dev/block/bootdevice/by-name/extra
virtyx said:
If we flash the boot.Img then another kernel may it work? @jgcaap how would we get it to work?
Never needed to do that on a previous android
Click to expand...
Click to collapse
You need to compile kernel that will allow to boot without the verity and change the ram disk.
benny3 said:
by default force encryption on /data is enabled, and dm-verify is enabled...boot.img needs to be modified to disable. also /data will have to be formatted to flash ROMS.
with dm-verify enabled, any changes to /system will cause no boot
to modify boot.img:
Code:
open /ramdisk/fstab.qcom
change:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait,verify
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=continue wait,check,formattable,forceencrypt=/dev/block/bootdevice/by-name/extra
to:
/dev/block/bootdevice/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/bootdevice/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc,discard,errors=continue wait,check,formattable,encryptable=/dev/block/bootdevice/by-name/extra
Click to expand...
Click to collapse
which is why ive asked users to format /data before flashing the boot.img which should disable verity and forceencrypt
jgcaap said:
You need to compile kernel that will allow to boot without the verity and change the ram disk.
Click to expand...
Click to collapse
this is what im doing...
so if someone is brave enough to test this (as i dont have a 1+5T yet)
format /data then using mtp trasnfer the modifiedboot.img to the phone, then flash modified boot.img
and see if you can boot into OS if you can please report back.
updated the modifiedboot.img to omit discard flag - should slightly improve performance but requires a cron job to manually trim partitions, automatic trim can cause hangs upon large file deletion, plus i dont find the need to run trim on the block layer every time a file is deleted, i would rather run it daily with a cron job.
Isn't this what the disable force encryption and disable no verity zip is for? To flash over stock boot image and allow boot on a decrypted device by disabling Force encryption and no verity.?
yung40oz84 said:
Isn't this what the disable force encryption and disable no verity zip is for? To flash over stock boot image and allow boot on a decrypted device by disabling Force encryption and no verity.?
Click to expand...
Click to collapse
yes, those zips only remove verity and force encryption
this boot img includes other tweaks not found elsewhere (ie, data writeback, barrier=0, noatime, nodiratime, noautoalloc, disabling auto-trim, etc) which all theoretically should improve throughput while reducing overhead
virtyx said:
yes, those zips only remove verity and force encryption
this boot img includes other tweaks not found elsewhere (ie, data writeback, barrier=0, noatime, nodiratime, noautoalloc, disabling auto-trim, etc) which all theoretically should improve throughput while reducing overhead
Click to expand...
Click to collapse
Doesn't the auto-trim flag keeps the NAND flash healthy and prevents data corruption? ?
ground-zero said:
Doesn't the auto-trim flag keeps the NAND flash healthy and prevents data corruption? ?
Click to expand...
Click to collapse
No, doesnt prevent corruption.
we dont need the trim command to run every time a file is deleted that just causes unnecessary overhead, its better if we run the trim command daily via a cron job.
(imagine deleting files and running the trim command everytime we do so, its not needed, the OS does adequate garbage collection and the Trim command gets issued automatically from android 5 so its not needed to add it in the fstab)
for your reading
https://wiki.archlinux.org/index.php/Solid_State_Drives#Periodic_TRIM