Related
Since most of the high-end devices are using now EXT4 partitions i decided to make a guide.
I am doing this because this is the easiest way to create an EXT4 image.
This is not my guide I am just adapting and make it clear to everybody; someone showed me how to do this (I will mention him at the end of the guide).
Let's assume that you dumped the system.img from your own device and you want to add something to it.
We will create a new system.img and we will name it system_new.img, the size will be 240 Mb.
Step 1
Linux Machine (I used Ubuntu)
We prepare the directories and copy the system.img in the folder in which we will work.
mkdir system (here we will mount the old system.img
mkdir system_new (here we will mount the system_new.img)
Step 2 – Creation of the actual EXT4.img
dd if=/dev/zero of=system_new.img bs=4k count=60000
Translation of the terms,
bs =blocksize, 4k= the size of the block`s which in this case is 4kb
count=60000, the number of block`s, in our case will result an image of 240 Mb.
The blocksize can be 1k/2k/4k/16k
To get the exact size of the image that you create use simple maths.
60000 * 4 = 240000
Step 3 Formating the system_new.img with EXT4
mkfs.ext4 system_new.img
It will be a question where you will select yes (Y)
We override the file system check (If you don`t do this, the image will not work)
tune2fs -c0 -i0 system_new.img
Step 4 We mount the directories that we previous created.
mount -o loop system_new.img system_new/
mount -o loop system_new.img system/
Step 5 We copy the content from the old system.img in the system_new.img
cp -v -r -p system/* system_new/
We sync the files
sync
Step 6 Unmounting the partitons.
umount system_new/
umount system/
Step 7 Enjoy your new ext4 system.img
Tips:
If you are using Ubuntu just type
sudo su
And you will be root and no more sudo at each command.
You can add new files in the new created system.img but you need to set the permissions and ownership properly, otherwise it will not work.
Credits: arctablet.com administrator.
work perfect!
I managed to create a new system img for huawei phone.
Errors in Step 3 and 4: Unable to proceed
Hi There,
I am getting errors in step 3 and 4.
Step 3 Formating the system_new.img with EXT4
mkfs.ext4 system_new.img
It will be a question where you will select yes (Y) -- after this below error comes
Device size reported to be zero. Invalid partition specified, or partition table wasn't reread after running fdisk, due to a modified partition being busy and in use. You may need to reboot to re-read your partition table.
We override the file system check (If you don`t do this, the image will not work)
tune2fs -c0 -i0 system_new.img -- after this below error comes
Attempt to read block from filesystm resulted in short read while trying to open system.img
Step 4 We mount the directories that we previous created.
mount -o loop system_new.img system_new/ -- after this below error comes
unknown filesystem type 'ext4'
Could you please help.
i whant to create and system.img.ext4 for my android ! ! But i saw that image which is created is just system.img ! I`m using ubuntu and i whant to know what is need it to create that system.img.ext4 ! I don`t see that img to be ext4 file ! Thanks
jabarel said:
i whant to create and system.img.ext4 for my android ! ! But i saw that image which is created is just system.img ! I`m using ubuntu and i whant to know what is need it to create that system.img.ext4 ! I don`t see that img to be ext4 file ! Thanks
Click to expand...
Click to collapse
I'm not sure but it's probably just a matter of file extenstion.
By the way, great tuto. May be someting to add :
Android ext4 don't seem to be the exact standart of linux ext4 file systems.
To make it fully compatible and usable with fastboot, the use of "ext2simg" can be useful.
So it will be something like this :
ext2simg fs2convert.img fsconverted.img
ext2simg can be found in android-tools in debian repository.
I am porting a rom ,i extracted "system.new.dat" into "sytem" folder , applied changes according to this guide to port a ROM -->> http://forum.xda-developers.com/showthread.php?p=65933478#post65933478
can you tell me how to reconstruct the "system.new.dat" from "sytem" folder ?
is mkfs.ext4 applet available to arm devices..??
you can do it faster...
Great if you create a new image, but to edit no need to create all these steps ...
Just copy the system.img to system_new.img and mount that one and edit..
There's no clear instruction!
Hours of researching many places and no good instruction about how to create or edit an EXT4 with or without Linux!
I know this is an old post but I just wanted to try, might get a reply!
Frank2406 said:
Hours of researching many places and no good instruction about how to create or edit an EXT4 with or without Linux!
I know this is an old post but I just wanted to try, might get a reply!
Click to expand...
Click to collapse
what is not clear?
this has been tested by me and it works.
there are more refined ways in doing it, it just depends on what you need to to with the ext4 image.
globula_neagra said:
what is not clear?
this has been tested by me and it works.
there are more refined ways in doing it, it just depends on what you need to to with the ext4 image.
Click to expand...
Click to collapse
Step 1: "We prepare the directories" you said. What directories?
"mkdir system"
"mkdir system_new" which, what or where are they?
Step 2: The whole step 2 for a newbie in Linux like me is bla bla bla except the title "Creation of the actual EXT4.img"!
And the rest of your guide is as the same as step 2 which I mentioned.
And if this guide is for Ubuntu experts then maybe in the beginning you could mention so people don't get their hopes up dear globula_neagra!!
Long story short, I just wanted to try a custom Rom on my Zenwatch 1, but I've forgot to make backup, so the official Rom was gone. Asus itself didn't help to get a copy of the official one, so I tried Anthias custom Rom instead, but that made the watch even worse.
Then I started to research how to fix it, so I found this article.
It s not a step by step guide on how to use ubuntu.
I assume that wheen you want to learn something you do use google too. For this instance i would google in this way "what does mkdir command in ubuntu"
After i understood the purpose of the command and how to use it i would try to apply it using the guide and after that you will see that things will start to make sense.
My guide was written with the idea that if you use android you have an idea of linux too and in this case ubuntu.
The command line in linux is somewhat similar to the one in windows commander there are some extra things that you need to learn but those can t be put in a guide like this.
In regards to your watch. My advice is to find another one and take a system dump from that one and flash it to yours if you have an unlocked bootloader.
Here you cand find some good reads on how to dump the files from the watch. And a bit more details on what is the business with the ext4 creation. Topic is5 years old but still relevant.
http://www.arctablet.com/blog/forum/arnova-7c-g3/arnova-7c-g3-dev-topic/
Hey all, This is my first post on the forum, so I thought I'd make it a guide.
I've run into a few roadblocks with installing some development tools like python and stuff, so I figured I'd try and make a filesystem image to hold all of it, what with Android preventing executables on your SD card from actually executing. You should NOT try and use this for freeing up space by moving apps to it. That just breaks things.
Things to know
A mount point is where you access the contents of a filesystem through.
A filesystem is basically a virtual disk.
I'm not responsible for your phone melting into a pool of acid or anything else you want to blame me for. You executed the commands, not me.
If there's been guides for this already, I didn't find them.
Playing with your system files is dangerous. Be careful
Playing with filesystems is even MORE dangerous. Don't do it unless you know what's going on.
Reversing and then combining two words in a sentence, then calling it a bit more dangerous is incredibly dangerous and can kill you. Don't do it.
As I said earlier: This is not intended to free up internal storage on your phone. It is intended to create extra space to put command-line executables.
This was created for those of us who have older phones that don't have a whole lot of internal storage. (Like the Milestone) This should also work on anything that meets the requirements listed below. I use it on a Motorola Milestone A853 running CyanogenMod 7.2.4f UMTS/SHOLES, and it took some tweaking, but it worked. Commands you put into your shell are marked with `bolded text and surrounded by back-ticks. Leave the back-ticks out. (`)`
Requirements! (obtained using `which <command name>` or a specified command)
Free space on your mSD
losetup (configuring loop devices)
mknod (creating loop devices)
mount (mounting filesystems)
mkdir (making directories)
su (root access)
umount (unmounting)
mke2fs (formatting)
Linux filesystem support (`cat /proc/filesystems | grep ext`)
Here we go!
This assumes you are going to use an ext4-formatted filesystem image mounted on /data/development/, with the image located at /mnt/sdcard/development.img. You WILL need to determine your phone's supported ext<num> filesystems using `cat /proc/filesystems | grep ext`. Choose the highest-numbered one.
Create the mountpoint, the image, and then format the image to ext4.
`mkdir /data/development/``dd if=/dev/zero of=/mnt/sdcard/development.img count=409600 bs=1024``mke2fs -l /mnt/sdcard/development.img -b 1024 -t ext4`
Create the block device, set it to point at the image, then mount it.
`mknod /dev/block/loop250 b 7 250``losetup /dev/block/loop250 /mnt/sdcard/development.img``mount -t ext4 /dev/block/loop250 /data/development`
Test it to see if it works.
`touch /data/development/testfile;ls /data/development/`
Use it.
Unmounting (/!\ For connecting to a computer to avoid corruption /!\)
`umount /mnt/sdcard/development.img``losetup -d /dev/block/loop250`
Well, that's all I've got. Suggestions and corrections, as well as good feedback are appreciated.
Some PAQs (Possibly Asked Questions)
Q: I'm getting some errors. Here they are: pastebin.com/some-errors
A: Great, I'll see what I did wrong, and if it's something on your end, I'll try and help you out.
Q: It dun werk
A: Tell me the errors instead of complaining about them. Just saying that does not help me and wastes my time and bandwidth.
Q: "No space left on device"; "Operation not permitted"; "No such file or directory"
A: SD card full; not root (or SD card is full, or something broke); Mount point doesn't exist or (if 'mount' returns that and the point exists) something not cool happened.
Usage guide on Non-Android devices
Some interesting bits of information for use on computers:
There's probably not an easy way to read/write/mount EXT2 filesystems on a Windows machine, so if you have a solution that's stable, go for it.
Linux computers definitely should support this, and I'm not sure about OSX computers, but in theory would work if you had the right things installed. iPhones ... well I have no idea what you'd do with it there.
Linux:
On the device:
THIS PART IS EXTREMELY IMPORTANT, NOT DOING THIS WILL RESULT IN BROKEN FILESYSTEMS!
`umount /mnt/sdcard/development.img`
`losetup -d /dev/block/loop250`Plug your phone into your computer, making sure that the computer mounts it and reads it as removable media, and that the image is present.
On the computer: (Path of your user folder, and the mount point at which your device's SD is mounted can and very likely will vary from distribution to distribution. Check your paths.)
`mkdir /home/user/android-devtools/`
`mount -o loop /media/user/android-sd/development.img /home/user/android-devtools/`Now, you can change things within the image as you normally would a file or folder. Be warned, sometimes doing this can create conflicts in the file permissions, so running the right commands on the phone to change the permissions as root (use `chmod` for the permissions) can save you boatloads of trouble getting things to work, or editing files.
Mac OSX might or might not be the same, but seeing as I haven't picked up an Apple computer since maybe 5 years ago, let alone attempted filesystem management, I just don't know.
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Difficulty: medium. No programming skills required, but not for noobs.
Ingredients
1 TF700T running a rooted stock-based ROM with busybox and a kernel with preinit support (hint: -that kernels work fine )
1 PC running Linux with a microSD card reader
1 fast microSD card with at least 4 GB
1 CyanogenMod 10.2 nightly ZIP (should also work for other ROMs - post your results)
1 seasoned chef
Time required: about 30 to 45 minutes.
Directions
Preheat oven to 220 degree celsius ... oops, wrong recipe.
If done right, the internal ROM and its data are perfectly safe. But I assume you have a backup nevertheless - don't blame me if anything goes wrong.
Prepare the microSD card
Insert microSD card into PC card reader. Using gparted, create and format 3 primary partitions:
p1: fat32, this will be your external sdcard as before.
p2: ext4, this will become /data
p3: ext4, this will become /system
Make sure to align the partitions to MiB, or even better multiples of 4 MiB. This may improve I/O performance.
In most cases you can simply shrink the existing FAT32 partition and then create the remaining ext4 partitions.
Partition 3 should be 700 to 800 MB - anything bigger is a waste of space, and anything smaller than 500 MB might cause problems.
Partition 2 will be your whole "internal storage" for the second operating system, so size it according to your storage needs for apps, app data and the emulated /sdcard.
I am using a Samsung 16 GB card with the following partition sizes:
p1: ~ 8 GB
p2: ~ 6 GB
p3: ~ 800 MB
Prepare the new ROM
Before installing the second ROM to the microSD card, the ZIP file must be slightly modified. I assume you know how to unpack and repack a ZIP file and how to use a text editor - if not, find a tutorial elsewhere. .
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
First, extract boot.blob and set it aside for later. Then carefully remove it from the ZIP. Second, find META-INF/com/google/android/updater-script and modify it:
Replace all occurrences of mmcblk0p1 with mmcblk1p3. I had 3 occurrences in CM's updater-script - make sure you modify all of them, otherwise your internal ROM might not survive the installation. This change will redirect the installation to the external microSD card. Finally, remove the line that says package_extract_file("boot.blob", ...) near the end - it would overwrite the kernel and we don't want that.
Now we need to add the WiFi modules. These are compiled directly into the CM kernel, but separate modules in the stock kernel.
Get the kernel modules from your running ROM - they are in /system/lib/modules (e.g. using adb pull /system/lib/modules), and copy at least these two into the ZIP into /system/lib/modules:
cfg80211.ko
bcmdhd.ko (note: for TF300, I think you need bcmdhd_29.ko instead)
Finally, repack the ZIP, mount the first partition of your microSD card and copy the ZIP file there.
Extract the ramdisk files
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
Here comes the tricky part. You need to extract the ramdisk from the boot.blob you saved from the ZIP file in the previous step.
To do that, you need tools that may not be in every household, but should be easy to find using your favorite search engine. In case you have trouble finding and/or compiling them, you can find the result of this step in post #2.
First we need to unpack the blob (https://github.com/AndroidRoot/BlobTools):
Code:
blobunpack boot.blob
This will create boob.blob.LNX. This is the boot image, from which we need to extract the ramdisk (https://github.com/huaixzk/unpackbootimg):
Code:
unpackbootimg -i boot.blob.LNX
This will create several files, we are interested in boot.blob.LNX-ramdisk.gz - copy this one to your tablet, e.g. into /sdcard. For example:
Code:
adb push boot.blob.LNX-ramdisk.gz /sdcard/
Prepare the preinit script and the ramdisk files
Note: This step can now be automated, see http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
To do it manually:
On the tablet, open a shell in a terminal app or use adb shell and become root (su). Run the following commands:
Code:
mount -o remount,rw /system
cd /system
mkdir boot
cd boot
mkdir rootfs_cm
cd rootfs_cm
gzip -d -c /sdcard/boot.blob.LNX-ramdisk.gz | cpio -i
The first line makes /system writable until the next reboot. The next few lines are self-explanatory. The last line uncompresses the ramdisk image we created in the previous step and extracts the contained files. We are doing this on the tablet itself to preserve the file permissions.
Now modify the file fstab.cardhu (one of the files just extracted).
Replace mmcblk0p1 with mmcblk1p3 and mmcblk0p8 with mmcblk1p2.
mmcblk0p2 can stay as it is, it's the /cache partition that is only used to communicate with the recovery.
Next we need to make sure the WiFi modules that we added are loaded at boot time. Edit init.cardhu.rc and find the "on boot" line. Add below (indentation is important):
Code:
insmod /system/lib/modules/cfg80211.ko
insmod /system/lib/modules/bcmdhd.ko
Near the end of init.cardhu.rc is another reference to mmcblk0p8 that needs to be modified to mmcblk1p2 - near "service setup_fs".
Finally create the file /system/boot/preinit with the following content:
Code:
#!/system/bin/sh
# preinit: only /sys and /system are mounted (ro), / is still rw
PATH=/sbin:/system/bin:/system/xbin
# auto-detect rom2sd
if [ -d /sys/block/mmcblk1/mmcblk1p3 ]; then
echo "\nsystem/boot/preinit: mmcblk1p3 detected, setting up for ROM2SD.\n"
cp -a /system/boot/rootfs_cm/* /
fi
Make sure to make it executable:
Code:
chmod 744 /system/boot/preinit
This script is run by the kernel before the real Android init. It. detects if a microSD card with 3 partitions is inserted, and if yes, it copies the files for the CM root filesystem into the ramdisk. The following Android boot procedure will then mount /system and /data to the partitions on the microSD card and the whole operating system will run from the microSD card. If no card is inserted, nothing is modified and the normal internal ROM is started.
Flashing the ROM
Insert your microSD card into the tablet, boot to TWRP and flash your modified ZIP as usual - but disable signature checking because we didn't sign the modified ZIP.
Recovery
The recovery doesn't know about the external ROM, so you can't use the recovery to backup or restore its system or data. I prefer using the PC for that anyway.
Booting
To boot from internal storage, make sure the microSD card is not inserted when you start the tablet (you can insert it as soon as the boot animation appears). To boot from the microSD card, make sure it is inserted before you turn the tablet on.
That's all. Add more microSD cards for triple-boot, quad-boot, etc.
Notes
My kernel currently has not enabled SELINUX in the config, but CM appears to work anyway.
Update: -that6 enables SELinux.
Shortcut
In case you don't want to extract the CM ramdisk from the blob yourself (or you have trouble finding/compiling the tools to do so), you can try using mine - from my unofficial build of cm-10.2-20131024: View attachment boot.blob.LNX-ramdisk.gz
Automated solution
See http://forum.xda-developers.com/showpost.php?p=47333729&postcount=31
(reserved for additions)
_that said:
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Difficulty: medium. No programming skills required, but not for noobs.
Ingredients
1 TF700T running a rooted stock-based ROM with busybox and a kernel with preinit support (hint: -that kernels work fine )
1 PC running Linux with a microSD card reader
1 fast microSD card with at least 4 GB
1 CyanogenMod 10.2 nightly ZIP (should also work for other ROMs - post your results)
1 seasoned chef
Time required: about 30 to 45 minutes.
Directions
Preheat oven to 220 degree celsius ... oops, wrong recipe.
If done right, the internal ROM and its data are perfectly safe. But I assume you have a backup nevertheless - don't blame me if anything goes wrong.
Prepare the microSD card
Insert microSD card into PC card reader. Using gparted, create and format 3 primary partitions:
p1: fat32, this will be your external sdcard as before.
p2: ext4, this will become /data
p3: ext4, this will become /system
Make sure to align the partitions to MiB, or even better multiples of 4 MiB. This may improve I/O performance.
In most cases you can simply shrink the existing FAT32 partition and then create the remaining ext4 partitions.
Partition 3 should be 700 to 800 MB - anything bigger is a waste of space, and anything smaller than 500 MB might cause problems.
Partition 2 will be your whole "internal storage" for the second operating system, so size it according to your storage needs for apps, app data and the emulated /sdcard.
I am using a Samsung 16 GB card with the following partition sizes:
p1: ~ 8 GB
p2: ~ 6 GB
p3: ~ 800 MB
Prepare the new ROM
Before installing the second ROM to the microSD card, the ZIP file must be slightly modified. I assume you know how to unpack and repack a ZIP file and how to use a text editor - if not, find a tutorial elsewhere. .
First, extract boot.blob and set it aside for later. Then carefully remove it from the ZIP. Second, find META-INF/com/google/android/updater-script and modify it:
Replace all occurrences of mmcblk0p1 with mmcblk1p3. I had 3 occurrences in CM's updater-script - make sure you modify all of them, otherwise your internal ROM might not survive the installation. This change will redirect the installation to the external microSD card. Finally, remove the line that says package_extract_file("boot.blob", ...) near the end - it would overwrite the kernel and we don't want that.
Now we need to add the WiFi modules. These are compiled directly into the CM kernel, but separate modules in the stock kernel.
Get the kernel modules from your running ROM - they are in /system/lib/modules (e.g. using adb pull /system/lib/modules), and copy at least these two into the ZIP into /system/lib/modules:
cfg80211.ko
bcmdhd.ko
Finally, repack the ZIP, mount the first partition of your microSD card and copy the ZIP file there.
Extract the ramdisk files
Here comes the tricky part. You need to extract the ramdisk from the boot.blob you saved from the ZIP file in the previous step.
To do that, you need tools that may not be in every household, but should be easy to find using your favorite search engine.
First we need to unpack the blob (https://github.com/AndroidRoot/BlobTools):
Code:
blobunpack boot.blob
This will create boob.blob.LNX. This is the boot image, from which we need to extract the ramdisk (https://github.com/huaixzk/unpackbootimg):
Code:
unpackbootimg -i boot.blob.LNX
This will create several files, we are interested in boot.blob.LNX-ramdisk.gz - copy this one to your tablet, e.g. into /sdcard. For example:
Code:
adb push boot.blob.LNX-ramdisk.gz /sdcard/
Prepare the preinit script and the ramdisk files
On the tablet, open a shell in a terminal app or use adb shell and become root (su). Run the following commands:
Code:
mount -o remount,rw /system
cd /system
mkdir boot
cd boot
mkdir rootfs_cm
cd rootfs_cm
gzip -d -c /sdcard/boot.blob.LNX-ramdisk.gz | cpio -i
The first line makes /system writable until the next reboot. The next few lines are self-explanatory. The last line uncompresses the ramdisk image we created in the previous step and extracts the contained files. We are doing this on the tablet itself to preserve the file permissions.
Now modify the file fstab.cardhu (one of the files just extracted).
Replace mmcblk0p1 with mmcblk1p3 and mmcblk0p8 with mmcblk1p2.
mmcblk0p2 can stay as it is, it's the /cache partition that is only used to communicate with the recovery.
Next we need to make sure the WiFi modules that we added are loaded at boot time. Edit init.cardhu.rc and find the "on boot" line. Add below (indentation is important):
Code:
insmod /system/lib/modules/cfg80211.ko
insmod /system/lib/modules/bcmdhd.ko
Near the end of init.cardhu.rc is another reference to mmcblk0p8 that needs to be modified to mmcblk1p2 - near "service setup_fs".
Finally create the file /system/boot/preinit with the following content:
Code:
#!/system/bin/sh
# preinit: only /sys and /system are mounted (ro), / is still rw
PATH=/sbin:/system/bin:/system/xbin
# auto-detect rom2sd
if [ -d /sys/block/mmcblk1/mmcblk1p3 ]; then
echo "\nsystem/boot/preinit: mmcblk1p3 detected, setting up for ROM2SD.\n"
cp -a /system/boot/rootfs_cm/* /
fi
Make sure to make it executable:
Code:
chmod 744 /system/boot/preinit
This script is run by the kernel before the real Android init. It. detects if a microSD card with 3 partitions is inserted, and if yes, it copies the files for the CM root filesystem into the ramdisk. The following Android boot procedure will then mount /system and /data to the partitions on the microSD card and the whole operating system will run from the microSD card. If no card is inserted, nothing is modified and the normal internal ROM is started.
Flashing the ROM
Insert your microSD card into the tablet, boot to TWRP and flash your modified ZIP as usual - but disable signature checking because we didn't sign the modified ZIP.
Recovery
The recovery doesn't know about the external ROM, so you can't use the recovery to backup or restore its system or data. I prefer using the PC for that anyway.
Booting
To boot from internal storage, make sure the microSD card is not inserted when you start the tablet (you can insert it as soon as the boot animation appears). To boot from the microSD card, make sure it is inserted before you turn the tablet on.
That's all. Add more microSD cards for triple-boot, quad-boot, etc.
Click to expand...
Click to collapse
It is a nice detail instruction for new users like me. I really like it a lot and I can use some information from your post for my system2sd... However, maybe I misread your post. I don't see any information about repack the blob when you are done modifying the fstab.cardhu. I know a little bit of ramdisk and can get around it but that information will help the first time users... Just my opinion and thanks for sharing a valuable information to us...
LetMeKnow said:
However, maybe I misread your post. I don't see any information about repack the blob when you are done modifying the fstab.cardhu.
Click to expand...
Click to collapse
That's because you don't need to repack the blob or reflash the kernel - I wanted to simplify the procedure, so I added preinit support to the kernel's ramdisk a few months ago. You just put some files in /system/boot and the kernel will run your preinit script that modifies the ramdisk at boot time.
Just remember that if you reflash your internal ROM, you have to recreate the /system/boot stuff.
_that said:
That's because you don't need to repack the blob or reflash the kernel - I wanted to simplify the procedure, so I added preinit support to the kernel's ramdisk a few months ago. You just put some files in /system/boot and the kernel will run your preinit script that modifies the ramdisk at boot time.
Just remember that if you reflash your internal ROM, you have to recreate the /system/boot stuff.
Click to expand...
Click to collapse
Oop, I forgot that you use it in your boot folder... It is my bad.. I will give it a try when I am done with my system2sd testing and will ask more questions on the way.. Thanks for the information...
Cheers,
LMK
_that said:
Notes
My kernel currently has not enabled SELINUX in the config, but CM appears to work anyway.
(reserved for additions)
Click to expand...
Click to collapse
You should be fine until I enforce SELINUX. But I haven't finished the policies yet. Still have some issues to iron out with that. Have about 90% of them done, I think.. lol
Just out of curiosity, will this only work with primary partitions?
johnlgalt said:
Just out of curiosity, will this only work with primary partitions?
Click to expand...
Click to collapse
It should also work with logical partitions if you modify the partition numbers accordingly. And please remove the full quote of my guide from your post, we should not emulate an Outlook-style mess in the forum.
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4
_that said:
It should also work with logical partitions if you modify the partition numbers accordingly. And please remove the full quote of my guide from your post, we should not emulate an Outlook-style mess in the forum.
Sent from my ASUS Transformer Pad TF700T using Tapatalk 4
Click to expand...
Click to collapse
Yeah, I quoted it that way b/c I was asking specifically about that part - but it that part works I suppose the rest would too, huh? :silly:
Wow
Thx for this, easy cheesey, Great work, Love the dual boot!!!!
_that said:
Tired of backup, wipe, flash, backup, wipe, restore, ... just to try a different ROM?
Today we will cook a nice tasty dual-boot for the TF700T. You will have two separate environments with different ROMs, apps and data that share only the common Linux kernel binary.
Click to expand...
Click to collapse
Is there any chance *someone with the required skills* could port bootmanager to our device?
BootManager
it would be the best, considering that your method uses the same load-from-sdcard thing.
Just curious thats all.
kali113 said:
Is there any chance *someone with the required skills* could port bootmanager to our device?
BootManager
it would be the best, considering that your method uses the same load-from-sdcard thing.
Just curious thats all.
Click to expand...
Click to collapse
Looks like commercial software, so ask the devs of that app.
Here is an experimental flashable zip file that redirects the TWRP recovery to the ROM2SD environment. It doesn't really install anything to storage, it just reconfigures the device nodes so that the recovery is tricked into accessing the system and data partitions on the microSD card instead of internal storage.
It works so well that after "installing" this, a following ROM install that unmounts and formats /system and installs itself to /system on mmcblk0p1 will actually be installed on the microSD card, so you don't need to replace the partition names in the updater-script any longer (but you still need to comment out the blob flashing line for now or reflash my kernel after the ROM).
It also works so well that after "installing" this, you don't see your internal /sdcard any longer, so put whatever you want to flash on the first partition of the external microSD card.
"Installing" the script again will undo its actions, so you can toggle back and forth between external and internal storage.
Warning: I tested this only once, and the script does not have any error handling - if the inserted microSD is not prepared for ROM2SD, behavior is undefined - most likely the recovery will complain that it can't mount system or data. Use this at your own risk and make sure you have backed up all valuable data and your ROM, just in case.
View attachment dev-rom2sd.zip
The script also contains a nice example how to output text from a shell script to the recovery console. It shows a list of device nodes so you can see what the script did (the device numbers of mmcblk0p1 and mmcblk1p3 are identical).
Can I follow this guide to have paranoid rom on internal and cromi-x rom on microsd?
vnphatbuddha said:
Can I follow this guide to have paranoid rom on internal and cromi-x rom on microsd?
Click to expand...
Click to collapse
I've never tried PA but it may work if you use my kernel and modify the preinit script accordingly (my kernel contains a stock-compatible ramdisk, so you need to copy the PA ramdisk to / if the microSD is *not* inserted).
_that said:
I've never tried PA but it may work if you use my kernel and modify the preinit script accordingly (my kernel contains a stock-compatible ramdisk, so you need to copy the PA ramdisk to / if the microSD is *not* inserted).
Click to expand...
Click to collapse
sorry for such a noob question but how do you compile the zips from the git links to an executable? Or does the bloobtool and unpackbootimg able to run from its extracted zips? slightly new to this...
vnphatbuddha said:
sorry for such a noob question but how do you compile the zips from the git links to an executable? Or does the bloobtool and unpackbootimg able to run from its extracted zips? slightly new to this...
Click to expand...
Click to collapse
You need to compile the blobtools on git. extract the .zip and run blobunpack on the .blob then abootimg -x on the boot.img.to repack: abootimg --create *new-bootimg* - k *zImage* -r *ramdisk*, then repack the .blob
and/or
follow this tutorial from the blob master himself http://forum.xda-developers.com/showpost.php?p=36925180
JoinTheRealms said:
You need to compile the blobtools on git. extract the .zip and run blobunpack on the .blob then abootimg -x on the boot.img.to repack: abootimg --create *new-bootimg* - k *zImage* -r *ramdisk*, then repack the .blob
and/or
follow this tutorial from the blob master himself http://forum.xda-developers.com/showpost.php?p=36925180
Click to expand...
Click to collapse
The problem I'm having is that I do not know how to use git to compile. What are the commands and do I input it in the top search bar of the site?
vnphatbuddha said:
The problem I'm having is that I do not know how to use git to compile. What are the commands and do I input it in the top search bar of the site?
Click to expand...
Click to collapse
You don't use git to compile, you use it to manage the source code.
To compile the source code, you need the appropriate development tools installed (I think it's called "build-essential" on Debian-like distributions) and run "make" in the directory with the extracted source code.
_that said:
You don't use git to compile, you use it to manage the source code.
To compile the source code, you need the appropriate development tools installed (I think it's called "build-essential" on Debian-like distributions) and run "make" in the directory with the extracted source code.
Click to expand...
Click to collapse
Wow this is too complicated to compile, having to setup and run debian on usb. Guess I can't try out rom2sd
Lanchon REPIT: The In-Device Data-Sparing Repartitioning Tool For Android
REPIT is a simple, safe, device-only, data-sparing, and easily portable repartitioning tool for Android devices:
device-only: just flash a zip file in recovery to repartition the device.
simple: rename the zip file before flashing to configure your choice of partition sizes, file systems, wipes, etc.
safe:
a correctly ported REPIT can never hard-brick your device.
before starting, REPIT checks for the existence of all the tools that will be needed for the task at hand, verifies that the current partition layout passes several sanity checks, checks and fixes all the involved file systems, and verifies that the new partition layout will meet its sanity checks too. REPIT performs a dry-run of the complete repartitioning process to detect possible problems early on.
if REPIT fails, it will nonetheless try to restore your device to a working in-between state.
my estimate is that around 1000 users have already repartitioned with REPIT with no incidents of data loss, boot loops or soft bricks (2016-04).
easily portable: a simple configuration file is all that is needed to port REPIT to a new device.
Documentation (HELL YEAH, read this!) -> HERE
Downloads -> HERE
this is a user discussion thread. post here for general discussion and user support.
for official support create a Github issue, but only of you have read the docs.
new versions will not be announced here.
please 'watch' the Github project to receive notifications.
special thanks to the.gangster.
XDA:DevDB Information
Lanchon REPIT, Tool/Utility for all devices (see above for details)
Contributors
Lanchon
Source Code: https://github.com/Lanchon/REPIT
Version Information
Status: Stable
Created 2016-04-13
Last Updated 2019-06-07
Reserved
Reserved
Good to have a place again to discuss issues or simple questions.
Great tool, that meanwhile left its corner where it grew up (the Galaxy S2 - i9100), meanwhile supporting a growing number of devices.
RELEASES AND CHANGELOG
the.gangster said:
Good to have a place again to discuss issues or simple questions.
Great tool, that meanwhile left its corner where it grew up (the Galaxy S2 - i9100), meanwhile supporting a growing number of devices.
@Lanchon
you accidently linked the downloads to your flashize github instead of the Repit one.
Click to expand...
Click to collapse
lol thanks, mucho copy/pasta, fixed!
Thanks so much!
Perfect tool, used this evening on a old but still used I9100!
Tried this on a n7000 recently, tried to resize cache, which didn't work, saw partition structure with modem after cache, and understand your concerns in the comments. I imagine the we could so some experiments like you are doing for the Honor 4, however I'm not at the stage where I want to volunteer my device as potential sacrifice.
A question on "wipe", how sure are we that "wipe" actually wipes, ie is all the previous data non-recoverable down to a block level?
Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.
If I have a used ext4 parition, and then format & wipe it then I think a fstrim happens. If I then change it to vfat, and dd the partition, am I able to recover blocks from the original ext4 partition, or does the trim cause the nand to regard the blocks as empty and return 0x0000000 or 0x11111111 or something deterministic?
I'm looking for a wipe that actually wipes, ext4 and vfat, rather then my current solution which is to dd if=/dev/zero of=/path, which is slow and is difficult to get a progress report, as kill -USR1 is a PITA.
samarium said:
Tried this on a n7000 recently, tried to resize cache, which didn't work, saw partition structure with modem after cache, and understand your concerns in the comments. I imagine the we could so some experiments like you are doing for the Honor 4, however I'm not at the stage where I want to volunteer my device as potential sacrifice.
A question on "wipe", how sure are we that "wipe" actually wipes, ie is all the previous data non-recoverable down to a block level?
Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.
If I have a used ext4 parition, and then format & wipe it then I think a fstrim happens. If I then change it to vfat, and dd the partition, am I able to recover blocks from the original ext4 partition, or does the trim cause the nand to regard the blocks as empty and return 0x0000000 or 0x11111111 or something deterministic?
I'm looking for a wipe that actually wipes, ext4 and vfat, rather then my current solution which is to dd if=/dev/zero of=/path, which is slow and is difficult to get a progress report, as kill -USR1 is a PITA.
Click to expand...
Click to collapse
hi,
well, it's not that it didn't work lol! cache was intentionally left out of the resizable set. you've seen the comments and the 4X discussion so you know exactly why.
i wouldn't do the experiments anyway. in the Honor there is something useful to be gained: 1 extra GB to a 4GB /data, which is a lot. in the S2 cache is 100MB. cache is unused nowadays, so the only logical thing to do is shrink it. plus you want something left, like 32MB. so we will risk devices for 68MB? not on my watch
secure wipe is a very complex issue and there's an awful big can of worms there, believe me. it'll try to paint a picture.
ssds have a bunch of 'trim' commands. there's ERASE and DISCARD, and later TRIM was added, all with slightly different semantics. ans they all come in standard and secure flavors. most recently you can come across the standard non-queued commands or the new queued variants.
the non-secure flavored commands are performance-oriented: they are hints to help the ssd. the drive can ignore them if it wants. it can ignore requests for short ranges but honor requests for large extents, or whatever.
more recently devices can implement DRAT and RZAT (deterministic read after trim and read zero after trim), ending the previous non-deterministic behavior. take a look:
http://www.t13.org/documents/uploadeddocuments/docs2010/e09158r2-trim_clarifications.pdf
but there are a million bugs in ssd firmware so linux blacklists broken functionality. like RZAT in many drives (you can google it), even if the drive says it supports it.
in any case RZAT drives just alter the FTL (flash translation layer) structures to unmap the block, they don't erase flash, so your data is typically still there but normally inaccessible. and there is probably even a history of previous snapshots of the block, not just the latest.
that's where the secure commands enter the picture: supposedly the firmware must actually erase from flash all copies of the targeted blocks. in reality, firmwares are so buggy i wouldn't trust them for that, except maybe if the drive is intel brand.
back to the real world... the exynos:
>Does the wipe trigger some type of NAND erase cycle? This would be problematic on n7000 given the hard brick issues with NAND firmware there, and on the n7000 IIRC the ioctl() is filtered and purposely ignored, maybe this is also an issue with i9100? I don't recall.
you are living in the past. more than two years ago i started arguing that non-secure trim commands should in all probability work fine and could be used to speed up the S2 family. rationale is complex but you can google my threads about it. no-one listened so 2 years ago i learned to build kernels and did some tests with volunteers and began publishing trimming kernels (google i9100 trim for a bit of history). finally in 2016 trim was finally added to official CM 13, 12.1 and 11.
you could be trimming your device without knowing: if you are using recent official CM, you are already trimming. many other kernels switched to trim too.
but... in the S2, secure trim kills the eMMC, so only non-secure variants are issued by trim kernels. secure erase is not a possibility.
i don't know if the eMMC is RZAT, but i wouldn't trust the firmware anyway. if you want to wipe, dd is your best option. but don't use zeros!!! some ssd's compress data. use a pseudo random stream instead. after all, non-secure trim is not very different from a write, in the best case, so just write for safety and be done with it.
yes, dd won't wipe reserved blocks. no way to do that except:
-MAYBE... an eMMC full reset (including bootloader) by resizing the boot partitions (google) which is very dangerous and can easily hard brick the device.
-putting a power drill to you beloved S2
regarding what repit does:
-it trims only if the kernel has trim enabled.
-and it trims only ext4 partitions.
thanks!
Thanks for the detailed reply.
I'm currently using i9100 CM12.1 & n7000 CM13/Nightowl, and have been trimming vfat partitions.
Now you remind me, I do recall reading threads about trim safe a while ago, but I think I was more irritated at the time by the seemingly random kernel crashes & process terminations that eventually were tracked down to kernel interrupt fp register save/restore, and went down the Sony path for a while while the n7000 was unusable. Amusingly, the n7000 now has CM13, while the Sony Z Ultra is languishing and isn't looking good for CM13 at the moment.
While I agree that for general SSDs, zero blocks could be compressed, and blocks could be deduped, do you really think this is happening in n7000/i9100 emmc? I dont expect so, seems they seem too old. I agree that a /dev/urandom would be a better if= than /dev/zero for dd, however this is going to use much more power, and I'm usually wiping a phone with limited time and power.
I'm not trying to protect from something as serious as direct flash chip access, just want to be reasonably sure that whatever was on the phone has been overwritten and is not easily available to standard and even mildly esoteric extraction methods.
samarium said:
Thanks for the detailed reply.
I'm currently using i9100 CM12.1 & n7000 CM13/Nightowl, and have been trimming vfat partitions.
Now you remind me, I do recall reading threads about trim safe a while ago, but I think I was more irritated at the time by the seemingly random kernel crashes & process terminations that eventually were tracked down to kernel interrupt fp register save/restore, and went down the Sony path for a while while the n7000 was unusable. Amusingly, the n7000 now has CM13, while the Sony Z Ultra is languishing and isn't looking good for CM13 at the moment.
While I agree that for general SSDs, zero blocks could be compressed, and blocks could be deduped, do you really think this is happening in n7000/i9100 emmc? I dont expect so, seems they seem too old. I agree that a /dev/urandom would be a better if= than /dev/zero for dd, however this is going to use much more power, and I'm usually wiping a phone with limited time and power.
I'm not trying to protect from something as serious as direct flash chip access, just want to be reasonably sure that whatever was on the phone has been overwritten and is not easily available to standard and even mildly esoteric extraction methods.
Click to expand...
Click to collapse
ok. then i would format in ext4 and trim. you can use repit for doing both in a single shot, but you need a trimming kernel. take a dd snapshot of one or a couple of short pieces of the partition, both before and after the operation. compare them and post here, i'd surely like to know .
but... keep in mind that there are several different emmcs out there in the S2s, so you'd need to validate for each one. which reminds me, also post your device emmc IDs! use the eMMC brickbug check app for instance.
regarding the /dev/urandom vs /dev/zero thing, i'm not religious, i don't hold unwarranted beliefs about what i don't know. i investigate, i have no gut feelings on stuff
but if you want to know: i'm a bit obsessive, i certainly would have done at least something if i was coding the FTL, even if it is old. if your design is RZAT, the least you can do is trim the block instead of writing it when data is all zeros. you may think this would slow the emmc down, but this can be implemented in pseudo-zero time: writing usually entails generating some kind of checksum of the data. so note the magic checksum that corresponds to an all-zero block, and only if the checksum of the data being written matches the magic, actually check for all-zero data before writing. of course this can be 'attacked' by intentionally generating checksum collisions but who cares. the time saved by not garbage collecting, not using a free block, and not writing the block with all-zeros certainly pays for the checksum comparison against the magic value. also note that straight brute force comparison of all blocks is mostly ok too, as most written blocks will fail early anyway (ie, after one or a couple of bytes).
of course The One True Solution(R) is to encrypt the phone before using it...... assuming that you can actually wipe the key when you need to lol. ideally the key is in a separate hardware keystore adept at wiping keys. but on the S2 it just in the same eMMC . so this is a bit like explaining where the universe came from by saying that god created it, and then conveniently forget to explain where did god come from lol.
the power drill solution still mostly works on the S2 though
Pls help
##################################
Lanchon REPIT
A Data-Sparing Repartitioning Tool
Version: 2016-04-15
Device: i9100
Copyright 2016, Lanchon (GPLv3)
####################################
===== PRELIMINARY CHECKS =====
info: valid package names: <prefix>[-(system|data|sdcard|preload)=<conf>]...<suffix>
info: valid partition <conf> values: [<size-in-GiB>|same|min|max][+[keep|wipe][+[ext4|vfat|f2fs|swap|raw]]]
----- DEFAULTS -----
system = size:same + content:keep + fs:ext4
data = size:same + content:keep + fs:ext4
sdcard = size:same + content:keep + fs:vfat
preload = size:same + content:keep + fs:ext4
info: parsing package name
----- CONFIGURATION -----
system = size:1.0 + content:keep + fs:ext4
data = size:6 + content:keep + fs:ext4
sdcard = size:max + content:keep + fs:vfat
preload = size:min + content:keep + fs:ext4
info: disabling swap
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.
Usage: dirname FILENAME
Strip non-directory suffix from FILENAME
info: copying package to '/tmp'
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file
[ERROR 1]
Whats wrong
just change your current directory to /tmp and try to flash it again from there. (all within the recovery)
Lanchon said:
ok. then i would format in ext4 and trim. you can use repit for doing both in a single shot, but you need a trimming kernel. take a dd snapshot of one or a couple of short pieces of the partition, both before and after the operation. compare them and post here, i'd surely like to know .
but... keep in mind that there are several different emmcs out there in the S2s, so you'd need to validate for each one. which reminds me, also post your device emmc IDs! use the eMMC brickbug check app for instance.
regarding the /dev/urandom vs /dev/zero thing, i'm not religious, i don't hold unwarranted beliefs about what i don't know. i investigate, i have no gut feelings on stuff
Click to expand...
Click to collapse
bauner produced a new n7000 IsoRec with TWRP + OTG which I wanted, so while I was installing I tested a few things.
I generated a block binary file with each of the 1kB blocks annotated for the 200MB n7000 cache partition, and dd'd the file to the cache partition prior to each mkfs.
Code:
$ cat blocknull.pl
#!/usr/bin/perl
use strict;
my $count = $ARGV[0];
$count = 1 if $count == 0;
$count *= 1024 if $ARGV[0] =~ /M$/;
$count *= 1024 * 1024 if $ARGV[0] =~ /G$/;
for (my $i = 1; $i <= $count; $i++)
{
printf "\nBLOCK %10d kB %6d MB %2d GB BLOCK\n", $i, $i / 1024, $i / 1024 / 1024;
print chr(0) x (1024-43);
}
$
Code:
BLOCK 1 kB 0 MB 0 GB BLOCK
...
BLOCK 204800 kB 200 MB 0 GB BLOCK
Then operated on both vfat and ext4 file systems to determine which of the 204800 block signatures where remaining after various operations.
Code:
# tr -d '\0' < /dev/block/mmcblk0p7 | grep BLOCK.*BLOCK > cache.x.y.desc
...
# wc -l cache.?.?.*
204800 cache.1.1.dd
201632 cache.1.2.mkfs.fat32
197041 cache.1.3.copyfile
204800 cache.2.1.dd
0 cache.2.2.mkfs.ext4
204800 cache.3.1.dd
197380 cache.3.2.mkfs.ext4.twrp
60 cache.3.3.fstrim
60 cache.3.4.copyfile
#
So as expected vfat format doesn't change the underlying data returned, it just gets changed as it is used, as show by the signature counts on cache.1.*
ext4 is more interesting, as I tried a manual mke2fs -t ext4 for cache.2.* and TWRP wipe ext4 for cache.3.*. The TWRP wipe is not using secure discard as can be seen from recovery.log, but things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.
Code:
recovery.log:
warning: wipe_block_device: Wipe via secure discard suppressed due to bug in EMMC firmware
Maybe more interesting is that even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed, which I don't expect, some inconsistency in fs metadata setup in mkfs maybe? Doesn't matter to me, 1 or 2 wipes, but seems I will be using mke2fs -t ext4 via terminal and then using TWRP wipe/format as required.
FYI, EMMC IDs PNG attached.
samarium said:
bauner produced a new n7000 IsoRec with TWRP + OTG which I wanted, so while I was installing I tested a few things.
I generated a block binary file with each of the 1kB blocks annotated for the 200MB n7000 cache partition, and dd'd the file to the cache partition prior to each mkfs.
Code:
$ cat blocknull.pl
#!/usr/bin/perl
use strict;
my $count = $ARGV[0];
$count = 1 if $count == 0;
$count *= 1024 if $ARGV[0] =~ /M$/;
$count *= 1024 * 1024 if $ARGV[0] =~ /G$/;
for (my $i = 1; $i <= $count; $i++)
{
printf "\nBLOCK %10d kB %6d MB %2d GB BLOCK\n", $i, $i / 1024, $i / 1024 / 1024;
print chr(0) x (1024-43);
}
$
Code:
BLOCK 1 kB 0 MB 0 GB BLOCK
...
BLOCK 204800 kB 200 MB 0 GB BLOCK
Then operated on both vfat and ext4 file systems to determine which of the 204800 block signatures where remaining after various operations.
Code:
# tr -d '\0' < /dev/block/mmcblk0p7 | grep BLOCK.*BLOCK > cache.x.y.desc
...
# wc -l cache.?.?.*
204800 cache.1.1.dd
201632 cache.1.2.mkfs.fat32
197041 cache.1.3.copyfile
204800 cache.2.1.dd
0 cache.2.2.mkfs.ext4
204800 cache.3.1.dd
197380 cache.3.2.mkfs.ext4.twrp
60 cache.3.3.fstrim
60 cache.3.4.copyfile
#
So as expected vfat format doesn't change the underlying data returned, it just gets changed as it is used, as show by the signature counts on cache.1.*
ext4 is more interesting, as I tried a manual mke2fs -t ext4 for cache.2.* and TWRP wipe ext4 for cache.3.*. The TWRP wipe is not using secure discard as can be seen from recovery.log, but things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.
Code:
recovery.log:
warning: wipe_block_device: Wipe via secure discard suppressed due to bug in EMMC firmware
Maybe more interesting is that even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed, which I don't expect, some inconsistency in fs metadata setup in mkfs maybe? Doesn't matter to me, 1 or 2 wipes, but seems I will be using mke2fs -t ext4 via terminal and then using TWRP wipe/format as required.
FYI, EMMC IDs PNG attached.
Click to expand...
Click to collapse
>it seems manual mke2fs -t ext4 does a wipe
it shouldn't. mke2fs -i thought- doesn't trim unless invoked with a specific option. repit invokes with the flag:
https://github.com/Lanchon/REPIT/blob/master/repit-fs-ext4.sh#L51
as to the question of why your markers were cleared anyway, i've no answer.
>even though it seems manual mke2fs -t ext4 does a wipe, when I do a fstrim is still says 180MB trimmed
some kernels inform the newly trimmed space: if you run trim twice you'll get "0 bytes trimmed" the second time.
other kernels (like CM's i9100) always inform (and presumably trim) the full partition free space, so 180MB is ok. if you run trim twice you'll get the same number of bytes both times.
>things are largely back on track after the first fstrim except for a hole from 131081 kB to 131125 kB.
here are some candidate causes:
a) ext4 fs is based on 'blocks' with each block being a constant number of sectors. it makes sense that fstrim should work on whole blocks. also, when ext4 writes a 'short block', ie one not completely filled with data, some sectors and the end of the block might remain unused. it makes sense for ext4 not to write these sectors at all. but the complete block will be marked as used given that the block is the granularity for that, so no sector in the block will be trimmed by fstrim. so some pre-format data might survive in these short blocks after fstrim by this mechanism, which could explain what you observed.
b) another cause could be that the emmc might ignore trim requests for spans shorter than some size or for misaligned spans (remember that erases are performed in large chunks) giving rise to the observed data survival. when formatting no data survives because partitions are position- and size-aligned to 1MB or 4MB, which might be enough to guarantee trim. (i find this explanation unlikely, but who knows.)
about repit:
repit formats and trims ext4 and f2fs in a single operation.
to wipe /data a single repit should be enough:
-data=+wipe
to wipe /sdcard you can take advantage of repit's capability to convert file systems and do two repits:
-sdcard=+wipe+ext4
-sdcard=+wipe
an idea that comes out of this is that repit could temporarily format in ext4 before formatting in other modes that do not support format-time trimming, such as when wiping vfat and swap. this would make the above 2 steps unnecessary.
darkz16 said:
[...]
info: disabling swap
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.
Usage: dirname FILENAME
Strip non-directory suffix from FILENAME
info: copying package to '/tmp'
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file
[ERROR 1]
Click to expand...
Click to collapse
this is very interesting.
the relevant lines are these:
https://github.com/Lanchon/REPIT/blob/master/repit.sh#L318-L322
Code:
if [ -f "$packageName" ]; then
if [ "$(dirname $(readlink -f "$packageName"))" != "/tmp" ]; then
info "copying package to '/tmp'"
cp -f "$packageName" "/tmp/"
hint="this package copied itself to '/tmp'; please run it again from there"
the line:
if [ -f "$packageName" ]; then
assures that the file $packageName exists.
but these logfile lines:
Code:
BusyBox v1.22.1 bionic (2016-01-10 12:49 +0530) multi-call binary.
Usage: dirname FILENAME
Strip non-directory suffix from FILENAME
are proof that 'dirname' is being invoked without argument, which means that 'readlink -f "$packageName"' produced an error!
how can 'readlink -f <file>' (which means 'canonicalize') give an error when invoked on an existing file is beyond me. it looks like your implementation of 'readlink' is broken.
what exact recovery are you using? who made it or where is it being distributed?
EDIT:
btw there is a quoting error in the code here but it shouldn't affect this. the line should be:
if [ "$(dirname "$(readlink -f "$packageName")")" != "/tmp" ]; then
darkz16 said:
[...]
cp: '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' and '/tmp/lanchon-repit-20160415-system=1.0-data=6-sdcard=max-preload=min wipe-i9100.zip' are the same file
[ERROR 1]
Whats wrong
Click to expand...
Click to collapse
so i committed what i think is a fix for this problem that i cant reproduce:
https://github.com/Lanchon/REPIT/commit/c7bc3655acc89ee554d1dafe09c7bb9948483c03
and attached is build for you to try.
IMPORTANT: EXTRACT THE ZIP FIRST, DONT JUST FLASH IT!
Lanchon said:
so i committed what i think is a fix for this problem that i cant reproduce:
https://github.com/Lanchon/REPIT/commit/c7bc3655acc89ee554d1dafe09c7bb9948483c03
and attached is build for you to try.
IMPORTANT: EXTRACT THE ZIP FIRST, DONT JUST FLASH IT!
Click to expand...
Click to collapse
Hi Lanchon.
I'm installed this zip but i have the same problem.
I'm copy, before zipping the achive, on the \tmp directory of emmc
What have i do wrong?.
Thanks.
chapito said:
Hi Lanchon.
I'm installed this zip but i have the same problem.
I'm copy, before zipping the achive, on the \tmp directory of emmc
What have i do wrong?.
Thanks.
Click to expand...
Click to collapse
no log, no kernel info, no recovery info. cant help you.
Lanchon said:
no log, no kernel info, no recovery info. cant help you.
Click to expand...
Click to collapse
Hi.
Forgive me for not giving more information to solve the problem.
Yesterday I could partition the memory.
I had to change the partition type of memory EMMC to vfat and the script to start.
I used the IsoRec TWRP 2.8.7.0.
I used the last script publicated "lanchon-repit-20160415-system=1.0-data=same-sdcard=max-preload=min+wipe-i9100.zip"
Thanks
chapito said:
Hi.
Forgive me for not giving more information to solve the problem.
Yesterday I could partition the memory.
I had to change the partition type of memory EMMC to vfat and the script to start.
I used the IsoRec TWRP 2.8.7.0.
I used the last script publicated "lanchon-repit-20160415-system=1.0-data=same-sdcard=max-preload=min+wipe-i9100.zip"
Thanks
Click to expand...
Click to collapse
you didn't need to change your sdcard to FAT !!!
you could have used: -sdcard=max++ext4
if only you had read the instructions! that's what they are there for lol
well, it's your data you had to format, not mine!
thanks!
Hi guys,
Here, for those who are interested, I'm maintaining the packages to use postmarketOS on bare-metal hardware.
I only tested the A750FN variant.
Check it out!
Feedbacks are welcome!
Many thanks:
@VDavid003 for kernel sources
Thanks alot for making this contribution
M0Rf30 said:
Hi guys,
Here, for those who are interested, I'm maintaining the packages to use postmarketOS on bare-metal hardware.
I only tested the A750FN variant.
Check it out!
Feedbacks are welcome!
Many thanks:
@VDavid003 for kernel sources
Click to expand...
Click to collapse
After a week or 2 i can get back home and test it , so keep making these and I'll test them and tell you about my experience
Hello, can you share how you did it? I can't find any files for flashing on the postmarketos wiki page, I have TWRP installed.
Arm1nas said:
Hello, can you share how you did it? I can't find any files for flashing on the postmarketos wiki page, I have TWRP installed.
Click to expand...
Click to collapse
I haven't tested it yet , but you'll have to use the pmbootstrap tool to build a zip that you can flash through the TWRP
The wiki of postmarketOS explains how to use the pmbootstrap tool. Go check it out
animegamer4422 said:
I haven't tested it yet , but you'll have to use the pmbootstrap tool to build a zip that you can flash through the TWRP
The wiki of postmarketOS explains how to use the pmbootstrap tool. Go check it out
Click to expand...
Click to collapse
I figured it out. I created an Ubuntu VM and built it. I am not sure why but now the phone doesn't boot to pmOS, it just spits out some errors or there is only a terminal. TWRP says it can't mount /system, maybe I have to reflash the recovery.
Arm1nas said:
I figured it out. I created an Ubuntu VM and built it. I am not sure why but now the phone doesn't boot to pmOS, it just spits out some errors or there is only a terminal. TWRP says it can't mount /system, maybe I have to reflash the recovery.
Click to expand...
Click to collapse
I don't think it's a issue with the recovery and also it's normal for TWRP to not be able to mount the system
Let's try to diagnose it by going through the error
Could you upload the log and also the screenshot of the error that it spits out
Also upload the built image to some cloud service and send the link here so that i don't have to go through and build the image again
Thanks for testing it out and I'll join you soon so keep trying and I'll try to do everything i can to help you , Have a good day.
animegamer4422 said:
I don't think it's a issue with the recovery and also it's normal for TWRP to not be able to mount the system
Let's try to diagnose it by going through the error
Could you upload the log and also the screenshot of the error that it spits out
Also upload the built image to some cloud service and send the link here so that i don't have to go through and build the image again
Thanks for testing it out and I'll join you soon so keep trying and I'll try to do everything i can to help you , Have a good day.
Click to expand...
Click to collapse
pmos-samsung-a7y18lte.zip
drive.google.com
I think that it's trying to install itself to /system partition which is very small, and the "data" partition is like 50GB. Maybe it's a problem with PBRP (I can't install twrp, it doesn't work for me).
Can you try installing this file and testing if it works for you, or is it the same problem?
Arm1nas said:
pmos-samsung-a7y18lte.zip
drive.google.com
I think that it's trying to install itself to /system partition which is very small, and the "data" partition is like 50GB. Maybe it's a problem with PBRP (I can't install twrp, it doesn't work for me).
Can you try installing this file and testing if it works for you, or is it the same problem?
Click to expand...
Click to collapse
I'd love to test it , but currently I'm not at my home and my A7 is at home (since It's not my daily driver) but I'll test it as soon as I can get back home
Until then
Keep figuring out things
Also I think you can use the TWRP terminal to Change the size of system partition using the resize2fs command i guess
I found this when I looked into it
First to clarify, Resize Partition is different than Resize File System, TWRP provides latter option. It resizes the ext2/3/4 filesystem to the size of partition it's created on. Filesystem size can be checked with df command when mounted, and partition size with blockdev. Just like HDDs or SSDs on PC, Android's eMMC storage is divided into partitions (can be 50+). Some of them have filesystem e.g. the larger ones userdata and system. In simple cases a filesystem occupies a complete physical partition, but it's not always the case, LVM makes it possible to have single filesystem on multiple partitions. Or the opposite what happened in your case as explained here: Sometimes the zip file of: a custom ROM does not have the correct size for the system partition and if the ROM flashes a raw system image, that image will not take up the full block device. Running resize2fs can fix the size Similarly: Sometimes flashing a factory image may flash userdata with an image with a file system that does not take up the full size of the block device So TWRP can expand the filesystem to reclaim wasted space. That's what happened in your case to the /system partition. The actual size of partition was 2.5 GB, but flashed image was of 1.5 GB. Coming to your query: I realized that the system partition is too big (~1.5GB). The current ROM uses only about 40% of the partition so I want to shrink it to make space for cache and data. You want to resize partition, not filesystem. So resize2fs (which TWRP uses at back end) isn't the right choice. As your partition table suggests, you need to delete and recreate partitions 9 to 12. IT'S DANGEROUS AND NOT RECOMMENDED, you may permanently brick your device. All data on these partitions will be lost, so do backup. Also, fdisk isn't proper tool for GPT, it's for MBR partition scheme. Use parted or gdisk instead, but with great care.
So now you can just resize the system partition in case it's size is smaller than the image (not likely in my opinion)
animegamer4422 said:
I'd love to test it , but currently I'm not at my home and my A7 is at home (since It's not my daily driver) but I'll test it as soon as I can get back home
Until then
Keep figuring out things
Also I think you can use the TWRP terminal to Change the size of system partition using the resize2fs command i guess
I found this when I looked into it
First to clarify, Resize Partition is different than Resize File System, TWRP provides latter option. It resizes the ext2/3/4 filesystem to the size of partition it's created on. Filesystem size can be checked with df command when mounted, and partition size with blockdev. Just like HDDs or SSDs on PC, Android's eMMC storage is divided into partitions (can be 50+). Some of them have filesystem e.g. the larger ones userdata and system. In simple cases a filesystem occupies a complete physical partition, but it's not always the case, LVM makes it possible to have single filesystem on multiple partitions. Or the opposite what happened in your case as explained here: Sometimes the zip file of: a custom ROM does not have the correct size for the system partition and if the ROM flashes a raw system image, that image will not take up the full block device. Running resize2fs can fix the size Similarly: Sometimes flashing a factory image may flash userdata with an image with a file system that does not take up the full size of the block device So TWRP can expand the filesystem to reclaim wasted space. That's what happened in your case to the /system partition. The actual size of partition was 2.5 GB, but flashed image was of 1.5 GB. Coming to your query: I realized that the system partition is too big (~1.5GB). The current ROM uses only about 40% of the partition so I want to shrink it to make space for cache and data. You want to resize partition, not filesystem. So resize2fs (which TWRP uses at back end) isn't the right choice. As your partition table suggests, you need to delete and recreate partitions 9 to 12. IT'S DANGEROUS AND NOT RECOMMENDED, you may permanently brick your device. All data on these partitions will be lost, so do backup. Also, fdisk isn't proper tool for GPT, it's for MBR partition scheme. Use parted or gdisk instead, but with great care.
So now you can just resize the system partition in case it's size is smaller than the image (not likely in my opinion)
Click to expand...
Click to collapse
The /system partition is 3.9G big.
This is everything:
https://imgur.com/MOKz0uR
Arm1nas said:
The /system partition is 3.9G big.
This is everything:
https://imgur.com/MOKz0uR
Click to expand...
Click to collapse
Sorry i was sick from past 2 days so couldn't reply earlier
Anyways could you like drop to a shell when you boot up postmarketOS
If yes then check the dmesg
I also think you'll have to flash a special kernel which could also be obtained from the pmbootstrap tool
Also it'd be great if you could record a video of the phone booting up into postmarketOS as that'd help us understand until how far it can reach and where it gets stuck
Thanks alot and Take care
animegamer4422 said:
Sorry i was sick from past 2 days so couldn't reply earlier
Anyways could you like drop to a shell when you boot up postmarketOS
If yes then check the dmesg
I also think you'll have to flash a special kernel which could also be obtained from the pmbootstrap tool
Also it'd be great if you could record a video of the phone booting up into postmarketOS as that'd help us understand until how far it can reach and where it gets stuck
Thanks alot and Take care
Click to expand...
Click to collapse
Hello, did you make any progress with it? I will try installing pmOS again and recording everything.
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
I logged in and typed:
$ df -H
This is the output:
https://imgur.com/7n61Vm3
If I try to start the desktop environment with $ startx command I get these errors:
https://imgur.com/8xOA1kc
dmesg output:
https://imgur.com/eizBP3m
https://imgur.com/nP8aAaB
This is the phone's partition layout:
https://imgur.com/9xNmaAV
https://i.imgur.com/M0m3GjW.png
D
Arm1nas said:
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
Click to expand...
Click to collapse
Sorry for the late reply
Anyways i just got home and have the smartphone I'm my hands
So i can too test it out
Also I think we should try switching to Wayland as X seems to be crashing
By using Wayland if it works we'll know that it's not a Xorg issue but if Wayland too fails we'll know that it's a big in the Kernel and the way it handles hardware
Also could you create a Telegram group for us to chat instantly I think that way we can help each other better and then we'll just create a general guide on fixing things ok XDA
(I cannot post links since I didn't started the thread)[/url]
Arm1nas said:
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
I logged in and typed:
$ df -H
This is the output:
https://imgur.com/7n61Vm3
If I try to start the desktop environment with $ startx command I get these errors:
https://imgur.com/8xOA1kc
dmesg output:
https://imgur.com/eizBP3m
https://imgur.com/nP8aAaB
This is the phone's partition layout:
https://imgur.com/9xNmaAV
https://i.imgur.com/M0m3GjW.png
Click to expand...
Click to collapse
Sorry for the late reply
Anyways ...post links since I didn't started the thread)
Arm1nas said:
This is my installation procedure:
On a Ubuntu 20.04 VM I run:
$ pmbootstrap init
I select my device, DE, go through the setup.
Then I type:
$ pmbootstrap install --android-recovery-zip
$ pmbootstrap export
Then on the phone I unmount everything:
https://imgur.com/PlQZ1oB
Go to ADB sideload:
https://imgur.com/xf1FBzQ
https://imgur.com/H9AbkXY
I connect the phone to my computer and use this command to install pmOS:
$ adb sideload pmos.zip
I recorded the installation procedure:
As you can see it boots up the first time, the file system only has 2.6GB free, when it reboots again, it just boots into busybox terminal. When trying to boot up it gives me these errors:
https://imgur.com/qEtwRlx
I logged in and typed:
$ df -H
This is the output:
https://imgur.com/7n61Vm3
If I try to start the desktop environment with $ startx command I get these errors:
https://imgur.com/8xOA1kc
dmesg output:
https://imgur.com/eizBP3m
https://imgur.com/nP8aAaB
This is the phone's partition layout:
https://imgur.com/9xNmaAV
https://i.imgur.com/M0m3GjW.png
Click to expand...
Click to collapse
I installed plasma desktop and it seems to be working great though there's no on screen keyboard so i had to use a USB OTG to connect a external keyboard and unlock the device and use it And also the performance is not very great it lags alot probably due to the lack of GPU acceleration
animegamer4422 said:
I installed plasma desktop and it seems to be working great though there's no on screen keyboard so i had to use a USB OTG to connect a external keyboard and unlock the device and use it And also the performance is not very great it lags alot probably due to the lack of GPU acceleration
Click to expand...
Click to collapse
What method did you use to flash pmOS? And what recovery do you have? Mind sharing the built pmOS files, so I can flash it myself?
Arm1nas said:
What method did you use to flash pmOS? And what recovery do you have? Mind sharing the built pmOS files, so I can flash it myself?
Click to expand...
Click to collapse
I created a recovery zip using Pmbootstrap and also I set the free space parameter (after running pmbootstrap init) to 2000mb (2gb)
And then i copied that zip file from the temp directory to a Pendrive and connected the pendrive to the phone in recovery mode (PBRP Recovery) and then flashed it
I'll upload the files in a bit
Also I tried using Phosh but it just gets to the Login TTY and then doesn't boots up and i think that's because the device lacks GPU acceleration
Also here's a Telegram group link which I'll delete once you join the group
~REMOVED~
M0Rf30 said:
Hi guys,
Here, for those who are interested, I'm maintaining the packages to use postmarketOS on bare-metal hardware.
I only tested the A750FN variant.
Check it out!
Feedbacks are welcome!
Many thanks:
@VDavid003 for kernel sources
Click to expand...
Click to collapse
hello, are this thread still active?