[ROM] Dirty Unicorns 6.0.1 {Flounder} (09/09/16)

[jhwbg]

For those of you having issues, I strongly recommend you follow @Lar5 instructions.

I use MOB30M vendor and bootloader 3.48.0.0135 if that can be of any help for you. I wiped everything many times. Let it boot for 45 minutes, still no luck. Tried open gapps and the one suggested in this thread, no luck here. So it looks like most of us do it like Lar5 suggest. I love your work, I run it on my 6P without any problems. Perhaps there are different revisions of the N9, maybe bootlooder version can be a problem. I really don't know. Keep up the good work and let's hope someone can find the problem.

 

[12paq]

You guys are doing something wrong then. The build boots fine AND I fixed the issue of root not working.

Make sure you're wiping system, data, cache, and dalvik prior to flashing the ROM and gapps.

I followed these wipe recommendations exactly and everything booted up fine.
I was hoping that this would boot loop so I could pull and post a log for the developers instead of whining, but no, it booted fine.

In TWRP make sure you wipe each partition recommended, especially system.

Also if you have been running a kernel with anything forced or unforced flash that kernel with this ROM.

Glad to be back on DU. Thanks for the build!

 

[jhwbg]

Boot log

Hi, here is the boot log from my N9, I hope it can be of some use.

 

[NYCHitman1]

Hi, here is the boot log from my N9, I hope it can be of some use.

That log doesn't say anything.

 

[jhwbg]

That log doesn't say anything.

Ok, well boot process stops there so no more information get logged.

 

[NYCHitman1]

At this point, it's clear that it's something weird going on with the few of you and your unit(s).

If I were you, I'd backup anything I have on my device and flash back to stock and then go through the motions over again. Somewhere along the way, you did something that is interfering with boot. I don't know if you're using FIRE-ICE kernel, which removes all se-contexts. However, what I mentioned above is what I would be doing if I were in your shoes.

 

[maelfilk]

Anyone has issues with music playback? When screen is off for a long time (like 15-20 minutes) the playback just stops (track progress bar is stuck, if i press play button nothing happens so i have to close and reopen player). Could it be some strange doze behaviour?

Yep, i think it's doze related, cause i was messing with its values and it seems to fine now that i returned everything to default.

 

[jhwbg]

At this point, it's clear that it's something weird going on with the few of you and your unit(s).

If I were you, I'd backup anything I have on my device and flash back to stock and then go through the motions over again. Somewhere along the way, you did something that is interfering with boot. I don't know if you're using FIRE-ICE kernel, which removes all se-contexts. However, what I mentioned above is what I would be doing if I were in your shoes.

I have tested this, full factory restore to Google stock 6.0.1 (MOB30M), booted up fine, then I flashed twrp 3.0.2.0.

I wiped

Dalvik / ART
System
Data
Cache

Installed official from 160610, and waited 20 min. unable to boot.

I wiped

Dalvik / ART
System
Data
Cache

Installed weekly from 160624, and waited 20 min. unable to boot.

I wiped

Dalvik / ART
System
Data
Cache

Installed weekly from 160603, success!

 

[NYCHitman1]

I have tested this, full factory restore to Google stock 6.0.1 (MOB30M), booted up fine, then I flashed twrp 3.0.2.0.

I wiped

Dalvik / ART
System
Data
Cache

Installed official from 160610, and waited 20 min. unable to boot.

I wiped

Dalvik / ART
System
Data
Cache

Installed weekly from 160624, and waited 20 min. unable to boot.

I wiped

Dalvik / ART
System
Data
Cache

Installed weekly from 160603, success!

Don't have an explanation for you. It works (obviously) for myself and many others. I can only go based off of what I can reproduce, which this I cannot.

 

[jhwbg]

Don't have an explanation for you. It works (obviously) for myself and many others. I can only go based off of what I can reproduce, which this I cannot.

I understand, I am just trying to help. I am willing to test stuff if you or someone else get some ideas.

 

[jhwbg]

Kernel

I have managed to boot Official 160610 & Weekly 160624, I flashed DU, then ElementalX 4.14 kernel and last gapps.
I have no idea why this works. Anyone that can explain this for a beginner?

 

[volkerth]

Ok, after jhwbg's and 12pac's posts I tried it the same way: clean flashing DU latest weekly, then the EX kernel, then gapps.: Success!
Can someone explain, why that is working here with another kernel only? The last time I installed EX was on stock. With the DU 10.0 release I switched from stock, no custom kernel, only some low level tweaking (sound).

 

[12paq]

I have managed to boot Official 160610 & Weekly 160624, I flashed DU, then ElementalX 4.14 kernel and last gapps.
I have no idea why this works. Anyone that can explain this for a beginner?

Ok, after jhwbg's and 12pac's posts I tried it the same way: clean flashing DU latest weekly, then the EX kernel, then gapps.: Success!
Can someone explain, why that is working here with another kernel only? The last time I installed EX was on stock. With the DU 10.0 release I switched from stock, no custom kernel, only some low level tweaking (sound).

I'll let the dev maintainers answer for sure, but my best *guess* is it has to do with the consistency needed with the ROM's kernel encryption or SELinux status and your device's existing encryption or SELinux status. I have had this issue before, but I have no idea how these kernels are compiled and why (or if) a custom kernel would help it boot. Curious, because Fire/Ice (which I use) and ElementalX are both different in this regard.
Again, just speculation here.

 

[volkerth]

I'll let the dev maintainers answer for sure, but my best *guess* is it has to do with the consistency needed with the ROM's kernel encryption or SELinux status and your device's existing encryption or SELinux status. I have had this issue before, but I have no idea how these kernels are compiled and why (or if) a custom kernel would help it boot. Curious, because Fire/Ice (which I use) and ElementalX are both different in this regard.
Again, just speculation here.

For anyone who wants to try: Dirty flash worked also for me. Restored my backed-up weekly 06.03 installation, dirty flashed DU weekly 06.24, then ElementalX, then TR Gapps. Booting, no FCs, no errors.

 

[uzi2]

I'll let the dev maintainers answer for sure, but my best *guess* is it has to do with the consistency needed with the ROM's kernel encryption or SELinux status and your device's existing encryption or SELinux status. I have had this issue before, but I have no idea how these kernels are compiled and why (or if) a custom kernel would help it boot. Curious, because Fire/Ice (which I use) and ElementalX are both different in this regard.
Again, just speculation here.

For anyone who wants to try: Dirty flash worked also for me. Restored my backed-up weekly 06.03 installation, dirty flashed DU weekly 06.24, then ElementalX, then TR Gapps. Booting, no FCs, no errors.

This suggests that the issue lies with any changes made to the kernel after 0603, (which was the last build before the June security update).
It is strange that it is only affecting some devices and not others, but at least the devs have a definite pointer as to where the problem lies.

 

[NYCHitman1]

It is strange that it is only affecting some devices and not others, but at least the devs have a definite pointer as to where the problem lies.

I have no control over why it works for some and not others. It doesn't make sense from a logical standpoint. It either should not work across the board or should work across the board. For reasons unknown, it works for some (myself included, as I've indicated numerous times previously) and others not. I have a few dedicated people that I can rely on for testing and none of them have issues.

I don't have much spare time, but when some time does become available -- I'll rebuild the kernel from scratch again.

EDIT: If any of you are interested -- shoot me a PM and I'll send you a boot.img when it's ready.

 

[uzi2]

I have no control over why it works for some and not others. It doesn't make sense from a logical standpoint. It either should not work across the board or should work across the board. For reasons unknown, it works for some (myself included, as I've indicated numerous times previously) and others not. I have a few dedicated people that I can rely on for testing and none of them have issues.

I don't have much spare time, but when some time does become available -- I'll rebuild the kernel from scratch again.

It is very frustrating when you cannot reproduce the issue and equally frustrating for those that cannot fix it.
I'm not sure you need to rebuild the kernel from scratch as the kernel in build 0603 appears to have no issues for anyone.

 

[NYCHitman1]

It is very frustrating when you cannot reproduce the issue and equally frustrating for those that cannot fix it.
I'm not sure you need to rebuild the kernel from scratch as the kernel in build 0603 appears to have no issues for anyone.

It doesn't take long to rebuild the kernel -- I know it sounds like some long winded event, but it won't take more than 20 minutes to get all the ducks in a row and then test.

Previous offer still stands for those of you experiencing problems.

 

[uzi2]

It doesn't take long to rebuild the kernel -- I know it sounds like some long winded event, but it won't take more than 20 minutes to get all the ducks in a row and then test.

Previous offer still stands for those of you experiencing problems.

I have now successfully updated from 0603 to 0624 by using the boot image from 0603.

The issue must be a change to the kernel since 0603

 

[NYCHitman1]

I have now successfully updated from 0603 to 0624 by using the boot image from 0603.

The issue must be a change to the kernel since 0603

See my previous post #1236.