I have been a big fan of VEGAn Ginger -- sure it has some issues but it works pretty well. But recently I was wondering how much of an issue would it be to install CM7.02, the VTL Launcher, and whatever other extras and just keep up to date.
I did and for the most part it works the same. A few things were FC that didn't on VEGAn and a few things worked that FC on VEGAn. No big difference on too many things.
However, two issues came up.
1) CM really wanted to install ROM Manager. The CM forum implied it works ok so I tried it. It DOES work on my system but it expects everything on /mnt/emmc which was a pain since all my backups and recovery were on the external sdcard /mnt/sdcard2 in VEGAn and /mnt/sdcard in CM7. What's worse is apparently it will refuse to flash over it self with an old version! So it wasn't insurmountable, just required me to move everything for awhile. But I finally got tired of it and reflashed good old bekit 0.8 using nvflash. So if you experiment, be sure you have a backup of partition 9 (clockwork mod) or you know how to unpack the ZIP file and flash it.
2) This brings up an interesting issue. I was going to try it but I didn't because I realized I'd have to repack the root directory and I didn't want to do it. But if the Gingerbread ROM repackagers were interested this would be easy for them to do. I'd propose having 3 directories in /mnt (well, plus the others, but 3 we are interested in): /mnt/emmc /mnt/sdcard /mnt/sdcard2
What you would do is let CM7 mount /mnt/emmc as always and change vold.conf to mount the external card at /mnt/sdcard2. Then you bind mount /mnt/emmc over /mnt/sdcard. That way you have the exact same filesystem at /mnt/emmc and /mnt/sdcard and in CM7 and the other ROMs it would "just work" since regardless of where you were looking for the SDCARD you'd wind up with the internal unless you looked for sdcard2.
I understand not all devices have big internal SD and that's why CM is set up the way it is, but if we are mucking with the mount scheme anyway, why not like this?
I may go in and try it again if I reinstall CM7. Without having to recast the ROM you'd have to put a userinit script in that DID not block but would spin off a process to wait for /dev/emmc to mount and then moved /mnt/sdcard to /mnt/sdcard2 and then created /mnt/sdcard again and did the bind mount. This requires a remount of root to make it writeable, etc. Kind of a pain.
Something like this (untested):
#!/system/bin/sh
( until mount | grep -l sdcard
do
mount -o remount,rw / /
mv /mnt/sdcard /mnt/sdcard2
mkdir /mnt/sdcard
chown 1000 /mnt/sdcard
chgrp 1015 /mnt/sdcard # whatever sdcard_r gid is? 1015? 1025?
chmod 076 /mnt/sdcard
mount -o bind /mnt/emmc /mnt/sdcard
mount -o remount,ro / /
done ) &
Something like that. Would be easier if you could just get vold to mount on sdcard2 to start with and have /mnt/sdcard and /mnt/sdcard2 already created in /mnt.
Just a thought.
By the way, another trick like this that I do is to mount sdcard2 as a subdirectory of sdcard. That works great EXCEPT when you USB mount the tablet it never works until you unmount. Not a big deal but a pain.
Good suggestion, but it's easier to just symlink /mnt/sdcard to /mnt/emmc and mount the internal SD card there--assuming that vold does not check that the mount point is not a symbolic link. The external SD card can be mounted on /mnt/sdcard2.
However, this might be a temporary problem. Google, for Gingerbread, wants the removable SD card on all devices, whether cell phone or tablet, to always be mounted on /mnt/sdcard (or /sdcard) and the internal SD card to be mounted elsewhere (/mnt/emmc, I believe), which is why Gingerbread-based firmwares like CM7 have /mnt/emmc and /mnt/sdcard as mount points.
In 6 months, hopefully, everybody will be on Gingerbread+ and the current multiplicity of possible mount locations will cease to be an irritation.
you have emmc and sdcard mountable right now. you can also mount a usbdisk. you can have 2 mounts going at the same time currently.
Screenshots? Last I checked (7.0.2) you still could not take a SS by any method on CM7.
That's pretty much why I'm on VEGANginger.
I used the vold.fstab.zip thing floating around here or on the CM forums to change the fstab on CM7 to be like VEGANtab/froyo for mounting the internal sdcard - makes all the 3rd party apps happy.
schettj said:
Screenshots? Last I checked (7.0.2) you still could not take a SS by any method on CM7.
That's pretty much why I'm on VEGANginger.
I used the vold.fstab.zip thing floating around here or on the CM forums to change the fstab on CM7 to be like VEGANtab/froyo for mounting the internal sdcard - makes all the 3rd party apps happy.
Click to expand...
Click to collapse
Same thing here, it makes almost everything back to normal, unless you try to use ROM Manager automagically, which will fail.
rajeevvp said:
Good suggestion, but it's easier to just symlink /mnt/sdcard to /mnt/emmc and mount the internal SD card there--assuming that vold does not check that the mount point is not a symbolic link. The external SD card can be mounted on /mnt/sdcard2.
However, this might be a temporary problem. Google, for Gingerbread, wants the removable SD card on all devices, whether cell phone or tablet, to always be mounted on /mnt/sdcard (or /sdcard) and the internal SD card to be mounted elsewhere (/mnt/emmc, I believe), which is why Gingerbread-based firmwares like CM7 have /mnt/emmc and /mnt/sdcard as mount points.
In 6 months, hopefully, everybody will be on Gingerbread+ and the current multiplicity of possible mount locations will cease to be an irritation.
Click to expand...
Click to collapse
Symlinks don't work for everything -- especially any FS that is VFAT. Bind mounts always work even through a chroot, etc. I don't think you can mount on top of a symlink either although I could be wrong. Same problem with trying to symlink /mnt/sdcard/sdcard2 => /mnt/sdcard2. The sdcard FS is VFAT so...
schettj said:
Screenshots? Last I checked (7.0.2) you still could not take a SS by any method on CM7.
That's pretty much why I'm on VEGANginger.
I used the vold.fstab.zip thing floating around here or on the CM forums to change the fstab on CM7 to be like VEGANtab/froyo for mounting the internal sdcard - makes all the 3rd party apps happy.
Click to expand...
Click to collapse
screen shots are in cm7 now.
wd5gnr said:
Symlinks don't work for everything -- especially any FS that is VFAT. Bind mounts always work even through a chroot, etc. I don't think you can mount on top of a symlink either although I could be wrong. Same problem with trying to symlink /mnt/sdcard/sdcard2 => /mnt/sdcard2. The sdcard FS is VFAT so...
Click to expand...
Click to collapse
No, symlinks will work in this case because the link in not on the VFAT filesystem--it's outside it. And, you can mount through a symlink.
pershoot said:
screen shots are in cm7 now.
Click to expand...
Click to collapse
Hm... they didn't work in 7.0.2 when I flashed it. So they're in the nightly since? I could flash over and kick the tires.
I have a good 2 GB of space that I am unlikely to use on the /data partition. So I created an 'sdcard' directory in there. What I'm trying to do is trick the system into believing that it's a second SD card. Can android support more than one? It's all good getting the directory to work as a secondary storage place, but the problem is, media scanner will not show pictures/music that are in that directory.
So my question is, is it possible to edit the ramdisk (init.rc) or vold.fstab etc or any other files, so the system is tricked into believing it's an actual storage card? I have tried making symlinks and doing directory bindings from /data/sdcard to /storage/sdcard1, but haven't had any luck.
Edit:
something like this maybe in init.rc??
symlink /storage/sdcard /sdcard
symlink /storage/sdcard1 /data/sdcard
export EXTERNAL_STORAGE /storage/sdcard
export SECONDARY_STORAGE /storage/sdcard1
I'm sure something is possible.
The nicest thing would be to have vold bind-mount a directory or loop-mount a filesystem image, but I'm not sure vold can do that at all and if it can I don't know what the syntax for that would be.
This would probably be a bit different between sense and aosp as it looks like vold is different.
You can easily bind-mount it yourself.
Either way, if you want to mount it on (say) /sdcard2 or anywhere on the root file system, you have to edit the ramdisk in the boot image.
But you can also mount it on top of /sdcard
mkdir /data/extra_sd
mkdir /sdcard/extra_sd
busybox mount --bind /data/extra_sd /sdcard/extra_sd
( ^^^-- I found that /system/bin/mount doesn't do --bind or -o loop and that busybox mount does.)
I tried this and it works. I have not yet experimented with putting it in an init.d script or so to mount it on boot and see if mediascanner scans it.
However, using this method you may corrupt stuff when you USB-mount your sdcard onto your PC. I'm not sure.
-Jobo
I've actually been trying numerous ways of mount bind all day. From init.d to repacking kernels with adjusted init.rc. Nothing worked.
The only way that works is using ScriptManager to run a busybox mount -o bind command at startup. It binds a subfolder in /sdcard/music to /data/media, where I've offloaded 1.5 GB of my music. I've rebooted many times and it seems to mount on time before messing up the media storage, and now I have 1.5 G extra SD space
Well, you could try "partitioning" the phone with LVM.
Which would actually be really interesting. I've got an extra gig of space in each of /system and /data that I'm not using. Being able to span that with /sdcard would be handy.
Actually, with that in place, you could combine /data and /sdcard into a single large partition and then just have both directories on that.
ardax said:
Well, you could try "partitioning" the phone with LVM.
Which would actually be really interesting. I've got an extra gig of space in each of /system and /data that I'm not using. Being able to span that with /sdcard would be handy.
Actually, with that in place, you could combine /data and /sdcard into a single large partition and then just have both directories on that.
Click to expand...
Click to collapse
That would be the ideal solution, which I have been hoping since day 1 becomes available from our phone, but does it not require S-OFF?
djsubtronic said:
That would be the ideal solution, which I have been hoping since day 1 becomes available from our phone, but does it not require S-OFF?
Click to expand...
Click to collapse
I don't think it should, since it's not changing the partition layout of the internal memory itself, just globbing it together and slapping virtual volumes on top with LVM. The biggest things are making sure that the kernel has LVM support and binaries built in and that recovery can get to those LVM binaries.
Perhaps I'm wrong though.
djsubtronic said:
I've actually been trying numerous ways of mount bind all day. From init.d to repacking kernels with adjusted init.rc. Nothing worked.
The only way that works is using ScriptManager to run a busybox mount -o bind command at startup. It binds a subfolder in /sdcard/music to /data/media, where I've offloaded 1.5 GB of my music. I've rebooted many times and it seems to mount on time before messing up the media storage, and now I have 1.5 G extra SD space
Click to expand...
Click to collapse
I really like the idea using data to get some extra space.
I tried "busybox mount --bind" via console and it works. Now i will have a look at ScriptManager.
But what happens if you are installing/updating a new ROM. Do you lose all your things located in /data?
regards
If you format /data then yes, obviously. You are only creating a "shortcut" to /data/folder.
Also, if you run out of space in /data/app/ you can move apps to /system/app instead.
I did that on my blade with a way too big /system/ partition and way too small /data/ partition
djsubtronic said:
I've actually been trying numerous ways of mount bind all day. From init.d to repacking kernels with adjusted init.rc. Nothing worked.
The only way that works is using ScriptManager to run a busybox mount -o bind command at startup. It binds a subfolder in /sdcard/music to /data/media, where I've offloaded 1.5 GB of my music. I've rebooted many times and it seems to mount on time before messing up the media storage, and now I have 1.5 G extra SD space
Click to expand...
Click to collapse
Could I get a hold of that script by chance?
Daiskei said:
Could I get a hold of that script by chance?
Click to expand...
Click to collapse
+1. Yes, please share.
One S | Xparent Blue Tapatalk 2 | Viper 1.2.1 | Bricked Beastmode
So updating a ROM without formating data partition should be no problem.
But for installing a new ROM i have to backup the folder in the data partition.
I tried to use ScriptManager, but this app seems to be bit overloaded.
After this i installed GScriptsLite.
In there i made a new script with something like this:
busybox mount --bind /data/myfolder /sdcard/myfolder
The script is not started automatically after a reboot, but after running the script via GScriptsLite the folder is mounted.
Yeah I suppose it could be difficult if changing ROMs, but I use CM only so I never worry about changing the data partition. But if I do, I just copy the /data/media folder onto my PC using adb pull, then do the wiping/flashing, and finally push the media folder back before booting the ROM.
As for the script, it's essentially just this one line:
Code:
busybox mount -o bind /data/media /storage/sdcard0/Music/Music2
I've kept the script file itself on the /data partition as well. In script manager I've set it to run the script as SU and on boot, and that's it. I've mounted it into a sub folder within Music since I use PlayerPro and it only adds music found within /sdcard/Music.
Yes, ScriptManager is a lot more complicated than GScripts, but it always mounts it automatically on boot so saves the hassle of having to remember to manually run the script if you ever reboot. Plus you only have to sort it out once then never open the app again if you don't want to
When I installed Android 5.0 and later 6.0 ROM on our Xperia L experience was much better than stock. These ROM's are simply fantastic! However, we have memory issues. Yeah we can use apps like Link2SD or foldermount, but that's too much of a hassle. Thet's not really a long-term solution.
The main problem is that /data partition is too small to handle modern app file sizes. It's only 1GB.
And /sdcard partition also exists (which is seperate from data) and represents internal memory - that's 4GB.
On top of that our phone has externalSD slot - /extSD option.
When you install an app it always directly installs to /data. Yeah you can move it. But still 1GB is not enough, somehow I keep getting not enough memory notification.
So the first solution by @Kahana82 was to repartition. That way we could remove 2GB from /sdcard and give it to /data. But the problem is that when we change partitions our phone gets bricked when stock ROM is flashed again.
But I have come across a new idea that could work. Just need community help for that as I am not that experienced.
So instead of repartitioning we could simply mount /SDCard as /data (just rename it!) and mount /data as /SDCard. That way we could increase /data from 1GB to 4GB and I think it is enough for basic app needs. And therefore flashing stock ROM should work as it is just change in kernel or system. Only 1GB internal memory wouldn't be a problem since Android 6.0 allows us to mount externalSD as internal memory.
Now how to do it. I have taken a look at this thread for 2011 Xperia Arc. Looks like ramdisk could be modified to do so as I see that mountpoint is there.
EDIT: OK, I've managed to unpack boot.img and ramdisk. Here's what I get:
fstab.qcom file
Code:
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/platform/msm_sdcc.1/by-name/boot /boot emmc defaults recoveryonly
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc,journal_async_commit,errors=panic wait,check,encryptable=/persist/footer
/dev/block/platform/msm_sdcc.1/by-name/userdata /data f2fs rw,nosuid,nodev,noatime,nodiratime,inline_xattr wait,formattable,check,encryptable=/persist/footer
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc,journal_async_commit,errors=panic wait,check
/dev/block/platform/msm_sdcc.1/by-name/cache /cache f2fs rw,nosuid,nodev,noatime,nodiratime,inline_xattr wait,check
/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel /recovery emmc defaults defaults
/devices/platform/msm_sdcc.1/mmc_host/mmc0* auto auto defaults voldmanaged=sdcard0:32,nonremovable,noemulatedsd
/devices/platform/msm_sdcc.3/mmc_host* auto auto nosuid,nodev voldmanaged=sdcard1:auto,encryptable=userdata
I propose another solution.
Format "SD 0" as EXT4.
Then mount during the boot of Android, "SD 0" as DATA partition.
Simply replace "date" with "SD 0" at the time of installation of partitions.
This does not alter the structure of partitions and would give the 4 GB device for apps installation.
I've done tests. It's easy to format using the TWRP "SD 0" as EXT4.
The same process is easy to reverse.
It is safe because it does not change the structure of the partitions. If there is any problem just restore the Stock ROM.
Soon just need help to know which Android configuration files need to change mount "SD 0 in EXT4" like the DATA unit.
The Xperia L pass from 1,57GB to 4 GB !!!
Help, please !!!!
All the MM ROMs for Xperia L should have Adoptable Storage. You could format a partition of your SD Card as Adoptable Storage (using Apps2SD). And you can then move most of the apps to that partition in its entirety. Apps downloaded from Play Store would automatically go to the Adopted Storage.
Only certain apps like WhatsApp and Maps would refuse to move. You could use Link2SD to force move such apps to Internal SD of your device. It will move a big part of it.
On older ROMs, you should be able to setup a partition of your SD as linkable storage, allowing Link2SD or Apps2SD to move the whole app to the partition.
DragonClawsAreSharp said:
All the MM ROMs for Xperia L should have Adoptable Storage. You could format a partition of your SD Card as Adoptable Storage (using Apps2SD). And you can then move most of the apps to that partition in its entirety. Apps downloaded from Play Store would automatically go to the Adopted Storage.
Only certain apps like WhatsApp and Maps would refuse to move. You could use Link2SD to force move such apps to Internal SD of your device. It will move a big part of it.
On older ROMs, you should be able to setup a partition of your SD as linkable storage, allowing Link2SD or Apps2SD to move the whole app to the partition.
Click to expand...
Click to collapse
There are advantages to swap partitions instead of using the SD Card:
- The new partition date would be within the device's NAND memory. So there are the risks involved in using a sdcard always fragile ...
- How the partition is within the NAND memory beyond the security there is the highest performance.
The only downside is that the restriction would increase from 1,57GB to 4GB.
In my case I not use the smartphone for gaming. All of my APPs would fit into 2.5GB.
If I still needed more space, could use "Adoptable Storage".
- Could unmount and remove the SD card when wanted, after all was being used only for personal files and not apps.
Also it would be a great experimental situation of low risk to learn how to configure mount partitions on Android.
ConceptBR said:
There are advantages to swap partitions instead of using the SD Card:
- The new partition date would be within the device's NAND memory. So there are the risks involved in using a sdcard always fragile ...
- How the partition is within the NAND memory beyond the security there is the highest performance.
The only downside is that the restriction would increase from 1,57GB to 4GB.
In my case I not use the smartphone for gaming. All of my APPs would fit into 2.5GB.
If I still needed more space, could use "Adoptable Storage".
- Could unmount and remove the SD card when wanted, after all was being used only for personal files and not apps.
Also it would be a great experimental situation of low risk to learn how to configure mount partitions on Android.
Click to expand...
Click to collapse
Guys, devs are apparently working on unifying partitions. That's the best solution.
It is already working on Xperia T. So it is possible on Xperia L as well.
Let's just wait and see for now.
IMO This is actually top priority for Xperia L lol other that this the device is working just fine.
ConceptBR said:
I propose another solution.
Format "SD 0" as EXT4.
Then mount during the boot of Android, "SD 0" as DATA partition.
Simply replace "date" with "SD 0" at the time of installation of partitions.
This does not alter the structure of partitions and would give the 4 GB device for apps installation.
I've done tests. It's easy to format using the TWRP "SD 0" as EXT4.
The same process is easy to reverse.
It is safe because it does not change the structure of the partitions. If there is any problem just restore the Stock ROM.
Soon just need help to know which Android configuration files need to change mount "SD 0 in EXT4" like the DATA unit.
The Xperia L pass from 1,57GB to 4 GB !!!
Help, please !!!!
Click to expand...
Click to collapse
That's the same thing I was thinking. But yeah, thanks for the info that SDCard can be formatted to ext4. Then I think this can happen:
Code:
# Android fstab file.
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/platform/msm_sdcc.1/by-name/boot /boot emmc defaults recoveryonly
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/devices/platform/msm_sdcc.1/mmc_host/mmc0 /data ext4 noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc,journal_async_commit,errors=panic wait,check,encryptable=/persist/footer
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc,journal_async_commit,errors=panic wait,check
/dev/block/platform/msm_sdcc.1/by-name/cache /cache f2fs rw,nosuid,nodev,noatime,nodiratime,inline_xattr wait,check
/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel /recovery emmc defaults defaults
/devices/platform/msm_sdcc.3/mmc_host* auto auto nosuid,nodev voldmanaged=sdcard1:auto,encryptable=userdata
Ehh, will try to make boot.img soon. You guys think this code would succeed? Then /sdcard wouldn't exist but let's just see if data would.
I've tried it and it f..ked my phone. I had to reflash stock and go to mm from there ...
cojocar.andrei said:
I've tried it and it f..ked my phone. I had to reflash stock and go to mm from there ...
Click to expand...
Click to collapse
Sorry to hear that...
In my case I need an even simpler solution ...
Using TWRP formatted "SD 0" as EXT4.
I managed to UnMount "/DATA" and "/sdcard".
I would like to reverse the mounts.
Partitioning modifies the structure of partitions.
Mounting is by software changes and safe.
The solution will allow any time to install the ROM Stock since the structure of the partitions will not be changed.
As in TWRP Terminal can ride correct partitions?
if I'm wrong then correct me, please ...
Device Configuration Partitons
sdcard -> /dev/block/mmcblk0p32
Userdata-> /dev/block/mmcblk0p31
CHANGE
sdcard -> /dev/block/mmcblk0p31
Userdata-> /dev/block/mmcblk0p32
------------------------------------------------------------
Is it correct? ADB Shell or Terminal?
unmount /sdcard/
unmount /Userdata/
mount -o rw /dev/block/mmcblk0p32/ /userdata/
mount -o rw /dev/block/mmcblk0p31/ /sdcard/
And reboot smartphone?
/system/init/init.rc?
------------------------------------------------------------
Sorry my bad english...
ConceptBR said:
In my case I need an even simpler solution ...
Using TWRP formatted "SD 0" as EXT4.
I managed to UnMount "/DATA" and "/sdcard".
I would like to reverse the mounts.
Partitioning modifies the structure of partitions.
Mounting is by software changes and safe.
The solution will allow any time to install the ROM Stock since the structure of the partitions will not be changed.
As in TWRP Terminal can ride correct partitions?
if I'm wrong then correct me, please ...
Device Configuration Partitons
sdcard -> /dev/block/mmcblk0p32
Userdata-> /dev/block/mmcblk0p31
CHANGE
sdcard -> /dev/block/mmcblk0p31
Userdata-> /dev/block/mmcblk0p32
------------------------------------------------------------
Is it correct? ADB Shell or Terminal?
unmount /sdcard/
unmount /Userdata/
mount -o rw /dev/block/mmcblk0p32/ /userdata/
mount -o rw /dev/block/mmcblk0p31/ /sdcard/
And reboot smartphone?
/system/init/init.rc?
------------------------------------------------------------
Sorry my bad english...
Click to expand...
Click to collapse
In theory it should work. I've tried it but it didn't come up right for me. I suspect the line in fstab.qcom for the user data that I've replaced (/devices/platform/msm_sdcc.1/mmc_host/mmc0).
I think we should replace
/dev/block/platform/msm_sdcc.1/by-name/userdata
with
/dev/block/platform/msm_sdcc.1/by-name/sdcard
and of course format sdcard as ext4.
I see no reason why it shouldn't work. Probably I'll try it again in a few weeks, when I'll have some spare time ...
So for this to work the fstab.qcom needs to look like this:
#TODO: Add 'check' as fs_mgr_flags with data partition.
# Currently we dont have e2fsck compiled. So fs check would failed.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
/dev/block/platform/msm_sdcc.1/by-name/boot /boot emmc defaults recoveryonly
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/platform/msm_sdcc.1/by-name/sdcard /data ext4 noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc,journal_async_commit,errors=panic wait,check,encryptable=/persist/footer
/dev/block/platform/msm_sdcc.1/by-name/sdcard /data f2fs rw,nosuid,nodev,noatime,nodiratime,inline_xattr wait,formattable,check,encryptable=/persist/footer
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 noatime,nosuid,nodev,barrier=1,data=ordered,noauto_da_alloc,journal_async_commit,errors=panic wait,check
/dev/block/platform/msm_sdcc.1/by-name/cache /cache f2fs rw,nosuid,nodev,noatime,nodiratime,inline_xattr wait,check
/dev/block/platform/msm_sdcc.1/by-name/FOTAKernel /recovery emmc defaults defaults
/devices/platform/msm_sdcc.1/mmc_host/mmc0* auto auto defaults voldmanaged=sdcard0:31,nonremovable,noemulatedsd
/devices/platform/msm_sdcc.3/mmc_host* auto auto nosuid,nodev voldmanaged=sdcard1:auto,encryptable=userdata
Great job! It's usable?
Option58 said:
Guys, devs are apparently working on unifying partitions. That's the best solution.
It is already working on Xperia T. So it is possible on Xperia L as well.
Let's just wait and see for now.
IMO This is actually top priority for Xperia L lol other that this the device is working just fine.
Click to expand...
Click to collapse
That's great, but what are people who can't use SD cards are supposed to do? Where will they store their data?
stuckbootloader said:
That's great, but what are people who can't use SD cards are supposed to do? Where will they store their data?
Click to expand...
Click to collapse
Want to hear my advice? Install ROM that gives you most data space, I don't know which ROM that is. And use your device as-is until you buy new one. You could also replace your motherboard.
I know this is not xda-spirit like, but I have to say give up messing with your existent motherboard before you hard-brick your device, I destroyed mine. Had to buy new device. Xperia L can be hard-bricked if you mess with partitions.
stuckbootloader said:
That's great, but what are people who can't use SD cards are supposed to do? Where will they store their data?
Click to expand...
Click to collapse
In Xperia T, i think what @Adrian DC use a sdcard emuled for this...
Option58 said:
Want to hear my advice? Install ROM that gives you most data space, I don't know which ROM that is. And use your device as-is until you buy new one. You could also replace your motherboard.
I know this is not xda-spirit like, but I have to say give up messing with your existent motherboard before you hard-brick your device, I destroyed mine. Had to buy new device. Xperia L can be hard-bricked if you mess with partitions.
Click to expand...
Click to collapse
Other Roms? In Galaxy S2 for example, with PIT partitions(other method), all ROMS working today with pits (official cyanogenmod inclusive) . I'm sorry, but, this is the price of testing
Thread closed at OPs request