[X Style (Pure) Android Development] SenK9:
Good news, I found a temporary workaround in the meantime for the bug. Here is how:

STEPS:

1) Flash latest build as normal, don't reboot yet

2) Flash the AOSP Bliss kernel from here (http://downloads.blissroms.com/Bliss/Official/clark/kernel/PureBliss_Kernel_v.1.1.zip), don't reboot yet

2) Flash the attached SELinux script from this post

3) Reboot and no more SDcard corrupt messages

In other words, you need 3 vital ingredients - ROM + Script + Kernel, flash all three zips and you're good to go!

The rest of this post is explanation and detail of my findings, not necessary to read unless you want to know how it works.

--------------

What is the SD card issue?

If you're just joining this thread, this issue occurs when the external SDcard is used in 'portable' mode, not 'combined' mode, from what I gather is the case for most people. On boot, Android sometimes refuses to recognise the card, and displays a '(Brand) SDcard is corrupted. Touch to Fix'. As you can imagine, pressing on this notice will ask you if you want to format the SDcard. DON'T do this. The card is not really corrupted at all, the contents are still there, but Android just can't recognise it. If you roll back to a working ROM, or eject the card and put it into your PC, you'll see the contents there. This happens regardless whether the internal storage is encrypted, or whether you have passcode, etc, those are irrelevant. It's a permissions issue, see below.

What did I do to test the workaround?

* Flashed latest build alone = corrupted SD

* Flashed latest build with script = corrupted SD

* Flashed latest build with script + Bliss Kernel = Working OK

Just the ROM + script alone won't work, you need the kernel too, explanation is below! If you are already experiencing corrupted SD message from a previous ROM, you CAN just flash the kernel + script without re-flashing the whole ROM, and it works, I tested this.

I took some screenshots below to show the latest build running and my SDcard working at the same time.

How does it work?

On further digging around, some people in other devices had similar issues also with avc: denied errors on boot. AVC refers to 'access vector cache' which is part of the SELinux component of Android. SElinux is an access-control security feature of the kernel (which by default in Android 5.0+ to enforcing) and has been around on x86 Linux for decades. You can read more about how SELinux is implemented in Android here - https://source.android.com/security/selinux/

The issue I believe occurs because SELinux's default policy is to blanket DENY access to anything that hasn't specifically been whitelisted for access, because safety first. In this case, that includes our poor external storage and that's why everything breaks. As you know, POSIX filesystems already have a specific owner/group/global read/write access, but SELinux adds an additional layer on top of that, which is why many apps have had issues writing to the shared external SD card space (but not their own application storage) since 5.0+. In this case, Android itself is blocked from a misconfiguration of SELinux contexts, that's why it throws an error.

Most custom ROM developers will do tweaks to manually workaround the mappings for different storage mounts to get it all working, Android has dozens of mappings it can be very complex. For users, if it doesn't work, the solution is to set SElinux to permissive (ie. mode 0), not the default enforcing (mode 1). Permissive mode still logs SELinux issues, but it allows normal operations to proceed globally, thus ignoring the contexts.

So to set to permissive, this can be done a number of ways (usually by typing 'setenforce 0') or toggling it in 'Developer Options'. However, this is still not enough, the issue for us is that things are breaking right on boot even before we can do anything. It needs to be set even BEFORE boot (ie. in a recovery script). I found the attached script on another thread somewhere, all it does is run a script that has two lines, you can open up the zip and check for yourself:

#!/system/bin/sh
setenforce 0
echo "0" > /sys/fs/selinux/enforce

This sets SElinux to permissive (mode 0) before the boot has already started. You only need to flash this ONCE after flashing the ROM (since flashing a new ROM resets selinux back to enforcing). It will stay permissive until you flash the next build or another ROM. Easy as pie.

Why is the other kernel required?

For SELinux to be set to permissive, the kernel itself should not have the 'DCONFIG_ALWAYS_ENFORCE=true' config flag set, or should be what's known as an 'insecure kernel', one that's less locked down than stock (see https://source.android.com/security/overview/kernel-security.html). I found that, just by luck, the PureBliss kernel linked at the top, does work with the SElinux disable script. Alternatively, it could be something to do with the SE contexts or fstab that's also defined in the kernel flashable. The kernel flashable contains alot - not just kernel settings, but volume mappings, SELinux settings, memory settings, and more. If you notice BlissROM (where this SDcard issue doesn't happen), has different external SD card path mappings to Temasek, but yet the SE contexts are nearly identical. I think OP Dev can clarify more, I'm not knowledgeable enough in ROM building.

Is it safe to use that kernel?

If you're concerned about whether the Bliss Kernel is safe to use, this is the original thread - http://xdaforums.com/moto-x-style/development/blissful-kernel-t3321658. The download is from the BlissROM site, and they are a big project that builds on top of CM13, very well known in the community and they build for many devices. You can also view the kernel source on their Github repo - https://github.com/TeamBliss-Devices.

As for daily use, the Bliss kernel for all intents and purposes is nearly the same as the stock kernel. Same battery, maybe a bit smoother performance. Might be more IO schedulers or CPU governors. I just use interactive as I would on stock. There should be no big surprises there. By following the steps above, there's basically no difference in day-to-day use. We can't use Frankenclark kernel, as that's designed for stock-based ROMs, not CM-based ROMs.

Can I undo the changes?

If you wanted to re-enable SELinux, just re-flash the latest ROM on top, without flashing the SELinux script. Then SELinux will be re-enabled from then on. OR if you want to do it manually without reflashing the ROM, remove permissive.sh from /system/su.d/, then use 'setenforce 1' at a root prompt and reboot. OR if you want to restore the kernel, then use TWRP to restore just the boot partition from before.

Is disabling SELinux bad?

On a mission-critical server or one that requires high level of security, probably. But on your phone, probably not. The main purpose is to limit the damage to the rest of the system if there's some vulnerability or malicious app that runs loose. Android already uses individual UIDs and GIDs for each app and sandboxes their access to resources, and on top of that, we're running unlocked bootloaders, with a custom ROM, with root access. Chances are you're more technically savvy than the average user and you'll be fine.

It's not an ideal situation, but as a temporary workaround to get the SDcard working properly, it will do the job. This probably explains why the last few builds I'm one of those that didn't have the issue. Each new build, I have a sequence of zips that I always flash: ROM => Kernel => Selinux => Xposed => Adblock => Boot animation.

I'm sure the dev will implement the correct SELinux contexts/domains for SDcard in an upcoming build to permanently fix the issue once and for all, but in the meantime, this solution will fix the SD card issue. Let me know if it works for you, or if you have questions.