yashsingh1/xdaforums huggingface dataset:
[SuperR Kitchen] thgxda:
Hi Captain_Throwback,

I don't know, it is just a nightmare :(

Your advise, using AIK, was quite good.

After "fixing" the errors with the "magic"-file, I finally was able to create a new boot.img, including my changes I've done before for getting the init.d working with cm13. I packed all together, copied it to my mobile and installed it.

Yes the new ROM IS running, my modifications are in the "init.cm.rc", "su -" gives me root-access via ADB and "pm list users" is still working, even as root.

But guess what: the "init.d" is not working anymore!

The changes I've made in the "init.cm.rc" where not the reason that I got the "init.d" working with my prior builds, right now, I assume that it was SuperSU that it made working. Unfortunately it seems, that the current version 2.62-3 has still some problems, because after using "su -", commands like "pm ..." or just "logcat" are not working any more.

So right now, I'm done, I have no idea anymore how to get the "init.d" running on cm13, without breaking s.th. else :(

Time is mostly over and I need this by Christmas :(

Any ideas would be appreciated and thanks a lot for all the help,

kind regards,

thgxda
[SuperR Kitchen] Rydah:
Hey [MENTION=5787964]SuperR.[/MENTION] The kitchen is building around 30 errors in the script. A user of mine was able to fix it up. Do I send it to you, both the original and fixed?

Sent From My LG V10
[SuperR Kitchen] SuperR.:
Not sure what you mean, but send original and fixed and I will figure it out :)

edit: oh, I guess you are talking about the updater-script. If so, just the fixed one should be sufficient. Most likely they are missing metadata lines rather than errors. Same thing we just went through with the Samsung wifi, and HTC M8/A9 broken stuff. Just need to add the Manufacturer specific things to the database and we should be good to go. The contexts are pulled from the boot.img so if the line exists in the updater-script it will be the correct context.

edit2: I also guess you are referring to this post

http://xdaforums.com/showpost.php?p=64382044&postcount=188

If so, the best would be to send me the stock updater-script he is referring to.
[SuperR Kitchen] bcrichster:
Both might help for comparisons.. [emoji41]
[SuperR Kitchen] MrEvilPanda:
Note 4 duos error

I tried to deodex my stock 5.1.1 rom on my N9100(note 4 duos) but to no avail. Whichever option i choose i seem to get the following error : block_image_update(): no file "data.new.dat" in package. Status 7 ; Installation aborted.

The rom version is N9100ZCU1COK1, and i am using the latest kitchen. I am using debian 64 bit . Can someone help me.??
[SuperR Kitchen] SuperR.:
The problem you are having is that your rom is trying to flash a file that does not exist in your rom zip - data.new.dat. If you did not add anything to the /data directory in your project, remove user app support and build again. If you did add things to /data, try a different data partition size detection method and make sure data.new.dat exists before trying to flash again.
[SuperR Kitchen] Er. Aditya:
this has never hapened before , just testesd latest kitchen on note 4 G base rom

first simple deodexed rooted rom

i guess root dint made my rom boot , then i flashed custom kernel and it booted

and as soon as it finished booting i got phone fc , splanner fc
[SuperR Kitchen] SuperR.:
The kitchen no longer messes with your boot.img at all when adding root. All the boot mods are performed by SuperSU. Additionally, flashing a new kernel after the new systemless SuperSU will result in not having root. If there is a problem with this method of root for your device, feel free to post on the Experimental systemless SuperSU thread.

If root is not causing your issues, please try to figure out what the last working kitchen version was so I can try to narrow down when the problem started.
[SuperR Kitchen] Er. Aditya:
i dont know what might that be , which version of SU latest kitchen uses ?? 2,62 ?? adn at the end of flashing twrp asks me to install su , i deny as per said by chainfire

your correct i dont have root atm...

i dont remember its been quite some time i made a rom but i have 9.6.6 with il test tomorrow

[MENTION=5787964]SuperR.[/MENTION] edit : here's what i tested

first i made a stock rooted rom but it rebooted again and again bootlooped

then i tried flashing our kernel only and ended up in no root situation

then i flashed su zip 2.62 over our kernel and rebooted and has root as well ,

then i flashed stock kernel alone and it booted again but without root

then i flashed su zip and has root again

so it might be possible kitchen is not being able or something in script

edit 2: i was wrong stock kernel started reboting again n again and when i wiped dalvik n cache it bootlooped... custom kernel works though
[SuperR Kitchen] Captain_Throwback:
Quick question for you, [MENTION=5787964]SuperR.[/MENTION]: Are there any plans to include su.d support to the ROM, as an alternative to init.d for people that choose to root with SuperSU? Or how about an option to use the Open-Source Superuser root method rather than SuperSU? I believe the former includes a sepolicy patcher and a binary that copies to /sbin in the ramdisk, and a Play Store app. More info here.

Also, just flashing a kernel won't remove root, unless that kernel is packed into a boot image that overwrites the rooted ramdisk. Most of the kernel installers I use prefer AnyKernel to prevent such modifications and preserve root. I think all kernel devs should use that method, tbh.

---------- Post added at 12:37 PM ---------- Previous post was at 12:24 PM ----------

The sysinit service shouldn't be set to enabled. However, for it to actually start, you need to either add it to an init class, or start the service directly somewhere in init. That's probably why it wasn't working.

I usually use "class late_start" if using a 5.x+ ROM. If older, you can just add "start sysinit" somewhere so the service gets run once at boot time. Either method should work.
[SuperR Kitchen] Captain_Throwback:
double post (why xda, why?!)
[SuperR Kitchen] sefrcoko:
You should try again with the latest kitchen version which, if i'm not mistaken, has a newer supersu than the one included in the kitchen version you are using.
[SuperR Kitchen] AndroidGX:
Hiya! :good:

Looks like somethings wrong when trying to cook into marshmallow for LG G4, when I choose the following :

Build full ROM Zip with "set_metadata".

The updater-script is well made but right after, it stucks at this message and zip creation is stuck also at 202mb :

------------------------------------------------------
SuperR's Kitchen
by SuperR
------------------------------------------------------

Building agx.zip in simplegx_rom ...

I waited for over 1 hour, but still stuck.

Always have to close kitchen window's. And the zip is just not finalized (can't open it, errors).

Any ideas ?

Here is my zip-log as attachment (maybe it can help?)

Cheers' :cowboy:
[SuperR Kitchen] thgxda:
no, it still includes SuperSU 2.62-3, the 2.64 just was published some hours ago.

Any way to include it by myself?

Thanks a lot,

kind regards,

thgxda
[SuperR Kitchen] Maw2607:
SM-G925F

Hi,

Firstly i'm not a dev but i like make my own rom for my use on my free time. With your v0.9.7.1, i make a SM-G925F rom odexed and root with sparse-dat. It is based on our last 5.1.1 firmware G925FXXU3QOLB and everything work as expected: root, wifi, bluetooth, camera, ... and with the original kernel.

I will try now add init.d support to my rom.

Thanks you for your work and time.:good:
[SuperR Kitchen] JustZaphod:
I'm trying to compile a functioning ROM with the stock "G920TUVS3DOJC" from my Galaxy S6 from T-Mobile.. I can successfully compile a functioning and bootable ROM, however I'm missing Wifi Calling.. Everything works other than this.. This is not a WiFi problem as it connects just fine, but I'm currently using someone elses build of the same stock rom and there are no issues at all, that rom appears to be built with Superr as well.. I'm trying to compare Updater Scripts since there is very little difference.. I can't find what I'm missing

I'm attaching my Updater Script, I removed the Assert from the first line because it was giving an install error on TWRP.. Not a problem though.. I don't think this is an issue with the Kitchen, simply user error.. I'm just trying to find what I'm missing.. Any help or comments would be really appreciated
[SuperR Kitchen] sefrcoko:
No I wasn't referring to 2.64, I thought the older kitchen version you were using still had the system-based root as opposed to the later versions that have systemless supersu. Anyways, all good. :)
[SuperR Kitchen] bcrichster:
Which SuperR Kitchen version are you using? The newer ones fixed WiFi
[SuperR Kitchen] JustZaphod:
I said before.. The Wifi is

fine

.. No problems, I'm using v0.9.6.8

T-Mobile has a Wifi

Calling

feature that routes calls via Wifi.. That does not work when I complete a build..

The ROM boots, The Wifi WORKS, Bluetooth, NFC.. ETC..

Like I said its Wifi

Calling

that not only does not even function as option..
[SuperR Kitchen] Er. Aditya:
thNku il try latest su as i said i was using latest kitchen version and su 2.62.3 was included in that
[SuperR Kitchen] SuperR.:
v0.9.7.2

Changes:

Updated SuperSU to version 2.64 BETA.
[SuperR Kitchen] Danvdh:
SuperR, what is the preferred permission type for M? I'm currently using sparse but I noticed there's raw image now too?

Also I noticed you brand the build.prop when building, is there a way to disable this via donation or other means?
[SuperR Kitchen] SuperR.:
sparse_dat is the preferred method for L and M. raw_img is sort of a last resort if all else fails. I suppose some people may like the raw_img method and more options can't hurt :)

I have not considered allowing the removal of the branding via donation. Is this acceptable practice? I certainly don't want to force anyone to donate, but I also get annoyed when people use my work claiming that it's their own with no credit given. Thus the branding in the first place. Maybe donations would make me feel better about this part :p

I have been building roms for many years for many devices and this happens a lot. I am not sure if you read any of the previous posts regarding the removal of the branding, but so far I have maintained that it can be done but I will not explain how.

You have been at xda for longer than I so you may be able to provide insight on best practices. The options I see at this point are:

Make the branding removal more difficult and allow unbranding for a donation (should there be a set amount?)

Keep it the way it is where people can figure it out on their own or deal with the branding.

What are your thoughts on this?
[SuperR Kitchen] Danvdh:
I would gladly pay for the ability to remove the branding for my own project here

I currently use your kitchen and workaround the branding which isn't very complicated but it's nothing to do with your kitchen, I'd gladly donate to remove this, and yes set amount is fair, I'd go 5$ donation USD or so. There will be no rules against this, you are not using XDA to profit or forcing them to pay for anything as the kitchen works 100% fine as is.

even with my workaround for branding, I give you full credit in the OP :)

http://xdaforums.com/nexus-6/development/rom-5-1lightromstock-lmy47e-03-19-2015-t3059493

once again, thank you for the best kitchen I've seen to create stock ROMs
[SuperR Kitchen] Er. Aditya:
still bootloops with latest SU

bro does set_perm wipes internel memory ?? i just tested twice and it sure did mine

edit here's attached the difference between the updater scripts created by latest kitchen and earlier versions
[SuperR Kitchen] AndroidGX:
No idea [MENTION=5787964]SuperR.[/MENTION] ? :(
[SuperR Kitchen] Er. Aditya:
[MENTION=718594]super[/MENTION]R bro the new kitchen is wiping my internel storage :( i dont know what has been changed i tried different recoveries but today i have lost all my data
[SuperR Kitchen] Maw2607:
system.img size

I try to include data/app and remove some bloatware in my SM-G925F rom but when i do that the system.img size detection doesn't work anymore (but it work when i don't change anything to the original rom) and i must give manually the size but how to found it because i use hyper-v to emulate linux and i can't use adb detection. I Try with diskinfo on the playstore but i don't know if 3651460576 is a good value..

If some one can help me.
[SuperR Kitchen] Mr Impossible:
Donation for branding removal would be your best bet. More experienced dev's will know how to remove it and should give creds anyway. I have been playing with your kitchen the past few days and have to say your doing some damn nice work on this! Kudos
[SuperR Kitchen] sefrcoko:
Personally I would leave it as it is now. People will always find a way to circumvent things if they really want. It's up to you of course in the end and you'll have support either way :). If you decide on pay-for-no-branding then check to make sure that is permitted under xda rules first. No-string-attached donations are definitely ok here but not sure about pay-for-something donations. Might be ok too but check first to avoid potential headaches if you choose that road. [emoji106]
[SuperR Kitchen] Captain_Throwback:
I've always been of the opinion that work out on XDA is put there because we enjoy the challenge of doing it and want to produce it to help others. Donations should always be voluntary. The branding thing is really no big deal, imo, if people are using your fantastic tool to help them build a working ROM for their device. I think people should donate to you AND leave your branding in their ROM, to encourage others to use it.

I really don't think most XDA users think enough about how much time devs spend on these tools to make their lives easier. Oftentimes you'll see ROM devs getting donations, but the people that worked hard to make the tools that allowed the ROM to be built get nothing. I find that unfair and ridiculous. So I don't know - maybe there is some merit to the "donation for removal of branding" idea after all, so the end-builders can't take all the credit without first giving back. Okay, I think I changed my answer, lol.

Personally, I removed the branding from the ROM itself but left it in the updater-script of my ROM and added a mention to you and a link to this thread in my ROM OP. But I also donated because I appreciate your work and understand the effort involved. At the end of the day, I think it's up to you.
[SuperR Kitchen] SuperR.:
You have a /data directory in your rom so user app support is automatically added. If you don't want user app support (which wipes /data on flash), simply rename or remove the /data directory.

I have no idea. It looks like it hangs while zipping in the middle with no error. I have not seen this before. What Linux system are you running?

You can just remove the old SuperSU.zip and add the new one. It is located in /kitchen/tools/root/. If your rom is already rooted before you do this, you will need to unroot and root again for the changes to take effect in your rom.

Seems hyper-v is a Windows app running in Windows. I don't support Windows. Use Linux :)
[SuperR Kitchen] Captain_Throwback:
[MENTION=5787964]SuperR.[/MENTION]

I just attempted to unsecure a boot.img, and in the process of doing so, the kitchen appears to add a second "ro.adb.secure" line to my default.prop instead of just replacing the one that's there. Can you confirm? I usually do it manually, since I prefer to leave adb secure while unsecuring the image overall (which breaks adb altogether on Marshmallow, btw), but when I went to check how the kitchen does it, I noticed two of the ro.adb.secure lines.

So, If i start with a stock, secure boot.img, after extracting it, my file looks like this:

#
# ADDITIONAL_DEFAULT_PROPERTIES
#
[B]ro.secure=1
ro.adb.secure=1[/B]
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=0
ro.zygote=zygote32
persist.sys.strict_op_enable=false
persist.sys.whitelist=/system/etc/whitelist_appops.xml
dalvik.vm.dex2oat-Xms=64m
dalvik.vm.dex2oat-Xmx=512m
dalvik.vm.image-dex2oat-Xms=64m
dalvik.vm.image-dex2oat-Xmx=64m
ro.dalvik.vm.native.bridge=0

Once choosing the option to "insecure" the boot.img, I end up with this:

#
# ADDITIONAL_DEFAULT_PROPERTIES
#
[B]ro.secure=0
ro.adb.secure=0
ro.adb.secure=1[/B]
ro.allow.mock.location=0
ro.debuggable=0
persist.service.adb.enable=0
ro.zygote=zygote32
persist.sys.strict_op_enable=false
persist.sys.whitelist=/system/etc/whitelist_appops.xml
dalvik.vm.dex2oat-Xms=64m
dalvik.vm.dex2oat-Xmx=512m
dalvik.vm.image-dex2oat-Xms=64m
dalvik.vm.image-dex2oat-Xmx=64m
ro.dalvik.vm.native.bridge=0

P.S. Is there any way to remove busybox from the ROM? You seem to add it by default, without any option to remove it. I can obviously do it manually, but I was wondering why it's automatically added? Especially on Marshmallow ROMs, with toybox included, the busybox applets are becoming less and less necessary. And with systemless root, the preferred location of the busybox install might not be /system/xbin anymore. [MENTION=4544860]osm0sis[/MENTION]' Busybox Installer, for example, detects systemless root and determines where Busybox should be installed. A modular install like that might be something to consider.
[SuperR Kitchen] Er. Aditya:
so adding data/ functionality wiped my internel memory ??
[SuperR Kitchen] jazzespresso:
Something I realized, not sure if it is relevant to this or not, but found a bit strange so I like to share this with you guys:

This is Samsung SM-T350 (5.0.2/5.1.1) firmware by the way,

Superr Kitchen; it does all good, it deodexed it, then unsecure the boot.img, it creates full zip, and flashes all OK...

then realized Samsung's Smart Manager's Device Security option says " Threat found" all red icon....doing some search on XDA, some people says it is because it sees SuperSu, to it triggers Samsung's Smart Manager's Device Security display that message...

now, strange part of all this that, when I was on stock ROM (but not deodexed), but using [MENTION=4899305]ashyx[/MENTION] boot.img (rootable), that was not the case Samsung's Smart Manager's Device Security app does not detect anything and no message...

It seems to me like Superr Kitchen does something during the entire ROM creation (suspecting boot.img) that causing Samsung's Smart Manager's Device Security app display that message.

Of course, this is NOT a biggie, i can simple delete Samsung's Smart Manager app, but kind of found a bit strange...
[SuperR Kitchen] thereassaad:
I add this to csc then its disable that option as u rooted & no way to make it work with rooted ok

CscFeature_SmartManager_DisableAntiMalware>true </CscFeature_SmartManager_DisableAntiMalware>
[SuperR Kitchen] Captain_Throwback:
[MENTION=5787964]SuperR.[/MENTION]

I found a permission using set_metadata that appears twice:

set_metadata("/system/bin/PktRspTest", "uid", 0, "gid", 2000, "mode", 0755, "capabilities", 0x0, "selabel", "u:object_r:diag_exec:s0");

It appears once at the top of the permission list in alphabetical order with the uppercase bins, and then a second time further down in alphabetical order with the lower case.
[SuperR Kitchen] Maw2607:
Sorry i'm on xumbutu 64Bits under hyper-V and all is working very good, i just want to know how i can find my data size partition.

Thanks
[SuperR Kitchen] jazzespresso:
[MENTION=5564860]Androidwizzard[/MENTION] suggested to use Storage Space from Google play store, it does shows all your partition...
[SuperR Kitchen] AndroidGX:
Ubuntu 14.04 LTS (64-bits) virtualized via VirtualBox (on Windows 10 64-bits).

I finally gave up and tried sparse dat instead, and it zip finished.

But when I tried to flash-it, rom does not boot at all, stuck at first LG boot logo.

Seems like your kitchen not really loves LG G4 firmwares :crying::D

Any idea about this [MENTION=5787964]SuperR.[/MENTION] ? :highfive:

Many thanks in advance :good:
[SuperR Kitchen] Maw2607:
Thanks for the apps i now know the partition size.
[MENTION=718594]super[/MENTION]R

The detection partition size problem only occurs when i add the data/app folder and even if i choose to enter it manually, the system.new.dat is too small.

When i make a rom without data/app it's ok and if i try to add the data/app folder the system.new.dat is very small.

It's just a small problem for me and as i say before your kitchen is already great.
[SuperR Kitchen] SuperR.:
If you add user app support, the /data partition is formatted when flashing the rom.

Got it, thanks for pointing that out :)

I don't have any ideas. If you have a fully working updater-script I can take a look to see the differences. Meanwhile, you could try the raw_img method.

When you add /data/app, you are asked twice to choose a partition size detection method. Once for the system partition, and a second time for the data partition. Make sure you are choosing the correct method for the correct partition both times.

Thanks again for the bug report. Insecure boot is fixed in the version below along with the answer to your last question :)

WARNING: The busybox used in this version is experimental. It is no longer added with root but you must add root to add Busybox. I have not tested this Busybox implementation at all so try at your own risk.

Sorry, no time for testing at the moment. Let me know how it goes.

v0.9.7.3

Changes:

Removed duplicate PktRspTest metadata.

Added option to add/remove busybox and now use [MENTION=4544860]osm0sis[/MENTION] Busybox installer.

Fixed ro.adb.secure=1 being left behind when insecuring boot.img.
[SuperR Kitchen] Er. Aditya:
thankyou bro dint realised that and all my data is gone :(
[SuperR Kitchen] Captain_Throwback:
Is this really the desired behavior for custom ROMs, though?

I know "dirty" flashing is popular with custom ROM users, and while copying new apps to /data may cause some duplication depending on how the apps are copied, for the most part I think people are either expected to wipe /data themselves if they don't want to keep it, or the ROM builder needs to add some additional safeguards to prevent duplication of data.

I just tried the data/app support with the sparse_dat format, and I also didn't realize that my Internal (emulated) storage would get erased by the installation. For devices with emulated storage and people flashing custom ROMs, the expectation is always that internal storage will never be touched. Even TWRP doesn't touch it (or back it up, for that matter). It's probably preferable that when sparse_dat is selected, that applies only to the system portion of the install - the user app/data portion can/should still be handled by set_metadata/perms and standard folder extraction.

At least that's my opinion on it . . .
[SuperR Kitchen] Maw2607:
Sorry i don't see that there is twice question, thanks for the explanation.
[SuperR Kitchen] Danvdh:
[MENTION=5787964]SuperR.[/MENTION]

Confirmation #06M36029W66688600

:D :highfive: :cowboy:
[SuperR Kitchen] SuperR.:
Thank you very much :)
[SuperR Kitchen] SuperR.:
Well, I do not disagree with you. If the general consensus is NOT to wipe data when /data/app is enabled, I am happy to remove it. However, sparse_dat will still wipe /data and I don't think there is anything that can be done about it. This method writes the img to the partition, similar to dd. The updater-script does not include a format command for system or data when using sparse_dat. Instead it uses block_image_update which overwrites the whole partition.

edit: just realized you were saying exactly that lol. Sorry about that. It was actually requested to enable sparse_dat data at some point a while back. I will think on a good way to handle it :)