yashsingh1/xdaforums huggingface dataset:
[SuperR Kitchen] SuperR.:
It uses sudo commands for both unpack and repack of the ramdisk, but the terminal remembers your password for a period of time so it did not ask for it again on repack.
[SuperR Kitchen] SamuriHL:
I had rebooted in between the unpack and repack so it wouldn't have cached sudo. It was weird. Not sure what's up with it yet. We'll figure it out though.
[SuperR Kitchen] Rydah:
I really hate to keep being that guy but I tried rebuilding my rom using sparce_dat with user apps enabled since it was added in the latest update. System builds fine but the data image doesn't seem to. Not only does it lock my computer up alot while building data sparce dat image, I also get this:

Sent From My LG V10
[SuperR Kitchen] ziddey:
Sure. The difference is in ownership. Unpacking (cpio -i) as a regular user will not preserve the ownership. However, repacking (cpio -o) does.

To repack, add -R 0.0 to cpio (i.e. --owner root.root).

e.g.

find . |cpio -o -H newc -R 0.0 | gzip -9 > ../newinitrd.img

I just tested and this works just fine without being root.
[SuperR Kitchen] SuperR.:
Thank you for this. To clarify, unpack ramdisk does not need anything different but repack needs the extra "-R 0.0". Is this correct?

edit: and neither unpack or repack need to be run as root?
[SuperR Kitchen] ziddey:
Right. Otherwise, Android won't be happy that the ramdisk contents are owned by superr.superr

edit: Unpacking as root does preserve ownership, and it is indeed root.root.

https://www.gnu.org/software/cpio/manual/html_node/Options.html
[SuperR Kitchen] SpasilliumNexus:
I've updated to 0.9.6.4 to play with creating sparse data and saw this in the log when I noticed they weren't being created.

Sparse system files still work fine.
[SuperR Kitchen] hohassan444:
A am sure of size (cat proc/partitions X 1024) , and i use new untouched kitchen. Also SYSTEM.NEW.DAT is built but with different size every time...if i repeat the process gives different sizes....sometimes the size is 1.6 gb or 1.1 gb or 1.7 gb....so i think the problem is in creation of image. lastly , some roms build without problems.

thanks in advance.
[SuperR Kitchen] dkionline:
Whats with compression? Rather your build isnt working cause of needed symlinks.
[SuperR Kitchen] Rydah:
Same here

Sent From My LG V10
[SuperR Kitchen] SuperR.:
When I tested the data dat creation, I chose to get the partition size from the /data directory and it worked without issues. I am now wondering if img2sdat.py has a limitation on size and maybe your data partition is too large? Keep in mind, I am not certain of what happens if you flash a 200MB sparse dat image to a partition that is 8GB for example. Do you lose the space or does it copy them as files and the rest of the 8GB is still available to Android?

After reading through the link you posted, the -R 0.0 can only be used as root. It seems that unpacking as normal user and repacking ramdisk with sudo and the -R 0.0 should work. The -R 0.0 should make everything in the ramdisk owned by root:root regardless of who owns it on the pc before packing. Does this sound correct?

edit: well, we may as well test it out. It can't break any more than it already is. Let me know how it goes

v0.9.6.5

Changes:

Attempt to fix Marshmallow boot.img.
[SuperR Kitchen] Rydah:
DELETE
[SuperR Kitchen] ziddey:
-R works for regular users. No need to sudo at all when dealing with the ramdisk.
[SuperR Kitchen] Rydah:
My Log After Using /data

Created filesystem with 11401/274176 inodes and 539178/1096704 blocks
rimg2sdat tool, provided by Howellzhu@gmail.com
Data block: 502503 (2010012 KBs)
Zero block: 594201 (2376804 KBs)
Total block: 1096704 (4386816 KBs)
Creating filesystem with parameters:
Size: 56290705408
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 32768
Label:
Blocks: 13742848
Block groups: 420
Reserved block group size: 1024
Created filesystem with 99/3440640 inodes and 322545/13742848 blocks
Total of 13742848 4096-byte output blocks in 884 input chunks.
Generating digraph...
Finding vertex sequence...
Removing backward edges...
0/0 dependencies (0.00%) were violated; 0 source blocks removed.
Reticulating splines...
Traceback (most recent call last):
File "/home/superuser/SuperR/tools/img2sdat.py", line 40, in <module>
main(sysimg, outdir)
File "/home/superuser/SuperR/tools/img2sdat.py", line 14, in main
bif.Compute(outdir)
File "/home/superuser/SuperR/tools/blockimgdiff.py", line 193, in Compute
self.ComputePatches(prefix)
File "/home/superuser/SuperR/tools/blockimgdiff.py", line 262, in ComputePatches
for piece in self.tgt.ReadRangeSet(xf.tgt_ranges):
File "/home/superuser/SuperR/tools/sparse_img.py", line 101, in ReadRangeSet
return [d for d in self._GetRangeData(ranges)]
File "/home/superuser/SuperR/tools/sparse_img.py", line 140, in _GetRangeData
yield fill_data * (this_read * (self.blocksize >> 2))
MemoryError
Creating filesystem with parameters:
Size: 4492099584
Block size: 4096
Blocks per group: 32768
Inodes per group: 8064
Inode size: 256
Journal blocks: 17136
Label:
Blocks: 1096704
Block groups: 34
Reserved block group size: 271
Created filesystem with 11401/274176 inodes and 539178/1096704 blocks
rimg2sdat tool, provided by Howellzhu@gmail.com
Data block: 502503 (2010012 KBs)
Zero block: 594201 (2376804 KBs)
Total block: 1096704 (4386816 KBs)
Need size of filesystem
[B][COLOR="Red"]Cannot open input file data_new.img
Traceback (most recent call last):
File "/home/superuser/SuperR/tools/img2sdat.py", line 40, in <module>
main(sysimg, outdir)
File "/home/superuser/SuperR/tools/img2sdat.py", line 12, in main
tgt = sparse_img.SparseImage(sysimg)
File "/home/superuser/SuperR/tools/sparse_img.py", line 27, in __init__
except FileNotFoundError:
NameError: global name 'FileNotFoundError' is not defined[/COLOR][/B]

My user apps are approximately 247.8 MB.
[SuperR Kitchen] SuperR.:
Give this a try :)

v0.9.6.6

Changes:

Attempt to fix sparse dat data creation
[SuperR Kitchen] Rydah:
sweet. will report back in a few. should i let it detect through adb or manually enter /data still?
[SuperR Kitchen] SuperR.:
It should not matter. I removed img2sdat.py altogether and used rimg2sdat for all dat creation. It should work now if system is working for you. This should also fix issues anyone may have had with vendor dat.
[SuperR Kitchen] Rydah:
Okay, building. ???

Sent From My LG V10

---------- Post added at 04:17 PM ---------- Previous post was at 03:25 PM ----------

OK built fine. Flash time. Also FYI, SuperSU 2.60 beta now available.

Sent From My LG V10
[SuperR Kitchen] enotar:
No go here when flashing PB with updater binary. Sparse dat. I will tty with metadata
[SuperR Kitchen] SpasilliumNexus:
Just updated to 0.9.6.6 and gave it a try again. This time, I only get data.patch.dat in the output directory next to system.new/patch/transfer.dat files, but no additional ones (I'm assuming that data.new.dat and data.transfer.dat are supposed to be created too.)

Here's what's inside main.log

And here's what's in zip.log

The total size of my data/app folder is 258.4MB, which includes just extra Google apps to be installed on a 2015 16GB Moto X Pure Edition.

I've also noticed that when the "Choose system partition detection method" is asked before building, it asks twice (I use number 1 for this.)

The first time it asks, on my phone I get the "ls -al /dev/block/bootdevice/byname" toast from SuperSU.

The second time it asks, I choose the same option again, but no toast from SuperSU on the phone (perhaps this could be the cause?) but still proceeds to build.

First time. Notice how there's an option 4 in this one:

Second time. This time, option 4 isn't an option anymore:

Here is what I see when I scroll up while the ROM is being created:

As for the kitchen setup, it is as follows:

8) ROM Tools

Deodex ROM (Deodexed)

Root/Unroot ROM (No Root)

User app support (Supported)

Change perm type (sparse_dat)

Asserts: Add/Change devices (clark)

7) Build Menu

1) Build full ROM Zip

Should we zipalign...? yes

I've tried both using the prebuilt binaries (64-bit for my system setup) and the ones that get built in the kitchen upon running on fresh copies of the kitchen.

And finally, here's my by-name output.

Hopefully this helps pinpoint the issue. If you need any more info, please let me know.
[SuperR Kitchen] Rydah:
[MENTION=5083335]Spasticdroid[/MENTION] [MENTION=718594]super[/MENTION]r my rom built fine with sparce dat data img enabled. I had left my data there prior to flashing and after flashing, it did indeed wipe /data but didn't reduce the partition size. I'll end up not enabling user app support as it wipes out the /data partition but it works now. ????

My rom is having issues with a few apks that couldn't be deodexed. Is there a way I can find out why they won't deodex?

Sent From My LG V10

---------- Post added at 05:49 PM ---------- Previous post was at 05:38 PM ----------

Also, could you add support for making separate zips to accompany the rom? For example, I want to include preloaded apks into /data without deleting data from the partition. Unless you can work magic and make sparce dat data not wipe but simply add to...?

Either way, appreciate your time and help. Glad you got data to work with sparce dat.

Sent From My LG V10
[SuperR Kitchen] SpasilliumNexus:
Oh damn I didn't think of that. I might not use it and just create a separate zip for data apps then.

As for the deodexing issue, are you debloating it then deodexing the ROM? If so, that's normal since the kitchen won't deodex anything that was debloated/moved from the working directory to 00_project_files.
[SuperR Kitchen] Rydah:
The apks that won't deodex were there in my system.img ? its literally two apks. I was just gonna leave those apks odexed but they still force close like crazy .

Sent From My LG V10
[SuperR Kitchen] SuperR.:
I have no idea what this means.

It is not asking you the same thing twice. Notice one says system and the other says data. There are 2 images being built so we need 2 partition sizes. You only get option 4 if there is a system.img in the project dir and you are choosing system size (which happened the first time you saw the message), or data.img and you are choosing data size (which did not happen since you don't have a data.img), etc.

I don't understand the problem in your case since the system dat built fine (all dat creation uses the exact same code in v0.9.6.6). There is not much I can do about it other than suggest you try another method for getting the data partition size.

Glad it worked for you :) I will look into adding another option in build custom zip menu for data.

You would need to create an issue in smaliex github if you are deodexing L, or smail github if you are deodexing M. I can't do anything about specific apk's not deodexing properly.
[SuperR Kitchen] bigrammy:
Probably not a great time to ask as I am rushing to work just now :(

Do you by chance have /system/app/appthatstheproblem/arm and arm64 folders both with .odex files ?

I had this sort of issue with my mediatek rom and I never really got to the bottom of it but the /system/framework/ had both arm and arm64 boot odex :confused:

eg: it seems a few of the apk's needed to run as 32bit as well as 64bit :confused:

I thought this was just a mediatek weirdness but maybe not. :laugh:

Later release roms came full 64bit :good:
[SuperR Kitchen] Rydah:
Actually yes, my stock odexed base does have both arm and arm 64 folders with odex files in framework. So I have to leave those folders there odexed?

For the two apps that force close and won't deodex, I am copying the full folder from my odex base including the arm folder inside each app.

Edit:

So one of my apps that fails to deodex and force closes when I copy the odexed version to my deodexed base only has the arm folder inside it.

/system/app/LGWeatherService/arm/LGWeatherService.odex

No arm64 folder inside. Was your last post about arm and arm64 in framework just an example? Lol thanks for your time.

Sent From My LG V10
[SuperR Kitchen] bigrammy:
I had to leave the entire rom odexed as it just seemed to break no matter what I tried :crying:

I only spent a short time trying workout why then gave up due to a lack of info at the time and it seemed like it was getting above my pay grade :laugh:

Mediatek/manufacturer later released a ROM with the affected apk's all arm64 so I never really looked back after that :o

I know that don't help you too much but maybe someone will know how, why, what, where, when in this thread as there is some pretty big hitters. :fingers-crossed:

Off to mend some s**t planes now so good luck bro. :highfive:
[SuperR Kitchen] phongpan355:
Can I use it on Cygwin64 Windows?
[SuperR Kitchen] Er. Aditya:
as dev has said countless times in thread your free to make it work on cygwin on your own but dev dsnt supports cygwin
[SuperR Kitchen] kn06497:
:confused:

Help
[SuperR Kitchen] theincognito:
[MENTION=5787964]SuperR.[/MENTION] , [MENTION=5083335]Spasticdroid[/MENTION] & anyone else who can help me: How to add my device to the devices list? Please help. I am using Moto G3. Android 6.0.0,CM13.0.

Edit: I searched the fstab.qcom,but I dunno what I should add from there to byname file. Also,there is no ro.product.device in my build.prop.

Edit 2: Attached the file with the mount points.
[SuperR Kitchen] bigrammy:
Just seen your edit.

In my mediatek rom I had a few apk's that had both arm and arm64 odex folders with .odex's.

I also had arm boot.oat and arm64 boot.oat in the system/framework folder so it seemed the rom was actually using both :confused:

Later roms removed the arm boot.oat and apk's arm folder leaving just arm64 stuff. :good:
[SuperR Kitchen] Rydah:
Yeah, I have both boot.oat arm and arm64.

Sent From My LG V10
[SuperR Kitchen] SuperR.:
If you leave framework odexed, you can use odexed and deodexed apk's in your rom. If you deodex framework, you can only use deodexed apk's.

The kitchen properly handles arm and arm64 odex files and boot.oat, even if they both exist in the same rom. See this issue I posted a while back on the smali github. Info straight from the dev of smali/baksmali ;)

https://github.com/JesusFreke/smali/issues/320

Please send your build.prop
[SuperR Kitchen] Rydah:
Ah good to know. Looks like I'll leave framework odexed and deodex everything else besides the faulty apps in which I'll also leave odexed. I might need to make smali edits to framework files but I can always deodex them, decompile, edit, recompile and reodex and it'll still work right? (I know how to reodex)

Sent From My LG V10
[SuperR Kitchen] SuperR.:
Your device must be rooted to extract img's from your phone. If it is rooted, then I don't know what to tell you. The kitchen tries 2 methods to extract and if both fail you get that message. It might be that your sdcard does not have room for the img.

I have no idea honestly. I have never reodexed anything since I have always had odexed roms to begin with.
[SuperR Kitchen] SuperR.:
Here is a test version of the Kitchen set up to use the new SuperSU BETA 2.6.0. In theory, it should set up systemless root on all M roms, do the sepolicy patching for M and Samsung 5.1.1, and also the required ramdisk edits for M and Samsung 5.1.1. All this happens when the zip is flashed. It should root normally on all other roms. Good luck and let me know how it goes. If it works out I will push the changes to the main kitchen :)

SuperRs_Kitchen_v0.9.6.6_test.zip
[SuperR Kitchen] Rydah:
Just wanted to report from my prior posts, leaving framework odexed allowed my rom to boot and maintain an almost full deodexed rom. Thanks again. :)

Sent From My LG V10
[SuperR Kitchen] theincognito:
Attached here.
[SuperR Kitchen] Mobile number tracker:
nice work.
[SuperR Kitchen] Rydah:
Ok, I'm back with a new question/problem to solve. So my rom did flash and boot and is running fine for my users with one problem, WiFi is not working properly. Basically it won't connect to any networks and just tries to obtain an IP Address but never does. Weirdly, the same exact ROM that I built in the kitchen works with WiFi if I create it as a system.img and flash it via fastboot but not if I flash it as a zip.

I'm using the same files in my new system.img as my rom, permissions type set at "set_metadata."

One of my users said it may be related to SELinux. Any ideas?
[SuperR Kitchen] SuperR.:
I am waiting to get feedback about the test kitchen with SuperSU 2.6.0 before releasing any further kitchen versions but this will solve your problem in the meantime. Replace the superr file in the main kitchen directory with the one in the appropriate attached zip. If you are using the test kitchen mentioned above, use the zip that has "-test" in the name, otherwise use the other one.

It could certainly be an selinux issue. You are probably missing an important wifi related set_metadata line. The Kitchen has a database it uses so it may be missing this part for your rom.

One option you have is to track it down and add it to your scirpt. If you get it working, send me the lines that fixed your issue and I will add them to the database.

Another option is to use sparse_dat which will almost certainly give you the same results as flashing the system.img with fastboot.
[SuperR Kitchen] Rydah:
Thanks, I will see if I can find what is causing the issue and will let you know.
[SuperR Kitchen] Rydah:
[MENTION=718594]super[/MENTION]r one of my testers found it and we fixed it.

Here is the fixed lines:

set_metadata_recursive("/system/etc/dhcpcd", "uid", 0, "gid", 0, "dmode", 0755, "fmode", 0644, "capabilities", 0x0, "selabel", "u:object_r:dhcp_system_file:s0");
set_metadata("/system/etc/dhcpcd/dhcpcd-hooks", "uid", 0, "gid", 2000, "mode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
set_metadata("/system/etc/dhcpcd/dhcpcd-run-hooks", "uid", 1014, "gid", 2000, "mode", 0550, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");

I definitely rather use sparce_dat permissions going forward, but as a base i left it open to them. Thanks!
[SuperR Kitchen] SuperR.:
Scratch all that, i see the difference.

edit: on third thought, I don't see the difference in what you posted and what I presume was already in your updater-script. Please post the lines the kitchen produced that did not work for comparison. Thanks
[SuperR Kitchen] Rydah:
Original Script From Kitchen

set_metadata_recursive("/system/etc/dhcpcd", "uid", 0, "gid", 0, "dmode", 0755, "fmode", 0644, "capabilities", 0x0, "selabel", "[COLOR="Red"]u:object_r:dhcp_system_file:s0[/COLOR]");
set_metadata("/system/etc/dhcpcd/dhcpcd-hooks", "uid", 0, "gid", [COLOR="red"]2000[/COLOR], "mode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
set_metadata("/system/etc/dhcpcd/dhcpcd-run-hooks", "uid", 1014, "gid", 2000, "mode", 0550, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");

Edited By Me

set_metadata_recursive("/system/etc/dhcpcd", "uid", 0, "gid", 0, "dmode", 0755, "fmode", 0644, "capabilities", 0x0, "selabel", "[COLOR="red"]u:object_r:system_file:s0[/COLOR]");
set_metadata("/system/etc/dhcpcd/dhcpcd-hooks", "uid", 0, "gid", [COLOR="Red"]0[/COLOR], "mode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
set_metadata("/system/etc/dhcpcd/dhcpcd-run-hooks", "uid", 1014, "gid", 2000, "mode", 0550, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");
[SuperR Kitchen] SuperR.:
Interesting. Thanks for posting that. I wonder how to detect whether a rom needs one or the other as it is not mentioned in the file_contexts of several devices where the manufacturer uses the context the kitchen currently uses. I wonder if those devices would work properly using the standard system context that ended up working for you. I guess the best way to find out is to change it in the kitchen. I am sure we will find out if it breaks things fairly quickly lol

edit: I am not sure where it came from, but this line was not created by the kitchen:

set_metadata("/system/etc/dhcpcd/dhcpcd-hooks", "uid", 0, "gid", 0, "mode", 0755, "capabilities", 0x0, "selabel", "u:object_r:system_file:s0");

The kitchen uses this line as a base for dhcpcd-hooks:

set_metadata("/system/etc/dhcpcd/dhcpcd-hooks", "uid", 0, "gid", 2000, "mode", 0755, "capabilities", 0x0, "selabel", "#CONTEXT");

The #CONTEXT is replaced by either "u:object_r:system_file:s0" or the context defined by the file_contexts file if it exists. The kitchen would have created the correct output for that particular line but the recursive line context is different.
[SuperR Kitchen] Rydah:
Lol yup. Is it normal that the kitchen keeps overwriting my edits on build.?

Sent From My LG V10

---------- Post added at 04:01 PM ---------- Previous post was at 03:57 PM ----------

Also, SuperSU was updated again, 2.61

---------- Post added at 04:11 PM ---------- Previous post was at 04:01 PM ----------

Hmmm, I didn't do anything else besides use the kitchen. I'm honestly very confused.

Edit: that line has the correct context. the "2000" had to be changed to "0"
[SuperR Kitchen] SuperR.:
Yes if you are referring to build.display :p

If you started with a rom zip, maybe it was somehow leftover from the old updater-script? Not sure. I bet if you use the kitchen below and extract a system.img it will work out of the box :)

Here is another test kitchen using the new SuperSU v2.61. I really need feedback on this because it is a pain to update 2 versions lol.

edit: moved correct link to my next post
[SuperR Kitchen] Rydah:
I'll test shortly. :D also, did you see my edit?

that line has the correct context. the "2000" had to be changed to "0"
[SuperR Kitchen] SuperR.:
Oh, well I lied then. The test kitchen will not work out of the box. Hang on a sec and i will swap it out :)
[SuperR Kitchen] SuperR.:
This one will work out of the box :)

PLEASE TEST ROOT IF YOU HAVE AN M DEVICE OR SAMSUNG 5.1.1

Other testers are welcome too :)

SuperRs_Kitchen_v0.9.6.6_test_3.zip
[SuperR Kitchen] Rydah:
Downloading. Will be back. ?

Sent From My LG V10

---------- Post added at 05:06 PM ---------- Previous post was at 04:38 PM ----------

Latest test kitchen fixed my issues. ???

Sent From My LG V10
[SuperR Kitchen] duniel:
Congratulations!

Dear [MENTION=5787964]SuperR.[/MENTION]

I've used your kitchen to make a flashable zip for my device (bq Aquaris E5 HD - mt6582).

Your kitchen is awesome! No issues on stock 4.4.2 kitkat (provided by manufacter)... It boots ok and all work well...

On next days I'll try with stock lollipop (5.0.2) and I'll tell you the results....

I've added support for my device to the kitchen, I attach a zip with the files.

Regards and thanks for your excellent work!
[SuperR Kitchen] oak:
Superr, I built a Marshmallow 6.0.1 Shamu (just released) rom. Left odexed, debloated and did some buildprop edits. It flashed and works flawlessly. I left root to Chainfire's 2.61 flashable.

Thanks for your work on this. Works great!

Edit: Oh, here's a little donation for your efforts. 51L29215L6886924P Thanks again.
[SuperR Kitchen] SuperR.:
Did you use test kitchen 3 and let the kitchen add root? It uses SuperSU 2.61 with no other mods.

edit: Thank you very much :)
[SuperR Kitchen] oak:
Sorry, no, I used 9.6.5 and just flashed root before boot. I'll give the latest test a go and let you know.

---------- Post added at 08:35 PM ---------- Previous post was at 08:02 PM ----------

Update: I used test 3 to create a Marshmallow 6.0.1 rom for Shamu and rooted with Superr. Flashed and runs perfectly. Root works great. Thanks again for this excellent tool!

What I did:

Google Image - Shamu 6.0.1

perm type - sparse_dat

added ad blocking host file

edited build prop for lcd value

debloated

custom debloated

left odexed

rooted
[SuperR Kitchen] SuperR.:
Very nice :) Thanks for testing Kitchen test 3. Now we just need to hear from the Samsung camp to see how it goes on their 5.1.1. Hopefully all will go well and I can push the changes.