yashsingh1/xdaforums huggingface dataset:
[SuperR Kitchen] SuperR.:
New Plugin :)

Partition Zip

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

Create a flashable zip of one or more image files as long as you know the partition name where it should be flashed.

Usage:

Copy the partition images you want in the zip into your rom directory.

In the kitchen main menu, choose Misc Tools > Run a plugin > partition_zip

Choose a partition img from the list.

For by-name devices, type the partition name from your device where it should be flashed (ex. aboot)

For mmcblk devices, choose your block from the list (add it to the device superr_mmc file if needed first).
[SuperR Kitchen] jazzespresso:
yeap, set_metadata works like a charm on MM ROMs, even if it is considered an old method, but working fine with MM ROMs

---------- Post added at 08:49 AM ---------- Previous post was at 08:41 AM ----------

well, i got the similar issue, plus during Kitchen's deodexing, it throw bunch of "not enough memory", even if Kitchen deodexed many others, a few of them got "not enough memory", I was going to ask [MENTION=5787964]SuperR.[/MENTION] about it, I remember I saw something about increasing memory allocation one of the post but I could not able to find that post...so instead of dealing with it, I used SVADeodexerForArtx32/SVADeodexerForArtx64 tool deodex it, then copy back to app/priv-app/framework folder back to Kitchen...
[SuperR Kitchen] raimondomartire:
For me work only test 3 but I must add this 2 commands

sudo apt-get install gawk liblz4-tool lzop

sudo apt-get -y install r-base
[SuperR Kitchen] jazzespresso:
ok I tested my MM ROM, it flashed all good, but stuck on Samsung Logo, waited for 20 mins, nothing, then rebooted back to recovery and flash it back stock (untouched) boot.img, and after that it rebooted all good.

so looks like boot.img issue I am dealing here...not sure what's offending though....I pick option 2 when I re-pack boot.img..

CURRENT PROJECT: sm-t550

ANDROID VERSION: 6.0.1

1) Pack boot.img, delete ramdisk

2) Pack boot.img, keep ramdisk

3) Add/Remove init.d support (CURRENT: Enabled)

4) Insecure/Secure the boot.img (CURRENT: Insecure)

5) Remove dm-verity (CURRENT: Disabled)

6) Remove forceencrypt (CURRENT: Disabled)

m = Main menu

q = Quit
[SuperR Kitchen] Er. Aditya:
i always do this and mine boots properly and yes you have to keep ramdisk because all the changes go into that..wiered its not booting for you
[SuperR Kitchen] Captain_Throwback:
[MENTION=5787964]SuperR.[/MENTION]

The forced encryption detection in the Kitchen is a bit off. In my current project fstab, I actually have one line that has the "forceencrypt" flag, and another line that has "encryptable". I think the Kitchen sees the second one and thinks forced encryption is disabled. However in this case, it isn't. Forced encryption only applies to the userdata partition, so the Kitchen should be looking specifically at that line in the fstab. Also, is there a way to re-enable forced encryption with the kitchen? I just realized it's not a toggle, but an "Off-only" switch.

EDIT: It doesn't seem to be properly removing verity either?

See this RUU for reference: http://dl3.htc.com/application/RUU_PERFUME_WL_M60_SENSE80GP_NA_Gen_Unlock_1.53.617.5.exe
[SuperR Kitchen] SuperR.:
v2.0.8.1 (Donate version)

Changes:

Fixed forceencrypt not being detected properly.

forceencrypt can now be added and removed.

v1.0.7.5 (Standard version)

Changes:

Fixed forceencrypt not being detected properly.

forceencrypt can now be added and removed.
[SuperR Kitchen] bleros:
Thanks man i will try hope [MENTION=5787964]SuperR.[/MENTION] will check my deodex.log uploaded.
[SuperR Kitchen] Timei:
Excellent tool!!! BIG THANKS , SuperR.!!! u r genious=)
[SuperR Kitchen] kotobodj:
i'm deodex firmware samsung S5 lte-a G906S MM, rom boot oke . but some apps force close .
[SuperR Kitchen] Er. Aditya:
thanks for sharing this but am this has been discussed 500 times , the dev dsnt have any solution at the moment to fix samsung stock deodexing issue
[SuperR Kitchen] Captain_Throwback:
[MENTION=5787964]SuperR.[/MENTION]

Thanks for the update!

Unfortunately forced encryption and dm-verity are still not being detected properly for me with the 1.53 RUU, at least in my existing project - do I need to create a new project for the detection to work right?
[SuperR Kitchen] bigrammy:
port plugin

Hi all,

I have been working on a Mediatek (for now) porting plugin & would like some suggestions from those who have Mediatek 64bit porting experience LP+ :o

I would like to know what in your own opinion's works best to get the "port" to boot first time. :laugh:

eg: Porting Base to Port or Port to Base which folders and file sets you use etc etc.

I know there are plenty of Guides but I am just trying to narrow down the best "proven formula" for obvious reasons. :confused:

The plugin is still pretty basic just now but I feel fairly confident I can expand it later on. (Just baby steps for now :laugh:)

This is not about a fully working all things fixed port but simply getting it to fully boot on the device SoC to SoC Android version to Android version.

Any Feedback via post or pm would be appreciated. :D
[SuperR Kitchen] SuperR.:
That's strange. Here is what fstab.qcom from the RUU you linked looks like after removing forceencrypt and dm-verity using the new update. Is it correct?

http://hastebin.com/ugicevewom.xml

I did not do anything to dm-verity in the last release because it seemed to be working properly. Not sure what the problem is. You should not need to start a new project.
[SuperR Kitchen] Captain_Throwback:
Yours is correct. For some reason, mine isn't getting changed. Let me create a new project and see if it continues to happen.
[SuperR Kitchen] SuperR.:
v2.0.8.2 (Donate version)

Changes:

Support for adding/removing forcefdeorfbe (the new forceencrypt found in N roms).

Changed the adding/removing forceencrypt method.

dm-verity - only look for and replace verify on /system lines in fstab.

v1.0.7.6 (Standard version)

Changes:

Support for adding/removing forcefdeorfbe (the new forceencrypt found in N roms).

Changed the adding/removing forceencrypt method.

dm-verity - only look for and replace verify on /system lines in fstab.

[MENTION=1162986]Captain_Throwback[/MENTION] - Maybe this will help :)
[SuperR Kitchen] Captain_Throwback:
FYI - You'll want to include /vendor lines for your verity check as well ;).

I'll give this a shot momentarily.
[SuperR Kitchen] Captain_Throwback:
Well, I just attempted to restore the forceencrypt flag (which it says it did successfully), but it still says forceencrypt is disabled. So it must be something on my end. I'll try starting fresh.
[SuperR Kitchen] SuperR.:
If you did not remove it with the new version, it will not restore it. Due to the new forcefdeorfbe, the new version adds a file to your 00_project_files directory so it knows what to restore. If that file does not exist it will skip it.
[SuperR Kitchen] migascalp:
Same for me with forceencrypt. ROM HTC 10 v1.30.
[SuperR Kitchen] Captain_Throwback:
Okay, I did a fresh checkout of the kitchen, and did a clean extraction of the 1.53 RUU to a new project folder. Upon extracting the boot.img, the kitchen reports that forceencrypt is disabled (which it isn't). So that explains why it isn't disabling it, at least. But it doesn't explain why it isn't detecting it properly.
[SuperR Kitchen] SuperR.:
The only thing I can think of is that maybe the kitchen is finding the wrong fstab. Can you open a terminal to your ramdisk directory and run the following command?

sudo find ! -type l | grep -v "goldfish\|ranchu" | grep -m 1 fstab

The output is the fstab that is being used. Thanks
[SuperR Kitchen] migascalp:
azerty@azerty-XPS-8900:~/Documents/Kitchen/superrs-kitchen2/superr_pme_1.30.401.1/bootimg/ramdisk$ sudo find ! -type l | grep -v "goldfish\|ranchu" | grep -m 1 fstab
[sudo] Mot de passe de azerty*:
./charger.fstab.qcom
azerty@azerty-XPS-8900:~/Documents/Kitchen/superrs-kitchen2/superr_pme_1.30.401.1/bootimg/ramdisk$
[SuperR Kitchen] SuperR.:
well, that is the problem on yours for sure. Try this command

sudo find ! -type l | grep -v "goldfish\|ranchu\|charger" | grep -m 1 fstab
[SuperR Kitchen] Captain_Throwback:
That works.

I wonder why you didn't have this issue? You're using the exact same RUU that I am :confused:.

$ sudo find ! -type l | grep -v "goldfish\|ranchu" | grep -m 1 fstab
./charger.fstab.qcom
$ sudo find ! -type l | grep -v "goldfish\|ranchu\|charger" | grep -m 1 fstab
./fstab.qcom
[SuperR Kitchen] migascalp:
azerty@azerty-XPS-8900:~/Documents/Kitchen/superrs-kitchen2/superr_pme_1.30.401.1/bootimg/ramdisk$ sudo find ! -type l | grep -v "goldfish\|ranchu\|charger" | grep -m 1 fstab
./fstab.qcom
azerty@azerty-XPS-8900:~/Documents/Kitchen/superrs-kitchen2/superr_pme_1.30.401.1/bootimg/ramdisk$
[SuperR Kitchen] SuperR.:
I used the ruu from the link you provided. Not sure why, but it detected correctly for me. It detects correctly with this change too so an update is on its way :)

That's the one :)
[SuperR Kitchen] SuperR.:
v2.0.8.3 (Donate version)

Changes:

dm-verity - Also look for and replace verify on /vendor lines in fstab.

Fixed fstab detection.

v1.0.7.7 (Standard version)

Changes:

dm-verity - Also look for and replace verify on /vendor lines in fstab.

Fixed fstab detection.
[SuperR Kitchen] migascalp:
forceencrypt correctly detected for me now.

Thank you
[SuperR Kitchen] Captain_Throwback:
Yes! It's working properly now. Thanks! :)
[SuperR Kitchen] bcrichster:
Ur intense, Bro! [emoji41]

Sent from a Dirty Unicorn's LolliPop! N9515
[SuperR Kitchen] sokkoban:
First of all thank you for this great work!!! I created my custom rom with your kitchen :)

Can you help me about plugin I can't download from this site every time give me the following error
[SuperR Kitchen] sefrcoko:
Hi SuperR, I just sent a donation your way :)

Confirmation Number: 4RS10630JH502471A (via PayPal)

Gitlab username: sefrcoko

Thanks!
[SuperR Kitchen] SuperR.:
The error is because either 1) you are not a member of the donate private repo OR 2) you are not logged in to gitlab.

Added, thanks :)
[SuperR Kitchen] bigrammy:
My First little Plugin:

A simple kernel.elf unpacker I made because the kitchen seems not to detect the kernel.elf "after" you have created your superr_project so I could not unpack it using the kitchen.

I have used "zenity" in my plugin which comes as standard on Ubuntu but not sure about any other distros. (Pretty sure the purists wont like it :laugh: )

Usage:

Follow the instructions.

If you have a boot.elf instead simply rename it to kernel.elf

Download Here

[MENTION=5787964]SuperR.[/MENTION]

I am not sure how to use gitlab or if we are supposed to push the plugins to yours somehow :eek:

I think I made it private and just imported your list of users so in theory anyone who as access to yours has access to this?

Let me know how and where I screwed up if I did same goes with the code.

This is all so Newwww :silly:

Any feedback is welcome.
[SuperR Kitchen] Er. Aditya:
Hey great dev i wanted to know that is this possible to make a script that downloads a zip from somewhere say mega and extract into system ??
[SuperR Kitchen] bcrichster:
Now you're being Str8 lazy. [emoji23]

Sent from a Dirty Unicorn's LolliPop! N9515
[SuperR Kitchen] Er. Aditya:
Sorry bro ... i shoukd have tried first
[SuperR Kitchen] bcrichster:
[MENTION=5787964]SuperR.[/MENTION] Lost extraction support for tar.a files, have to manually rename.

I've also learned a while back that the boot.img needs Bumped after checking it for by-name on LG stock ROMs (KK) for some reason. Dunno if ya fixed it or I ever mentioned it cuz I was having PC issues & I've been trying to redo the PC situation since.. Working on a stock LG ROM, will be uploading the device file in a bit.

[MENTION=5750672]Er. Aditya[/MENTION] your msg box is full, can't send.

Sent from a Dirty Unicorn's LolliPop! N9515
[SuperR Kitchen] Er. Aditya:
All cleared now...
[SuperR Kitchen] SuperR.:
Nice work man :) The first user submitted plugin :highfive:

Some things:

1. It might be nice to end up with the bootimg directory inside the current rom directory instead of superr_elf. This way the kitchen can make edits to the ramdisk after it is unpacked. However, if there is no elf repack it doesn't matter anyway lol

2. You can look at the code in the apktools plugin to see how I did the zenity check if you want to make sure the user has zenity before running the plugin.

3. zenity produces ugly errors (not your fault) that can easily be avoided. Here is a fixed example line from your script that does just that:

zenity --info --text="Simple kernel.elf Unpack Plugin by @bigrammy\nfor superr-kitchen" 2>/dev/null

The "\n" is new line in the zenity window fyi

4. Importing the users from superrs-kitchen2 or my plugins repo will work until I add new users. Then you will need to import again (seems like a pain for you). I will investigate options regarding some sort of donate version community repo and will let you know what I come up with.

5. The download link may be better going to the direct download. In this case it would be:

https://gitlab.com/bigrammy/plugins/raw/master/kernel-elf-unpack-plugin.zip

Plugins can do anything you want. You can check the nexus_dl plugin code for an example of how to download files :)

I will look into these things as soon as I get a chance :)
[SuperR Kitchen] bcrichster:
Here's the LG Zone2..
[SuperR Kitchen] bigrammy:
Thanks SuperR :o

Many thanks for the feedback and suggestions it's much appreciated :good:

1. Yes I did think about that but as you have said the kitchen and I cannot successfully repack the .elf (at least for my mediatek device that is) so rather than potentially confuse the kitchen during the repacking of a project I thought it best to keep it separate for now. You can always move the bootimg folder to the project for any ramdisk edits. :good:

For my own use I basically have a mediatek boot.img stripped of the ramdisk and kernel I then add the kernel and ramdisk from the .elf and repack it. ;)

2. I will check that and add it :good:

3. Not sure about this one as I don't see any errors in my terminal when I run the script just a single echo output from 7z.

This is the entire out I get when the plugin has run :confused:

Choose an option and press ENTER: 13
13059 blocks

I guess you are running your terminal in some kind of verbose mode which shows more than mine does.

I go by the saying that ignorance is bliss :laugh:

My other planned plugins are far far larger than this one and rely on zenity quite heavily so if it's making a mess in the background I may need to seek your advise further on this to quiet it down unless adding the >/dev/null to the end of all the zenity stuff does the trick. :o

4. Thanks :)

5. I will edit that now :good:
[SuperR Kitchen] SuperR.:
Here is what I came up with.

If you wish to contribute plugins and you are using the donate version, you can follow the steps in this link.

Basically, I created a new branch in the plugins repo called "user_contrib". Just ask me for developer status which will give you access to git push to this branch. There is a small risk since everyone with developer status can delete the contents of the branch if they accidentally delete all the files locally and then git commit. That said, make sure you have a backup of your plugin outside of your local git repo :)

Once your plugin is pushed, you can create a plugin post (preferably in the same format as the current plugins listed in post #5) and I will add it to the repo on post #5.

edit: [MENTION=3924647]bigrammy[/MENTION] - You now have developer status in the plugin repo. Let me know how it all goes :)
[SuperR Kitchen] SuperR.:
Here are the zenity lines fixed with no errors:

zenity --info --text="Simple kernel.elf Unpack Plugin by @bigrammy\nfor superr-kitchen" 2>/dev/null
zenity --question --text="Please Choose your kernel.elf in the next window\nPress YES to Continue or NO to Exit" 2>/dev/null
elf_path="$(zenity --file-selection 2>/dev/null)"
zenity --info --text="kernel.elf Unpack is complete.\nPlease see superr_elf.\nWarning!! superr_elf will be wiped\nthe next time you run this plugin" 2>/dev/null
[SuperR Kitchen] Jonny:
[MENTION=5787964]SuperR.[/MENTION] can we have an option to detect the by-name parts from a recovery.img? I wrote a post about a week ago explaining why.

http://xdaforums.com/chef-central/android/kitchen-superrs-kitchen-t3202296/post66939108#post66939108
[SuperR Kitchen] bcrichster:
I thought it was already there..??

Sent from a Dirty Unicorn's LolliPop! N9515
[SuperR Kitchen] bigrammy:
Thanks SuperR

Please Just make the changes and add it to your repo for now while I get my head around the gitlab stuff you posted :eek:

I trust you 100% and I am more than happy to learn from the master. :o

Hopefully we can do this stuff in the gitlab prior to the commit (get me talking like I know what I am doing :laugh: )

---------- Post added at 01:12 AM ---------- Previous post was at 01:03 AM ----------

Hi.

I spotted this earlier but what mediatek device are you using??

Seems really strange to use different paths. Could you upload the boot and recovery for me to take a look?
[SuperR Kitchen] Jonny:
Elephone P9000 - I know, seems Elephone is lazy and uses the same recovery for M2 as they do for P9000

Unfortunately I'm a student with only a casual job - I have no regular source of income, so I didn't really have much choice when looking for a cheap, fairly high end device.

Boot >>> https://mega.nz/#!ZhwH0QhA!yqA_se7hDXTMF1Rzt9q4CkX8PVDL_1nUuupETc4e-5k

Recovery >>> https://mega.nz/#!hwY3iKgS!q7Kr26HoDD55Pkv-34TSpDK7innfibQVhRdBFEnDDsE
[SuperR Kitchen] bigrammy:
Nothing wrong with that device and nice work on the custom ROM BTW :good:

I will take a look tomorrow AM and see if I can see what is going on in there. I assume you have TWRP as a custom recovery already?
[SuperR Kitchen] SuperR.:
What is not working about sparse dat? If it is giving you an update-binary error, try the newest kitchen (v0.9.1.2) as it should fix that problem for you.

Did you unpack/repack the boot.img before building your rom? If so, please try it with the original boot.img and let me know if the wifi issue is gone.
[SuperR Kitchen] reefuge:
will update my linux machine as on the windows 10 pc at moment - last i tried 9.0.9 - not touched boot.img using stock

will try the v9.1.2 and try sparse.dat build again - i know sparse.dat works with my custom recovery as I can install cm12.1 etc

cant remember sparse.fault - just error when trying to flash - will report back later as off to try now...
[SuperR Kitchen] Dior DNA:
silly question perhaps ...

Do the deodexed apk files result in ART style dalvik cache on lollipop?

(perhaps ART style is only one on lollipop anyways?)
[SuperR Kitchen] hohassan444:
thanks in advance , i will try tomorrow
[SuperR Kitchen] reefuge:
sparse.dat error is as follows

Extracting system.....

blkdiscard failed: invalid argument

E: Error executing updater binary in zip '/sdcard1/test.zip

now gonna do metadata type to test wifi problem
[SuperR Kitchen] Dior DNA:
sorry to answer own question : yes, one gets ART style dalvik cache on lollipop
[SuperR Kitchen] bcrichster:
[MENTION=718594]superr[/MENTION] - 11k views & #1 sitcky in Chef Central / Android!! Whoo hoo!!

Gratefully sent from my Rooted N9510 JollyRoger4G
[SuperR Kitchen] SuperR.:
v0.9.1.3

Changes:

The Kitchen will now find all odex files within your rom and deodex them no matter where they are.

Changed the Choose a different project menu to single column.
[SuperR Kitchen] reefuge:
REF: MOTO G 2nd Gen (XT1068)

Semi solved sparse.dat still not working - if using a stock system.img taken from OEM motorola firmware.zip, it fails to identify as lollipop and does not offer sparse.dat as a build option

when testing I do NOT alter roms from stock - just to test the build methods are working

JUST had a light bulb moment.... I am making the system.img on my windows PC from sparse_chunks x 4 (so could be my fault)

Can your kitchen handle sparse_chunk conversions?

but sparse.dat works if you use system.ext4.tar from custom recovery backup...........! This is the excact same img as above but just allowed to boot once to make a backup in recovery (so as clean as can be) it still fails to install though, but at least it builds using system.ext4.tar

the wifi problem still does not lock on using stock boot.img (tried sparse.dat and metadata ways) going to get the boot.img from a clean twrp backup and try that

will point out I'm having more fun than I've had in ages trying to figure this out .... lol
[SuperR Kitchen] SuperR.:
v0.9.1.4

Changes:

Added support for sparse chunks.

Added assert changes to custom zips and boot/recovery zips.

Some minor UI changes
[SuperR Kitchen] not-i:
Awesome mate
[SuperR Kitchen] SuperR.:
Can you provide a link to the system.img from the OEM moto firmware?

It can now :)

I think this post had your same issue. I read through it and the only thing of value is why the flash is not working...not enough space in the system partition. Which means the system.img we create for use in sparse dat rom is too large. The kitchen needs to set the size before creating the img. So far I use the size of a system.img in the project directory if it exists (which should normally work well), and if not I use the size of the current project system directory (I think this is the problem area). I do not have a better way to do this so if anyone has a suggestion please let me know. I could make users plug in the device and get the info from there but not everyone has the device they are working on.

If a clean stock boot.img still has the same issue I am not sure what to suggest. If you figure out the problem please let me know so I can fix it.

This part I am especially happy to hear :)
[SuperR Kitchen] hohassan444:
it works now well with my stock rom....but if try to port rom to my device...the rom builds without problems , but during install it gives me error ;

1 : sparse_dat....error is BLKDISCARD INVALID AEGUMENT..installation failed

2 : set_perm or set_metadata...error is some symlinks failed...in this case if i replace metainf folder with another known to flash normally with ported rom..it flashes without problems...so i suspect some errors in updater-script file. I think it is better to have some control over symlink creation during rom building.

thanks in advance
[SuperR Kitchen] SuperR.:
1. I just spoke about this in my last post. I am trying to figure out a better way to get the system partition size (or at least not too large but still large enough to fit the system directory contents). I am testing some theories now.

2. I am curious which symlinks are failing since the kitchen only uses symlinks obtained from an existing source. The source changes depending on the files used during extraction. If it is a pre-existing flashable rom it will use the existing symlinks from that rom's updater-script. If it is a system.img, tar, dat, or win it will find all the symlinked files and create symlinks for them. In other words, this kitchen does not use "static" or "common" symlinks" at all so I can't imagine what is failing. Can you provide a recovery log after trying to flash the rom?

What control do you want?
[SuperR Kitchen] hohassan444:
1- how can i get recovery log ?

2 - ..in archikitchen the same problem occur if i select specific symlinks from within the rom..but during building rom there is option to add generic symlinks in addition to symlinks from within the rom..in this case installation proceed without problems.

thanks again
[SuperR Kitchen] SuperR.:
v0.9.1.5

Changes:

Adjusted the way we determine the system.img size and system size for sparse dat creation.

UI enhancements

I am not sure if this will help anyone but it has a decent chance I guess :p

I added a warning if you don't have a system.img in your project directory. At least now if it does not work you were warned ;)