[ Windows / Linux / Mac ][DONATE] SuperR's Kitchen (v3.2.1.2 - 1-14-2021)

Kc_Nirvana

Senior Member
May 18, 2012
235
47
58
Lisbon
According to the server log, you are running v3.2.0.9 on Linux. This version still has the vendor extract issue. It was fixed for Linux, WSL2, and Mac in v3.2.1.0 and higher.

BTW, if you tested building a sparse img in v3.2.0.9 Ubuntu 18.04, you were using the old make_ext4fs. In this case, please test building the img again in v3.2.1.1 :)

edit: I forgot to answer your question about asking for password when extracting. Starting with v3.2.1.0, Linux, WSL2, and Mac use mount to extract img files by default. This requires root permissions, so the sudo password is required. v3.2.0.9 used the Python ext4 module to extract just like Windows. The Python ext4 module is the reason for the xattr crash.
Vendor img fixed like you said
But when I use e2fsdroid
Code:
[INFO] Building sparse system_new.img



Running: mke2fs

mke2fs 1.45.4 (23-Sep-2019)

Creating filesystem with 917504 4k blocks and 229376 inodes

Filesystem UUID: f7f4d979-8ef1-425a-8141-14799c93c665

Superblock backups stored on blocks:

    32768, 98304, 163840, 229376, 294912, 819200, 884736



Allocating group tables:  0/28     done                           

Writing inode tables:  0/28     done                           

Writing superblocks and filesystem accounting information:  0/28     done





Running: e2fsdroid

[] not found in fs_config, using defaults
Same problem that I have on Ubuntu 16.04
So not Ubuntu problem

And I didnt touch the rom.
Only extract system and vendor and build
 

SuperR.

Recognized Developer
Mar 23, 2014
2,544
8,488
203
Invisible
Vendor img fixed like you said
But when I use e2fsdroid
Code:
[INFO] Building sparse system_new.img



Running: mke2fs

mke2fs 1.45.4 (23-Sep-2019)

Creating filesystem with 917504 4k blocks and 229376 inodes

Filesystem UUID: f7f4d979-8ef1-425a-8141-14799c93c665

Superblock backups stored on blocks:

    32768, 98304, 163840, 229376, 294912, 819200, 884736



Allocating group tables:  0/28     done                      

Writing inode tables:  0/28     done                      

Writing superblocks and filesystem accounting information:  0/28     done





Running: e2fsdroid

[] not found in fs_config, using defaults
Same problem that I have on Ubuntu 16.04
So not Ubuntu problem

And I didnt touch the rom.
Only extract system and vendor and build
There must be some missing package that I have installed. I will keep looking into it. FYI, on v3.2.1.1 you can edit kitchen/tools/srk.conf, "use_make_ext4fs=Yes". This will use the old make_ext4fs instead of e2fsdroid until I get it all sorted out. Sorry for all the trouble and thanks for testing 🙂

EDIT:
@Kc_Nirvana @815301697

After a few hours of pulling out the rest of my hair, I think I found the problem some users are facing when building sparse img files. Not enough RAM.

I was finally able to reproduce the issue on an Ubuntu 16.04 VM with 4GB RAM. Then I powered off the VM, increased the RAM to 8GB and the sparse img built with no issues.

It appears that when the sparse argument is given to mke2fs, the entire sparse system.img is created in RAM all at once and then written to disk. When the img size is greater than the available RAM, it says "fail to alloc X", meaning it can't allocate RAM for X amount of bytes.

In the case of WSL/WSL2, Windows uses several GB of your RAM as the host, then Linux is trying to cram 7GB of data into your RAM. If there is no available RAM, it can't be allocated for the system.img build.

To resolve this issue, the kitchen can check how much ram a PC has and change the way it does things based on that information. For example, if there is less RAM than the size of the img we are building, we should create a raw img and convert to sparse. Otherwise, we can directly create sparse. There should not be much time difference in the build either way as this is basically what is happening with e2fsdroid builds anyway. The next update will attempt a fix for this :)
 
Last edited:

shenzhigang

New member
Nov 27, 2020
1
0
1
This is an error when extracting rom from custom recovery.

ERROR:
Something went wrong. Most likely you lack permission to
pull images from your device.


Kitchen version: V3.2.1.1 (MacOS 64bit)
Android version: 8.1.0
Android kernel: 3.9.075
Phone: Lenovo Z5
Recvery: twrp-3.3.0-0420

I tried on the free version v1.2.1.2 (LINUX), same error occurs.
However, it works on the free version v1.1.9.5(LINUX).
 

Attachments

SuperR.

Recognized Developer
Mar 23, 2014
2,544
8,488
203
Invisible
I have never gotten the adb img pull to work on all devices. It seems when I make a change that works on one device it makes it fail on another. I am glad the free Bash kitchen worked for you :)
 

prkfsz

Senior Member
Jun 16, 2020
64
22
8
Hi.

Have a problem. I have a device that there is no TWRP for, no custom roms, no current or in the future probable developers activities. Barely a method for rooting that is quite cumbersome and not really satisfactory for me (IF you succeed you have to turn the device on via recovery every time otherwise unpleasant things can happen).

The device is Samsung Galaxy tab A 8" with S-pen (2019), SM-P205, the best and most practical darn thing with a chip that nobody has ever heard of.. :rolleyes:

But the situation is rather frustrating since i really can't make myself use it having google and all that bloat installed, especially google. And have i mentioned google?
I have heard of Kitchen as a method of playing with and modifying the software in an easy way using computer and then installing it to the phone. Which leads us to my question.

HERE IS WHAT I WANT TO DO: I would like to take a downloaded stock ROM (Android 9 or 10), de-bloat it, de-knox it, de-google it, and then flash it in to the device through ODIN (no TWRP, remember?).

Is that possible? And how much of an effort would that take? I am not really a complete noob, but for instance i haven't done anything involving adb or something like that. Which.. probably makes me a noob anyway.. 😜

Any help greatly appreciated!
 

Verbato

Senior Member
Jan 1, 2007
339
175
63
Hallingdal
An unusual problem, I am sure.
In Linux (Arch):

Code:
$ cat img_build.log

[INFO] Building sparse system_new.img
Running: mke2fs
mke2fs 1.45.4 (23-Sep-2019)
Creating filesystem with 712679 4k blocks and 178464 inodes
Filesystem UUID: f4832262-9fe0-49ef-82f2-8ce8424dd2ca
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

Running: e2fsdroid
__populate_fs: Could not allocate block in ext2 filesystem while writing file "TeleService.apk"
e2fsdroid: Could not allocate block in ext2 filesystem while populating file system

[ERROR] Out of space in system_new.img file.
[SUGGESTIONS]
[OPTION 1] Remove some unneeded files from the system directory.
[OPTION 2] Choose manual partition size and increase as needed.
Code:
$ du -shc system_ext system_ext.img
406M    system_ext
393M    system_ext.img
The funny part here is that I have neither added nor removed a single file in system_ext. I thought I'd do a dry run before I changed anything. Nope, no such luck.
It has all been extracted through the kitchen (option 4 in main menu).
The size of system_ext.img has been taken from the size of the original system_ext.img.

ROM that this is taken from: https://mifirm.net/downloadzip/6615
 

Sapiens

Member
Jan 22, 2007
47
5
28
Screenshot 2021-01-13 193042.jpg


I am having this problem with the kitchen running on WSL2. It works fine unpacking the official rom (samsung sm-n986b android 11) but before it finishes doing it gives this error which I have googled and havent found anything.

Any help would be appreciated.
 

SuperR.

Recognized Developer
Mar 23, 2014
2,544
8,488
203
Invisible
Hi.

Have a problem. I have a device that there is no TWRP for, no custom roms, no current or in the future probable developers activities. Barely a method for rooting that is quite cumbersome and not really satisfactory for me (IF you succeed you have to turn the device on via recovery every time otherwise unpleasant things can happen).

The device is Samsung Galaxy tab A 8" with S-pen (2019), SM-P205, the best and most practical darn thing with a chip that nobody has ever heard of.. :rolleyes:

But the situation is rather frustrating since i really can't make myself use it having google and all that bloat installed, especially google. And have i mentioned google?
I have heard of Kitchen as a method of playing with and modifying the software in an easy way using computer and then installing it to the phone. Which leads us to my question.

HERE IS WHAT I WANT TO DO: I would like to take a downloaded stock ROM (Android 9 or 10), de-bloat it, de-knox it, de-google it, and then flash it in to the device through ODIN (no TWRP, remember?).

Is that possible? And how much of an effort would that take? I am not really a complete noob, but for instance i haven't done anything involving adb or something like that. Which.. probably makes me a noob anyway.. 😜

Any help greatly appreciated!
It should be possible using the donate kitchen with the samsung_tools plugin for the tar.md5 creation. I am not a Samsung user so I have not tested this myself.
An unusual problem, I am sure.
In Linux (Arch):

Code:
$ cat img_build.log

[INFO] Building sparse system_new.img
Running: mke2fs
mke2fs 1.45.4 (23-Sep-2019)
Creating filesystem with 712679 4k blocks and 178464 inodes
Filesystem UUID: f4832262-9fe0-49ef-82f2-8ce8424dd2ca
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

Running: e2fsdroid
__populate_fs: Could not allocate block in ext2 filesystem while writing file "TeleService.apk"
e2fsdroid: Could not allocate block in ext2 filesystem while populating file system

[ERROR] Out of space in system_new.img file.
[SUGGESTIONS]
[OPTION 1] Remove some unneeded files from the system directory.
[OPTION 2] Choose manual partition size and increase as needed.
Code:
$ du -shc system_ext system_ext.img
406M    system_ext
393M    system_ext.img
The funny part here is that I have neither added nor removed a single file in system_ext. I thought I'd do a dry run before I changed anything. Nope, no such luck.
It has all been extracted through the kitchen (option 4 in main menu).
The size of system_ext.img has been taken from the size of the original system_ext.img.

ROM that this is taken from: https://mifirm.net/downloadzip/6615
I have seen this before, and I have no idea what to do about it. e2fsdroid builds a system.img which is an EXT4 file system. I have no idea how the manufacturer gets more data in it than can fit. You can see my only suggestions in the log you posted.
View attachment 5186209

I am having this problem with the kitchen running on WSL2. It works fine unpacking the official rom (samsung sm-n986b android 11) but before it finishes doing it gives this error which I have googled and havent found anything.

Any help would be appreciated.
It seems you did not follow my WSL2 guide for installing the kitchen. You have the kitchen installed in C:\Windows\system32\kitchen. I recommend following the guide to avoid annoying Windows errors and general slowness :)
 
  • Like
Reactions: Verbato

Verbato

Senior Member
Jan 1, 2007
339
175
63
Hallingdal
I have seen this before, and I have no idea what to do about it. e2fsdroid builds a system.img which is an EXT4 file system. I have no idea how the manufacturer gets more data in it than can fit. You can see my only suggestions in the log you posted.
Yeah, I suspected as such. fdupes -R ./system_ext4 finds a lot of duplicates. Maybe they have hard-linked these files? That would explain the magic trick of squeezing in more than fits.
Don't worry, not important (to me), just interesting.

Code:
$ fdupes -R ./system_ext
./system_ext/framework/oat/arm/wigig-service.vdex
./system_ext/framework/oat/arm64/wigig-service.vdex

./system_ext/framework/oat/arm/vendor.qti.voiceprint-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.voiceprint-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.latency-V2.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.latency-V2.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.ims.rcsconfig-V2.1-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.ims.rcsconfig-V2.1-java.vdex

./system_ext/framework/oat/arm/vendor.qti.ims.rcsconfig-V2.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.ims.rcsconfig-V2.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.ims.rcsconfig-V1.1-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.ims.rcsconfig-V1.1-java.vdex

./system_ext/framework/oat/arm/vendor.qti.ims.rcsconfig-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.ims.rcsconfig-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.ims.callinfo-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.ims.callinfo-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.ims.callcapability-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.ims.callcapability-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.wigig.supptunnel-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.wigig.supptunnel-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.wigig.netperftuner-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.wigig.netperftuner-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.sensorscalibrate-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.sensorscalibrate-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.fingerprint-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.fingerprint-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.data.latency-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.data.latency-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.data.iwlan-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.data.iwlan-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.data.dynamicdds-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.data.dynamicdds-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.data.connection-V1.1-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.data.connection-V1.1-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.data.connection-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.data.connection-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.capabilityconfigstore-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.capabilityconfigstore-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.hardware.alarm-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.hardware.alarm-V1.0-java.vdex

./system_ext/framework/oat/arm/vendor.qti.data.slm-V1.0-java.vdex
./system_ext/framework/oat/arm64/vendor.qti.data.slm-V1.0-java.vdex

./system_ext/framework/oat/arm/uimremotesimlocklibrary.vdex
./system_ext/framework/oat/arm64/uimremotesimlocklibrary.vdex

./system_ext/framework/oat/arm/uimremoteserverlibrary.vdex
./system_ext/framework/oat/arm64/uimremoteserverlibrary.vdex

./system_ext/framework/oat/arm/uimremoteclientlibrary.vdex
./system_ext/framework/oat/arm64/uimremoteclientlibrary.vdex

./system_ext/framework/oat/arm/uimlpalibrary.vdex
./system_ext/framework/oat/arm64/uimlpalibrary.vdex

./system_ext/framework/oat/arm/uimgbamanagerlibrary.vdex
./system_ext/framework/oat/arm64/uimgbamanagerlibrary.vdex

./system_ext/framework/oat/arm/uimgbalibrary.vdex
./system_ext/framework/oat/arm64/uimgbalibrary.vdex

./system_ext/framework/oat/arm/remotesimlockmanagerlibrary.vdex
./system_ext/framework/oat/arm64/remotesimlockmanagerlibrary.vdex

./system_ext/framework/oat/arm/qti-telephony-utils.vdex
./system_ext/framework/oat/arm64/qti-telephony-utils.vdex

./system_ext/framework/oat/arm/qti-telephony-hidl-wrapper.vdex
./system_ext/framework/oat/arm64/qti-telephony-hidl-wrapper.vdex

./system_ext/framework/oat/arm/qti-telephony-common.vdex
./system_ext/framework/oat/arm64/qti-telephony-common.vdex

./system_ext/framework/oat/arm/qcrilhook.vdex
./system_ext/framework/oat/arm64/qcrilhook.vdex

./system_ext/framework/oat/arm/com.qualcomm.qti.uceservice-V2.2-java.vdex
./system_ext/framework/oat/arm64/com.qualcomm.qti.uceservice-V2.2-java.vdex

./system_ext/framework/oat/arm/com.qualcomm.qti.uceservice-V2.1-java.vdex
./system_ext/framework/oat/arm64/com.qualcomm.qti.uceservice-V2.1-java.vdex

./system_ext/framework/oat/arm/com.qualcomm.qti.uceservice-V2.0-java.vdex
./system_ext/framework/oat/arm64/com.qualcomm.qti.uceservice-V2.0-java.vdex

./system_ext/framework/oat/arm/com.qualcomm.qti.imscmservice-V2.2-java.vdex
./system_ext/framework/oat/arm64/com.qualcomm.qti.imscmservice-V2.2-java.vdex

./system_ext/framework/oat/arm/com.qualcomm.qti.imscmservice-V2.1-java.vdex
./system_ext/framework/oat/arm64/com.qualcomm.qti.imscmservice-V2.1-java.vdex

./system_ext/framework/oat/arm/com.qualcomm.qti.imscmservice-V2.0-java.vdex
./system_ext/framework/oat/arm64/com.qualcomm.qti.imscmservice-V2.0-java.vdex

./system_ext/framework/oat/arm/com.qti.media.secureprocessor.vdex
./system_ext/framework/oat/arm64/com.qti.media.secureprocessor.vdex

./system_ext/framework/oat/arm/com.qti.location.sdk.vdex
./system_ext/framework/oat/arm64/com.qti.location.sdk.vdex

./system_ext/framework/oat/arm/com.android.hotwordenrollment.common.util.vdex
./system_ext/framework/oat/arm64/com.android.hotwordenrollment.common.util.vdex

./system_ext/etc/qvr/cfg/356/0/65536/mtp865_6dof_config.xml
./system_ext/etc/qvr/cfg/356/1/131072/morpheus_6dof_config.xml
./system_ext/etc/qvr/cfg/356/1/65536/trinity_6dof_config.xml

./system_ext/etc/fs_config_dirs
./system_ext/etc/fs_config_files
./system_ext/etc/group
./system_ext/etc/passwd
./system_ext/etc/selinux/mapping/26.0.cil
./system_ext/etc/selinux/mapping/27.0.cil
./system_ext/etc/selinux/mapping/28.0.cil
./system_ext/etc/selinux/mapping/29.0.cil
 
Last edited:
  • Like
Reactions: SuperR.

Verbato

Senior Member
Jan 1, 2007
339
175
63
Hallingdal

SuperR.

Recognized Developer
Mar 23, 2014
2,544
8,488
203
Invisible
Hmmm... Just looking to try out some GSI's, I came across this:

(Source: https://github.com/phhusson/treble_experimentations/releases/tag/v300.l )
So yeah, sounds like some variant of hard link.
BTW, seems like this is the case for system.img as well. In all android 11-rom's.
As of v3.2.1.1, the kitchen uses the shared_blocks flag if it exists in the original img you extract. As of v3.2.1.2, you can force it on or off via configuration file. See the v3.2.1.2 release post for details.

edit: I should mention this only applies to Linux/WSL/WSL2.
 
  • Like
Reactions: Verbato

Verbato

Senior Member
Jan 1, 2007
339
175
63
Hallingdal
You need to add the line to kitchen/tools/srk.conf. See the release post for details as mentioned in the post directly before yours.
I have added that line. (shared_blocks=Yes) Yet...

Bilde_2021-01-16_101227.png


Bash:
$ cat img_build.log

[INFO] Building system_new.img

Running: mke2fs
mke2fs 1.45.4 (23-Sep-2019)
Creating filesystem with 712679 4k blocks and 178464 inodes
Filesystem UUID: 8047ac87-e4cf-4f90-aab6-42317717c152
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Allocating group tables: done                           
Writing inode tables: done                           
Writing superblocks and filesystem accounting information: done


Running: e2fsdroid
__populate_fs: Could not allocate block in ext2 filesystem while writing file "TeleService.apk"
e2fsdroid: Could not allocate block in ext2 filesystem while populating file system

[ERROR] Out of space in system_new.img file.

[SUGGESTIONS]
[OPTION 1] Remove some unneeded files from the system directory.
[OPTION 2] Choose manual partition size and increase as needed.
And yes, it is updated to the latest version.
Code:
5) Check for updates (CURRENT: v3.2.1.2)
 

SuperR.

Recognized Developer
Mar 23, 2014
2,544
8,488
203
Invisible
I have added that line. (shared_blocks=Yes) Yet...

View attachment 5189015

Bash:
$ cat img_build.log

[INFO] Building system_new.img

Running: mke2fs
mke2fs 1.45.4 (23-Sep-2019)
Creating filesystem with 712679 4k blocks and 178464 inodes
Filesystem UUID: 8047ac87-e4cf-4f90-aab6-42317717c152
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Allocating group tables: done                          
Writing inode tables: done                          
Writing superblocks and filesystem accounting information: done


Running: e2fsdroid
__populate_fs: Could not allocate block in ext2 filesystem while writing file "TeleService.apk"
e2fsdroid: Could not allocate block in ext2 filesystem while populating file system

[ERROR] Out of space in system_new.img file.

[SUGGESTIONS]
[OPTION 1] Remove some unneeded files from the system directory.
[OPTION 2] Choose manual partition size and increase as needed.
And yes, it is updated to the latest version.
Code:
5) Check for updates (CURRENT: v3.2.1.2)
I did not mean to give you the impression that shared_blocks would fix your issue. As I mentioned for your situation, the only suggestions I have are in your log. I have not seen any difference in space saving within the img when using the shared_blocks feature. I don't even know what it does besides make the partition read-only on the device. My comment was only to inform you that the kitchen can enable the shared_blocks feature you were mentioning.
 
  • Like
Reactions: Verbato

Verbato

Senior Member
Jan 1, 2007
339
175
63
Hallingdal
I did not mean to give you the impression that shared_blocks would fix your issue.
By all means, I am unique, but I don't think I'm that unique. This is a problem that will be more recurring as 11 is pumped out. That was an even more recent version of the ROM, btw.
Would some sort of duplicate check be an idea? So the script can run ln -h on files that are duplicates. It will make the script even slower (I guess there's a reason behind why you don't use brotli in your script). But at least then it would work. On the other hand, it should also be possible to check the inodes of files before extracting them from various images, and that way check if there are files that are hard linked (using the same inodes).

Trust me, my case isn't all that unique. I'm sure more people will run in to this problem as time passes. Just don't refer to it as, "the Verbato problem" then. :p