[Galaxy S III I9305 (4G LTE + 2GB RAM) Android Deve] p.a.n:
As I see it, the biggest disadvantage of the chroot solution (from the user perspective) is that, there are more files on the system partition (aprox. 10 MiB), but there is still plenty of space left (more than a half in my case with nano gaps). There are also other negatives (boot time, RAM comsumption), but they (AFAIK) are not measurable, so I don`t see absolutely any reason to worry about it. The biggest positive is that you can choose from several RIL versions.

Others also had problems with it, just [MENTION=5361494]Glenn2[/MENTION] has the worst one. I am sorry about that, but I don`t see any reasonable way how to help him :(

Forget how? The problem still exists. I suppose that it is caused by some change in linking between Android 5 and 6. So either we get somehow source code for ks (I don`t see how) or we use some kind of hack - chroot, edit ks on binary level, use it from some other device with official vendor MM support and the same modem board (I tried razorg but without success). There may some other way, but it will be most probably some kind of hack. From all these options I see the chroot approach as the smallest hack. It is standard way to solve this kind of problems on unix systems.

As I wrote, at this moment, I don`t see any reason to do so.

I don`t see anything scary or wrong about chroot. There are more scary things in this (and Android general) - e.g. the proprietary stuff. The whole RIL stuff is a blackbox, only Samsung knows what is does. I don`t mean being paranoid because of possible spying. There is a technical reason to be scared from this - I see a risk of hardware damage. AFAIK it didn`t happen, but it wouldn`t surprise me.

The code still changing, every build is different :)

I`d like that :) That the reason, why I am publishing all my code changes, wrote the build guide, help the people with their builds. Or at least I try to do so, I am not perfect...

Some hints are here, it is linked from OP, but it little bit hidden, I`ll fix that. The best advice I can give you, is - try to understand it. I don`t know what your knowledge about this is, but you can google a lot of information.

Basically yes (if that recovery supports f2fs), but with this approach you loose all your data... Make a backup first, then change the FS and then restore the backup.

The CM and recovery are usually build together. That recovery is part of the installation package, but is not installed unless it is enabled in the developer options. It was somehow mentioned in this thread.

The problem is that TWRP requires lzma compression of the ramdisk, AGNi doesn`t support it and I didn`t manage to force the build system to create boot and recovery ramdisk with different compression. I beleive that it is doable, but simply returning to standard recovery is easier.

Thanks, I could google it, it was just an excuse for not testing it :)

Thanks for opening this problem CM forum. It could be for many reasons. My fix could be wrong, or there may be another bug. [MENTION=5197763]evilracer123[/MENTION] did you do any changes regarding this? Which commit of FM did you build from?

I know about this problem, I probably mentioned it somewhere, I`ll ad a note to OP.

Both? Even mine? Maybe the fix is in the official code now.

It seems to me, that external sdcard access rules are changing in every Android version. I mentioned somewhere in this thread how solved this for Osmand. But I don`t know if it could applied to this problem. On the other hand, this could be something solvable in the application - e.g. cgeo has no problem with reading offline maps from external sdcard. I am planning to investigate what the difference is, but I can`t promise anything.

To the question - it sounds nice, but external sdcard is significantly slower than the internal one.