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).
Related
What you need:
1. Swap Capible ROM with Root Access (see list below)
2. A third Partition on your SD card, known as Linux-swap set between 16-32MB (Easiest way to achieve that for free if you don't have linux with gparted is to download the Ubuntu ISO disk and install it on your system, all for free. can even be installed through Windows or run straight off the disk. you can also follow the link Here.)
3. Research
4. Terminal or ADB
5. Thumbs
What to do:
1. download the attached file and copy it to your sdcard, unmount sdcard from computer.
2. in terminal or adb shell type:
don't type things in ().
Code:
$su (terminal only)
#mv /sdcard/userinit.sh /system/sd/
#chmod 775 /system/sd/userinit.sh
#sh /system/sd/userinit.sh
This should do it, no reboot required. if you want to verify that you have your swap space running now or after a reboot simply type:
Code:
#free
you should see total memory to the right of "Swap" be filled in with the number of bytes you set.
A little bit about Swap on the G1:
Swap partitions are currently completely seperate from ROMs. all ROMs should be able to do this, however I'm not specfically certain and don't have the time or patience to try in or do research for it.
YOU DO NOT NEED TO FLASH YOUR ROM AT THE SAME TIME TO GET THIS TO WORK. In fact, you will have to do this everytime AFTER you do a new flash or wipe. I'm getting mixed reports about this, I myself didn't have to redo this after flashing CM 3.5.3, however it is possible that some are not mounting /system before pushing/copying the file over, which makes thier effort pointless and explains the confusion!
Other Notes:
This script was written by Dwang, I had no part in it, I'm just trying to make it easier and seperate it from Cyanogens mod threads.
Also please understand that Linux does ./sdcard/ and /sdcard/ in linux, nor is there any difference from /sdcard/tmp/ and /tmp/ when you prompt to /sdcard/ (ie, typing cd /sdcard or cd sdcard)
Also, please do not set up your linux swap over 32MB, you're asking for trouble.
Swap Capible ROMs (Dev's PM me if you incorperate this into your ROM):
Cyanogen's MOD 3.5.2 + higher
JACHero w/ http://forum.xda-developers.com/showpost.php?p=4054111&postcount=19
Thank you.. will give this a try and let you know.
A small .bat file would be nice for this since it has to be done after every flashing
We might need a .bat file for all the .bat files i'm collecting.
Wasnt this experimental in CM's rom and it ran "sluggish"?
Unsure, and it runs fine. as far as a .bat.... why? it's all .sh. does .bat even work in linux?
Denkai said:
What you need:
YOU DO NOT NEED TO FLASH YOUR ROM AT THE SAME TIME TO GET THIS TO WORK. In fact, you will have to do this everytime AFTER you do a new flash or wipe.
Click to expand...
Click to collapse
I thought userinit.sh on /system/sd would survive a flash an/or wipe?
Also you might add that mkswap should be run once on a newly created swap partition.
looking over the userinit.sh...........
What exactly does this, .sh, do??
bkmo said:
I thought userinit.sh on /system/sdcard would survive a flash an/or wipe?
Click to expand...
Click to collapse
/system/sdcard doesn't exist. it's /system/sd and no, it doesn't it gets copied over.
Mikey1022 said:
looking over the userinit.sh...........
What exactly does this, .sh, do??
Click to expand...
Click to collapse
first part checks to find the 3rd partition and sets it up as linux swap. the second script checks for media files meant for ring tones and seperates them so that the file doesn't show up twice in your music player.
Denkai said:
/system/sdcard doesn't exist. it's /system/sd and no, it doesn't it gets copied over.
Click to expand...
Click to collapse
Sorry system/sd ...I was editing the post to correct it when you replied. I re-flashed cyanogen 3.5.2 without a wipe and userinit survived.
Denkai said:
/system/sdcard doesn't exist. it's /system/sd and no, it doesn't it gets copied over.
Click to expand...
Click to collapse
/system/sd doesn't get copied over on a flash - that's why userinit.sh is placed there, so users can put custom commands in a location where the ROM (just CM, AFAIK) will know to execute them.
If you aren't running CM 3.5.2 or greater you'll need to set this up somehow so that it is run on boot. Cyanogen has a line added to his A2SD script that will do that.
Now.. Any advice on how to create my swap partition if I don't have a memory card reader to use on a PC w/ Ubuntu? I tried a gparted live cd on my GF's Thinkpad, but the card reader wasn't detected. I'm sure there's some way to do it at the command line, but my linux-fu is out of practice and I never did mess with partitions much.
BTW, thanks for posting - I saw this in the CM experimental thread but kept forgetting to install, until I saw this post. Doing it now
Saiboogu said:
Now.. Any advice on how to create my swap partition if I don't have a memory card reader to use on a PC w/ Ubuntu? I tried a gparted live cd on my GF's Thinkpad, but the card reader wasn't detected. I'm sure there's some way to do it at the command line, but my linux-fu is out of practice and I never did mess with partitions much.
Click to expand...
Click to collapse
Gparted was not detecting my SD reader on my Dell until I installed the newest Gparted from source on Ubunty Jaunty.
bkmo said:
Gparted was not detecting my SD reader on my Dell until I installed the newest Gparted from source on Ubunty Jaunty.
Click to expand...
Click to collapse
OK -- I should have tried a Jaunty disk anyway, I just got sidetracked by the gparted disk not working. I'll try the newer Gparted version with that. Thanks.
Thanks for making a separate thread. You should probably put the post I wrote on how to make a swap partition in your first post.
http://forum.xda-developers.com/showpost.php?p=4029519&postcount=145
Instead of running it again and again, I would prefer it to be added to runme.sh in boot.img... so that it will be run automatically on every boot...
I am trying it now...
it only gets run once on boot, I believe. will add that post, thanks.
what level swappiness is everyone finding optimal?
i'm on a non class 6 microsd and if i set swappiness over 30, it doesn't take long for the system to get bogged down by IO
alapapa said:
what level swappiness is everyone finding optimal?
i'm on a non class 6 microsd and if i set swappiness over 30, it doesn't take long for the system to get bogged down by IO
Click to expand...
Click to collapse
yeah I think 30 may be a bit too high. I'm using 10 or 20 now.
Try 100 It actually makes the phone super responsive at first, but then it starts getting very laggy after a while.
sangeet.003 said:
Instead of running it again and again, I would prefer it to be added to runme.sh in boot.img... so that it will be run automatically on every boot...
I am trying it now...
Click to expand...
Click to collapse
The script was written for cyanogen's ROMs 3.5.2 or greater.
Those ROMs will automatically execute /system/sd/userinit.sh on bootup. Which means no modifying anything in update.zip
The attached boot image is for JACHERO 2.~r6 I have added the script to the runme.sh to mount swap on every boot i am trying to add the .29 kernel which has multitouch....
The swappiness is set to 80 which I feel Works Great Means +20 than the system Default(60) swappiness...
I have not tested it Coz i cant Partition the Sdcard currently with 1 more partition, Will be testing it later say in 5-6 hours...
Testers are appreciated...
Just extract it on computer & fastboot flash it.... on the boot partition...
Noobs Dont Try It
Saiboogu said:
/system/sd doesn't get copied over on a flash - that's why userinit.sh is placed there, so users can put custom commands in a location where the ROM (just CM, AFAIK) will know to execute them.
If you aren't running CM 3.5.2 or greater you'll need to set this up somehow so that it is run on boot. Cyanogen has a line added to his A2SD script that will do that.
Now.. Any advice on how to create my swap partition if I don't have a memory card reader to use on a PC w/ Ubuntu? I tried a gparted live cd on my GF's Thinkpad, but the card reader wasn't detected. I'm sure there's some way to do it at the command line, but my linux-fu is out of practice and I never did mess with partitions much.
BTW, thanks for posting - I saw this in the CM experimental thread but kept forgetting to install, until I saw this post. Doing it now
Click to expand...
Click to collapse
If you mount the sdcard from the menu bar (USB), it will also mount the ext partition too. From there u should b able to partition from within Ubuntu.
I'm working on a cwm recovery flasher to flash twrp. When script goes to inject twrp into boot.img it says that there is no ramdisk in boot.img. I have read in other forums that cwm 6 doesn't read boot.img correctly whem it goes to copy it to /tmp. Anyone have any idea what might cause that?
Also the script attempts to mount /system, but gets error "Block device required". The script I used is:
mount ("ext4", "EMMC", "system", "/system")
I read somewhere that I needed to add -o to the mount script, but that just seems to cause other errors, maybe I'm putting -o in wrong place. I have tried right after the word mount and also just inside the parenthesis. Why do I get "Block device required"?
blscallions said:
I'm working on a cwm recovery flasher to flash twrp. When script goes to inject twrp into boot.img it says that there is no ramdisk in boot.img. I have read in other forums that cwm 6 doesn't read boot.img correctly whem it goes to copy it to /tmp. Anyone have any idea what might cause that?
Also the script attempts to mount /system, but gets error "Block device required". The script I used is:
mount ("ext4", "EMMC", "system", "/system")
I read somewhere that I needed to add -o to the mount script, but that just seems to cause other errors, maybe I'm putting -o in wrong place. I have tried right after the word mount and also just inside the parenthesis. Why do I get "Block device required"?
Click to expand...
Click to collapse
Looks like our mounting SD but labeling it as system...that might be one of your probs...
And that part in the updater script is just an extra thing I added because when I first released it system wasn't mounted by default...
Also now that I think about it I don't think its cwm6 that's the problem...cm9 uses the same recovery and can still flash it, and twrp can't reinject it self...so its something with our new setup...at least that's what I think
Sent from my SGH-I997 using Tapatalk 2
Coming from purely a Linux environment, you get a "block device required" message from mount if you try to mount something without specifying what actual block device it is you're mounting.
Mount requires 3 key pieces of info: the filesystem type, the device to mount (a /dev device), and the path to put the resulting mount. Some of those pieces of info it can get by looking at the fstab file, which pre-defines pieces of info to allow you to shorthand a mount call by simply telling it to mount a path... it then looks up the info in fstab and mounts whatever devices is set to be at that path.
So, if your fstab doesn't exist, or isn't in the right location, then if you tell it to simply mount a path, it won't know what device goes there. Also, if the /dev fs isn't mounted, then you won't be able to tell it to mount a device since the device doesn't exist yet.
No idea if any of that info helps you or not - but as the previous poster mentioned, emmc and system aren't the same... emmc is external sd.
mg2195 said:
Looks like our mounting SD but labeling it as system...that might be one of your probs...
And that part in the updater script is just an extra thing I added because when I first released it system wasn't mounted by default...
Also now that I think about it I don't think its cwm6 that's the problem...cm9 uses the same recovery and can still flash it, and twrp can't reinject it self...so its something with our new setup...at least that's what I think
Sent from my SGH-I997 using Tapatalk 2
Click to expand...
Click to collapse
I thought cm9 used cwm 5? Most of the updater script I have changed anyway, that's not even the same mount command you were using. You called busybox to mount. I've changed a lot in the zip, got rid of a bunch of stuff that wasn't needed. It fails in the same place though. Definately wrong with the way boot.img is being copied. I even checked out boot.img that was left on /sdcard, it seems ok, but it is about 1mb bigger than the boot.img you sent me.Check this out mg:
http://forum.xda-developers.com/showthread.php?p=32001544#post32001544
T959V looks like same problem. They even tried to do it with adb and got read errors.
Edit: I changed mount to mount mtdblock2 as /system which should be correct, still getting No ramdisk in boot.img, I still think dump_image might be causing this, is there something else that can do this?
blscallions said:
I thought cm9 used cwm 5? Most of the updater script I have changed anyway, that's not even the same mount command you were using. You called busybox to mount. I've changed a lot in the zip, got rid of a bunch of stuff that wasn't needed. It fails in the same place though. Definately wrong with the way boot.img is being copied. I even checked out boot.img that was left on /sdcard, it seems ok, but it is about 1mb bigger than the boot.img you sent me.Check this out mg:
http://forum.xda-developers.com/showthread.php?p=32001544#post32001544
T959V looks like same problem. They even tried to do it with adb and got read errors.
Edit: I changed mount to mount mtdblock2 as /system which should be correct, still getting No ramdisk in boot.img, I still think dump_image might be causing this, is there something else that can do this?
Click to expand...
Click to collapse
Hmm...but yeah its not the same exact one as cm9 hasn't been updated in a while...but it is using cwm6...or maybe its just my self compiled cm9 that is using cwm6 lol...if I have time I'll sync IP the latest cm9 sources which should give me the most up to date recovery...I'll see if twrp works with it...
Sent from my Holiday using Tapatalk 2
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
First off, this is an ICS kernel that is intended for use with ICS ROMs. If you aren't using a ROM that is substantially similar to TeamAcid's CM9, then you may want to reconsider before you flash this.
This kernel is the same as the current TeamAcid CM9 kernel. Now that @FBis251 poked me about it, there is a version that also includes the "Hefe Kernel of Darkness" patch to turn off the touch-key backlight after it is touched.
If it's not all that different from the TeamAcid kernel, why would I want to flash this?
It's got TWRP
You can reliably mount /sd-ext or...
...move /data to your microSD, never worry about running out of app & data space, and speed your boot time
It allows you to get to the file system early in the boot process, to be able to change things that ordinarily you couldn't without creating a custom initramfs. This lets you, for example, create /sd-ext and mount something there, or get even wilder and do something completely untested like replacing /data entirely
TWRP can backup and restore /sd-ext
You hate the touch-key backlight
You want to be able to load the FUSE kernel module
How does it work?
When the SGS4G boots, it has a filesystem in the compressed boot/recovery image. It mounts that as the root file system, starts things running, and then all but that root filesystem sort of disappears as Android starts taking over. What happens and what is in that root file system is pretty much locked down unless you're going to create your own boot images. You can't edit a file on your running system and change that behavior. So....
The boot scripts in this build look for /system/etc/init-on-fs.sh right after /system gets mounted, but before much else happens. If it is executable, it will run the script. This means that you can make most of the changes to the environment or process you might reasonably want!
The "interesting" section of init.herring.rc is shown in the hidden text
Code:
on fs
exec /system/bin/logwrapper /system/xbin/echo "init.herring.rc: on fs enter"
# We chown/chmod /efs because mount is run as root + defaults
mkdir /efs 0775 radio radio
chown radio radio /efs
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mkdir /radio 0775 radio radio
mount yaffs2 [email protected] /radio
chmod 0775 /radio
chmod 0775 /radio/modem.bin
chown radio radio /radio
chown radio radio /radio/modem.bin
mount yaffs2 [email protected] /efs
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /data
mount yaffs2 [email protected] /cache
exec /system/bin/logwrapper /system/etc/init-on-fs.sh
chmod 770 /efs/bluetooth
chmod 770 /efs/imei
mkdir /gps 771 gps system
chown gps system /gps
[...]
My init-on-fs.sh
Lists the mounts already in place (from the "stock" init commands)
Creates /sd-ext
Mounts the second partition of the microSD on /sd-ext
Lists the mounts, which should now include /sd-ext
and looks like this:
Code:
#!/system/bin/sh
/system/xbin/busybox mount
/system/xbin/busybox mkdir /sd-ext
/system/xbin/busybox mount -t ext4 /dev/block/mmcblk0p2 /sd-ext
/system/xbin/busybox mount
Since it's running under logwrapper the output goes to the logs and can be seen with logcat or the like.
Since this script runs before any "working" directories get set up and before any processes start running, if you're adventurous, you could even change the mounting of /data and just use microSD storage. I haven't gotten that adventurous yet, as TitaniumBackup seems to be very reliable in moving app data to the microSD partition.
Do I need to repartition my microSD and use /sd-ext?
Nope, you can just enjoy TWRP if you want.
How do I install it?
Download the current version from the next post. Push to your device and flash with your recovery.
init-on-fs.sh does not have an installer and is not distributed. Create it in /system/etc and make sure it's executable.
I have a question...
Check the FAQ right after the Downloads.
If you still have questions, especially if they are about how to use the Hefe Hook or how to configure your phone for 2 GB of /data, please use the Q&A thread.
.
Downloads
kernel-hefehook-kod-2013-12-23-111936.zip
Changes:
Properly incorporates "Hefe Kernel of Darkness" changes
Otherwise the same as kernel-hefehook-2013-12-18-084851.zip
2.6.35.7-Hefe-Hook-KoD-ICS-00184-g807d04b #1 PREEMPT Mon Dec 23 11:17:49 PST 2013
kernel-hefehook-kod-2013-12-19-171937.zip
Note: long-press of the touchpad doesn't work in this version. Please use a later version
Changes:
Incorporates "Hefe Kernel of Darkness" changes
Otherwise the same as kernel-hefehook-2013-12-18-084851.zip
As before, this is a hack to turn off the touchpad backlight as soon as it comes on.
2.6.35.7-Hefe-Hook-KoD-ICS-00176-gb430787 #1 PREEMPT Thu Dec 19 17:19:10 PST 2013
kernel-hefehook-2013-12-18-084851.zip
Changes:
TWRP fstab adjusted to be able to manage and backup mmc0p3 (potentially as /data)
fuse.ko available (~680 kB so not built into kernel)
2.6.35.7-Hefe-Hook-ICS-00171-g79fe663 #1 PREEMPT Wed Dec 18 08:47:03 PST 2013
Kernel code equivalent to 674765731f093fdb5f4a2416b03cf2c6c2c98e67 in TeamAcid's repository
with FUSE enabled as a module in the kernel build
Code:
diff --git a/arch/arm/configs/cyanogen_galaxys4gmtd_defconfig b/arch/arm/configs/cyanogen_galaxys4gmtd_defconfig
index 22303ee..5e44f0b 100644
--- a/arch/arm/configs/cyanogen_galaxys4gmtd_defconfig
+++ b/arch/arm/configs/cyanogen_galaxys4gmtd_defconfig
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.35.7
-# Sun Aug 12 20:38:04 2012
+# Wed Dec 18 07:54:02 2013
#
CONFIG_ARM=y
CONFIG_HAVE_PWM=y
@@ -38,7 +38,7 @@ CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
-CONFIG_LOCALVERSION="-cyanogenmod-ICS"
+CONFIG_LOCALVERSION="-Hefe-Hook-ICS"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
@@ -1900,7 +1900,8 @@ CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
-# CONFIG_FUSE_FS is not set
+CONFIG_FUSE_FS=m
+# CONFIG_CUSE is not set
CONFIG_GENERIC_ACL=y
#
kernel-hefehook-2013-12-12-231320.zip
Changes:
Initial public release
2.6.35.7-Hefe-Hook-ICS-00170-g6a2c60a [email protected]#1 Thu Dec 12 23:11:25 PST 2013
Kernel code equivalent to 674765731f093fdb5f4a2416b03cf2c6c2c98e67 in TeamAcid's repository
MD5 (kernel-hefehook-2013-12-12-231320.zip) = 0bb3950af5a09e1e0364a467c79fceb0
MD5 (kernel-hefehook-2013-12-18-084851.zip) = 38e76dc0d5dc5ae795b3d2ec57183d92
MD5 (kernel-hefehook-kod-2013-12-19-171937.zip) = 06f4ca9535d1baa88b8cc70984dbc661
MD5 (kernel-hefehook-kod-2013-12-23-111936.zip) = 9b638c335ecbcfdd998658b9d6346e63
FAQ
Why doesn't long-press-Home work? ("Darkness" version only)
Because I derped in the merge. I'm checking a version now and should have it up before Christmas.
Do I need to partition my microSD? Do I need to use /sd-ext?
Only if you want to use /sd-ext. You can enjoy TWRP without partitioning your microSD or using a boot-time script.
Will this work without init-on-fs.sh?
Yes
Will you give me instructions on how to replace /data completely with my microSD?
No, I haven't tried it yet myself
No, I need to make sure you can back it up and restore it under recovery
Yes, though first let me get rsync posted and some clear instructions worked out.
How do I format my microSD?
For my init-on-fs.sh script to work, you need your microSD formatted with the "old style" MBR partitioning scheme. My script looks for an ext4 partition as the second partition.
I do all my partitioning on Ubuntu or FreeBSD. You can boot Ubuntu on your Windows machine without overwriting anything ("Try Ubuntu"). I don't trust any Windows program to create a reliable Linux file system.
How do I ask about something else?
Please use the Q&A Thread.
Building
Build using the CM9 "ics" branch using the generally available instructions
Kernel source is on github. Hefe-Hook and Hefe-Hook-KoD are the two branches of interest. Both should be clearly tagged at each release.
galaxys4gmtd.xml:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remove-project name="CyanogenMod/android_vendor_cm" />
<project path="vendor/cm" name="teamacid/android_vendor_cm" revision="ics" />
<project path="packages/apps/SamsungServiceMode" name="CyanogenMod/android_packages_apps_SamsungServiceMode" revision="ics" />
<project path="packages/apps/CMFileManager" name="teamacid/android_packages_apps_CMFileManager" revision="ics" />
<project path="device/samsung/galaxys4gmtd" name="teamacid/android_device_samsung_galaxys4gmtd" revision="ics" />
<project path="vendor/samsung" name="teamacid/proprietary_vendor_samsung" revision="ics" />
<project path="kernel/samsung/galaxys4gmtd" name="jeffsf/android_kernel_galaxys4gmtd" revision="Hefe-Hook-KoD" />
</manifest>
<!--
teamacid's CM9 local_manifest.xml
=================================
vi: ts=4:sw=4:et:noai
-->
twrp.xml:
Code:
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remove-project name="CyanogenMod/android_bootable_recovery" />
<project path="bootable/recovery" name="TeamWin/Team-Win-Recovery-Project" revision="twrp2.5" />
</manifest>
<!--
teamacid's TWRP local_manifest.xml
======================================
vi: ts=4:sw=4:et:noai
-->
TWRP is from the "twrp2.5" branch with the following commits reverted in git
35a35a67663127e42c8048ca0dc7465068a5606f
516e4e23721e4e5aa0a349ab8f27c22a81665880
Note that the "twrp2.5" branch is, at this time, pointing to the same commit as the "ics" branch.
The "twrp2.7" branch is heavily laden with selinux code for later Android releases and appears to have left ICS in the dust.
Changes to to the initramfs are self-documenting and visible in the distributed code.
Ooooo.... look! FIRST!
"My /data's bigger than your /data. Nah nah ne nah nah..."
Code:
localhost / # df -h /data
df -h /data
Filesystem Size Used Available Use% Mounted on
/dev/block/mmcblk0p3 5.6G 2.0G 3.4G 37% /data
localhost / # du -h /mnt/secure/asec
du -h /mnt/secure/asec
16.0K /mnt/secure/asec
It also boots in a minute, with all apps present and ready. No more three or four minutes until everything was read, mounted, and all off SD for all the "external storage" apps.
I'll probably remount the MTD partition as /data/dalvik-cache since my earlier check suggested that the internal flash was faster than the external ext4 for tiny, random reads.
Would you add FUSE (Filesystem in Userspace Linux kernel module) please to the kernel? I would like to try Paragon NTFS driver that said it even works in boot and recovery.
I tried the app, but it complained about the kernel not supporting fuse. I am using hefe kernel on AOKP-ICS.
Let me look at the config. It shouldn't be a problem. Nice to know that people are still interested in a solid ICS experience.
Posted from my SGS4G, thanks to Team Acid development
I really appreciate that you are continually working on development for this device, especially in this area
Sent from my SGH-T959V using Tapatalk 2
Rebel_X said:
Would you add FUSE ...
Click to expand...
Click to collapse
Today's build has the fuse.ko module built and available. I didn't build it into the kernel as it looked to be pretty large (~680 kB on disk) and I'm not sure something that many users would need. If it doesn't automatically load when you start your app, you may need to manually load it (or have it done in a start-up script).
Code:
localhost / # lsmod
lsmod
Module Size Used by Not tainted
bcm4329 213497 0
localhost / # insmod /system/lib/modules/fuse.ko
insmod /system/lib/modules/fuse.ko
localhost / # lsmod
lsmod
Module Size Used by Not tainted
fuse 58977 0
bcm4329 213497 0
Let me know if you have any issues or need help in getting it to load automatically for you.
I'm also curious about the use case. I just haven't run across a need or good use for FUSE on my phone. I have used it for ssh-based file systems in the past and it was pretty slick for that.
As this application of the Hefe Hook kernel is likely to generate more questions that "just an ICS kernel" would have, please use the Q&A Thread.
So, you want to have a nice, big, fast data partition so you don't have to worry about running out of space, or wait for all your apps to be mounted, one-by-one, off your SD. You want to be able to try a new ROM without worrying about your data at all as well, eh?
Oh, you're not on Team Acid CM9 or a similar ICS ROM? You can read along, but I don't know of any other SGS4G ROMs with a boot image / kernel that lets you do this the same way.
OK, all that said, breathe deeply and consider that you might lose all your data if things go awry. Breathe easier in that there are some great backup tools out there!
For this to work well, you'll need a good microSD. One that is at least "Class 10" and from a reputable manufacturer is highly recommended. I've had good luck with SanDisk and Transcend. I'm currently using the SanDisk Ultra 64 GB microSDXC Class 10 UHS-1 Memory Card 30MB/s with Adapter SDSDQU-064G-AFFP-A
Today's prices are not as bad as they were a year ago:
16 GB - $13
32 GB - $22
64 GB - $47
These 64 GB cards work just fine in my experience, being able to address all 64 GB in our phones.
These instructions assume that you have a blank card in your hands and aren't going to mess with the one you are presently using in your phone. You'll have to juggle a bit if you are going to "reuse" your current card.
Format your new card
First, we need to prepare that new card. I suggest four partitions, though you can get away with just the first three.
1) "sdcard" -- FAT
2) "sd-ext" -- ext4
3) "data" -- ext4
4) (spare) -- ext4
Here is how I think about partition sizes:
3) "data" -- 2 GB seems reasonable. I'm using about 1 GB and it would probably double if I installed the apps I've pulled off over the time I've had the phone since I didn't have enough space
4) (spare) -- 6 GB -- Why? I can do two full-image, uncompressed backups of 2 GB of data and 1 GB of internal storage. I can use rsync to very, very quickly do a backup as it only had to copy the added/changed files, not the whole thing. (More later on this.)
2) "sd-ext" -- 1 GB -- What do I do with this? All my apps and data are already on the microSD. I need something here so that scripts that grab the second partition don't grab our data partition. It could be smaller, but I figure I've got 1 GB in my pocket in case I fill everything else up.
1) "sdcard" -- 64 GB - 9 GB = 54 GB left. If you have a 16 GB card, it would be 7 GB, pretty tight, and I'd probably sneak some off of sd-ext and the fourth parition. Well, no, I'd spend a couple more dollars and at least buy a 32 GB card.
I do all of my partitioning on machine running Ubuntu. If you run Windows, you can boot into Ubuntu and run it without installing it.
Apologies here that there aren't a lot of details here yet on how to run the disk tool on Ubuntu. I wanted to get this up sooner than later.
Format the drive with a Master Boot Record (MBR) partition table
Add partitions (my 64 GB sizes shown):
1) FAT, 54 GB, "SD64-2-sdcard"
2) ext4, 1 GB, "SD64-2-sd-ext"
3) ext4, 2 GB, "SD64-2-data"
4) ext4, 6 GB (the remainder), "SD64-2-p4"
I name the partitions so that they are easier to manage on desktop machines. Unfortunately, I don't see the kernel picking up the names on the phone. My naming convention is the "SD64-2" identifies a chip -- a SanDisk 64 GB chip that I've scrawled the number "2" on with a marker. I've got a bunch of them and can't remember which is which without marking them.
Now, put that "new" chip somewhere safe, not in the phone!
You've still got your "old" microSD in the phone.
Power it off, remove your SIM card.
Boot it up and plug it in to your computer, if it isn't already. You don't want to run out of battery half-way through something important. Some things are easier through adb than on the phone. You do have adb up and running on your computer, right?
Get Backups
1) Turn off WiFi (yes, really -- you don't want anything changing your data after you've backed it up)
2) Backup with TitaniumBackup
2) Reboot to recovery
3) Run a full backup in recovery
4) Remove your day-to-day microSD
Get your information over to the "new" microSD
There are a lot of ways to do this, the easiest is probably to get both the old and the new chip mounted on a Linux machine and use rsync, along the lines of
Code:
rsync -avihP /media/jeff/SD64-1-sdcard/ /media/jeff/SD64-2-sdcard/
rsync -avihP /media/jeff/SD64-2-sd-ext/ /media/jeff/SD64-2-sd-ext/
Be careful with the trailing slashes! Especially if they are missing on the source, you'll get a very different result. The "-a" option is the important one, "-vihP" are all about getting some verbose output that supposedly a human can read as it is copying everything.
Grab a beer, cup of coffee, whatever. There is no magic if you are copying over a bunch of GB from one chip to another, especially over USB.
You now have a copy of your old card on your new card, with the new card having the right partitions.
You can run it again to convince yourself that the two have the same files. I do it myself. If it doesn't copy anything, it should be all good. It is a lot faster when you don't have anything to copy!
Put away your old card somewhere safe. Really. Take it out of your computer.
Get utilities on microSD
Before you take the new chip install a couple things. I use the 4th partition for this as "scratch" space. You want a copy of rsync for your phone, Hefe Hook kernel (2103-12-18 or later), and a version of init-on-fs.sh that mounts your microSD for /data (instead of the internal flash). Do not push init-on-fs.sh to the phone yet!
Get your old /data onto the new card
5) Put the new microSD in your phone. Leave the SIM out!
6) Boot to recovery -- I do this by having the phone connected and hitting "return" on
Code:
adb reboot recovery
as soon as I see the Team Acid logo ger replaced my the CyanogenMod boot animation. If it gets to be running, don't panic! No SIM, no WiFi remember? You won't get calls, SMS, push updates, new mail, nothin' Just reboot into recovery and continue.
7) Fire up adb shell, mount the partitions, and get rsync available
Code:
mount -a
cp /mmc0p4/rsync /system/xbin/
chmod 755 /system/xbin/rsync
8) Copy over your /data to the new partition!
Code:
rsync -avihP /data/ /mmc0p3/
Same warnings on trailing slashes, as well as making yourself confident that everything was copied over by running the rsync command twice.
9) Install init-on-fs.sh that will mount your microSD as /data
Code:
cp /mmc0p4/init-on-fs.sh /system/etc/
chmod 755 /system/etc/init-on-fs.sh
My /system/etc/init-on-fs.sh is chatty, but works for me:
Code:
#!/system/bin/sh
/system/xbin/busybox mount
/system/xbin/echo
/system/xbin/busybox mkdir /sd-ext
/system/xbin/busybox mount -t ext4 -o noatime /dev/block/mmcblk0p2 /sd-ext
/system/xbin/echo
/system/xbin/busybox mount
/system/xbin/echo
/system/xbin/busybox umount /data
/system/xbin/busybox mount -t ext4 -o noatime /dev/block/mmcblk0p3 /data
/system/xbin/echo
/system/xbin/busybox mount
10) Reboot to Android
Woo hoo!! Check your system space, you should have a bunch of free space on internal now!
Get everything "internal"
You want your stuff off "android secure" since the way that it works is that Android creates a file that is a filesystem for each and every app you've moved to SD. At boot time, it reads the file, mounts it, checks the filesystem, then "hooks up" the app inside. It can take a couple minutes for this to complete! Putting them on "internal" storage does away with that. They are "just there" like your internal apps used to be. That means you get all the widgets and everything too.
(No, I don't know how to turn off notifications when you move the XDA app to "internal" -- the settings don't seem to do anything.)
Don't rush this. You want to be able to get back to /data on the internal flash later if you need to. We haven't erased /data -- it is a handy "backup" there right now.
This assumes you have TitaniumBackup, perhaps Pro is required. If you don't own it already, I think it is a solid product. If you use something else to manage your apps and backups, take this as an outline.
This looks like a lot to do -- but if you ever have to restore to your internal storage, you'll know what you already had on SD so you can restore it there!
11) Mark your on-SD apps -- this is a pretty-well hidden feature, so stick with me
Launch TiB
One it gets going and "all application information has been loaded"
Go to the Backup/Restore tab
Click on "Click to edit filters"
Clear any existing filter and set
Filter by type: User
Filter by location: External
Click the green checkmark in the top right
It should return to the list of apps, all your on-SD apps should be shown
Click on "Click to edit filters" again
Click on the "Create label..." button
Enter a name, "Apps on SD, December 2013" or whatever makes sense to you
Click on "Add/Remove elements..." button
Click on "Select shown elm." button
You should now see only the "filtered" elements
Click the green checkmark in the top right
Click the "Save" button on label dialog
Click the green checkmark in the top right
You should see your on-SD apps tagged. Phew!!
12) Move all your on-SD apps and data to internal storage
Click the grey checkmark in the top right
You should see the Batch actions screen
Run "Move user apps to internal memory"
Run "Move app data to internal memory" (if you have it)
13) Kick back -- you've done it
I'd reboot to recovery at this point and backup your new data partition. The partions you will want to backup now are labeled
boot (mtd)
recovery (mtd)
system (mtd)
efs (mtd) -- once in a while is fine
cache (mtd) -- can skip, it's cache after all
Android Secure -- should be 0 MB, if so, can skip
sd-ext (p2) -- backup if you have important stuff here
data (p3) -- <== this is all your stuff now!
You can skip "userdata (mtd)" now as it is your "old" internal data partition.
You should also see that TWRP will let you put your backup on your choice of partitions on your microSD:
sdcard (p1)
sd-ext (p2)
mmc0p4
WhyTF is this guy not RC/RD already!?!?
Hey I flashed this on an sgs4g and your darkness patch didn't seem to work, this is on the Dec 18 build.
bhundven said:
WhyTF is this guy not RC/RD already!?!?
Click to expand...
Click to collapse
will put in a nomination when I get home if it's ok with Jeff for RC.
sent from within the white knight
FBis251 said:
Hey I flashed this on an sgs4g and your darkness patch didn't seem to work, this is on the Dec 18 build.
Click to expand...
Click to collapse
I'll take that as a polite request to dust off the cobwebs, patch the current kernel sources, and provide a "Darkness" version with the touch-key backlight turn-off hack
@FBis251 -- it's been checked and is up now -- I had forgotten how nice it is not to have the lights on all the time!
Amusingly, my look at the CM10 and CM11 sources look like they do what my kernel hack does, but in the Android layer.
jeffsf said:
I'll take that as a polite request to dust off the cobwebs, patch the current kernel sources, and provide a "Darkness" version with the touch-key backlight turn-off hack
@FBis251 -- it's been checked and is up now -- I had forgotten how nice it is not to have the lights on all the time!
Amusingly, my look at the CM10 and CM11 sources look like they do what my kernel hack does, but in the Android layer.
Click to expand...
Click to collapse
Ah I misread the OP, I thought I had read "This includes the kernel of darkness patch" but you said that this wasn't derived from the kernel of darkness .
Thanks for the update, flashing it now.
EDIT
Everything's working as expected, thanks again!
moved to Q&A thread (sorry, I need to get glasses).
I'm going to respond to you in the Q&A thread, if you don't mind.
I'll also make links to it a little more evident once I get back with you.
Bumping this thread to verify that this procedure works well with Team Acid AOKP (milestone 6 build 5). Feels smoother than CM9 too.
EDIT
Since it's a dev thread, I'm gonna post a tip that @bhundven gave me. He said to try using noop as the scheduler for the SD card since it seems to get better performance than deadline or cfq.
You can do this by adding an init.d script under /system/etc/ (or just edit one of the ones that are already there) and add the following:
Code:
echo "noop" > /sys/block/mmcblk0/queue/scheduler
FBis251 said:
Bumping this thread to verify that this procedure works well with Team Acid AOKP (milestone 6 build 5). Feels smoother than CM9 too.
EDIT
Since it's a dev thread, I'm gonna post a tip that @bhundven gave me. He said to try using noop as the scheduler for the SD card since it seems to get better performance than deadline or cfq.
You can do this by adding an init.d script under /system/etc/ (or just edit one of the ones that are already there) and add the following:
Code:
echo "noop" > /sys/block/mmcblk0/queue/scheduler
Click to expand...
Click to collapse
FB...you're the only one who could get away with a bump. haha So glad to see you are still around, even if its just lurking around back in the shadows. you're one of 4 who helped me get to where I am with Android from day 1. I love this phone! Thanks. (I know this is off topica sn a dev thread I apologize in advance)
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?