yashsingh1/xdaforums huggingface dataset:
[SuperR Kitchen] Androidwizzard:
[MENTION=5787964]SuperR.[/MENTION]

If you don't find anything relevant in updater-script I have found other things starting with extraction of system.img of Samsung firmware -> a bunch of libs get lost which come in about a dozen apps.

Those apps also don't get deodexed properly - surprise?

It has been too late at night but 2 apps I remember: Bluetooth and Nfc

If you or someone else is interested in I will post in detail tonight.
[SuperR Kitchen] :
Thanks for the hardwork you are doing for us Sammy guys. Great to see people supporting SuperR rather than complaining. My knowledge isn't as good as yours but will gladly help best I can
[SuperR Kitchen] thgxda:
Hi Androidwizzard,

I didn't touched the "root"-option in the kitchen at all, it just is there, saying that my device already is rooted. I would expect, that it would not touch that at all and I don't have an idea if my little change (set 'disabled' to 'enabled') in the init.cm.rc could cause the problem (I even do not know if this would solve my problem at all):

# sysinit (/system/etc/init.d)
service sysinit /system/etc/init.d
user root
oneshot
enabled

Well everything I want, is a working init.d in CM, nothing else. Unfortunately the CM13 build for my device should have it included, but it is not working :(

Thanks,

kind regards,

thgxda

---------- Post added at 11:27 AM ---------- Previous post was at 11:13 AM ----------

Hi SuperR,

can you explain me how I can extract this number?

Or is it the same for all cm13.0 builds, so I don't have to change it?

EDIT:

Seems to be, that I found it by myself in the repo and that it is always the same for CM13.0:

https://github.com/CyanogenMod/android_device_motorola_peregrine/blob/cm-13.0/BoardConfig.mk

# Partitions
BOARD_BOOTIMAGE_PARTITION_SIZE := 10485760
BOARD_RECOVERYIMAGE_PARTITION_SIZE := 10485760
BOARD_SYSTEMIMAGE_PARTITION_SIZE := 1157627904
BOARD_USERDATAIMAGE_PARTITION_SIZE := 5930598400

The "cm_peregrine" is generated by the Kitchen, when reading a new ROM. So I have to modify it before building a new one.

Thank you very much,

kind regards,

thgxda
[SuperR Kitchen] Androidwizzard:
I'm getting angry and impatient sometimes which I really regret, so apologies to all who might feel offended by my posts.

Now to you [MENTION=7144757]thgxda[/MENTION]

I haven't the slightest idea what the kitchen does when getting to extract an already finished rom.

That's why I'd prefer a simple tool which extracts the image only and you should be good to go.
[SuperR Kitchen] thgxda:
don't worry I about, I don't have any problems with this :)

That is what I prefer too and this was my first try too, but the image I build didn't worked after I flashed it on my mobile.

Thanks again,

kind regards,

thgxda
[SuperR Kitchen] manojpy:
[MENTION=5787964]SuperR.[/MENTION] I am currently on custom rom 6.0.1 made by your masterpiece. This is for nexus 6. Really appreciate your work. Thanks

The issue I face is while set_meta and set_perm create a flawless bootable rom, sparse_dat creates a 12.5 mb file with no system new dat. After giving all instructions, when asked to connect rooted device through Adb, within seconds, it says your rom is created but turns out to be 12.5mb. happened with earlier versions and 9.6.7 also. Can you tell me if I am doing something wrong.
[SuperR Kitchen] thgxda:
Hi everybody,

so finally I was successful, CM13 with root and, as far as I tested right now, with working init.d :)

First what did not worked for me:

- any modifications in the init on my mobile, these changes are withdrawn with the next boot from the content of the ramdisk

- any scripts to fix "Xposed", "set Selinux to permissive" or whatever, like this one: Xposed Issues on Nexus 6? Try this! or here or that one Make persistent changes to init.rc

What was necessary before building the new image:

- change "cm_peregrine" to "peregrine" under "ROM Tools" - "Asserts ..."

- disable/enable root once under "ROM Tools" - "Root/Unroot ROM ..."

- in "Boot/Recovery Tools" do "Unpack boot.img"

- edit the bootimg/ramdisk/init.cm.rc and change 'disabled' to 'enabled':

# sysinit (/system/etc/init.d)
service sysinit /system/etc/init.d
user root
oneshot
enabled

- then "Pack boot.img, keep ramdisk" (or "delete" seems to be doing exactly the same)

- save the old ramdisk.gz and rename the new one ramdisk-NEW.gz (or similar) to the original name

- finally create your new ROM with "Build Menu" - "Build full ROM Zip", do the align and set the system image size manually to 1157627904 (only valid for CM13.0, you find it in the BoardConfig.mk as "BOARD_SYSTEMIMAGE_PARTITION_SIZE := 1157627904")

- copy the new image to your mobile, boot into TWPR and flash it, as "others" say, do not install SuperSU via TWPR after flashing the ROM, this will result in a boot loop of CM!

More tests has to be done, thanks to everybody for the help and a special thanks to SuperR for his support,

kind regards,

thgxda
[SuperR Kitchen] jazzespresso:
samsung stuff pain in a.....

i was finally able to create deodexed rooted ROM using your tool, but a lot of things manually needs to be taken care of, at least in my cases.

Deodexing works OK (kind of), but google apps does not plays nice when they deodexed, so I removed them (the ones actually you can download from play store).

however, deodexing part, I actually got better success using [MENTION=6242674]svadev[/MENTION] SVADeodexerForArtx32.zip tool (updated with oat2dex v0.85 version - https://github.com/testwhat/SmaliEx/releases/tag/0.85)

so once your tool created build zip, I use SVADeodexerForArtx32.zip tool to deodex app, priv-app and framework, and then manually copied back to superr's build rom's system folder and then removed google apps.

there are a lot of samsung users, so whatever you add or fix would create ultimate tool for creating samsung base ROMs, so kudos to you:good:
[SuperR Kitchen] SuperR.:
Ok Samsung users. Time to test. Added some things from the updater-script posted by [MENTION=5564860]Androidwizzard[/MENTION], and improved a couple things in general while creating the set_metadata lines. Let me know how it goes :)

v0.9.6.8

Changes:

Attempt to fix set_metadata issues on Samsung devices and possibly some others
[SuperR Kitchen] Dior DNA:
I have already once reported, this is just a refresh in case

someone has seen same.

Basically I deodex Jiayu S3 Germany custom LP 5.1.1 perfectly fine

with this tool. It is a Mediatek SoC. So no complaints for this great

tool.

But somehow I can send but not receive SMS with the deodexed

firmware. I can receive SMS with original one.

I wonder if, meanwhile, similar behaviour is experienced by anyone

else. And, or, if there is a workaround. Perhaps I could skip to

deodex a few apk and/or jar but I am not sure which ones.
[SuperR Kitchen] enotar:
I will try metadata tonight and report

Thank you for that
[SuperR Kitchen] Captain_Throwback:
[MENTION=5787964]SuperR.[/MENTION]

Is it possible to have the kitchen pull the proper metadata directly from a booted up, rooted device? You'd just need the uid, gid, permissions and context from the files in /system/bin, system/xbin, and some files in /etc and /vendor, right? Wouldn't that help fill in some of the blanks for devices where the kitchen doesn't know what to set? Also, how about using file_contexts from the boot.img ramdisk to validate the default file contexts for the metadata lines? I know some of the defaults in the kitchen use a different context than some of my files (probably some HTC-specific stuff). Just wondering if those options were considered. I know in the case of the newer HTC devices, there's no easy way to build a ROM from scratch, i.e. not existing, working updater-script, so building from scratch, with the proper metadata and getting everything to work can be quite challenging. I want to thank you for all the hard work you've put in on this kitchen - in fact, I think I'm going to send a donation your way.
[SuperR Kitchen] SuperR.:
Thank you :) You are right. It is challenging to create a rom from scratch. Even more to create 100's of roms from scratch from all manufacturers and Android variations as this kitchen is attempting to do lol.

As it is right now, the kitchen has a database with set_metadata lines. There is no context set in the database (#CONTEXT placeholder). If the line in the database matches a file in the rom, the line is added to the updater-script and the context is changed according to the file_contexts file pulled from the boot.img. If the context does not exist in file_contexts but the file exists in the rom, then it is given the standard "u:object_r:system_file:s0". This method should work out well once the database is populated with the manufacturer specific metadata. Using a method that gets all the info from the phone is less desirable as not everyone has the device they are building roms for.

Try out the new version and let me know how it goes. I added the M8 lines so you may have better luck now :)
[SuperR Kitchen] Captain_Throwback:
I'll give it a shot on M8 again, but since I do have a working ROM using sparse_dat (which is preferable anyway), I think I'll focus my efforts on A9, which appears to be a bit more tricky, especially since I know there are even more lines that that one requires that I don't have any reference for.

I was, however, trying to convert this ROM that installs system.img via dd in the updater-script (!) to sparse_dat format, and I was having trouble getting it to build. In fact, I had a similar issue to what [MENTION=4685292]manojpy[/MENTION] reported where the kitchen builds for a few seconds, says it's done, and the resulting file is less than 20MB.
[SuperR Kitchen] STEVE_MARS:
Hi,

I´ve been used Superr kitchen since three months ago, without problem. My notebook had broken and I install Ubuntu 15.10 to another one, Toshiba Core2duo with 4 years.

And now, in "new" notebook, with severals kitchen version (last 9.6.8, for example but happens on all versions), when I build a full zip ROM only make a 10 mb size, or 14, either one chance 40 mb. Don´t work, obviously.

What´s wrong?. Thanks in advance.

P.D. Sorry for my English, I´m Spanish.
[SuperR Kitchen] SuperR.:
This is an issue with the system partition size the kitchen is using. If you used adb detection when you get the small zips, try system.img or manually enter the correct size in bytes. One of those options will surely work for you :)
[SuperR Kitchen] Captain_Throwback:
I tried the manual entry and system.img and the result was the same.
[SuperR Kitchen] STEVE_MARS:
Hi, SuperR. Thanks, you´re the king :o.

It´s strange. My notebook problem are overheating, and I semi-solved it. In this notebook, all work fine, without problem.

But I copy all the kitchen folder to older notebook, and when build ROM say that it´s finished at 10, 14 or 20 Mb. I don´t undestand, why in one notebook all works and in other don´t?:eek:
[SuperR Kitchen] bcrichster:
You may need to do an actual Clone so that your Notebook can build the binaries from within itself, just remember to make sure you have all dependencies met in the new notebook first
[SuperR Kitchen] STEVE_MARS:
Yes, but if all dependencies are not install in new notebook, not work all except the .zip size, not?.

I´m not sure if I explain me in my bad english...
[SuperR Kitchen] bcrichster:
No. Don't half@$$ it or copy anything but project folders, reClone the Kitchen (from bitbucket) into your new PC after making sure your dependencies are met. Try again.. Some PC's may be similar models but sometimes a slightest change in chips/boards can make a difference. Those dependencies are crucial to all aspects of the Kitchen, not just one function or another as they all depend on each other..
[SuperR Kitchen] SuperR.:
Very strange. I downloaded the rom you linked and extracted the system.img and boot.img manually. Then I used the kitchen to extract the system.img. During the process my first problem occurred when there was no mount point listed in fstab for /system :eek: (I have added a last ditch effort to the kitchen to look for by-name/userdata if all else fails so that is working now). Once that was cleared up, I went to the build menu and chose to build full rom zip. I chose the system.img partitions size detection since I do not own the device and had no issues at all. I am not sure at this point what the difference is on my machine. You could try to use this number as your system partition size "1073741824". I retrieved it from the HTC M8 AOSPA repo.

edit: are you on 32-bit Linux by chance? Sparse dat will not work if you are. rimg2sdat is a 64-bit binary and is closed source :(

1. I would hardly call this a problem. If you are not going to put anything in your /data directory, delete it. Problem solved :)

2. Yes. If one of three does not work, try the other two :)

For other variants, sometimes all that needs to be changed is the asserts. Sometimes other things too. Most of the time the same model device on a different carrier have the same partition size. I am not magic so I will not be able to provide all the changes for all the variants of all the models :p I suggest getting someone that has the device you want to build roms for to get you the files/information you need :)
[SuperR Kitchen] SuperR.:
v0.9.6.9

Changes:

General performace improvement by removing many uneeded pipes and commands.

set_metadata will now only be allowed for KitKat and newer roms since it will not work on older ones.

When detecting by-name from boot.img, if we can't find /system in fstab we will look for /data instead.

sparse_dat is no longer allowed on 32bit Linux since it will not work.

edit:

v0.9.7.0

Changes:

Fixed one last place where sparse_dat could be selected on 32bit Linux
[SuperR Kitchen] enotar:
0.9.6.8 we have Wifi now. Good news. Drive still give trouble.

0.9.6.9 works well with metadata and Samsung Wifi is good.

thank you for fixing

My problem is now to update apps
[SuperR Kitchen] thgxda:
Hi all,

I'm almost "done", in "either way", while everything seems to work with my CM13.0 kitchen-build, means root, init.d, autostart crond, a show stopper just popped up :(

"pm" is not working anymore, when I make a "su -" after login via "adb shell", same for "logcat", that only produces an empty output:

# /system/bin/pm list users
Error: Could not access the Package Manager. Is the system running?

Without using "su" it works as it should and "logcat" also lists the log as expected.

Any idea?

Thanks a lot,

kind regards,

thgxda
[SuperR Kitchen] Captain_Throwback:
Nope, 64-bit all the way.

But it turns out after refreshing the kitchen and re-extracting the images, I'm able to build a ROM that boots. The problem is, is stays stuck at the end of the bootanimation and never finishes initializing. I assume that somewhere in the building process, something gets broken, but I have no way to tell where, since adb isn't working on the device for me to pull a logcat. If I just flash the original ROM, which uses dd to flash the boot and system images, the ROM boots fine. Any ideas on where to look?

I'm about to try an A9 ROM now and see if that even boots. None of my previous attempts did. Oddly, it seemed to be related to the unpacking of the ramdisk as root - if I unpack it the "normal" way, the boot image appears to work, but when using the --sudo option, it wouldn't boot. That makes no sense, since they're all Marshmallow ROMs I'm flashing :confused:. Once I have more info on this, I'll post back. Thanks again for all your help.
[SuperR Kitchen] SuperR.:
Sadly I don't know what the problem is or where to look. The conversion you are doing is pretty straight forward. One thing you could try is to see if the system.img the kitchen creates works before converting to sparse dat. You can test by creating a system.img from the build menu, and replace the one in the rom zip that uses dd to flash. If it works properly, then the issue is in the sparse dat creation. If it does not work, then something is going wrong when creating the system.img. At least it will narrow down the things to look at a bit. Good luck :)
[SuperR Kitchen] Captain_Throwback:
I'll give that a shot. At least it'll help narrow down where the issue is, even if nothing can be done to fix it.

Also, I now remember the problem on A9 - it wasn't the inability to create a sparse_dat zip - it was the inability to flash it. The recovery log gets up to "Extracting system" and just gets stuck there forever. Relevant portion of the log is below - not sure what I can do about that besides try set_metadata instead, which I know will be missing symlinks.

Installing '/external_sd/01_Aero/Sprint_A9_stock_CPTB.zip'...
Checking for MD5 file...
Skipping MD5 check: no MD5 file found
I:Zip contains SELinux file_contexts file in its root. Extracting to /file_contexts
I:Legacy property environment initialized.
minzip: Extracted 2 file(s)

Sprint A9 stock CPTB Installer
Built with SuperR's Kitchen

about to run program [/tmp/install/bin/backuptool.sh] with 2 args
Extracting system...

blockimg version is 1
erasing 811008 blocks
writing 261840964 blocks of new data
[SuperR Kitchen] SuperR.:
I am not sure what can be done with that sparse dat flashing problem. One option is that I could add another "perm type" that flashes system.img using dd like the rom you are working with. It is not ideal but it may get the job done.
[SuperR Kitchen] bcrichster:
That's a sweet idea!
[SuperR Kitchen] thgxda:
Hi SuperR,

do you have an idea why your kitchen "mess up" the CyanogenMod-root, even if you do not touch anything according "root"?

I was looking through you superr-script, but couldn't find the reason for that.

Maybe an option would be, to include a possibility to keep the system.img and just to rebuild the boot.img before building a new zip-file?

Later I will try to build a new ROM with the boot_tools manually again, may be s.b. can me give a hint how to this correctly.

Thanks a lot,

kind regards thgxda
[SuperR Kitchen] bcrichster:
instead of making him do extra work, just remove the system.img from the project folder before any modifications then just re-add the system.img to your zip after building?
[SuperR Kitchen] Captain_Throwback:
Well, it may not be necessary to fix my problem after all, as set_metadata appears to create a fully working ROM for me now on the A9, with your updater-script additions from the M8. I did find a few additional files in my ROM not included that do have defined contexts, but they may not be necessary. I'm adding them now to see if they break anything.

So, thanks for making those updates - I think that explains why WiFi wasn't working for me before.
[SuperR Kitchen] thgxda:
Hi bcrichster,

I was thinking to do so too, but I'm not doing any modifications in the system.img at all. So I assume, that these mods are doing during the final build of the new ROM, so a backup/restore will not help really.

In addition I think, that the kitchen should not touch the system.img at all, when not modifications where done.

Anyway I will look in this again!

Thanks a lot,

kind regards,

thgxda
[SuperR Kitchen] bcrichster:
It actually shouldn't mess with the original image anyways.. Just the system folders that get extracted from said image. Try building your zip and change out the new system.img for the old one and see if it flashes? May be a repacking issue we're unaware of.. That'll help spot it too
[SuperR Kitchen] Kenny Bee:
[MENTION=718594]superR[/MENTION] please help me im newbie how to solver this :confused:

View attachment 3581518
[SuperR Kitchen] SuperR.:
I have added the lines you posted and they will be in the next update.

We will need separate lines for the files if they are in separate locations. Only the lines that refer to files that exist in the rom are used in the updater-script so it does not matter how many lines the database has. In other words, a samsung rom will not end up with htc specific lines because the files they refer to don't exist in the rom.

cygwin is not supported and will not be supported by me ever. Run Linux :)
[SuperR Kitchen] Kenny Bee:
so how to run ur programmer im use cmd and powershell also did not working tell me im on windows 10 pro :rolleyes:

and im run cygwin64 again i got this error

View attachment 3581597
[SuperR Kitchen] bcrichster:
CYGWIN IS NOT SUPPORTED NOR WILL IT EVER BE!! [emoji43] So plz stop asking him to do something he's REPEATEDLY stated he won't do.. You won't get help on Windows Anything from him, he's pouring his heart, soul, and knowledge to help us with his Linux scripts. [emoji41]

But.. If you're ever so stuck with Windows anything and not willing to change or make a Linux Live boot disk, then run a Virtual Box with a Linux iso file and you may have better luck. But working with Android on Windows is like making an adaptor for an adaptor for something completely different. [emoji48]
[SuperR Kitchen] :
Try running linux in a virtual box from osboxes.org if you don't want to install linux. Or you can easily run Linux from a USB stick or dual boot
[SuperR Kitchen] shoey63:
30 posts, heaps of helpful replies, and not once have you pressed the "thanks" button. I personally don't care, but it is good etiquette to show appreciation to those who are trying to help you.
[SuperR Kitchen] thgxda:
Hi bcrichster,

it should not affect the system.img, but it does.

SuperR's Kitchen rebuilds the "system.new.dat" and others just before it packs the new ROM together, so "injecting" the unmodified files from cm13 is not that easy.

I tried to build my own ROM with the bootimg_tools (unzip, split_boot, repack_ramdisk, mkbootimg, zip) again, but my boot.img is to small, so it will not work, no idea why this is the case.

So next try was, just using the boot.img build by SuperR's Kitchen, to replace the original one in cm13, but unfortunately this image is installable but not bootable (probably some meta wrong or whatever, my knowledge building ROMs is quite limited) :(

Last try with doing the other way around, replacing the "system.new..." in a SuperR's Kitchen ROM with the ones from cm13, but this ROM even is not installable :(

So right now I don't know how to go on ...

Thanks a lot,

kind regards,

thgxda

---------- Post added at 03:35 PM ---------- Previous post was at 02:41 PM ----------

PS: Maybe, somebody has a good link, how to build a modified image without using any "kitchen".

Thanks a lot, thgxda
[SuperR Kitchen] Captain_Throwback:
If all you need to change is the boot.img, have you tried using Android Image Kitchen (if it supports your device)? There are several good tools for just modifying boot images. I think [MENTION=4544860]osm0sis[/MENTION] even has a script for injecting init.d into the ramdisk.
[SuperR Kitchen] Captain_Throwback:
Double post (XDA Server error)
[SuperR Kitchen] Captain_Throwback:
Triple post (XDA Server error)
[SuperR Kitchen] Captain_Throwback:
Quadruple post (XDA Server error) - this is ridiculous
[SuperR Kitchen] yunuskk:
Note 4 N910C

SuperR's Kitchen v0.9.7.0

wifi working

init.d working

root working

Using sparse_dat
[SuperR Kitchen] fathergweedo:
Better yet, install it on a USB flash drive (64GB should be plenty for a lightweight distro) and configure it to your specific hardware. Remove any packages you will never use/need to conserve space and install the kitchen. With this option you just boot the Linux distro on the USB and still have access to the built-in storage/files/capacity of your Winbox. Still a dual boot setup, you just don't need to install it directly on your computer.

I have a dedicated desktop running Mint @ home, but a copy of Lubuntu on USB for use on my laptop while @ work or otherwise away. No BS VM's or difficult configuration issues to deal with. I just keep a copy of the kitchen on it and can take a "project" with me.

Best of both worlds ;)
[SuperR Kitchen] SuperR.:
v0.9.7.1

Changes:

Added more metadata for HTC M8 and HTC A9.

Added new perm type - raw_img - lets you create roms that flash raw images.

Better handling of symlink creation when building images.

Added a check when detecting partition sizes with the adb method to make sure we find it before proceeding.
[SuperR Kitchen] Dior DNA:
I skipped files in system/plugin and now SMS receive works. I suspect FwkPlugin.apk