Database Info

[UTIL] sdparted v0.6 - easy sdcard partitioning, upgrading to ext3/4

this script automates the process of partitioning a sdcard on your android device. it should work fine for all sizes/types of sdcards, but since i can't test all sizes/types of sdcards, we'll have to see.
if you are running into problems with the script, post the log file(located at /data/sdparted.log) when asking for help.
big ups to cyanogen (parted and upgrade_fs) and Denkai (upgrading to ext4).
i welcome all comments, questions & suggestions, related to the script. this is NOT a general q&a.
read the ENTIRE post BEFORE asking questions, please.
to manually partition your sdcard see my other thread.
DISCLAIMER: i take no responsibility for what happens to you, your phone, sdcard, data, sanity, etc if you use this script. remember to backup your sdcard to your pc before you begin. this script has the potential to COMPLETELY WIPE your sdcard!
##########################
shameless promotion:
sdparted can also be found in amon_ra's recovery and natalic's android toolkit.​
##########################
features:
-automated partition of sdcard using parted
-upgrading to ext3/ext4
-downgrading to ext2
-interactive mode
-supports units (M and G)
-supports floating point partition sizes (ie. .5G=512M)
-automatic logging to /data/sdparted.log​
##########################
requirements:
android phone with proper utilities(cm-recovery-1.4, amon_ra's recovery)
sdcard <--class 6 recommended(adata makes good ones...they max out the g1 hw in terms of speed)
adb
fingies​
##########################
Code:
sdparted v0.6 created by 51dusty
if you use this script in your work, please give some credit. thanks.
requirements: cm-recovery-v1.4
usage: sdparted [options]
options:
--fatsize|-fs SIZE[MG] set the size of the fat32 partition to <SIZE>.
default=total sdcard size - (ext + swap)
--extsize|-es SIZE[MG] set the size of the ext partition to <SIZE>.
default=512M
--swapsize|-ss SIZE[MG] set the size of the swap partition to <SIZE>.
if set to 0, no swap partition will be created.
default=32M
--extfs|-efs TYPE set the filesystem of ext partition to <TYPE>.
valid types=ext2, ext3, ext4
default=ext2
--upgradefs|-ufs TYPE upgrades existing ext partition to <TYPE>.
this operation will NOT wipe your sdcard and
cannot be used with any partition creation options.
valid types=ext3, ext4
--downgradefs|-dfs TYPE downgrades existing ext partition to <TYPE>.
this operation will NOT wipe your sdcard and
cannot be used with any partition creation options.
valid types=ext2
--interactive|-i interactive mode
--help|-h display this help
--printonly|-po display sdcard information
--silent|-s do not prompt user, not even initial warning.
examples:
sdparted creates swap=32M ext2=512M fat32=remaining free space
sdparted -efs ext4 creates swap=32M ext4=512M fat32=remaining free space
sdparted -fs 1.5G -efs ext3 creates swap=32M ext3=512M fat32=1536M
sdparted -es 256M -ss 0 creates no swap ext2=256M fat32=remaining free space
sdparted -ufs ext4 upgrades ext partition to ext4
##########################
need to backup your ext partition?
the following commands will backup/restore your ext partition to/from a folder named sdbackup in your current directory. these must be run while phone is booted, not recovery.
to backup your ext partition: adb pull /system/sd/ %CD%\sdbackup
to restore back to sdcard: adb push %CD%\sdbackup /system/sd
##########################
to run from computer:
1. download sdparted.txt below to computer
2. connect g1 via usb
3. boot into cm-recovery-v1.4, goto console(alt-x)
4. at your windows cmd prompt type: adb push /path-to/sdparted.txt /sbin/sdparted
5. then type: adb shell chmod 755 /sbin/sdparted
6. to run type adb shell and hit enter.
7. you can now run script (ie. sdparted -efs ext4).​
to run w/o computer:
1. download sdparted.txt below to root of sdcard. (get downloadcrutch if needed*thnx lycoln)
2. boot into cm-recovery-v1.4, goto console(alt-x)
3. at # prompt type: mount /sdcard
4. then, mv /sdcard/sdparted.txt /sbin/sdparted
5. then, chmod 755 /sbin/sdparted
6. you can now run script (ie. sdparted -efs ext4).​
you CANNOT run this script from terminal app.
##########################
if the script crashes or you receive an error:
immediately pull the log to your computer(using adb pull /data/sdparted.log sdparted.log), b/c the log will not be there after a reboot. send me the log when reporting errors, please.
##########################
changelog:
changes in v0.6
*new feature=interactive mode
*tweak user abort function for those with itchy fingers
changes in v0.5.3
*remove initial warning(kinda pointless if there is another before you wipe)
*clean partition table handling code
*general code cleanup/consolidation in anticipation of new features
changes in v0.5.2
*handling of "partition 1 may not be aligned to cylinder boundaries", fixing "sh: -gt: argument expected" and related phenomena (ie. sdparted trying to partition using negative numbers ) reported by midtoad
changes in v0.5.1
*slight change to logging(so slight it only gets a .1), fixing "/sbin/sdparted: line 5: .//sbin/sdparted: not found"
changes in v0.5
*new feature=floating point partition sizes
*new feature=downgrade ext filesystem (ext3->ext2 ONLY, for now)
*fix some crappy programming
changes in v0.4
*unmount all partitions before operations, fixing "Error: Partition(s) on /dev/block/mmcblk0 are being used".
*remove some useless code
changes in v0.3
*new feature=logging
*new feature=units
*new feature=print card info
changes in v0.2
*add cm-r-v1.4 check to prevent running in 1.3.1
##########################
todo items:
-downgradefs support for ext4
##########################

Excellent!
One of the easiest things Ive done in a while. Worked great!

great.
i'm new to android, so i have a question.
I'm guessing when you go to settings and eject SD card, it only unmounts the FAT32 partition, right?
So does that mean the only safe way to eject the card is shutting down?
great job!

SyXbiT said:
great.
i'm new to android, so i have a question.
I'm guessing when you go to settings and eject SD card, it only unmounts the FAT32 partition, right?
So does that mean the only safe way to eject the card is shutting down?
great job!
Click to expand...
Click to collapse
That depends which ROM you are running and how it's set up. CyanogenMod for example, will automatically use the Ext partition for Apps-to-SD if it finds one. Ejecting a card while the phone is using it as part of its internal memory would be a Bad Thing™.
If you are running the stock firmware, it would be safe to remove the card after ejecting it in settings.

Could anyone at their convenience post directions for using this with console,
and where to place text attached? Funny, I've done this the manual way but don't know the simple things.
Thanks in advance for your work and patience. =)

Figured this one out!

Can you tell me how exactly to run this script? I ran this in recovery and i get sdparted not found.

sacredsoul said:
Can you tell me how exactly to run this script? I ran this in recovery and i get sdparted not found.
Click to expand...
Click to collapse
where did you place the file? did you run chmod?

excellent! Great job dusty

sacredsoul, Make sure you have the latest Cyanogen's Recovery Image, which I used 1.4. I got the same error using 1.31. I then updated to 1.4 and it worked perfectly. great Post 51dusty.

i am tryin to do this...hw do i get in recovery mode and wat exactly im i typin?..i hav a 4gig

Just wanted to chime in and say this script worked beautifully for me on a 16gb card.
Thanks!

I don't get it, am I mounting first, placing the file on the SD, then rebooting into recovery? The instructions make it sound as if I can just boot into console and pull it off my machine. Many people might find that confusing.

ctheory83 said:
I don't get it, am I mounting first, placing the file on the SD, then rebooting into recovery?
Click to expand...
Click to collapse
...i don't say to mount anything.
ctheory83 said:
The instructions make it sound as if I can just boot into console and pull it off my machine.
Click to expand...
Click to collapse
actually, you can...but you push instead.
51dusty said:
to install from computer, download, boot into cm-recovery-v1.4, goto console, and adb push /path-to/sdparted.txt /sbin/sdparted, then adb shell chmod 755 /sbin/sdparted. you can now run the script from adb(in recovery) or from g1 recovery console.
Click to expand...
Click to collapse
i will edit post to make installation less "confusing"...done.

Hey dusty i been struggling with this for like a week now and finally decided to post! so i got the adb thing running on my pc, windows 32-bit and it finds my device when i put the command "adb devices", so that far im fine but then your instructions tell us to boot the phone into recovery console and the type "adb shell" the result comes up "no adb found", at this point i have tried it with my phone plugged into the pc and unplugged without mounting it from the G1... please help what am i doing wrong im really confused! thanks!

The script is great i finally figured it out how to work this thing, but i just a bit of an issue now, when i keep installing apps my internal storage is also getting reduced a bit, i have installed about 100mb of apps and my internal storage reduced to 67 from 70mb, i have already cleared cache, using the app to move it to sd card, and also turned my phone off and took out the battery and rebooted, but its standing at 67mb... does this possibly have anything to do with protected apps??? please help!!

adb not found
hi,
it says adb not found, what am i doing wrong ?.

so my problem is that im not quite sure on what you mean by the path in the following command
adb push /path-to/sdparted.txt /sbin/sdparted
i know that you mean where ever the file is located but, for instance i just put mine in the c drive, so it should be adb push /c drive/sdparted.txt /sbin/sdparted
what is the correct way that should look?
edit: ok so i found my problem, i tried to install it from the adb shell, that was wrong, and this is the string in windows cmd i used for sdparted located just on the c drive
"adb push %cd%\sdparted.txt /sbin/sdparted" it then says the speed it was written, etc. does that mean it is correctly installed? from here, im not too sure how to go about setting up my partitions, again im very new to this.

you can now run the script from adb(in recovery) or from g1 recovery console.
Click to expand...
Click to collapse
Everything went okay, only the last stap with running from adb i dont understand.
What command is that ?

CoopZor said:
Everything went okay, only the last stap with running from adb i dont understand.
What command is that ?
Click to expand...
Click to collapse
i have edited first post to clarify how to run.
to run, from adb:
1. boot into cm-recovery-v1.4, goto console(alt-x)
2. at windows prompt, type adb shell and hit enter.
3. once connected via adb, you can now run script (ie. sdparted -efs ext4).
Click to expand...
Click to collapse

removing apps2sd - questions

I've followed this guide from loccy, except for the last part where he uses vi editor in order to edit the apps2sd script...
http://forum.xda-developers.com/showpost.php?p=4353332&postcount=68
also when i install a fresh ROM, the app-private directory does not exist to begin with since i don't have any purchased .apk's installed in the /system/sd folder, so i basically just skipped all the steps for modifying the app-private folder... i did however create the proper folders in the /data folder for app-private and followed the corresponding commands... when i try to cp the file information from the SD to /data/app-private folder, i get a no such file or directory exists error, which i'm assuming happens because i have no private apps... i don't know if this is causing my problem, if so please let me know...
since I could never get VI editor to work properly in a windows command prompt, i adb pull the a2sd file from /system/bin and edited the file using notepad++, and adb push the file back... i verified that the file was pushed correctly and edited correctly by pulling it back again and verifying the changes were correctly made... i'm assuming not being able to use VI editor is probably whats causing my problems as i'm running windows 7 RTM, and notepad++ is possibly changing the file structure of the a2sd when i edit it on my machine...
i assumed busybox was installed cause if i run an invalid vi command, i get busybox reference information from the shell returned to me... i even went as far as installing my own instance of busybox to see if that would fix my VI editor problem, but that didn't help either... when i type #VI a2sd to edit the a2sd script file, i only get a partial amount of the actual script, some of it which comes out garbled, and i can't do anything, not press esc, not type an exit/reboot command, press j or k to move up and down... i can however type :q to exit the VI editor instance...
after pushing the a2sd script file after editing it with notepad++, my phone gets stuck on the first splash screen... unforutunately, i don't have a log i can provide to you guys, cause when i run adb logcat when the phone is booting, it just stays at waiting for device...
any help would be appreciated... if possible i would like to get this sorted out so maybe a script can be written for those who want to disable apps2sd like me...

Would be great if someone could upload a modified a2sd file with app2sd disabled, then we only put this file in update.zip file, sing it, and then make a fresh flash... Thats correct? or we need to change the update.zip structure?
ATM i am not at home then i can't try to use VI, but i sure that someone can upload the a2sd file modified

yah... after i finished writing my original post, i tried using VI again and noticed in the header of the a2sd script on jacherorom 1.4 that the a2sd script was written by cyanogen...
so, it was just a matter of taking the a2sd script from cyanogens 4.0.1 release, extracting his update.zip, taking the a2sd file from system/bin, and adb push the file to replace the existing file from your recovery image...
it worked like a charm... i'm currently running 230mb free on a fresh install... already i've noticed that its slightly faster than running off your ext for apps2sd on a class 6, but only time will telll... i'm gonna run this ROM through its courses and post my results... hopefully it doesn't slow down as much as using apps2sd, i'll post my results in a day or two

you can try just removing your ext2/3 partition. if the ROM does not detect a ext2/3 partition, it wont move hte apps to that partition thus no apps2sd.

motivecc said:
yah... after i finished writing my original post, i tried using VI again and noticed in the header of the a2sd script on jacherorom 1.4 that the a2sd script was written by cyanogen...
so, it was just a matter of taking the a2sd script from cyanogens 4.0.1 release, extracting his update.zip, taking the a2sd file from system/bin, and adb push the file to replace the existing file from your recovery image...
it worked like a charm... i'm currently running 230mb free on a fresh install... already i've noticed that its slightly faster than running off your ext for apps2sd on a class 6, but only time will telll... i'm gonna run this ROM through its courses and post my results... hopefully it doesn't slow down as much as using apps2sd, i'll post my results in a day or two
Click to expand...
Click to collapse
But you modified a2sd from cyanogens ROM or what? You put the modified one in the update.zip then fresh flash?

fridlack said:
But you modified a2sd from cyanogens ROM or what? You put the modified one in the update.zip then fresh flash?
Click to expand...
Click to collapse
nope, the a2sd script from cyanogen's 4.0.1 ROM automatically disables apps2sd if your have a fat32 only memory card, thus taking care of having to edit the script myself...
all i did was go into my recovery image, and do the following:
Code:
# go to the tools directory of your android sdk and run a push command
# the format of a push command goes as follows
# adb push <local directory of file> <directory of file on device>
# in my case i would have to type
adb push c:\androidsdk\androidsdk\a2sd /system/bin/a2sd
and thats it
by using the adb push command, i don't have to modify the update.zip file and go through the process of having to resign it... i find it easier to run this command to just replace the one file... i recommend doing this after a fresh install only of course...

motivecc said:
nope, the a2sd script from cyanogen's 4.0.1 ROM automatically disables apps2sd if your have a fat32 only memory card, thus taking care of having to edit the script myself...
all i did was go into my recovery image, and do the following:
Code:
# go to the tools directory of your android sdk and run a push command
# the format of a push command goes as follows
# adb push <local directory of file> <directory of file on device>
# in my case i would have to type
adb push c:\androidsdk\androidsdk\a2sd /system/bin/a2sd
and thats it
Click to expand...
Click to collapse
Thanks for the info, will give it a try

be careful what ROM you use it with... i would only suggest using it with any ROM that utilizes cyanogen's method of a2sd, as using a different one might brick or crash the phone... you can check by
Code:
adb pull /system/bin/ c:\<folder name here>
that will pull all your files to folder of your choice, and you can read the a2sd file by opening it with wordpad and seeing who made it... most likely its cyanogen anyway, but it doesn't hurt to check

Ext4 fs?

Just a quick thought - I was trying to figure out if I might get somewhat better filesystem performance out of ext4 rather than ext3 for the user data partition. As a first pass, I compiled a kernel with ext4 enabled, and tried to change my boot partition init.rc to mount /data as an ext4 partition rather than an ext3 - my understanding is they should be mount-compatible even without repartitioning.
The result of this was a bootloop. Had to reflash back to a working boot.img. Didn't do anything bad to my /data partition though.
Any ideas why this might be happening? Is there a way to grab dmesg from a boot looping kernel on Android?

I've found the following procedures to be helpful in debugging custom kernels.
First, remove the fbcon.c patch in the kernel source (you can just edit the one line that gets modified and uncomment it):
Code:
nano drivers/video/console/fbcon.c
Search for "navy", then uncomment the line:
Code:
update_screen(vc);
Rebuild your kernel. Now you'll have the ability to get a framebuffer console, if your kernel command line arguments are correct. You have to supply custom kernel command line arguments when using mk-boot-img. I use the following when using mk-boot-image:
Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "[email protected] [email protected] vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](bootbmp),[email protected](logodata)" -o boot.img
The important part there is changing the console parameter from the default ttyS0 to tty0.
I make separate boot images when debugging - one that executes a shell in the initial ramdisk, and one that doesn't. To get a shell in the initrd, which you'll want to do in this case to figure out your mount issue, is change the above mkbootimg --cmdline parameter:
Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "break=top [email protected] [email protected] vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](bootbmp),[email protected](logodata)" -o boot.img
Notice the "break=top". This will give you a command shell before anything in initrc has been executed. You could also use "break=bottom" or "break=init" to get you to different spots in initrc.
Hope that helps! Happy hacking!

Oh, and I forgot to mention that a usb keyboard is very handy after you get a shell

jersacct said:
I've found the following procedures to be helpful in debugging custom kernels.
First, remove the fbcon.c patch in the kernel source (you can just edit the one line that gets modified and uncomment it):
Code:
nano drivers/video/console/fbcon.c
Search for "navy", then uncomment the line:
Code:
update_screen(vc);
Rebuild your kernel. Now you'll have the ability to get a framebuffer console, if your kernel command line arguments are correct. You have to supply custom kernel command line arguments when using mk-boot-img. I use the following when using mk-boot-image:
Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "[email protected] [email protected] vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),153728[email protected](cache),[email protected](bootbmp),[email protected](logodata)" -o boot.img
The important part there is changing the console parameter from the default ttyS0 to tty0.
I make separate boot images when debugging - one that executes a shell in the initial ramdisk, and one that doesn't. To get a shell in the initrd, which you'll want to do in this case to figure out your mount issue, is change the above mkbootimg --cmdline parameter:
Code:
mkbootimg --kernel zImage --ramdisk initrd.gz --cmdline "break=top [email protected] [email protected] vmalloc=192M video=tegrafb console=tty0,115200 fbcon=rotate:1 fbcon=font:VGA8x8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=9c5ed6131a00 tegraboot=nand mtdparts=tegra_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](bootbmp),[email protected](logodata)" -o boot.img
Notice the "break=top". This will give you a command shell before anything in initrc has been executed. You could also use "break=bottom" or "break=init" to get you to different spots in initrc.
Hope that helps! Happy hacking!
Click to expand...
Click to collapse
Hey jersacct, so I've tried this (recompiled with your suggested patch, then made new boot image with the last set of params you mentioned) and I absolutely see the framebuffer scrolling by rapidly right after the Viewsonic Birds display. However, I never get the break into console - the FB scrolls by very quickly, then I get the GTabDevs boot image for about 2 seconds, then I boot loop again.
Any ideas? I have tried both the break=top and break=init variants of that mkbootimg command line with no success.
EDIT: I tried with a known-good ramdisk image too. The boot.img boots fine, but again I never get dropped to console.

Hmm, I suspected the issue might be that the default config has a pesky setting called CONFIG_CMDLINE="" that could be force-overriding any command line passed to the kernel from the boot image. Tried again with that line commented out, and still didn't have any luck getting the break= command to do anything.
I could probably try forcing the command line from CONFIG_CMDLINE but not sure why that would be different from passing it in mkbootimg...
EDIT: nope, I tried that too. Doesn't make a difference. So I assume it's receiving the CMDLINE just fine. For some reason break=top isn't giving me a console. I also tried it with my USB keyboard already plugged in to see if that was making a difference with the input devices, and still no console.

Still no luck on the debug console. At my wit's end on that. All I can say is that on a regular boot with ext3 mounting my /data partition I see that the partition is dirty and the first mount attempt fails. Second attempt seems to succeed. Says I need to fsck my data partition - which I'd do, but our busybox doesn't seem to support fsck.
Anybody know where I can find a busybox binary that properly supports fsck for ext2/3 and also has mkfs.ext4? I know the Archos guys seem to have one and that's an ARM v9 device so it should work, but I'm having trouble finding it (I even downloaded the "SDE" firmware from the Archos site).
I think the reason the ext4 driver is probably just that it's dirty, though I can't confirm that without the damned debug console.
If I can get an up-to-date busybox on here, I suspect this will just start working magically, without further ado. Ideas are appreciated, either on busybox binaries or on getting the initramdisk console stuff that jersacct posted to work.

These guys can help you:
http://forum.xda-developers.com/showthread.php?t=895599
And it makes a HUUUUGE difference...

rcgabriel said:
Still no luck on the debug console. At my wit's end on that. All I can say is that on a regular boot with ext3 mounting my /data partition I see that the partition is dirty and the first mount attempt fails. Second attempt seems to succeed. Says I need to fsck my data partition - which I'd do, but our busybox doesn't seem to support fsck.
Anybody know where I can find a busybox binary that properly supports fsck for ext2/3 and also has mkfs.ext4? I know the Archos guys seem to have one and that's an ARM v9 device so it should work, but I'm having trouble finding it (I even downloaded the "SDE" firmware from the Archos site).
I think the reason the ext4 driver is probably just that it's dirty, though I can't confirm that without the damned debug console.
If I can get an up-to-date busybox on here, I suspect this will just start working magically, without further ado. Ideas are appreciated, either on busybox binaries or on getting the initramdisk console stuff that jersacct posted to work.
Click to expand...
Click to collapse
You know, I didn't think to mention that I was using the Karmic ramdisk image - I bet our stock ramdisk image doesn't have breakpoints setup in initrc. You can grab a copy of a stock initrd image here:
http://www.retardedrobot.com/karmic-initrd-orig.gz
Then just use it instead of the stock ramdisk image when using mkbootimg. Please note, I hardcoded mine to get root to work off the SD card. I think this is an unmodified initrd, so it may work straight out of the box (and boot android if allowed). You might have problems with it though, and may need to unpack it, edit some scripts (for mounting root, etc) and repackage it.
Hope that helps.

stanglx said:
These guys can help you:
http://forum.xda-developers.com/showthread.php?t=895599
And it makes a HUUUUGE difference...
Click to expand...
Click to collapse
Yeah, I've seen the thread before.
I think I was just exhausted and bleary eyed earlier and completely frustrated.
Now that I'm a little more clear-headed, things are much easier.
I've snagged the busybox build out of the Archos initramfs. It indeed does all the ext4 stuff.

jersacct said:
You know, I didn't think to mention that I was using the Karmic ramdisk image - I bet our stock ramdisk image doesn't have breakpoints setup in initrc. You can grab a copy of a stock initrd image here:
http://www.retardedrobot.com/karmic-initrd-orig.gz
Then just use it instead of the stock ramdisk image when using mkbootimg. Please note, I hardcoded mine to get root to work off the SD card. I think this is an unmodified initrd, so it may work straight out of the box (and boot android if allowed). You might have problems with it though, and may need to unpack it, edit some scripts (for mounting root, etc) and repackage it.
Hope that helps.
Click to expand...
Click to collapse
Ahh, this explains why it doesn't work. Thanks so much, I'll take a crack, but hopefully I can clean up my /data partition into a proper ext4 partition with busybox and get it mounting now. I'll see tomorrow, too tired tonight.

Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.
Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.
What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.
So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.

rcgabriel said:
Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.
Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.
What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.
So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.
Click to expand...
Click to collapse
will it incorporate in the future Vegan release? I know we have to do complete format, and goto ext4?
Will love if we can get ext4.

Are you using internal or external (sd card) for the test? The internel storage is very very slow compared to most class 4 sd cards.
rcgabriel said:
Ba...ZING! Finally got ext4 driver working properly. Figured out what was causing the bootloops before, I think - or at least localized the issue.
Running an e2fsck and disabling inandop.sh seems to have done the trick. I think one of the checks in inandop.sh was triggering a reboot. My init.rd now successfully mounts /data as an ext4 partition, mount reports the partition as ext4.
What I need to do now is try to clean up inandop.sh so it properly uses the right binaries to set up the partition as a true ext4. Currently just mounting an ext3 partition with the ext4 driver.
So far no significant performance boost in Quadrant, it's within 50 points of where it was before. But I'm not done yet.
Click to expand...
Click to collapse

One would think that Viewsonic will atleast put class 4.. It does appear to be slow at times when you use SDCard for cache to browse..

stanglx said:
Are you using internal or external (sd card) for the test? The internel storage is very very slow compared to most class 4 sd cards.
Click to expand...
Click to collapse
Using internal SD card. I don't have an extra microSD handy here, just the one in my Nexus One, which is 16GB class 2 so probably too slow to be useful for that.
Still I'm fairly convinced that I should be able to get better results with the internal SD card.

Take a look.. See if your getting the same results with ext4..
Here is the output of a test:
http://forum.xda-developers.com/showpost.php?p=10239762&postcount=2
As you can see a Class
rcgabriel said:
Using internal SD card. I don't have an extra microSD handy here, just the one in my Nexus One, which is 16GB class 2 so probably too slow to be useful for that.
Still I'm fairly convinced that I should be able to get better results with the internal SD card.
Click to expand...
Click to collapse

stanglx said:
Take a look.. See if your getting the same results with ext4..
Here is the output of a test:
http://forum.xda-developers.com/showpost.php?p=10239762&postcount=2
As you can see a Class
Click to expand...
Click to collapse
I'll do more testing later, but right now I've managed to bootloop my G Tablet and I don't have my USB cable here, it's at the office (snow day today). I can boot to recovery but it seems like ClockworkMod recovery 0.8 doesn't want to mount my external MicroSD card from my N1 to copy over a working update.zip to re-flash.
So unless I find another USB cable lying around the apartment somewhere, my G Tablet is out of commission until Monday or until I hit the nearest Radio Shack this weekend.

Status update: I am waiting on a class 6 SD card from Newegg so I can try more stuff out and perfect this without continually screwing up my internal SD card and having to repartition, reformat, etc.
In the meantime, I have tried adapting Chenglu's data2loop method to use an ext4 filesystem in the loop device files rather than an ext2 filesystem as he uses, using a kernel with ext4 enabled.
The good - I'm getting even higher Quadrant benchmarks than with the baseline data2loop. Up to around 3470, averaging around 3400 with a couple of runs. I was, with the same kernel and Chenglu's data2loop patch, getting in the 3200s to 3300s, so the difference seemed somewhat significant to me.
Unfortunately, it seems to puke out every time I reboot. The data must get screwed up somehow in the /data/ext4 files, and my G Tab goes schizo and won't even finish the bootup process - screen flickers from the "Vegan" logo during boot, and then screen shuts off. Have to hard shut-down then hard reboot to recovery and wipe data to get things working again.
The /misc/inandop.log file seems to report that data-to-loop was successfully enabled, so I'm not sure exactly why it's puking out in such epic fashion. Have to work more on this later.

Most likely experiencing some corruption in the cache.... add the sync command to the mount and see if that helps stability using the loopback device.... Also when you create the file system are you using
mkfs.ext4 -O ^huge_file ....
I have read you need to turn off huge_file as it causes some issues (dont remember where I read it though)
rcgabriel said:
Status update: I am waiting on a class 6 SD card from Newegg so I can try more stuff out and perfect this without continually screwing up my internal SD card and having to repartition, reformat, etc.
In the meantime, I have tried adapting Chenglu's data2loop method to use an ext4 filesystem in the loop device files rather than an ext2 filesystem as he uses, using a kernel with ext4 enabled.
The good - I'm getting even higher Quadrant benchmarks than with the baseline data2loop. Up to around 3470, averaging around 3400 with a couple of runs. I was, with the same kernel and Chenglu's data2loop patch, getting in the 3200s to 3300s, so the difference seemed somewhat significant to me.
Unfortunately, it seems to puke out every time I reboot. The data must get screwed up somehow in the /data/ext4 files, and my G Tab goes schizo and won't even finish the bootup process - screen flickers from the "Vegan" logo during boot, and then screen shuts off. Have to hard shut-down then hard reboot to recovery and wipe data to get things working again.
The /misc/inandop.log file seems to report that data-to-loop was successfully enabled, so I'm not sure exactly why it's puking out in such epic fashion. Have to work more on this later.
Click to expand...
Click to collapse

So just to update this thread, I did get ext4 working stably on the /data partition. The trick is doing everything from recovery mode - making the ext4 filesystem via adb push and adb shell, then flashing an update.zip from recovery that packages a kernel that supports ext4 with a ramdisk/init.rc that mounts /data as ext4 and skips the inandop.sh step entirely since that was the source of bootloops (stock inandop.sh expects /data to be ext3 and pukes if it's not).
You can see my detailed instructions over here: http://forum.xda-developers.com/showpost.php?p=10489732&postcount=23
The bad news is really no significant performance bump from ext4 in the standard 2gig partition. But I expect it to be stable as hell. Still need to experiment more with ways to speed things up (safely).

[HOWTO] Dual-boot Android ROMs, e.g. CROMI-X and CM

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

a7y18lte: Porting on postmarketOS

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?