OK, this thread is going to be a work in progress, intended to serve as a reference for the work I've been doing on LVM partition remapping.
My work was done initially on a Find 7, but this should eventually be usable on many other devices (I have the Find 5 and N1 in mind for when I return from vacation). Also, this would not have been possible without the work Steven676 did years ago on the Nexus S, which has been used by all AOSP-derivative projects to support the Samsung Aries (Galaxy S) family for quite some time now.
The current state of things is that the patches are solid and work very well for the system side of things, but there is still a bit of work needed on the recovery side of things. This is due to TWRP having an architectural limitation I need to work on - Whether a device uses emulated storage or not is set at compile time, which is a problem if your design requires automatic detection of configuration at run time.
One of the key design goals here was to support both normal and LVM configurations automatically with a single build that detects which configuration is present on a device at run time.
A second key design goal was that the underlying partition table of the device is not touched in any way. Touching the partition table of a mobile device in the field is a fundamentally dangerous operation, as many partitions contain data that is device-unique or will render a device unbootable if altered. Recovery methods that involve DDing partition images to nonstandard partitions is asking for trouble due to typos... There's no protection against a user typoing the name of a critical partition.
Initially, I'm going to dump the contents of an email I wrote to someone giving them documentation on how to integrate LVM into their project. Over time I'll clean up and reorganize this post, including adding some more links. Also, since this email was written, I've added a LOT of comments to each patch explaining what is going on.
For additional documentation, especially a more user-oriented view of things (such as how to set this up if you want to use it with Omni nightlies) - see the Omni nightlies thread on XDA.
So here goes:
How it's implemented - the complete patch set is at:
https://gerrit.omnirom.org/#/q/topic:find7_lvm - Expect this to periodically change as work on this feature continues (Note: All patches required to support nightly builds of Omni have been merged. At this point, all remaining work that I expect is on polishing up TWRP.)
With the rest of this post, I'll talk about each individual patch and what it does.
https://gerrit.omnirom.org/#/c/9273/ - This is a patch against frameworks/base which adds an alternative to storage_list.xml called storage_list_lvm.xml - The frameworks will choose storage_list_lvm.xml instead of storage_list.xml if the property ro.lvm_storage is set to 1 - The device init scripts will set this property if they detect an LVM configuration.
https://gerrit.omnirom.org/#/c/9207/ - This is an Omni-specific patch. Omni builds for both the Find 7 and OnePlus One (also known as find7op) and both share a common device tree. The LVM patches do not apply to the find7op, so we move init.recovery.rc out of the msm8974-common tree - You likely don't have to worry about this unless you also have a -common tree for find7 and find7op
https://gerrit.omnirom.org/#/c/9276/ - Normal Android kernel ramdisks do not include busybox or any form of shell, making it impossible to run shell scripts without /system mounted. Since we need to run a shell script prior to mounting partitions, we need to add busybox to the ramdisk. This patch does that. For legal reasons you may wish to replace busybox with system/core/toolbox and system/core/sh - I have not tried doing so. If you choose to stay with busybox, you will have to provide the busybox source code in order to comply with the GPL.
https://gerrit.omnirom.org/#/c/9205/ - This adds the LVM binary and LVM configuration file to the ramdisks of both normal boot and recovery. This patch does not actually begin doing anything with the binaries, I separated it out from the other patches as a way to keep things organized so I could start working with the binaries when I began this project. The original source code and documentation for the binary is at https://github.com/steven676/android-lvm-mod
One change I made in lvm.conf that differs from the Samsung aries family (galaxysmtd, fascinatemtd, captivatemtd, etc.) is that I changed the filter line to only allow the userdata and sdcard partitions. This prevents LVM's vgscan from accidentally determining another partition is a physical volume, and also prevents users from accidentally running pvcreate on a critical partition.
https://gerrit.omnirom.org/#/c/9206/ - This is where all of the "heavy lifting" is done. I'm going to work on adding more comments to the init scripts and shell scripts to document them tonight and tomorrow, but I'll try to explain things here.
Android's init system is a bit limited in that it's very difficult to have conditional behavior defined in init.rc - which appears to be why Qualcomm loves to use shell scripts called from init. Similarly, much of the LVM magic happens in three shell scripts (which execute at three different phases within the boot sequence).
In the early-init phase, the two "wait" blocks ensure that the underlying block devices are ready before vgscan/vgchange are called. This will probably slow down booting by a few fractions of a second unfortunately.
vgscan will scan the volumes defined in lvm.conf (in this case, only the userdata and sdcard partitions) for LVM physical volumes. If LVM physical volumes are detected and form a proper volume group, vgscan will create appropriate device nodes. With the configuration I'm using, the device node will be /dev/lvpool/userdata - which consists of a single logical volume that merges the sdcard and physical userdata physical volumes (partitions). The configuration of lvm.conf prevents LVM commands (especially pvcreate) from altering partitions we don't want to alter. If someone accidentally tries to, for example, run pvcreate on the system partition, it will give an error indicating that the partition was not part of the filter.
vgchange will activate the physical volumes detected by vgscan
lvm_init.sh will check to see if /dev/lvpool/userdata exists, and copy fstab.qcom.lvm to fstab.qcom, init.fs.rc.lvm to init.fs.rc, and twrp.fstab.lvm to twrp.fstab if it does. If it does not, it selects fstab.qcom.std, etc.
In the "on init" section, the init script exports all environment variables from init.fs.rc, and creates all storage-related directories and symlinks needed for both configurations (except for when they conflict). lvm_symlinks.sh will create directories/symlinks that must be configuration-specific. Just like lvm_init.sh - it decides what to do based on whether /dev/lvpool/userdata exists
In the "on fs" section - we do an SELinux restorecon on /dev/mapper/lvpool-userdata (/dev/lvpool/userdata would probably work here too). If it doesn't exist, this will fail gracefully without causing any issues.
In "on early-boot" - lvm_setprop.sh uses /system/bin/setprop to set ro.lvm_storage to 0 or 1 depending on the detected configuration. The property service is not available until early-boot - so this cannot be in lvm_init.sh or lvm_symlinks.sh This propery is used by the frameworks/base patch above to determine which storage_list to choose.
At the end of the init.qcom.rc, the fuse daemon for emulated storage is added for all configurations. (I could not figure out a good way to make this conditional based on whether LVM was present or not). In a non-LVM configuration, it runs but is harmless - it maps /data/media (which is empty) to /mnt/shell/emulated (which nothing is looking at due to the environment variables and symlinks set in the "on init" section )
You will probably notice that Omni's standard storage configuration is fairly different from ColorOS - this is due to the way KitKat storage works, but it allowed us to get away without using Oppo's ext4 permissions hacks in our kernel (by remapping permissions instead, in a manner similar to how the emulated storage system works) The way we handle our /sdcard partition does interoperate without issues with the ColorOS approach.
https://gerrit.omnirom.org/#/c/9279/ is a patch specifically for TWRP. TWRP currently determines whether to use emulated storage (/sdcard on /data/media) at build time instead of at run time. Until I have time to fix this, the patch here operates as a workaround. It is similar to the behavior of the fuse sdcard daemon in the previous patch - it maps /data/media to /sdcard whether the configuration is actually emulated storage or not. If the device is not using emulated storage (LVM), mapping of /data/media to /sdcard is still mostly harmless. However it does result in undesirable changes to TWRP's user interface. DO NOT USE THIS APPROACH IN PRODUCTION RELEASES. It's a horrible hack. You'll need to figure out how to properly do /data/media handling depending on whether LVM is present or not based on how your own recovery architecture works.
https://gerrit.omnirom.org/#/c/9281/ adds "raw" sdcard and userdata partition entries to the partition table for the LVM configuration. This allows a user to return their device to a standard configuration by formatting the underlying sdcard and userdata partitions directly, instead of the removelvm ZIP at the beginning of this email. - To be abandoned, this patch was squashed into 9206
FAQ
Q: Coldbird already had repartitioning support. Why did you create this different approach?
A: Even before he started work, I strongly recommended that he not touch the partition table of the device. It's a really bad idea and is fundamentally dangerous. It's pure luck that someone hasn't hardbricked yet. (A number of people have come close.) If you read through his thread and the ColorOS 2.0.2 thread, you'll see that the repartitioning approach fails frequently, and in multiple ways. (Missing partition contents, partition table ending early, etc. The latter is really scary, one person had the process fail at mmcblk0p19 - what if someone else's partition table write operation aborted even earlier?.) Also, nearly everyone that has implemented support for that approach has needed a separate build to support it. (Oppo is the first to manage autodetection.) I also provided him all of the reference information from Steven676's work.
LVM is far safer. The underlying partition table is not touched in any way. Instead, LVM remaps sectors on the fly so that two partitions that are not adjacent to each other on the physical storage appear as a single contiguous partition to the filesystem drivers. Linux has supported LVM for on the order of a decade, if not more. I've been using LVM on my file server since 2006. (Yes, the system is 8 years old and still working other than needing a new power supply after a thunderstorm. Nothing to do with LVM. ) In addition, the lvm.conf configuration used here provides protection against accidental typos causing damage. Undoing the changes is as simple as doing a wipe of /data and /sdcard from any standard recovery and can be done in seconds, not of running a special batch file that runs a bunch of fastboot commands and takes 4-5 minutes. Similarly, the LVM setup process currently described in the Omni thread involves flashing a single ZIP from recovery that takes only 10-15 seconds, and most of that process is flashing an LVM-aware recovery. (The only limitation currently is that the ZIP must be on external storage - USB OTG or MicroSD)
To put it simply, it Just Works. No need to back up a pile of partitions other than /data and /sdcard because those partitions are never touched or altered.
Q: I have a device with a ridiculously oversized /system partition, can I get some of that back for /data?
A: Yes, you can. Add the physical /system partition to the lvm.conf filters and add it to the lvpool when creating it, then create a smaller /system LV out of this big pool. (see updater.sh in device/samsung/aries-common/ of any AOSP-derivative for hints here.) Be careful though - leave enough spare space for growth (new Android versions, etc.) While it should be possible to use some of the LVM tools along with ext4 resize tools to reorganize the LVs without wiping, this is very difficult and you'll probably have to make users wipe /data if you want to alter /system.
*reserved 2*
Nice work, I hope all the patches can be widely used on some other devices and other roms.
systop said:
Nice work, I hope all the patches can be widely used on some other devices and other roms.
Click to expand...
Click to collapse
Yup. I know Andre from PA was working on it last week but I haven't heard from him lately.
My priority when I return from vacation will be fixing up the TWRP side of things. It's working for now, but the user interface on non-LVM configs is a little funky thanks to RECOVERY_SDCARD_ON_DATA being compile time. This has never been a problem before since a single TWRP binary never had to support two different configurations before. I plan on either doing a property-based approach or fstab-based like CWM. (It should be possible for someone to make a CWM build that automatically detects configuration without any modifications to CWM, based on reading the code - but I haven't tried it myself.)
Once TWRP is in better shape, I plan on doing the Find 5 and N1. These will have the challenge of not having a MicroSD slot, so I may have to change TWRP so that it use /tmp instead of /sdcard when doing "adb sideload", or at least gives the user that option.
Good stuff :good: I don't really need it as of yet, but when my new device is provided (warranty) I will surely give this a try.
I hope ayysir will merge the LVM support very soon ^^
Find 7u PA 4.6 beta 1
Awesome work mate. I have avoided other methods because I'm always the guy that will have a device fail at very bad timing; like during boatloader or SBL stage.
I'm really glad you have continued to work on this. I have hit thanks a few times but would also like to thank you here
tork987 said:
I hope ayysir will merge the LVM support very soon ^^
Find 7u PA 4.6 beta 1
Click to expand...
Click to collapse
He had issues with merging support, hopefully now that I've added more documentation he can try again.
how are the *.std files created?
atm this is tough for me to port from omni to cm base which AOSPA Oppo trees
ayysir said:
how are the *.std files created?
atm this is tough for me to port from omni to cm base which AOSPA Oppo trees
Click to expand...
Click to collapse
the std files are also part of the device tree
https://github.com/omnirom/android_device_oppo_find7/tree/android-4.4/configs
ayysir said:
how are the *.std files created?
atm this is tough for me to port from omni to cm base which AOSPA Oppo trees
Click to expand...
Click to collapse
For the fstabs - they are simply moves/renames of the fstab files and other storage-related items from the standard Oppo configuration (they should appear as renames/moves in the Gerrit commit...)
For the init.fs.rc file - all of the "export <blah>_STORAGE" lines from init.qcom.rc/init.find7.rc are cut out of the RC file and put into .std
Obviously, the .lvm versions of the files are the ones where the fstab has been altered to support a single data partition with emulated storage.
Amazing work and amazing posts. Thanks a lot for your sharing. ?
I've got a question related to your configuration (/data and /sdcard merged) : are the LV hot-resizables?
Wendigogo said:
Amazing work and amazing posts. Thanks a lot for your sharing. ?
I've got a question related to your configuration (/data and /sdcard merged) : are the LV hot-resizables?
Click to expand...
Click to collapse
In theory, you could probably use some of the ext4 resizing tools to do something like this, but I haven't looked into it as there isn't much point in the current config (since the LVM userdata volume is allocated to use all space on the volume group).
Something like that might be more useful if someone ever uses LVM to regain some of the wasted /system partition space on certain excessively bloated devices (like some GS4 units).
Entropy512 said:
In theory, you could probably use some of the ext4 resizing tools to do something like this, but I haven't looked into it as there isn't much point in the current config (since the LVM userdata volume is allocated to use all space on the volume group).
Something like that might be more useful if someone ever uses LVM to regain some of the wasted /system partition space on certain excessively bloated devices (like some GS4 units).
Click to expand...
Click to collapse
Thanks for your answer.
Seems I misunderstood the way it's implemented here. All space is allocated to /data? So there's no more internal sdcard right?
But in that case an external sdcard is mandatory. How is it managed when there's no sdcard?
Enjoy!
Wendigogo said:
Thanks for your answer.
Seems I misunderstood the way it's implemented here. All space is allocated to /data? So there's no more internal sdcard right?
But in that case an external sdcard is mandatory. How is it managed when there's no sdcard?
Enjoy!
Click to expand...
Click to collapse
Android has supported emulated storage (where /data/media is mapped to /sdcard with a special FUSE daemon that makes /sdcard have DOS-like permissions despite an underlying ext4 partition) since ICS. It's pretty much the standard in all new devices - the Find 7 is to my knowledge the only device launched in 2014 not to use emulated storage. Most devices in 2013 also did - Oppos were again the rare exception.
As I understand it - for some reason Chinese users prefer the legacy pre-ICS partitioning scheme. My guess is due to UMS vs. MTP - MTP is required for access to emulated storage, UMS can't be used, but a lot of older desktop OSes have issues with MTP. So Oppo finds themselves in conflict between their home market (China) and expanding in the West. That said, the Find 7 was kind of a screwup in achieving this goal, since the internal sdcard partition was ext4 which meant UMS was a no-go for it.
Entropy512 said:
Android has supported emulated storage (where /data/media is mapped to /sdcard with a special FUSE daemon that makes /sdcard have DOS-like permissions despite an underlying ext4 partition) since ICS. It's pretty much the standard in all new devices - the Find 7 is to my knowledge the only device launched in 2014 not to use emulated storage. Most devices in 2013 also did - Oppos were again the rare exception.
As I understand it - for some reason Chinese users prefer the legacy pre-ICS partitioning scheme. My guess is due to UMS vs. MTP - MTP is required for access to emulated storage, UMS can't be used, but a lot of older desktop OSes have issues with MTP. So Oppo finds themselves in conflict between their home market (China) and expanding in the West. That said, the Find 7 was kind of a screwup in achieving this goal, since the internal sdcard partition was ext4 which meant UMS was a no-go for it.
Click to expand...
Click to collapse
I've got it now. Thanks for your explanations
I saw that Oppo phones didn't follow Android guidelines (yet?) by not using the emulated_storage mounting method but I didn't know why.
And your right, mtp doesn't work in Windows XP (or is hard to make working) and there's a lot of Asian people still using it. Obvious once you said it...
And that's also why only external sdcard is accessible in UMS mode in recovery.
Thanks again for your enlightenment. ?
Reading some of the comments on G+ it looks like Oppo might be using this solution for their KitKat release. I would be so pleased if they did.
Sent from my X9076 using Tapatalk
kishd said:
Reading some of the comments on G+ it looks like Oppo might be using this solution for their KitKat release. I would be so pleased if they did.
Sent from my X9076 using Tapatalk
Click to expand...
Click to collapse
You could be pleased...
Wendigogo said:
You could be pleased...
Click to expand...
Click to collapse
Had some problems with camera focus on earlier versions of omnirom for find 7. Now those have been addressed. I installed Omni and am on the nightlies with lvm. My find 7 and find 7a will not see another rom again.
Related
WARNING:
Use this on your own risk! I will not be held responsible for any failure that might be caused by using this.
"How should I know if it works? That's what beta testers are for. I only coded it."
- Linus Torvalds
What:
Yet another attempt at breaking free from RFS on the SGS phone (ie, lagfix), for Eclair, Froyo, and hopefully Gingerbread...
Which:
Supported devices are I9000 ATM. Theoretically it should work on all SGS variants, but since I only have I9000 to test on, I can't confirm this. I'd appreciate if other model owners will give it a try and report back.
Why:
KISS. I don't want to compile my own kernel or use a specific kernel (see voodoo) for my lagfix. I'd like to have a lagfix for ANY kernel out there.
z4mod is the 1st attempt in achieving that.
Another issue is standards. We don't need multiple lagfixes, all doing the same thing. One method, easy to customize and implement - thats the way to go.
How:
1. Use the online z4mod patcher to patch your kernel.
2. Download and apply one of the following update.zip files to convert your /data partition to the filesystem of your choice.
z4mod update.zip variants:
z4mod.ext2.update.zip - convert to ext2 - works on ALL kernels.
z4mod.ext3.update.zip - convert to ext3 - works only on modified kernel which supports ext3.
z4mod.ext4.update.zip - convert to ext4 - works only on modified kernel which supports ext4.
z4mod.auto.update.zip - automatically find which fs are supported by the kernel and convert to best suited - works on ALL kernels.
z4mod.rfs.update.zip - convert back to RFS - works on ALL kernels..
These update.zip files can be applied only to kernels which has been patched with z4build - a shell script which patches zImage to allow the init scripts additional non-RFS mount to each RFS partition, or with our online z4mod patcher. If the ROM you wish to install wasn't originally patched with z4build already, you can run z4build yourself on the zImage from the ROM package and put the patched zImage back to the ROM package for flashing, or use the online z4mod patcher to do it for you. It is that easy.
[NOTE:] Kernels (zImage) patched by z4build supports both mounts - RFS and non-RFS. So it doesn't change anything for users who doesn't apply z4mod.
You can also patch your z4mod scripts to enhance it's functionality, add more filesystems support, etc.
Although z4mod allows converting all the partitions from RFS to ext2/3/4, our update.zip files only convert /data - since this is ment for the 'masses'. If you feel brave enough, feel free to experiment with converting more partitions. All the sources are well documented.
Who:
z4ziggy, aka Elia Yehuda.
___
Original post [for reference]:
Although this is a half-baked project and far from complete, im introducing it to the xda community so i might get more ideas, and fix/implement more functionality, as the project advances.
z4mod is the 1st step in breaking free from RFS death grip - or at least tries to achieve this. The project adds ext3 support to a given zImage's init scripts, and creates update.zip for converting all RFS partitions and flash the patched zImage.
...thats the idea anyway.
ext4 support is planned for future official release. for testings purposes ext3 is sufficient.
sources and information can be found on my blog here: http://z4ziggy.wordpress.com
And of course, I'm not the only one interested in your measurements and conclusions
This looks really awesome, I'm loving it!
As far as the kernel patch goes, though:
Does the same kernel patch work for both 2.1 and 2.2 kernels? They seem pretty different.
Instead of requiring a linux box to patch the kernel, do you see any problems with doing the actual patching on the stock device itself? I didn't see anything in the script that should make this too difficult.
At any rate, this looks like The Solution.
love the work all 3 of you are doing with the file system on the i9000!
awesome job.
the patch is for the initscripts only - doesn't mind which kernel version. im doing my testings on Froyo 2.2 but patching should work the same on 2.1 scripts.
I hope to have some time later tonight to update the updater-script to follow all RFS partitions, and test it. ATM it works with my /cache partition only since its easy for testings (or "crashes" should i say? ).
i will update soon.
[edit]
regarding the linux part - no can do. We patch the initramfs scripts (which resides in the zImage), and i don't know of an easy way todo so from recovery mode. The easiest way is to use linux (even in a WM - you don't even need a full blown desktop, just CLI and compile tools) and patch the zImage, but i saw some Windows tools who might be able to do the same - I don't really know since i hardly use windows.
Thanks for your efforts! Keeping a close watch on this thread
z4ziggy said:
the patch is for the initscripts only - doesn't mind which kernel version. im doing my testings on Froyo 2.2 but patching should work the same on 2.1 scripts.
I hope to have some time later tonight to update the updater-script to follow all RFS partitions, and test it. ATM it works with my /cache partition only since its easy for testings (or "crashes" should i say? ).
i will update soon.
[edit]
regarding the linux part - no can do. We patch the initramfs scripts (which resides in the zImage), and i don't know of an easy way todo so from recovery mode. The easiest way is to use linux (even in a WM - you don't even need a full blown desktop, just CLI and compile tools) and patch the zImage, but i saw some Windows tools who might be able to do the same - I don't really know since i hardly use windows.
Click to expand...
Click to collapse
That's what rooting your phone is for! Just root the device, copy over all of the required binaries (arm statically linked if required, but busybox should handle 99% of what you're using in the script) and the kernel itself can be easily exacted using dd, of course.
Whole thing can be wrapped in a UI using java without too much hassle as well.
Most users aren't gonna be up to installing linux in a VM to run the script!
just replacing those scripts on your system won't do. you need to patch the initramfs and flash zImage back.
repackaging zImage with a new initramfs is not that simple. I'm using kernel_repacker todo so.
im sure there must be a better way than kernel_repacker, but until then, this is what we use
and about the Linux usage - the user would probably never use z4build script. only the update.zip. Modders, ROM creators, etc, should use z4build (or similar method to add the appropriate "mount ext3..." command to the "mount rfs", as i showed in my blog) to allow their kernel to support ext3. Simply apply z4build on any rom's zImage, and it's users can now apply the update.zip to have this rom' work with ext3.
I hope this explanation is suffice.
z4ziggy said:
just replacing those scripts on your system won't do. you need to patch the initramfs and flash zImage back.
repackaging zImage with a new initramfs is not that simple. I'm using kernel_repacker todo so.
im sure there must be a better way than kernel_repacker, but until then, this is what we use
and about the Linux usage - the user would probably never use z4build script. only the update.zip. Modders, ROM creators, etc, should use z4build (or similar method to add the appropriate "mount ext3..." command to the "mount rfs", as i showed in my blog) to allow their kernel to support ext3. Simply apply z4build on any rom's zImage, and it's users can now apply the update.zip to have this rom' work with ext3.
I hope this explanation is suffice.
Click to expand...
Click to collapse
Ah... kernel_repacker uses GCC. That would be pretty hard to port over to the SGS's stock kernel I guess.
Guess you're right then - would have to be run externally to the device. Bit of a shame since it adds to the complexity of the whole thing, still.
This does make it nice and quick to patch up any kernel at all though, which should make it much easier to keep the kernel patching up with any leaked kernels that come out!
looks like a very promising project! i liked voodoo but sadly we can not use it for 2.2 until we get the sources and it only converts the /data partition...
thanks for your work and i will be sure to check back here & on your blog soon
z4ziggy said:
Although this is a half-baked project and far from complete, im introducing it to the xda community so i might get more ideas, and fix/implement more functionality, as the project advances.
z4mod is the 1st step in breaking free from RFS death grip - or at least tries to achieve this. The project adds ext3 support to a given zImage's init scripts, and creates update.zip for converting all RFS partitions and flash the patched zImage.
...thats the idea anyway.
ext4 support is planned for future official release. for testings purposes ext3 is sufficient.
sources and information can be found on my blog here: http://z4ziggy.wordpress.com
Click to expand...
Click to collapse
Did you manage to compile ext3 or ext4 support to Froyo kernels? I only found ext2 support in them. (At least in JPK)
Another thing I see that you mount the rfs file on the device, but for me it only got mounted as vfat, so the symlinks in /bin in factoryfs.rfs were gone. (I solved this issue by adding commands to the initramfs that restore these symlinks)
ext3 is built into 2.2 kernel, i assumed the same for 2.1.
ext4 module will have to be rebuilt for each kernel, unless we build a standard kernel with ext4 support built-in, but all this will have to wait until samsung releases the sources.
[EDIT:]
Don't use the method which mounts the rfs files on the device. It uses ext2 and its obsolete already. I've only used the rfs mount on the device since it is the only way to have RFS readable as RFS and not as FAT. if your device mounted the RFS images as FAT, either:
1. you didnt use busybox mount
2. you might need to supply "-t rfs" to your mount command
z4ziggy said:
ext3 is built into 2.2 kernel, i assumed the same for 2.1.
ext4 module will have to be rebuilt for each kernel, unless we build a standard kernel with ext4 support built-in, but all this will have to wait until samsung releases the sources.
[EDIT:]
Don't use the method which mounts the rfs files on the device. It uses ext2 and its obsolete already. I've only used the rfs mount on the device since it is the only way to have RFS readable as RFS and not as FAT. if your device mounted the RFS images as FAT, either:
1. you didnt use busybox mount
2. you might need to supply "-t rfs" to your mount command
Click to expand...
Click to collapse
I know ext4 is missing, but I couldn't even get ext3 to work on JPK. (ext2 works)
for the mounts:
1. I did use busybox mount (using toolbox mount I couldn't even mount it in vfat mode)
2. I did supply -t rfs, but it told me invalid parameter
Some additions:
When I try to mount factoryfs.rfs in rfs mode it won't work (invalid argument). in vfat mode it works, but no symlinks and other rfs stuff. I can also mount it in j4fs mode, where I get some files not available in vfat mode (like param.blk or charging.jpg), the strange thing is these files are actually the same as in /mnt/.lfs
RyanZA said:
Most users aren't gonna be up to installing linux in a VM to run the script!
Click to expand...
Click to collapse
There's an easier workaround for that.
Provide instructions to:
- Copy required files to USB stick
- Download Ubuntu Live CD
- Boot from CD
- Run scripts
If you wanted to get fancy it could be prepackaged into an existing bootable CD distro with the scripts included (checking for updates when they're launched).
From what I've read, Desire owners used bootable CDs to root their phones, so it's obviously a viable option for the standard user.
Alright, that's the extent of my expertise. I'll leave you guys to sort out the real issues now!
I'm also very interested in this so subing myself to this thread.
I quite like the fact you Windows users have to use a Linux install to do it, I get a bit fed up having to find a Windows box somewhere to use Odin and Kies all the time.
RyanZA said:
Most users aren't gonna be up to installing linux in a VM to run the script!
Click to expand...
Click to collapse
Why? Surely the people wanting to do this kind of thing will be the more technical users anyway and us Linux users have to do the more difficult task of installing Windows in a VM to use the normal tools.
my ct-ng seems to be broken, my binaries doesn't execute on my SGS for some reason, so this will have to wait for tomorrow so I can investigate this further.
I need to compile the mkfs.ext3 staticly (which seems to compile fine using several different toolchains, but none works) so i can execute it from z4mod/updater-script.
dirk1978 said:
Why? Surely the people wanting to do this kind of thing will be the more technical users anyway and us Linux users have to do the more difficult task of installing Windows in a VM to use the normal tools.
Click to expand...
Click to collapse
Not true at all!
z4ziggy said:
my ct-ng seems to be broken, my binaries doesn't execute on my SGS for some reason, so this will have to wait for tomorrow so I can investigate this further.
I need to compile the mkfs.ext3 staticly (which seems to compile fine using several different toolchains, but none works) so i can execute it from z4mod/updater-script.
Click to expand...
Click to collapse
I've had so much trouble with statically compiling stuff...
We really need some kind of complete guide on all the ins and outs of statically compiling these system utilities. For a lot of them it doesnt seem to be all that straight forward...
i've a question
i've tried to mount the partitions as ext2/3 before by replacing the rfs in init.rc and recomplied the kernel and pack the zimage, but the system wont boot. it seems it wont accept any other fs other than rfs, rootfs, etc. my init.rc looks like this:
mount ext2 /dev/block/stl9 /system
so how did u simply mount them as ext3 by just changing the init.rc and recompile the kernel?
EDIT: sorry, i just tried it again and it's ok now, but not with the "||" (or) in the middle
I have been following the xda-developer website for awhile now, as I have a KIN 2m of my own and I have been interested in finding a way to root or replace the current OS with a new one. Since I haven't seen anymore progress with the phone itself, I decided to do some digging and see what I could do myself (I am a programmer and IT Specialist). What I found might be helpful.
According to other posts, and what is floating around the internet, the KIN 2m flash memory is based on the Samsung MoviNAND 8G architecture. The chip itself is the Samsung MoviNAND KLM8G4DEDD-B101 which supplies 8GB of flash memory to the phone. Since this is also a Flash based NAND memory, I decided to investigate into the actual filesystem (FS) which makes up the chip and which WindowsCE 6.0 is based.
Apparently, this particular NAND memory is based on the YAFFS2 (Yet Another Flash File System rev2.0) which supports both little- and big-endian (32 and 64-bit architecture and some 16-bit systems), respectively. Also, the operating systems that are built on this particular FS are WindowsCE, Android, Linux, pSOS, eCos, and ThreadX.
Going off what I had found, I discovered that with regard to WindowsCE in particular, there are four different parts to the KIN NAND set-up: A Portable YAFFS "Core", a YAFFS Direct Interface, the WindowsCE wrapper, and then of course the WindowsCE OS itself. For WindowsCE, the WindowsCE wrapper accesses the YAFFS Direct Interface, not the core directly. In order to write instructions to the NAND and the "core", a set of instructions in three different types are necessary. These types are a POSIX Application Interface, an RTOS Integration Interface, and finally Flash Configuration and Access Interface. I have attached (and pasted) below a diagram of the above description and I have attached a document which was provided by yaffs.net which also covers some of these details.
View attachment 1461518
The POSIX Application Interface allows execution of application code to access the filesystem. These commands that are executed are typically open, close, read, write, etc. The RTOS Integration Interface consists of functions which allows for YAFFS to access the RTOS system resources. The commands are things like lock, unlock, initialize, get time, set error, etc.. Finally, we have a Flash Configuration and Access Interface which allows YAFFS to access the NAND directly and it executes commands such as initialize, read chunk, erase block, etc.)
So this is what I have discovered so far, and I am currently working on seeing where I go from here. I am currently trying to mount my KIN and browse it as a YAFFS filesystem on my computer, and once I do that, I am thinking that I might be able to execute instructions to access the ROM and NAND chip. On the YAFFS.net website there are a lot of good documents on how this FS works and how commands are executed. I am currently trying to read all I can and see if there is anything I can do.
And the plus side is, after all of this digging and experimenting...my KIN still works!!
very interesting.
wouldn't instructions be executed on the ARM?
http://en.wikipedia.org/wiki/ARM_architecture#Instruction_set
the trick would just be getting something on there and running...
Edits:
actually we may have already found a way to execute. it involves XNA or Silverlight and its on these forums somewhere. now compiling something...
must note that this could probably end very poorly.
so how we write android to NAND?
http://source.android.com/
BOOM
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0290g/DDI0290G_arm1156t2fs_r0p4_trm.pdf
if we can access a console on the actual kin device we can compile code. now, how exactly we could do that is a mystery to me. the kinOS is running on top of windows CE kernel, so there may be one in there...
that console would be "run23"
http://support.microsoft.com/kb/194302
http://developer.download.nvidia.com/tegra/docs/tegra_250_hw_setup.pdf
check out page 12. to put the kin in recovery mode, you hold u+s+b+power.
also relevant
http://forum.xda-developers.com/showthread.php?t=894130&page=2
BOOM
infocenter.arm.com/help/topic/com.arm.doc.ddi0290g/DDI0290G_arm1156t2fs_r0p4_trm.pdf
if we can access a console on the actual kin device we can compile code. now, how exactly we could do that is a mystery to me. the kinOS is running on top of windows CE kernel, so there may be one in there...
that console would be "run23"
support.microsoft.com/kb/194302
Click to expand...
Click to collapse
That is a good thought. However, according to what I have found, there is no reason to go looking for a console on the device itself with which to compile/execute code. What I have found, to date, is that because the device is a YAFFS filesystem, if we have the correct drivers installed on our host machine (which can be gained from the internet), we can mount the device as a drive and using Command Prompt on the host machine we can compile and execute the code from there. We can use the commands NVFlash, mount, write, flash_eraseall, etc.
Sorry if this doesn't seem to make an sense at the moment...I am trying to multitask, and I believe I am failing miserably. I will hopefully have more information later.
IT_Tech said:
we can mount the device as a drive and using Command Prompt on the host machine we can compile and execute the code from there. We can use the commands NVFlash, mount, write, flash_eraseall, etc.
Click to expand...
Click to collapse
ooh, that's a good one. i think JohnKussak was doing something like that using the NVidia tegra toolkit, but he was not able to connect for some reason.
http://forum.xda-developers.com/showthread.php?t=894130&page=2
now, from what i understand of YAFFS (which is admittedly very little) it's just a partition of the memory right? or is the YAFFS system on a completely separate piece of memory?
i was reading about the MPU (memory protection unit) in the ARM manual and it described the layout of memory. basically it supports up to 16 blocks, all with 32 bit addresses (4294967295 bytes = 4gb). since there's 8 gb of storage on the kin, it can probably be assumed that 2 of those blocks are used for storage. another block is probably for RAM (256mb). now, the YAFFS system has to be accessible to the ARM somehow (maybe), so there are several possibilities.
1) the YAFFS file system is on a partition of the 8gb storage space
2) the YAFFS file system is on a partition of the 256mb RAM (pretty sure this isn't the case)
3) the YAFFS file system has its own block of memory
regardless, the MPU can be disabled. when it's disabled, no permissions are checked (ever) and we can read/write anywhere we please, including the YAFFS, wherever it may be. i'm not totally sure this is necessary, but i know we've had problems accessing system folders in the past. i suspect disabling the MPU could fix that, if we could manage.
i also suspect that the YAFFS is accessible when the phone is in recovery mode (u+s+b+power), we just need the correct drivers to flash a Tegra 2600 APX chip. i believe i read on the tegra thread that somebody couldn't find that particular driver. it may need to be written.
edit:
just found this https://developer.nvidia.com/tegra-2-technical-reference-manual
you have to apply for access and it can take up to a month i guess. i'm working on that right now. the main item of interest is "16.0 NAND Flash Controller". i'm gonna try looking in some shady places and see if i can't dig that up...
double edit:
just realized that tegra 2 is different than tegra APX, NVidia does not offer an APX manual anymore, if they ever did.
triple edit:
ooooookay. http://viewsonic-gtablet-for-dummies.webs.com/nvflash.htm
just grabbed source for drivers. unfortunately, NVflash does not run on 64 bit systems, which is causing a bit of problems for me...
slimeq said:
now, from what i understand of YAFFS (which is admittedly very little) it's just a partition of the memory right? or is the YAFFS system on a completely separate piece of memory?
Click to expand...
Click to collapse
From what I understand, YAFFS is a partitioning system. It does not need to be stored as a separate system on a separate piece of memory. However, it does also have the capabilities to be partially RAM based... Which may end up confounding things. If you get a chance, you may have done this already I don't know, but read up on the YAFFS file system on the yaffs.net website--it has a ton of documents on how the system works and the commands it executes, its architecture, etc.
slimeq said:
i was reading about the MPU (memory protection unit) in the ARM manual and it described the layout of memory. basically it supports up to 16 blocks, all with 32 bit addresses (4294967295 bytes = 4gb). since there's 8 gb of storage on the kin, it can probably be assumed that 2 of those blocks are used for storage. another block is probably for RAM (256mb). now, the YAFFS system has to be accessible to the ARM somehow (maybe), so there are several possibilities.
1) the YAFFS file system is on a partition of the 8gb storage space
2) the YAFFS file system is on a partition of the 256mb RAM (pretty sure this isn't the case)
3) the YAFFS file system has its own block of memory
Click to expand...
Click to collapse
Let me begin here and differentiate between YAFFS types...there are two types of YAFFS formatting--YAFFS1 and YAFFS2. The KIN is formatted using YAFFS2 because it has 8g of space. Yaffs2 is different from Yaffs1 in the fact that it allows for memory sizes greater than 4GB because it supports 4KB pages rather than 512byte pages (Yaffs1). I will spare all the details as they are lengthy, but check out:
yaffs.net/documents/how-yaffs-works and yaffs.net/yaffs-original-specification (paying attention to Yaffs2 and how it relates to it foundation off of Yaffs1). Also, since Yaffs only uses a RAM based system for emulation purposes when the kernel is not being run on a true NAND (or NOR) storage, we can eliminate Option 2. Option 3, may be viable, but I am not sure as to how. Option 1 seems to make the most logical sense (pun intended), because of how the YDI (YAFFS Direct Interface) works with the YAFFS kernel and filesystem, as well as the WindowsCE Wrapper, etc.
Now as for the MPU. Yaffs has a built in code to handle MPU and a way to disable it through a console session on a host machine, but I don't remember where I read it, I believe it was on the yaffs.net website in one of the technical documents... I will work to remember where I found it.
I hope we can get some more people on-board helping with this YAFFS thing. If we could, it might make this go a bit faster, and have more heads working on it. Plus they might see something we don't.
P.S: These are the HARDEST captchas I have ever seen in my entire life!
kin
Hopefully you get access to the filesystem with this IT_Tech :fingers-crossed:
Every once in a while, it's fun to revisit Dev on the Kin
I remember going through the Tegra 2500 APX links on the wayback machine:
http://web.archive.org/web/20100813070722/http://www.nvidia.com/object/product_tegra_apx_us.html
If you click the Specifications tab, you can see that the 2600 and 2500 are virtually identical, aside from some video features.
Also, the ZuneHD is the only other product listed as using the 2500 chip. I don't have one, so I wouldn't know for sure, but I wonder if its drivers could be tweaked to allow access to the Kin, in the same way as the Zune. I remember trying to hack into other Windows Mobile drivers (for other WinMo 6.x devices I have) but never getting anything further, even when in other USB modes on the device.
Hiya Folks,
Long time listener, first time poster.
I have a few questions:
a) Tiny, thanks a lot for your CM10.1+evervolv device tree builds, these are awesome. One question for you: Is there any chance you might be willing to post a short changelog when you post new builds? I understand that's a bit of an administrative headache, but it would be really nice to be able to get a sense, at least on a coarse level, as to what's new in each build... (ie: merged new display driver, picked up CM10.1 changes from x date to x date, explicitly tried to fix x)
b) With the initial jump to these builds, I took a full backup and started over. I've found that for some of the nightlies, I can just wipe caches and install the new OS image and everything seems to work. This, of course, is largely dependent on binary compatibility between sqlite versions, etc and high level compatibility between database schemas. Is there any way you could perhaps give a sense as to whether or not anything has changed that would definitely require a full wipe versus this build contains stuff that probably won't make a difference with each build along with a big disclaimer absconding any responsibility if things go wrong?
c) The camcorder is recording at a very low framerate, this is a known issue. Is there a fix coming down the line any time soon? I'm proficient with both userland and kernel hacking, and know my way around Android's internals pretty well. Do you have any information on what's causing this bug. I might be able to hack around a bit with it, but some sense of the history and the components involved would be helpful. (I have a sneaking suspicion this has to do with the video drivers and the sync to vsync stuff that is new in 4.1)
d) I've long been fascinated by the strange situation involving the scantily documented /datadata partition. My understanding is that this is some kind of faster chunk of hardware flash that is used by application databases with the idea being that it speeds them up. I believe ext4all mod moves the stuff onto the sdcard or regular internal storage and then symlinks. Has anyone considered playing with the Linux bcache module that allows faster storage block devices to serve as a cache over slower storage block devices in the storage hierarchy? I've been thinking about hacking on this myself, but I wanted to see if anyone has considered it and if it would cause problems that I don't see now (I could see it causing a problem with the current way nandroid backups are taken, or something along those lines, for example).
In any event, thanks for listening!
I'll try to summarize a, b, and c.
A. No official change log. I don't have time to write one. I try to post significant changes when I can.
B. I almost never wipe with cm. In theory you can even upgrade from cm10 to cm10.1. Wiping is overrated and its usually only useful to troubleshoot really weird issues.
C. The camcorder lag is likely a software or codec issue. Technically its not a bug but more of optimization issue. Preview glitching I'd call a bug.
Sent from my Galaxy Nexus using Tapatalk 2
a-dub said:
Hiya Folks,
Long time listener, first time poster.
I have a few questions:
a) Tiny, thanks a lot for your CM10.1+evervolv device tree builds, these are awesome. One question for you: Is there any chance you might be willing to post a short changelog when you post new builds? I understand that's a bit of an administrative headache, but it would be really nice to be able to get a sense, at least on a coarse level, as to what's new in each build... (ie: merged new display driver, picked up CM10.1 changes from x date to x date, explicitly tried to fix x)
b) With the initial jump to these builds, I took a full backup and started over. I've found that for some of the nightlies, I can just wipe caches and install the new OS image and everything seems to work. This, of course, is largely dependent on binary compatibility between sqlite versions, etc and high level compatibility between database schemas. Is there any way you could perhaps give a sense as to whether or not anything has changed that would definitely require a full wipe versus this build contains stuff that probably won't make a difference with each build along with a big disclaimer absconding any responsibility if things go wrong?
c) The camcorder is recording at a very low framerate, this is a known issue. Is there a fix coming down the line any time soon? I'm proficient with both userland and kernel hacking, and know my way around Android's internals pretty well. Do you have any information on what's causing this bug. I might be able to hack around a bit with it, but some sense of the history and the components involved would be helpful. (I have a sneaking suspicion this has to do with the video drivers and the sync to vsync stuff that is new in 4.1)
d) I've long been fascinated by the strange situation involving the scantily documented /datadata partition. My understanding is that this is some kind of faster chunk of hardware flash that is used by application databases with the idea being that it speeds them up. I believe ext4all mod moves the stuff onto the sdcard or regular internal storage and then symlinks. Has anyone considered playing with the Linux bcache module that allows faster storage block devices to serve as a cache over slower storage block devices in the storage hierarchy? I've been thinking about hacking on this myself, but I wanted to see if anyone has considered it and if it would cause problems that I don't see now (I could see it causing a problem with the current way nandroid backups are taken, or something along those lines, for example).
In any event, thanks for listening!
Click to expand...
Click to collapse
d) The /datadata partion is just a normal partition but is formated yaffs2, which is a little faster than ext 3 which is what /data and /cache normally use out of the box. However this partition is small, and fills up quickly. The ext4 mods do 2 things, they convert /data and /cache from ext3 to the slightly faster ext4. It also moves all of the files from the /datadata partition and instead placed the files on the /data partition in a data folder. So it still ends up having the path /data/data just as it did before the mod. This leaves the yaffs2 /datadata partion empty and unused.
I havent heard of bcache, so im not sure on that question. If you could get bcache to use the old /data/data partition as cache for the other partitions it might provide better performance. It shouldn't cause backup issues as /datadat is already backed up by nandroid, so all required filed should get backed up. If you get it working, i would definitley check it out.
How to install TWRP in my M30 the has already been updated to android 10. Then where can i get the suitable version of twrp and the steps to install it.
Plzz hepl
device info:
Galaxy M30 SM-M305F
android 10 (OneUI 2)
Exynos 7904
security update version M305FDDU3CSL5
TWRP for 10 is being worked upon. As of now there is no TWRP for 10. Please do not install the earlier TWRP, or you will end in a bootloop.
How long time take to upload twrp for galaxy m30 android 10 (OneUI2)
Plzz sir tell us
TWRP & Android 10
Please note that this post is primary related to TWRP and the Pixel 3 and 4 and devices that may ship in the future that ship with Android 10 as their original version of Android. Older non-Pixel devices that shipped with older versions of Android and receive upgrades to Android 10 are not affected.
Long story short, TWRP support for Android 10 is going to take a while.
Android 10 brings about the largest changes to the way AOSP implements recovery since Google shifted recovery from C to C++ when they moved from Android 4.0 to 4.1 more than 7 years ago. A lot of components in AOSP recovery were moved into subfolders, which makes merging the latest changes into TWRP more time consuming. At least on the Pixel 3, the ramdisk that we use for recovery is now handling part of normal boot in addition to recovery, so we're not sure what the best way will be to go about replacing recovery without affecting the ability to boot up normally. In addition, the way Google is building the ramdisk on the Pixel 3 is a lot different than the past. In the past, the executable binaries in the ramdisk were built as static binaries with no linked libraries. TWRP has almost always been built with separate linked libraries. The new dynamically linked stock ramdisk will make it harder for us to slip TWRP into the ramdisk.
Once we get TWRP compiling with the new changes from 10, we have some additional items that need consideration. As mentioned above, the stock ramdisk is using dynamic linking. Unlike TWRP, the stock ramdisk places the executables and libraries in the usual locations inside a /system folder. Normally TWRP leaves /system alone so that we can mount the system partition to its usual location of /system. If we leave things the way they are on the Pixel 3, mounting the system partition gets tricky. A lot of custom zips depend on mounting the system partition to /system.
Android 10 also introduces a new dynamic partitioning system. Instead of having a dedicated system partition and a dedicated vendor partition, etc. Android 10 uses a super partition. I like to think of the super partition as a partition that contains a bunch of smaller partitions. One of the side effects of this dynamic partition system is that Google has chosen to use a form of the ext4 file system that is for all intents and purposes, read-only. This choice means that even if you wanted to, you can't easily mount and modify the system partition. We haven't really discussed this with other developers yet, but it may impact your ability to do things like install Gapps. In addition, the dynamic partition model means that eventually, we should probably provide you, the user, some GUI driven tools in TWRP to allow you to manage the dynamic partitions that are on the super partition.
On top of all of the above, I, Dees_Troy, am the one who usually handles merges of new versions of Android. My wife is currently pregnant with our fourth child. I am quite busy with my growing family and the need to find a bigger house, so my time for working on TWRP right now is somewhat limited. So, I guess please be patient, or feel free to download the TWRP source code and make the needed changes yourself.
Source
Heya all,
this is one of my first threads here. I recently got an Mi 10T Pro, and after rooting it, I tried to somehow de-bloat it. There's a lot of stuff that I either don't need, or downright don't want in my phone (I'm looking at you Facebook).
Some of the apps I was able to uninstall with a root-level uninstaller, however, as I found out, sometime since... Android 10? The whole /system partition is mounted RO, and apparently can no longer be remounted as RW, so some of the deeper system apps can no longer be so easily removed.
Yes, I know that removing system apps is a risk, don't bring it up, I wouldn't be rooting my phone if I wasn't also willing to tinker with it.
Is there still a way to remove the deeply seeded applications? (For example the "Mi Video" app that resides in /system/app/MiuiVideoPlayer/MiuiVideoPlayer.apk)
You could disable them with some of the debloating methods. You won't gain space on system partition, and it's not really recommended because system partitions today really don't like to be mounted rw because of dynamic partition scheme...
They can be uninstalled with this tool
https://forum.xda-developers.com/t/tool-xiaomi-adb-fastboot-tools.3887359/
calinorg said:
You could disable them with some of the debloating methods. You won't gain space on system partition, and it's not really recommended because system partitions today really don't like to be mounted rw because of dynamic partition scheme...
Click to expand...
Click to collapse
Huh, never heard of that. Is there someplace I could read up on the dynamic partitioning? I am familiar with the way Linux deals with disk partitions, and as that was the same way Android worked before, I am confused now.
nesoler said:
They can be uninstalled with this tool
https://forum.xda-developers.com/t/tool-xiaomi-adb-fastboot-tools.3887359/
Click to expand...
Click to collapse
Thanks! I'll check it out.
Aldenar said:
Huh, never heard of that. Is there someplace I could read up on the dynamic partitioning? I am familiar with the way Linux deals with disk partitions, and as that was the same way Android worked before, I am confused now.
Thanks! I'll check it out.
Click to expand...
Click to collapse
Dynamic Partitions | Android Open Source Project
source.android.com
Basically, dynamic partitioning allows oem to resize partitions as needed without messing up the system, but the downside is that twrp and non-dynamic apps see only one super partition, which contains other partitions inside. Newer twrp builds (3.5.0+ ) have support for dynamic partitions but it's still under development and there's much stuff to consider. Basically, if you make system partition rw and put a file inside, you change it's properties (and size), but in super partition system partition stays the same size and format, so basically you overwrite something, and things get out of hand
That's why only recommended way to change anything in system and other partitions is to make magisk script to do it, because magisk knows how to approach system and other partitions in a way that it won't kill everything...
calinorg said:
Dynamic Partitions | Android Open Source Project
source.android.com
Basically, dynamic partitioning allows oem to resize partitions as needed without messing up the system, but the downside is that twrp and non-dynamic apps see only one super partition, which contains other partitions inside. Newer twrp builds (3.5.0+ ) have support for dynamic partitions but it's still under development and there's much stuff to consider. Basically, if you make system partition rw and put a file inside, you change it's properties (and size), but in super partition system partition stays the same size and format, so basically you overwrite something, and things get out of hand
That's why only recommended way to change anything in system and other partitions is to make magisk script to do it, because magisk knows how to approach system and other partitions in a way that it won't kill everything...
Click to expand...
Click to collapse
Aaah. Yes, thank you for the explanation. It sounds kinda like LVM in Linux - One "Super" partition like a Volume Group with individual partitions like Logical Volumes, able to be dynamically resized, while leaving any of the free space to use for the other partitions.
Ah well, at least I managed to disable some of the apps. Turns out the Xiaomi ADB Tools only really called "pm uninstall --user 0 *package.name*", so nothing special.
Aldenar said:
Aaah. Yes, thank you for the explanation. It sounds kinda like LVM in Linux - One "Super" partition like a Volume Group with individual partitions like Logical Volumes, able to be dynamically resized, while leaving any of the free space to use for the other partitions.
Ah well, at least I managed to disable some of the apps. Turns out the Xiaomi ADB Tools only really called "pm uninstall --user 0 *package.name*", so nothing special.
Click to expand...
Click to collapse
Yes, something like LVM, but it keeps partitions in read-only state, to prevent users from modification. If you change even 1 byte, partition is flagged dirty and not even e2fsck couldn't fix it... basically, until we get proper tools with proper support, messing the partition layout in android is a big no-no...
Yes, XAT is just a frontend for pm uninstall, but it's easier than typing commands, and also it keeps a nice list of uninstalled apps, so you can re-enable them with one click...
cant disable using titanium backup either
paul999 said:
cant disable using titanium backup either
Click to expand...
Click to collapse
As far as I can see, disabling a system app is still possible. Just not uninstalling as that would require a writeable /system partition which currently, as pointed out above, isn't really possible. I even tried the Titanium Backup's exploit method, but didn't work either. App's still installed, albeit disabled.