yashsingh1/xdaforums huggingface dataset:
[SuperR Kitchen] SuperR.:
As it is now, the kitchen does not unpack as root ever. It repacks as root (sudo), and cpio includes the -R 0.0 option to give root ownership to the ramdisk files when they are repacked. I have no idea how to do it the best way, but I am happy to make changes if you can guide me in the right direction.

I have heard that repacking as root is not required with the -R 0.0 option. I have also heard that unpacking as root is not required as long as you use the -R 0.0 option when repacking. Since I have no experience here, please let me know if you come up with something :)
[SuperR Kitchen] Captain_Throwback:
I wish I understood better how all of this works. I honestly have no idea. Maybe [MENTION=4544860]osm0sis[/MENTION] can shed some light on it?
[SuperR Kitchen] SuperR.:
[MENTION=4544860]osm0sis[/MENTION] is the person that would know :)

Here is what the kitchen is currently doing for M ramdisk (using gzipped ramdisk as an example)

Unpack:

cd bootimg
gunzip -c boot.img-ramdisk.gz | cpio -i

Repack:

cd ramdisk
find . | sudo cpio -o -H newc -R 0.0 | gzip -9 > ../boot.img-ramdisk-NEW.gz
[SuperR Kitchen] dkionline:
Unpacked 4.4 firmware for S3 today, but file linking is wrong, saw files under 100kb, but theres needed to work properly. I see that prob after 2nd half 2015 firmwares. Maybe some things are changed. Can u take a look?
[SuperR Kitchen] osm0sis:
That's a great idea for avoiding using root to unpack, while also avoiding having to use mkbootfs for repack, but doesn't account for things in the ramdisk that might not be root:root, so you could run into some issues there on some devices.

On AIK-Linux v2.0 I settled for using mkbootfs by default to make sure that most things would theoretically work correctly if someone didn't feel comfortable using root for some reason (paranoid about security or something?), and added a --sudo commandline option to unpack as root to completely preserve the initial ramdisk filesystem and detection to repack as root to do the same.
[SuperR Kitchen] josito_theDH:
It's possible add a rom image in device info with your awesome tool like this?

If someone can teach me how do it I'm very grateful...

Enviado desde mi Nexus 5 mediante Tapatalk
[SuperR Kitchen] SuperR.:
v1.0.0.9

Changes:

All Marshmallow boot/recovery operations will now be done as root.

NOTE: This is trial and error, so let me know how this goes. We can always revert if it does not work out. The other caveat is that all manual ramdisk modifications will need to be done as root since the files will be owned by root.
[SuperR Kitchen] C y a n i d e ~:
after updating the kitchen, added the device name in assert and did what you said but it still gives me this same line:

mount("ext4", "EMMC", "/dev/block/platform/mtk-msdc.0/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0
/system", "/system");

I don't know what is the problem, please help me. Thanks! :good:

edit:

Should I keep the ramdisk when packing the boot.img or delete it?
[SuperR Kitchen] SuperR.:
In your file manager, navigate to and open /kitchen/tools/devices/Lion-5/superr_byname in a text editor.

Replace all text in that file with the following and save the file:

\/dev\/block\/platform\/mtk-msdc.0\/by-name

After that, quit the kitchen, start the kitchen, change perm type to raw_img, then back to whatever you want to use.

I have no idea how that happened, but the above should fix it.
[SuperR Kitchen] ab-samy:
[MENTION=5787964]SuperR.[/MENTION]

Thanks for the great and powerful kitchen keep it up. :)
[SuperR Kitchen] Androidwizzard:
Dear and high valued friend,

I'm just feeling a bit guilty not answering immediately by pointing at the source, but I think as it occurs on unofficial built (not outrolled), not necessary to spend or waste time to try to fix something right now. :highfive:

Just in case here is the LINK
[SuperR Kitchen] bdorr1105:
Hey bud was wondering if you could add the option to choose what SuperSU version you want such as 2.46 stable, and of course the experimental versions like 2.66

Edit: if it is not to much of a pain in the butt that is
[SuperR Kitchen] bcrichster:
Just change out the SuperSu.zip for the one you prefer, and that's it. Run the Kitchen

If I Help, just hit the Thanks button! :cool:

Sent from my Xper!m3nt - ZTE N9515
[SuperR Kitchen] shoey63:
How on earth did you manage to get half of your /system fstab into the mount command in your updater script?

Delete the kitchen, re-download or clone the latest version, and start again.
[SuperR Kitchen] SuperR.:
This is interesting...no issues at all with that firmware on my end. I downloaded, manually extracted the 4.4GB tar.md5, manually extracted system.img and boot.img to the project directory. In the kitchen I chose system.img from the extract menu. It reports as 6.0 and gave me all the perm options. Not sure where to go from here :(
[SuperR Kitchen] sebastiandg7:
Mighty [MENTION=5787964]SuperR.[/MENTION]

In v1.0.0.9 the signed ROM zip size is 0 bytes....
[SuperR Kitchen] Captain_Throwback:
I just signed a ROM and it worked perfectly fine here.
[SuperR Kitchen] Captain_Throwback:
[MENTION=5787964]SuperR.[/MENTION]

With the update for unpacking boot images as root, I now get an error when extracting a new ROM and choosing set_metadata as the type:

Preparing updater-script ...
4140 blocks
rm: cannot remove ‘/home/throwback/android/SuperRs_Kitchen/superr_M8_6.12.1540.4/bootimg/ramdisk/sbin’: Permission denied

I assume that's related to the unpacking as root.
[SuperR Kitchen] sebastiandg7:
Hmm.. Thank for the info. I will download last version clean.
[SuperR Kitchen] bdorr1105:
Thanks for the latest version, anyway that this can preinstall xposed if we add our correct xposed zip? thanks
[SuperR Kitchen] C y a n i d e ~:
Yes, I did it all over again; after building, I tried to sign the zip and it is giving me this error

[COLOR="Red"]Something went wrong with the signing.[/COLOR]

I smell something fishy here. :fingers-crossed:

[MENTION=5787964]SuperR.[/MENTION]

P.S. it is still giving me this error too

[COLOR="Red"]E:error updating binary in zip '/sdcard/flash2-011116.zip'[/COLOR]
[SuperR Kitchen] SuperR.:
You are correct. Two things were going wrong.

1. The file_contexts file was not being copied because it was owned by root.

2. When the kitchen was checking what files exist it was trying to include the bootimg dir. Since it contained root owned files it was complaining.

Both are fixed in the version below. I really appreciate your thorough inspection of the kitchen functions and detailed error reports. Thank you again :)

I don't have any interest in supporting Xposed Framework and that is exactly what will happen if I include it in the kitchen. You will need to sort it out on your own if you want to include it with your rom. Please don't misunderstand my sentiment. I love Xposed and it is one of the first things I install on my devices. Good luck :)

I hope this does not sound offensive, but it seems to be some kind of user error since nobody else has this issue. However, I added Lion-5 to this new release so make sure you delete your /kitchen/tools/devices/Lion-5 directory before updating. After updating the kitchen, the correct Lion-5 by-name info will be there. If it still does not work after that, I have no suggestions.

v1.0.1.0

Changes:

Fixed set_metadata throwing errors on M roms.

Fixed system.img not showing as an option for system partition size if building immediately after extracting from system.img.

Added two devices to the repo.
[SuperR Kitchen] C y a n i d e ~:
Don't worry it doesn't sound offensive to me ;)

yes it did fix the update in binary error, but it is still giving me a bootloop maybe I'm doing something wrong.

ok, so I tried to downgrade my firmware from 3.2 to 3.1 and run the wireless update and then inspect the zip file and managed to get the updater-script(link below).

https://drive.google.com/file/d/0B7cbsEYhU6-cM2ZVVjJvVXpDeEU/view?usp=docslist_api (edited the name)

I hope that it can help, somehow, on solving the bootloops.

Thank you for the kind response :) :good:
[SuperR Kitchen] shoey63:
I also don't wish to offend, but maybe you need to learn a bit more about Linux and android before jumping in here with with problems that no one else seems to have. Your (brief) posting history seems to indicate you are new to it.

Basic Linux knowledge is a prerequisite to have before attempting rom building. This is not a tutorial thread.
[SuperR Kitchen] Captain_Throwback:
Just updated to 1.0.1.0, and I'm still getting errors when choosing set_metadata on the initial extract of the ROM:

Preparing updater-script ...
10980 blocks
rm: cannot remove ‘/home/throwback/android/SuperRs_Kitchen/superr_HIAE_WHL_1.57.90651.4/bootimg/ramdisk/res/images/charger/battery_scale.png’: Permission denied
rm: cannot remove ‘/home/throwback/android/SuperRs_Kitchen/superr_HIAE_WHL_1.57.90651.4/bootimg/ramdisk/res/images/charger/battery_fail.png’: Permission denied
rm: cannot remove ‘/home/throwback/android/SuperRs_Kitchen/superr_HIAE_WHL_1.57.90651.4/bootimg/ramdisk/sbin’: Permission denied
[SuperR Kitchen] SuperR.:
I am not able to reproduce these errors when extracting. Started with a clean project dir and bullhead 6.0.1 firmware. Extracted system.img from kitchen menu, said no to sparse dat, chose set_metadata, and no errors appeared. I am not sure it will matter, but can you send a link to the firmware you are extracting?
[SuperR Kitchen] Captain_Throwback:
Actually I can't in this case. I'll see if I still get that error on a different ROM. It's possible (probable, even) that it's something I did.
[SuperR Kitchen] SuperR.:
Not sure if this will fix your bootloop issue, but it might :)

v1.0.1.1

Changes:

Added recoveryimg dir to the ignored list in case it exists and contains root owned files.

Added missing metadata for Lion-5.
[SuperR Kitchen] Captain_Throwback:
[MENTION=5787964]SuperR.[/MENTION]

Just started with fresh boot and system images and extracted for a new ROM. Now I caught a new error real quick after I declined to use sparse_dat format:

Preparing project directory ...
cat: /home/throwback/android/SuperRs_Kitchen/superr_M8_6.12.1540.4_Dev_Edition/00_project_files/permtype: No such file or directory

And then after entering my ROM name, I chose set_metadata as the perm type, and still got this error:

Preparing updater-script ...
4140 blocks
rm: cannot remove ‘/home/throwback/android/SuperRs_Kitchen/superr_M8_6.12.1540.4_Dev_Edition/bootimg/ramdisk/sbin’: Permission denied

Using kitchen v1.0.1.1.

Link to images: https://basketbuild.com/devs/Captain_Throwback/One (M8)/Dumps/6.12.1540.4
[SuperR Kitchen] SuperR.:
The first error is harmless. The second one is probably harmless. Either way, errors are ugly and I think they are fixed now :)

v1.0.1.2

Changes:

Fixed cat error when permtype has not been created yet.

Fixed rm errors while deleting ramdisk when it contains root owned files.
[SuperR Kitchen] jugih:
Thanks again for this superrr-kitchen.

Just curious, what would be the easiest way to add additional flashable zips to a freshly baked ROM.

I mean in case of adding couple of files to system that would be easy to keep updated with simple flashable zip every now and then.

Kind of same idea that you have superSU and busybox in separate zip that are flashed at the end of the process.

Thanks!
[SuperR Kitchen] SuperR.:
It is not easy, but it can be done. You will need to look at how SuperSU and Busybox set up their META-INF directory and create your own update-binary to do what you want. Then look at how the kitchen sets up the flashing of those zips.

A much easier approach is to create a new project with the files you want to add and use the build custom zip option in the kitchen. The kitchen can create app, priv-app, framework, lib or media flashable zips. It is not set up to be included inside a rom zip, but it will make an update.zip with the contents you choose.
[SuperR Kitchen] SuperR.:
v1.0.1.3

Changes:

Fixed the remaining rm errors while deleting ramdisk on M roms.

Removed a line used for testing a while back.
[SuperR Kitchen] C y a n i d e ~:
Hi [MENTION=5787964]SuperR.[/MENTION]

I saw a flash-able stock rom of my device in a blog and checked its updater-script.

I noticed that it uses this path for formatting and mounting the /system

format("ext4", "EMMC", "/dev/block/mmcblk0p6", "0", "/system");
mount("ext4", "EMMC", "/dev/block/mmcblk0p6", "/system", "max_batch_time=0,commit=1,data=ordered,barrier=1,errors=panic,nodelalloc");

It's different from the generated path when using your kitchen and it also doesn't have an assert line in there :confused:

also should I keep the ramdisk or delete it when packing that boot.img?

anyway here's the link to the stock rom's updater-script

http://www.datafilehost.com/d/41296836

stock rom zip:

https://drive.google.com/file/d/0BxcQMS-B9CkQclJKZTlUTTZ2Nkk/edit

Thanks! :)
[SuperR Kitchen] bigrammy:
Ok bro you need to be really careful :eek:

The stock 3e recovery does not care what what blk number is used and only looks at "/system" it then uses it's own fstab.mt67** to find /system and flash it.

Some custom recovery may not account for this and take the blk number as true so you could end up with a screwed phone eg: flashing /system to your boot partition. (Most will just throw an error but still dangerous to the device)

So on Mediatek factory updates OTA's ignore the mount path

mount("ext4", "EMMC", "/dev/block/mmcblk0p6", "/system",

it's not a true path!! in most cases.

Your phone 100% uses

/dev/block/platform/mtk-msdc.0/by-name/system

you could also try

run_program("/sbin/mount", "-t", "auto", "/system");

but the first should work without any problems.

Next (bootloop) are you wiping the data and cache it's a must when you install any custom rom and the device can take like 15mins to fully boot. :eek:

Next (boot.img) Just try a build without the boot.img only a /system flash no mods or root just add a test.txt file and remove the recovery.from.boot.p file in /system flash it and see if all goes well...
[SuperR Kitchen] C y a n i d e ~:
Thank you so much for clarifying it all to me :) :good:

and to the wiping data and cache, yes I'm wiping it but I'm not quite sure about the waiting time though, I will pay more attention to it next time.

I will try your suggestions later and see if it will help.

Thank you so much! :)
[SuperR Kitchen] SuperR.:
[MENTION=3924647]bigrammy[/MENTION] can you send a link to the kernel.elf?

edit: and build.prop

edit2: I found an xperia c4 boot.elf, unpacked it, got the 0 and 1, renamed 1 to ramdisk.gz and tried to unpack it. Got "not in gzip format". I am not sure what format it is in. The kernel.elf I was using when testing worked fine so I am not sure what to do at this point. If you have another way to unpack the ramdisk, you can copy the file_contexts file to your 00_project_files directory which will allow you to use the kitchen. If you figure out how to unpack it in Linux, please let me know and I will update the kitchen to support it.
[SuperR Kitchen] bigrammy:
Hi bro,

Not had time check the kernel.elf again on windows just yet. :(

I know this device is a one off so if it's just this sony C4 that's affected dont worry yourself about it I can always do things manually in windows. :)

Good news is I ran the kitchen on another Mediatek ROM with a normal boot.img and it built a system.new.dat zip without any problems at all. :good:

I also found a Manufacturer's system.new.dat update zip and pulled the updater.script for comparison funny how they handle the system and boot flashes Pastebin updater.script :confused:

The things you wanted are here copy.com SonyC4 kerne.elf, build.prop, updater.script and binary .zip all in your own time bro Like i said I can always do things manually. :highfive:

PS: I have run out of Thanks Today 8 :(
[SuperR Kitchen] stephanepi:
I'm maybe missing something, but i unpacked the generated image.img and i didn't find busybox neither supersu ?
[SuperR Kitchen] SuperR.:
As I have explained several times before, the kitchen does not add Busybox or SuperSU files to the project. Instead it adds flashable zips inside the rom.zip. There are many variables to deal with (Android version, device architecture, manufacturer, system/systemless, etc.). Flashing the zips with the rom accounts for all of these variables and there is no reason to re-invent the wheel.
[SuperR Kitchen] fhem:
[MENTION=5787964]SuperR.[/MENTION] Not sure if it's me or the kitchen??? I'm working with the latest N9 WiFi images (MMB29S). I was trying to include the vendor image with the rom but the kitchen is not cooperating :confused: . I am trying to use sparse_dat perm to build. It unpacks both the system and vendor images but only builds the system. It worked for me in the past ---> so I'm not sure what is going on. I'm version 1.0.1.2 .. Looks like it dumping out of an "if loop" somewhere.

Thanks for the continued support and great work.
[SuperR Kitchen] SuperR.:
Just downloaded MMB29S, extracted system.img, said yes to extract vendor.img, said yes to include vendor in the rom, and built full rom zip with no issues. Are you sure you said yes to include vendor in your rom? Does the updater-script have vendor included? Does this file exist /kitchen/superr_yourproject/00_project_files/vendorimg ?
[SuperR Kitchen] fhem:
I said yes to vendor image and no the updater-script did not have the vendor included. I am going to delete reclone and start over. Probably should have done that before posting, sorry. I'll let you know the outcome. Thanks for quick response.

Edit:[MENTION=5787964]SuperR.[/MENTION] I apologize for wasting your time. Clean install solved my issue. I would usually do that before posting and I always will in the future. Once again ---- Thank you and sorry.
[SuperR Kitchen] sebastiandg7:
[MENTION=5787964]SuperR.[/MENTION] Extracted stock rom vía adb (Moto G XT1032 5.1 Retail US), deodexed system, zipalligned and builded ROM zip.

The thing is the system mount command enden up like this:

mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/[B][COLOR="Red"]system /system ext4 ro,seclabel,relatime,data=ordered 0 0
/system"[/COLOR][/B], "/system", "");

Isn't it suposed to be:

mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/[B][COLOR="Red"]system[/COLOR][/B]", "/system", "");

Hope this helps!

EDIT: Also happens with system extraction command.
[SuperR Kitchen] SuperR.:
Ok, this is now the second time this has been mentioned on two different devices. There must be a problem somewhere. Did both of you choose the adb method for determining by-name?
[SuperR Kitchen] C y a n i d e ~:
Yes, I did chose the adb method :eek:
[SuperR Kitchen] bdorr1105:
Where so you see this mount at?
[SuperR Kitchen] SuperR.:
v1.0.1.4

Changes:

Fixed by-name detection from device.

Misc error prevention.

[MENTION=7144762]C y a n i d e ~[/MENTION] and [MENTION=5764293]sebastiandg7[/MENTION] - You will need to remove your device directory located /kitchen/tools/devices/devicename. Once it is removed, extract your rom again and by-name detection should work now from device using adb.
[SuperR Kitchen] sebastiandg7:
Still getting the same by-name detected.... I'm going to download the last version apart and try again. I'll be telling you what happen.

EDIT: [MENTION=5787964]SuperR.[/MENTION] Tryed but not succeded. See attachments. How can I help you?
[SuperR Kitchen] SuperR.:
Unfortunately, I am not able to reproduce the problem with my moto g (xt1031).

Please open a terminal, plug your device in to your pc, and enter the following. Then copy/paste ALL the output. This will help me see what is going wrong. Thanks

adb shell "mount" | grep "by-name/system"
[SuperR Kitchen] sebastiandg7:
Here you have it:

sebastian@sebastian-pc:~$ adb shell "mount" | grep "by-name/system"
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0
[SuperR Kitchen] skivnit:
Great work man, just trying it. Very intuitive and easy to go through

Sent from my SM-G925F
[SuperR Kitchen] bigrammy:
Ref: kernel.elf info only

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

I think I may of found the issue for the ramdisk unpacking of the Sony kernel.elf.

Linux Version: 7zip

List of supported formats:
- Packing / unpacking: 7z, ZIP, GZIP, BZIP2, XZ and TAR
- Unpacking only: APM, ARJ, CAB, CHM, CPIO, CramFS, DEB, DMG, FAT,
HFS, ISO, LZH, LZMA, LZMA2, MBR, MSI, MSLZ, NSIS, NTFS, RAR [COLOR="Red"](only
if [B]non-free p7zip-rar package is installed[/B]), RPM, SquashFS, UDF,
VHD, WIM, XAR and Z.[/COLOR]

As you can see Here http://pastebin.com/JwG47bWY when using windows version which works perfectly we have the Copyright statment so I assume we need the Non-Free p7zip-rar package (eg inclusion of copyright statment) for handling the RPM. :rolleyes:

I will confirm later if adding this package fixes the Linux unpacking issue when I am off work on Monday/Tuesday. :eek:

I Can't thankyou enough for your Awesome work bro. :angel:
[SuperR Kitchen] zameer_yus:
There was a problem unpacking your boot.img.

error while unpcaking boot.img

There was a problem unpacking your boot.img.
[SuperR Kitchen] SuperR.:
That is exactly what it should be. Now let's find out why the entire line is being added to your superr_byname file. I am guessing gawk is not working properly for some reason. The following command should only print "/dev/block/platform/msm_sdcc.1/by-name/system". No need to plug in your device for this one.

echo "/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,seclabel,relatime,data=ordered 0 0" | gawk '{ print $1 }'

edit: This is the full command the kitchen uses. The output of this command is written to the superr_byname file.

byname1=$(adb shell "mount" | grep "by-name/system"); echo "$byname1" | gawk '{ print $1 }' | rev | cut -d'/' -f2- | rev | sed 's:/:\\/:g'
[SuperR Kitchen] stephanepi:
I have a problem. I don't have a working recovery. Intel tablet. The only way to flash is with fastboot.

Is there a way to manually install all addons (su, busybox,...) in the file system with proper permission and ownership before repack it to flash with fastboot.

Which config files must i look for in order to have a list of proper configuration for all added files ?
[SuperR Kitchen] bcrichster:
..Wrong thread?

If I Help, just hit the Thanks button! :cool:

Sent from my Xper!m3nt - ZTE N9515
[SuperR Kitchen] sebastiandg7:
Well, the commands work separetly. The kitchen autodetects the by-name when extracting the system vía adb? Because when I extract from rom zip and select to detec by-name vía adb it works... not when extracting system via adb.
[SuperR Kitchen] SuperR.:
v1.0.1.5

Changes:

Fixed - some kernel.elf would not extract (newer p7zip).

p7zip is now included in the kitchen.

Hopefully fixed by-name detection when extracting images from device.

[MENTION=5764293]sebastiandg7[/MENTION] - Please let me know if this one fixes it for you. Delete the existing device directory like you did before. Thanks

[MENTION=3924647]bigrammy[/MENTION] - This should fix your kernel.elf issue. I noticed that the p7zip in the Ubuntu repo is 5 years old thanks to you :)
[SuperR Kitchen] bigrammy:
Wow fixed already :eek:

Well spotted bro :good:
[SuperR Kitchen] Er. Aditya:
You sir are a superhero... amazing work again n again n again
[SuperR Kitchen] pattyboi:):
just wanted to say thank you for this awesome piece of work,takes a lot or irritation out of rom editing :)
[SuperR Kitchen] hohassan444:
please how can you unpack kernel.elf ?...i tried latest kitchen and give me an error. i have xperia c4 dual....i tried to name it to kernel.elf / kernel.img / boot.img...no success .
[SuperR Kitchen] SuperR.:
Currently the only thing supported with kernel.elf is unpacking to get file_contexts and by-name directory. It only happens during extraction, not from the boot tools menu. This may change in the future if someone knowledgeable explains a universal kernel.elf repack method for Linux.
[SuperR Kitchen] aniesh1114:
Thanks alot superr. Really appreciate ur work. Superrkitchen works like charm and very easy to use.

Just a request. If you could add "Decompile & recompile Apk" feature to kitchen. It might will help every1.