OUTDATED METHOD, CAN RESIZE PARTITIONS DIRECTLY IN "HEKATE".
This seems to be a popular question on the release thread, so I thought I would share the method I used to resize the partitions included in the stock switchroot android image.
You can do this a number of ways, I'm lazy tho.. so I went the fastest route I could think of.
All of the following steps were done on a linux virtual machine running the gparted live ISO.. this is not a tutorial how to setup a virtual machine or linux, I'm going to assume you're competent enough to do that as all the steps will require one or the other!
What tools are we going to be using?
gparted (GUI interface)
gdisk (terminal)
The only steps taken prior to what I'm going to share here is that I flashed the 16gb image to my microsd.
So what is the end goal?
Expand the general storage (fat32) partition.
Expand the android user data partition.
Allocate a partition for emummc (optional).
Repair the MBR which we destroy by resizing the partitions.
First thing I did was capture some data of the default partition layout for reference:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Great now that we have that, lets get stuck into it.
GPARTED
Fire up gparted and you'll be presented with the following popup:
We want to hit the "Fix" button.. this will allow us to utilise all the remaining space on the microsd card.
As soon as we do this tho, there is no turning back.. you'll need to complete the tutorial.
What we're looking at here is the default layout, note the unallocated space highlighted below:
The first thing we're going to do is expand the android user data partition (sdd7 in the screenshot above).. Right click "userdata" -> "Resize/move".
I decided to go with 32GB which should be plenty, how large you want to make this partition is entirely up to you.
The next thing we're going to do is move the partition down the stack, we do this by entering "0" into the "free space following" field.
You'll notice the white box surrounded by the dark purple border has moved position to the far right to reflect your changes.. hit the "resize/move" button and confirm the warning window.
You can now see the "userdata" partition has moved down the stack, will be resized to 32GB and our unallocated space has moved up.
We're now going to repeat this process for the remaining android partitions (without resizing tho).. starting from the "dtb" partition and working our way up to "vendor".
Right click partition -> "Resize/move".
Modify "free space following" to "0".
Hit the "Resize/move" button.
Confirm the warning.
You get the idea.. repeat this process until you reach the "hos_data" partition.
Eventually you'll be left with something like this, note the unallocated space is now directly under our "hos_data" partition.
It's time to expand our fat32 partition, you can drag the black arrow on the right hand side all the way to the end to set the maximum size.
[EMUMMC USERS ONLY] If you intend on using emummc we can allocate some space for the partition by entering "29856" in the "free space following field", this will automatically reduce the partition size to accommodate the required free space.. this step is completely optional.
[EMUMMC USERS ONLY] We need to create a new partition (right click "unallocated" -> "new").. the only option we're going to change here is the "file system" field to "unformatted".
Now is the time to verify all our settings are correct before finally hitting the apply button.. confirm the warning and let it do its thing.
Before closing gparted, we want to take note of the drive identifier located on the top right of the screen.. mine is "/dev/sdd", we're going to be using the next steps.
GDISK
All the remaining steps will be executed using gdisk in a terminal window.. first of which will be the following command:
Code:
sudo gdisk /dev/sdd
Replace "/dev/sdd" with your drive identifier.
Input "r" as a command, this will enter us into the "recovery/transformation" submenu.
You can output the MBR & partition table by inputting "o" & "p" as commands, since we used gparted the MBR has been modified.. we need to revert this back to ensure everything plays nice.
Input "h" as a command, this will create a new hybrid MBR to replace the one we destroyed with gparted. If you intend on using emummc we need to add both the hos_data partition (#1) & the emummc partition (#8)..
You would do this by entering:
Code:
1 8
Otherwise if you're not planning to use emummc, we just add the hos_data partition (#1):
Code:
1
Place EFI GPT parition first in MBR?
Code:
N
Creating entry for GPT partition #1 (MBR partition #1)
Enter an MBR hex code:
Code:
EE
Set bootable flag?
Code:
N
[EMUMMC USERS ONLY] Creating entry for GPT partition #8 (MBR partition #2)
Enter an MBR hex code:
Code:
0b
[EMUMMC USERS ONLY] Set bootable flag?
Code:
N
Unused partition space found. Use one to protect more partitions?
Code:
N
Great, now lets output the MBR & partition table by inputting the "o" & "p" commands once again to confirm our changes.
Looking good! :good:
The last thing to do is write our changes, we do this by entering the "w" command.
Do you want to proceed?
Code:
Y
That's it folks, we're done! I know this was a little lengthy... hopefully this helps some of you out!
If you're interested in knowing more in-depth info about hybrid MBR's I came across the following website that contains invaluable information: HERE.
Awesome. Thanks for the guide! It seems as though my suspicions weren’t unfounded. Seems like we do have to write the android image to SD first before an easy change can be made. I’ve been trying to do this manually for the past week or two, but I’ve always failed because I never got the partition map setup correctly(have only tried a few times as well).
Are you familiar with how the partition map needs to be set? I’d love to practice getting this setup manually.
This is interesting. I'll give this a try. Thanks for putting this up.
Are steps 9 & 10 needed if I'm planning to create a fresh emummc via SX OS?
My current setup is one emummc/emunand and I'm using it for both Atmos and SX.
Thank you very much, especially for the gdisk part!
Move/Resize "Unknown filesystem" partitions?
Having trouble moving these. Gparted doesn't seem to want to let me do it. Any known variables that may influence this?
~~Tito~~ said:
Awesome. Thanks for the guide! It seems as though my suspicions weren’t unfounded. Seems like we do have to write the android image to SD first before an easy change can be made. I’ve been trying to do this manually for the past week or two, but I’ve always failed because I never got the partition map setup correctly(have only tried a few times as well).
Are you familiar with how the partition map needs to be set? I’d love to practice getting this setup manually.
Click to expand...
Click to collapse
You're very welcome!
What other info did you need beside what is shown above? Nothing is stopping you from creating the partitions manually, but why would you.. seems like a waste of time to me!
geckoquiver said:
This is interesting. I'll give this a try. Thanks for putting this up.
Are steps 9 & 10 needed if I'm planning to create a fresh emummc via SX OS?
My current setup is one emummc/emunand and I'm using it for both Atmos and SX.
Click to expand...
Click to collapse
Zero experience with SX OS, can't say for sure.
If it were me, I would backup my current emummc, create a new partition & restore it (this is actually exactly what I did, I was migrating sdcards tho).
tabzer said:
Having trouble moving these. Gparted doesn't seem to want to let me do it. Any known variables that may influence this?
Click to expand...
Click to collapse
I'm assuming you're not using the gparted live CD? You need to make sure the partitions are not mounted.
If you continue to struggle just do yourself a favour and use the gparted live CD/USB, don't waste your time chasing your tail trying to troubleshoot.
fOmey said:
I'm assuming you're not using the gparted live CD? You need to make sure the partitions are not mounted.
If you continue to struggle just do yourself a favour and use the gparted live CD/USB, don't waste your time chasing your tail trying to troubleshoot.
Click to expand...
Click to collapse
Thanks. I was using Ubuntu, and even with the partititons unmounted, I was only allowed to resize/move the partitions that were not "unknown". It seems the gdisk live is even more powerful. I don't really understand what the difference is. But it works.
If I resize after mounting the 128gb image to 64gb, will I'll be able to use the remaining 64gb like a normal sd card?
So after doing this, I can't run any of the games that are installed to my SD card (I copied my old fat32 partition off and back after following this guide). Any idea why this happened?
Also, any way to access the fat32 partition from within Android itself?
Did you restore an image to the partition, or did you copy your files manually?
~~Tito~~ said:
Did you restore an image to the partition, or did you copy your files manually?
Click to expand...
Click to collapse
Copied my files manually. I've done that before when upgraded SD card to a larger card and no issues.
First, Nice guide..... As the person that wrote the original guide, I would recommend creating the partition scheme from scratch, so you dont have to move the data a bunch. Then copy the partition info from the individual partitions manually, like my original guide said.
BTW @op congrats on posting a decent guide before me. I was getting there, but got caught up in life.
bfenty said:
So after doing this, I can't run any of the games that are installed to my SD card (I copied my old fat32 partition off and back after following this guide). Any idea why this happened?
Also, any way to access the fat32 partition from within Android itself?
Click to expand...
Click to collapse
Verify the hybrid MBR is setup correctly.
gavin_darkglider1 said:
First, Nice guide..... As the person that wrote the original guide, I would recommend creating the partition scheme from scratch, so you dont have to move the data a bunch. Then copy the partition info from the individual partitions manually, like my original guide said.
BTW @op congrats on posting a decent guide before me. I was getting there, but got caught up in life.
Click to expand...
Click to collapse
Original guide?
Creating partitions manually is a waste of time in my opinion.. much easier and faster to simply move them.
EDIT: I will add there's no wrong way to do this, if you prefer to create the partitions manually go for it.. whatever works!
fOmey said:
I'm assuming you're not using the gparted live CD? You need to make sure the partitions are not mounted.
If you continue to struggle just do yourself a favour and use the gparted live CD/USB, don't waste your time chasing your tail trying to troubleshoot.
Click to expand...
Click to collapse
I also cannot move the partitions with unknown filesystems in gparted. No partition is mounted and isn't possible via ubuntu gparted and also not via gparted live usb...
Any ideas?
Edit: Tried to write the 3 partitions with unknown filesystem to .img files, format the partitions, move them, write the .img files back and do the gdisk stuff.
This also didn't work, hekate says no fat32 partition recognized though I can mount it just fine in ubuntu...
...No idea how you moved the partitions with unknown filesystems, I read gparted doesn't allow this by default.
hey, I've been trying to get this done for some time now but I haven't has thought your guide would help me but I keep running into the same problem.
keeps telling me that it's unable to mount SD card
The flag for the main FAT partition needs to be 0C. Gdisk will be your friend.
trohn_javolta said:
I also cannot move the partitions with unknown filesystems in gparted. No partition is mounted and isn't possible via ubuntu gparted and also not via gparted live usb...
Any ideas?
Edit: Tried to write the 3 partitions with unknown filesystem to .img files, format the partitions, move them, write the .img files back and do the gdisk stuff.
This also didn't work, hekate says no fat32 partition recognized though I can mount it just fine in ubuntu...
...No idea how you moved the partitions with unknown filesystems, I read gparted doesn't allow this by default.
Click to expand...
Click to collapse
I didn't do anything special..
Post the output of gdisk o & p command from the recovery menu.
JaRocker said:
hey, I've been trying to get this done for some time now but I haven't has thought your guide would help me but I keep running into the same problem.
keeps telling me that it's unable to mount SD card
Click to expand...
Click to collapse
Post the output of gdisk o & p command from the recovery menu.
Any changes you make in gparted will require you to go back to gdisk and restore the hybrid MBR.
hey so i followed the guide before with 16gb and it worked great.
i'm redoing it with 64 gb and i can't get around the very first step of moving userdata to the end.
anytime i try to do anything to it i get a warning saying "moving a partition might cause your OS to fail to boot" which i didn't get the first time around.
then when i apply the changes, it immediately gets an error.
any suggestions for this problem? Thank you!
So i followed the guide and it works. Now i have some questions to further improve my current setup below:
256gb microsd with SX OS, Atmos, Android (No more swapping of cards).
My problem now is I cannot use SX OS to create hidden partition emunand as this will format the sd card and i will lose the android partitions and configs.
One option is file based partition but my preference is hidden partition so i can again use same emunand if i want to toggle between SX OS/Android/Atmos.
This is because atmosphere file based emunand is not stable as per devs and i also cannot get it to work using my SX OS file based partition.
I used atmos emummc but SX OS is not detecting it obviously.
The questions are:
1. For emummc, can i put that in front so it will be at sector 0X2 which i believe what SX OS config is looking for?
2. If i just use gpart to move the emummc partition in front do i need to repeat all the gdisk commands again?
3. If my aspiration is not possible at all then i will just stick with SX OS file based partition. Can i delete the atmos emummc and just extend the fat32 partition so i can reclaim space? Do i need to run the gdisk commands again?
~~Tito~~ said:
The flag for the main FAT partition needs to be 0C. Gdisk will be your friend.
Click to expand...
Click to collapse
Oh so flag is the mbr hex code, right? And you say it should be 0C? I will try that.
In the guide it says enter EE for mbr hex code.
Related
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.
This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)
Here is how i see the next steps:
Strip down uboot (or other bootloader) and teach it boot from it's own partition.
For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.
This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)
Finish CWM. 100% done.
Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645
Work on CM9 for both SDcard and internal booting
See Below
So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.
If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.
So PM me or come to #nook-tablet @ freenode
Reserved
Bootstrap-loader (Goal #1)
Here is some more details on my thoughts on bootstrapping /boot and /recovery to boot unsigned images.
Today we are only bootstrapping with a 2nduboot on the sdcard. This would allow custom kernels and ramdisks on emmc for things like easier root, overclocking, CM9, CWM, etc
So my thoughts were to bundle together a bootstrap bootloader (uboot obviously will work, but another project that was used for CM on the touchpad called, moboot, may be a nice option to get menus and such) and the unsigned kernel+ramdisk into one binary blob. The unsigned boot.img will be at a well known offset. This will allow us to act as "stock" as possible and do things like. Replace just the kernel with an OC one. Replace just the ramdisk with ro.secure=0, etc.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
This would also allow us to completely replace recovery with CWM.
Current Status: Fattire working on a meny for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into. Low Priority
CM9 (Goal #2) Inprogress
There is a lot here and I am going to go at it pretty methodically adding one feature at a time. So graphics first, then key/touchscreen, usb gadget, etc.
There is a number of kernel changes that need to be done:
Find the closest git repo/branch/revision from omap zoom to apply B&N changes as a patch.
This will allow us to a) have revision history b) allow merging up to 3.0 easier
This is pretty important and if anyone is handy with git and knows of an easy way. Let me know
Backport key changes (fattire probably has this already done)
Backport usb gadget
Backport a hwrenderer compatable sgx drives (maybe move to a 3.x kernel at this point instead)
Backport
Current Status:
Teasers:
Wow. Thanks nemith for all the info. I will work with you and 100% will give the donation to them (verbal and writen agreement). From when I was building CWM on the GNex I remeber having to change one of the values in the .mk file to allow for adb.
Hi nemith,
That is a nice plan which aligned with my plan for modding u-boot to boot off the internal partitions .
I pushed some changes into my git repository on github which looks like #1 on your list. git://github.com/bauwks/Nook-Tablet.git
So for example, to build a 2nd u-boot that will install to the internal flash partition "recovery" and try to load the next stage at offset 256K of the internal "recovery" partition one would do:
(cd to u-boot directory and switch to second-uboot branch first, then)
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_irecovery
make
./tools/build_nt_2ndboot_img.py -f -o irecovery.img u-boot.bin
dd if=/dev/zero of=irecovery.img bs=1 seek=262143 count=1 # pads to 256K size
Then, you can cat your irecovery.img and your real recovery.img together and blast them onto the recovery partition.
There is also a nt2ndboot_iboot config that will do the same, but is used on the "boot" partition.
I have only done minimal testing with the recovery partition 2nd uboot. I'm about to write a full image onto my recovery partition and see what happens
Update:
I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N
nemith said:
So now that we have found the leaking crack in the bootloader and proved it's usefulness fat-tire and others are going to start work on a couple of key projects that I could use a little help on.
This will also keep conspiracy theorists at bay who call me "extremely low IQ male rooster with social development issues" (Also I have no pies)
Here is how i see the next steps:
Strip down uboot (or other bootloader) and teach it boot from it's own partition.
For example install 2nduboot in /boot, hijacking the signature check and then setting a 1MB offset to look for the real, unsigned boot.img. Repeat for recovery.
This is the real hold up and why there is nothing to "flash" as of yet. (still no pies)
Finish CWM. 100% done.
Completed. See recovery.img here: http://forum.xda-developers.com/showthread.php?t=1440645
Work on CM9 for both SDcard and internal booting
Started on this one as well. I can boot but haven't got adb working and no graphics (expected at this point)
So instead of insulting me. I am looking for some people to help work on these things. We are going to be doing this is private respostories and a private irc channel due to the stupid reward that is out there.
If you are wanting to work with me. The reward (if we get done by the 22nd) goes to Doctors Without Borders. This is where we should all be donating. No negotiating.
So PM me or come to #nook-tablet @ freenode
Click to expand...
Click to collapse
A bit on UI, cleanup, and various boot scenarios
Bauwks.. cool, glad emmc is is a go.
Current Status: Fattire working on a menu for SD booting. Still discussing best way to do internal booting although using bauwks bootstrap uboots will work for now for emmc but incorporating a possible menu is being looked into
Click to expand...
Click to collapse
UB2 update from me: A fruitful night with lots of fun enhancements, some modest UI feedback, and a sprinkling of safety/sanity fixes and other tweaks. SD and emmc options should be more convenient/consistent now, with recovery selection effectively handled by UB2 not UB1 (though power+n will remain an option obviously). I'll let nemith elucidate.
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?
Considering I don't have an NT and I'm working blind here with nemith testing... I think this could wind up pretty nifty.
bauwks said:
Update:
I flashed my recovery partition with irecovery.img + a random twrp2 image I had and it boots solely from internal flash! No more SD card needed, no more USB connection needed, just holding down power+N
Click to expand...
Click to collapse
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
dhkr234 said:
Nice!!!!
I was loathing the idea of having to keep a bootable sdcard in the thing forever. From my understanding of this, this hardware is now "cured", and just needs a special blob appended to the front of the boot and recovery partitions, eh?
Click to expand...
Click to collapse
Yeah. Or more specifically, everything in those partitions will need to be shoved over by a set amount to make room for UB2.
fattire said:
Also, bauwks, nemith suggested, and I thought it wasn't a bad idea, to expand to 512K instead of 256K as a partition buffer just to be on the safe side. I think he said the partitions are 16MB in all, so a little extra padding for possible future bloat is probably not a bad thing to have-- especially if there's gonna be a 2nd-bootloader "standard" (ie, so that any UB2 or menu will work in the future...) now's the time to decide- what do you think? Is 512 reasonable? Adding a single new .rle pushes you over. (We actually can eliminate two .rles right now, as the "charging" and "plugin" ones are effectively useless. I got rid of them, then added two more for feedback so I'm back to even, though eventually I'll probably get rid of them too.) What are your thoughts?
Click to expand...
Click to collapse
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
I can't really offer much as I am no android developer. I can modify basics and work thinsg out through educated trial and error but most of what you guys have been on about has been way out of my league. If it makes any difference I have 2 NTs one of which is brand new in a sealed box just sat waiting for the correct time to bother getting it out to play.
I'm quite happy to do testing, tweak things and do what I can where required.
Not sure what happened about the reward thing but as has been said before I think giving it to a good cause is a very decent and honest thing to do.
Doing it and donating the 'winnings' to a good cause is a far better idea and I commend you for following that route. Those that do it solely for the money aren't doing it for the reasons that I think XDA exists and from what I've seen before often get their money out of blatantly using other members hard work to make themselves look good, there always seems to be a lot of sitting on the fence then diving in at the last second and releasing something as their own when most of it isn't.
Anyway, enough babbling from me! Keep up the good work and when you think I can be of any help I will be more than happy to chip in where required.
bauwks said:
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
Click to expand...
Click to collapse
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right? Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...). Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.
Progress on CM9 from @AndroidNemith http://twitpic.com/86hx6m - Twitter
dhkr234 said:
Presumably, the partition table is write protected along with the xloader and bootloader partitions, right?
Click to expand...
Click to collapse
Nope.
dhkr234 said:
Now I guess that would be by power-on-write-protect rather than permanent write protect (which would obviously lock even THEM out of it...)
Click to expand...
Click to collapse
Nope.
dhkr234 said:
Stupid question, but has anyone checked if the eMMC reset pin is connected to a test point on the board or on some gpio we can manipulate? I'm just wondering if we can pull something like a gfree on this sucker, especially since the eMMC is practically identical to the one on VISION/GLACIER/ACE, just larger. Bounce that reset pin and reinitialize the eMMC with write protect disabled, replace xloader and uboot with proper uncrippled ones, and BE GOD.
Click to expand...
Click to collapse
This is not the g2. It's not a write-protected emmc and a power cycle of the emmc will do nothing. I appreciate the enthusiasm, but you're coming to this very late.
More rambling...
If I'm not mistaken, the way you're suggesting is UB2 would be a prepended portion of the boot and recovery images as part of a "package", and this is how we were already discussing doing it in the cm9 build system-- this also matches in effect how Nook Color CM7 distros work-- the bootloader is actually re-installed with every update.zip (to enforce compatibility as newer versions of Android require newer u-boot).
However, I was considering that some people want to swap various u-boots in and out of existing boot or recovery partitions without necessarily having to push aside the rest of the image to make room. So if they're thought of as a unit, it makes total sense to do it as you suggest- but if UB2 is something that can be replaced (or updated) independently, then maybe a standard "buffer" size would be more appropriate.
We've talked about a few ideas- if a simpler boot menu is used to replace UB2, or a redirection to "see other partition for bootloader"... then it could be 512K (or whatever) mostly wasted... which may not be a big deal either.
Anyway, just typin' out loud. Lots of options, and no "right" way to do it.
bauwks said:
Hi fattire,
I guess it depends on how you look at it. I was looking at it like: an "image" is a concatenation of a 2nduboot and an Android kernel/ramdisk. To install, one would just dd the "image" to a partition. Then the 2nduboot wouldn't have to have a fixed max size that is predefined, if it needs to be increased you would just modify the partition offset in the bootcmd to load the stuff after the new size. It would also make updating the 2nduboot easier because it's part of the "image".
But, I have not worked with Android before so I do not have expertise in how images are typically deployed. If you always want the real image to be at a fixed offset then increasing to 512K makes a lot of sense. You are free to use the solution that best fits your problem.
By the way, the offset of the real image doesn't have to be a power of 2, it only has to be a multiple of the MMC sector size (512 bytes).
Click to expand...
Click to collapse
aversion of single-point-of-failure
I'd like to recommend, to avert the Single Point of Failure, a manditory and automatic backup of the /ROM/ partition. Since you're developing the first custom kernel, there will be a lot of work based upon yours for this device.
This can be handled in the init scripts. after /ROM/, /system/ and /sdcard/ mount. If the /ROM/ folder is available and there is no backup, make one. This simple step can save alot of grief in the future in case of damage.
Untested code:
Code:
#! /bin/sh
ROMBACKUPDIR="/sdcard/backup/ROM/";
BACKUPFILE=$ROMBACKUPDIR"ROMPARTITION.img";
TESTFILE="/ROM/NAMEOFANYFILE";
ROMPARTITION="/dev/block/***";
busybox test ! -e $ROMBACKUPDIR && mkdir --parents $ROMBACKUPDIR;
#no backup detected, so make one.
busybox test -f /ROM/$TESTFILE && busybox test ! -f $BACKUPFILE && busybox dd if=$ROMPARTITION of=$BACKUPFILE;
where ***=the ROM partition on your kernel and NAMEOFANYFILE=the name of any file on the /ROM/ folder
Whomever is building the AOSP!!!
Be careful with the ICS 4.0.3. There are alot of issues with the way the AOSP market place is working with it. The 4.4.3 Market has a tendancy to crash continually. Might be worth building ICS 4.0.2, and using that to elimitate all the problems whe can.
I have a mac g5 on public ip space and a NT that I can plug in if any dev's want to use that.
other than that, I'm another tester for y'all.
Loglud said:
Adam,
I own the nooktabletdev.org wiki, I will add all of those into it, or allow you an admin account. Then we can just point to there.
Click to expand...
Click to collapse
I've begun said post here: http://forum.xda-developers.com/showthread.php?p=21371828
Congrats to everyone who cracked it finally
I can say with 90% surity that You can recover a junked ROM partition or for that matter a fully junked eMMC, for the simple fact that it gives other pheriperals a chance before booting into eMMC (cannt say 100 % by myself immidiately now, because have been busy with other stuff at work over the last week, so my memory FIFO wrt my experiments on NookTab is bit blurry now).
AdamOutler said:
I've begun said post here: http://forum.xda-developers.com/showthread.php?p=21371828
Click to expand...
Click to collapse
Ahhhh, documentation!!!!
But seriously, thanks very much for that.
And FYI: Probably the best place to keep documentation is right here: http://forum.xda-developers.com/wiki/BN_Nook_Tablet -- in the xda device wiki.
Hey guys this just made you famous on the interwebz...
http://www.engadget.com/2012/01/14/nook-tablet-bootloader-bypassed-android-4-0-takes-its-first-ste
Good jorb!
How to access pc hard drive while booting remix OS from USB flash drive?
not possible i think. android cant read other partitions.
RoboR1 said:
not possible i think. android cant read other partitions.
Click to expand...
Click to collapse
Rohan M said:
How to access pc hard drive while booting remix OS from USB flash drive?
Click to expand...
Click to collapse
Not true. I used this https://play.google.com/store/apps/details?id=eu.chainfire.stickmount and I can see my windows partitions sadly and oddly not my Linux ones. The windows partitions are read only but still that is great.
Sent from my XT1575 using Tapatalk
EDIT * EDIT * EDIT * EDIT * EDIT * EDIT * EDIT * EDIT * EDIT * EDIT * EDIT * EDIT *
This method don't working on RemixOS! Sorry cause dumb post.
stiw47
Off Topic:
Personal Opinion: Why so easily say "not possible I think"? Is it something impossible in cyber computer world. + this not required any advanced knowledge, this is a basic Linux staffs. Does not matter how much Remix looks like Windows, it is a still Linux base, have Linux Kernel and Busybox. Tip: Try to learn to not doing everything via GUI, try to learning using a CLI.
The end of off topic.
Let's start:
Unfortunately, I cannot boot Remix on my Toshiba Satellite L775D (probably hardware issue, I cannot boot Android x86 M and L also), but I have Android x86 KitKat installed on one of my partitions. Beside Android x86 (ext4), I have one Windows (ntfs), three Linux's (ext4), one data/storage partition (ntfs, data=PODACI on Serbian, on screenshots) and one trying of booting PhoenixOS (ext4). This is how look like:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I successful mounting all my partitions inside Android x86, and I suppose it is same in Remix (let me someone correct if I'm wrong). I mounting all my partitions in rw mode.
1. Linux partitions (ext2, 3, 4)
First, determine what is a name of drive you want to mount. Format for this, is sdXY, where X standing for HDD's order (a, b, c...) and Y for partition number on that disk (1, 2, 3...). For example: my Arch Linux is on sixth partition on first hard drive, it is a sda6. All partitions in Android are presented under /dev/block, so full path for my Archie will be /dev/block/sda6
Second, make folder where you want to mount partition. For example, I maded for me /storage/sdcard0/partitions/ARCH for mounting my Arch Linux partition.
Third, open terminal and execute:
Code:
su
busybox mount /dev/block/sda6 /storage/sdcard0/partitions/ARCH
And whoala, go in Root Explorer, or what ever, open /storage/sdcard0/partitions/ARCH, and you have your partition as rw. Of course, you have to edit comand line abowe, to be appropriate for your scenario (name of drive sda6 and folder where you want to mount partition).
2. Windows partitions (ntfs):
Even a Linux Desktop OSs, need a little program (binary, executable... what ever) called ntfs-3g for mounting ntfs partitions in rw mode. Fortunately, ntfs-3g exist ported for Android, thanks to devs.
First, download ntfs-3g from here
Second, extract .zip
Third, copy extracted ntfs-3g executable to your /system/xbin
Fourth, give them permission 755 (or rwxr-xr-x , how you like)
Fifth, make folder where you want to mount your ntfs partition. For example: I maded a folder /storage/sdcard0/partitions/PODACI for my ntfs storage partition (label PODACI)(partition which Windows people call "D:"). Notice before next step: My storage partition is sda2 (/dev/block/sda2)
Sixth and last: Open terminal and execute:
Code:
su
ntfs-3g /dev/block/sda2 /storage/sdcard0/partitions/PODACI
Output in terminal will be something like an error, but open Root Explorer or what ever and, whoala, your partition is here in rw mode.
Notice: You making folders for mounting just one time, of course. Every next time, you just execute comands.
You can make a script for mounting your desired partition(s) on boot. For example, for my storage partition above:
Code:
#! /system/bin/sh
ntfs-3g /dev/block/sda2 /storage/sdcard0/partitions/PODACI
[/CODE]
save as text file, and run (for example) via Script Manager app, as root and on boot options checked.
stiw47 said:
Off Topic:
Personal Opinion: Why so easily say "not possible I think"? Is it something impossible in cyber computer world. + this not required any advanced knowledge, this is a basic Linux staffs. Does not matter how much Remix looks like Windows, it is a still Linux base, have Linux Kernel and Busybox. Tip: Try to learn to not doing everything via GUI, try to learning using a CLI.
The end of off topic.
Let's start:
Unfortunately, I cannot boot Remix on my Toshiba Satellite L775D (probably hardware issue, I cannot boot Android x86 M and L also), but I have Android x86 KitKat installed on one of my partitions. Beside Android x86 (ext4), I have one Windows (ntfs), three Linux's (ext4), one data/storage partition (ntfs, data=PODACI on Serbian, on screenshots) and one trying of booting PhoenixOS (ext4). This is how look like:
I successful mounting all my partitions inside Android x86, and I suppose it is same in Remix (let me someone correct if I'm wrong). I mounting all my partitions in rw mode.
1. Linux partitions (ext2, 3, 4)
First, determine what is a name of drive you want to mount. Format for this, is sdXY, where X standing for HDD's order (a, b, c...) and Y for partition number on that disk (1, 2, 3...). For example: my Arch Linux is on sixth partition on first hard drive, it is a sda6. All partitions in Android are presented under /dev/block, so full path for my Archie will be /dev/block/sda6
Second, make folder where you want to mount partition. For example, I maded for me /storage/sdcard0/partitions/ARCH for mounting my Arch Linux partition.
Third, open terminal and execute:
Code:
su
busybox mount /dev/block/sda6 /storage/sdcard0/partitions/ARCH
And whoala, go in Root Explorer, or what ever, open /storage/sdcard0/partitions/ARCH, and you have your partition as rw. Of course, you have to edit comand line abowe, to be appropriate for your scenario (name of drive sda6 and folder where you want to mount partition).
2. Windows partitions (ntfs):
Even a Linux Desktop OSs, need a little program (binary, executable... what ever) called ntfs-3g for mounting ntfs partitions in rw mode. Fortunately, ntfs-3g exist ported for Android, thanks to devs.
First, download ntfs-3g from here
Second, extract .zip
Third, copy extracted ntfs-3g executable to your /system/xbin
Fourth, give them permission 755 (or rwxr-xr-x , how you like)
Fifth, make folder where you want to mount your ntfs partition. For example: I maded a folder /storage/sdcard0/partitions/PODACI for my ntfs storage partition (label PODACI)(partition which Windows people call "D:"). Notice before next step: My storage partition is sda2 (/dev/block/sda2)
Sixth and last: Open terminal and execute:
Code:
su
ntfs-3g /dev/block/sda2 /storage/sdcard0/partitions/PODACI
Output in terminal will be something like an error, but open Root Explorer or what ever and, whoala, your partition is here in rw mode.
Notice: You making folders for mounting just one time, of course. Every next time, you just execute comands.
You can make a script for mounting your desired partition(s) on boot. For example, for my storage partition above:
Code:
#! /system/bin/sh
ntfs-3g /dev/block/sda2 /storage/sdcard0/partitions/PODACI
[/CODE]
Wow...nice tuts
I hope this methode included on next remix beta released [emoji4]
Click to expand...
Click to collapse
@stiw47, your sollution didn't work for me. I do everything according to instruction, get error from terminal but partition isn't mounted, can't see it in any file explorer.
Not to brag but I can see my all my first hard drive partitions and my second hard drive partition just fine in the Remix OS file manager, I think I can because I'm using chainfire's Stick Mount app, when I open Remix OS's File Manager, I can find a folder called usbstorage and entering that folder list all my partitions as sda1 2 3 4 5 6 7 and then sdb1 second hard drive.
This is on my HP Envy DV6 and plus running the latest version rooted. 2.101 I think.
Hope this helps somehow.
Sent from my Z00D using XDA Free mobile app
lukros said:
@stiw47, your sollution didn't work for me. I do everything according to instruction, get error from terminal but partition isn't mounted, can't see it in any file explorer.
Click to expand...
Click to collapse
Realy sorry about this, but as I said, this working for me in Android x86 KitKat. I can't run Remix on my laptop. Try to use fuse.ko beside ntfs-3g. Read OP here.
In terminal I can see directories in the Ubunru folder that I created but no file explorer app sees anything.
Yeah, guys, you are right. I didn't been lazy, and I installed Remix on another laptop, just to try. ntfs-3g not working, confirm. About native mount of Linux partitions, it is very strange for me: @dlaciv12 is right - can't see content of partition in file manager, but it is there in Terminal ('ls' comand), strange.
Sorry once again because dumb post.
Well, I'll post this screenshots from my RemixOS on my HP Envy dv6 laptop, where the folder is and what's inside my usbstorage.
Anyone else wanting to access there Windows, Mac or Linux partitions in RemixOS, open File Manager, then My Remix from the left sidebar then usbStorage, all your partitions on all or most hard drives will be listed, I can't get my Zenfone 2E to mount in Remix because it wants to reformat my phone as a memory card, so I'll access my phone from my other 2 Linux OSes or Windows itself.
with root. i used https://play.google.com/store/apps/details?id=com.paragon.mounter.
tested on HFS+ and NTFS.
You are incredible.! Yes, I can see all contents on all partitions of my HD. U DA MAN!
Sent from XDA running on Remix OS
This thread is about how to install RemixOS on HDD without data.img or any size restriction. No need to for any tools to increase RemixOS size.
Update: The more I spend time on this the more I learn new things. We dont need ubuntu to edit grub.cfg. It can be done using Diskpart within Windows.
So the only thing we need Ubuntu right now is to copy the RemixOS files to ext4 partition before we begin installation.
Update 2:If you can boot using gparted (http://gparted.org) then you can directly copy the files to new partition. So no need for Ubuntu. Just copy the Remix ISO files to a subfolder in gparted USB. Once gparted is loaded, open terminal, reformat new partition to ext4, mount it and copy Remix ISO files from USB to partition. Now you can boot from Remix USB and install to this new ext4 partition.
Code:
sudo mkdir /home/user/RemixDir
suod mount -t ext4 /dev/mmcblk0p5 /home/user/RemixDir
sudo cp -r /lib/live/mount/medium/Remix32/* /home/user/RemixDir
/dev/mmcblk0p5 is the partition as seen from gparted.
/lib/live/mount/medium/ is the mount point of gparted USB drive as seen in gparted.
Original:
This is a long thread make sure you read it once before you actually do it. This is long because I documented every step.
Have 2 speedy SD USB3 cards. I am using Sandisk Ultra 64GB & 32GB. You can get away with one but you have to keep reloading Ubuntu and Remix.
Download and install EasyUEFI on Asus T100 from http://easyuefi.com/index-us.html
Download Universal-USB-Installer from http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/
Download Rufus 2.7 Portable from http://rufus.akeo.ie/
Download latest Ubuntu ISO and create bootable USB using Universal-USB-Installer. I am using Ubuntu 15.10. Also, Rufus cannot create persistent Ubuntu.
a. Make the USB persistent. We will need Ubuntu often.
Get the bootia32.efi for your device from anywhere as Ubuntu does not provide it in their Amd64 ISO. The bootia32.efi from RemixOS did not work for me. For my ASUS T100, I got it from http://www.jfwhome.com/2016/01/04/latest-steps-to-install-ubuntu-on-the-asus-t100ta/ and place under /EFI/Boot folder in Ubuntu USB.
Download RemixOS 32-bit zip and extract it somewhere. Use Rufus to load Remix32 ISO to SD card. Universal-USB-Installer created USB will not boot.
Open the Remix OS SD card. Go to efi/boot and edit grub.cfg. We don’t need to put Windows entry here as we will do it later after everything is done.
Code:
menuentry 'RemixOS' --class android-x86 {
search --file --no-floppy --set=root /kernel
set root='hd1,gpt5'
linuxefi /kernel root=/dev/ram0 androidboot.hardware=remix_x86 androidboot.selinux=permissive INSTALL=1
initrdefi /initrd.img
}
Extract Remix ISO as well. Create a folder in Ubuntu USB called Remix32 and copy contents of Remix ISO to Remix32 folder in Ubuntu USB.
Start Windows on ASUS T100 and create new partition using Disk Management. Label it RemixOS. I would rather do it here than from Ubuntu so I don’t mess up Windows. Does not matter what filesystem you use here as you will format again from Ubuntu.
Connect Ubuntu USB to ASUS
Now boot Asus T100 and hit delete key like crazy to get into boot setup. If you see ASUS logo you are too late.
Disable secure boot and make Ubuntu USB first boot option. Save changes and restart.
When you see Try Ubuntu screen press CTRL+ALT+DEL, screen should resize to native resolution. Then select Try Ubuntu and let Ubuntu load.
Open Files, you should see RemixOS partition. Right click and select format.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Select Custom typeName: RemixOSFilesystem: ext3 (I tried ext4 before but had lot of problems running RemixOS so changed to ext3. You can use ext4 if you have problem with ext3.)
After format complete, select Computer -> cdrom. This is the Ubuntu USB folder. You should have RemixOS folder here. Copy the content from this folder to RemixOS partition you created above.
Shutdown Ubuntu, plug Remix32 USB and get to boot from it.
You will see only RemixOS option here. You can press C and go to grub> prompt. Type ls to see all your partitions and make sure RemixOS partition has files are at ls (hd1,gpt5)/
If you see this message, something was not copied over from Remix32 ISO to new partition.
Android-x86 installer is not available
Press RETURN to run live version
After you answer/choose following options, Choose to Run Android-x86 not Reboot. You will be at RemixOS logo and install will continue and complete.
If you are reinstalling RemixOS after say changing partition from ext3 to ext4 or updating/upgrading RemixOS, skip Grub and Grub2 install.
But do over-write system.
Once reboot, you will not see RemixOS/Windows yet. It is still Windows only.
[*]Now we will boot Ubuntu again.
[*]This is where Linux purists are gonna kill me. I don’t know any other way to show Windows + RemixOS boot option, so if you know please let me know and I will update my post.
[*]Open Disks application in Ubuntu.
[*]Select EFI partition and mount it.
Lets boot Windows, open Admin Command Prompt and type Diskpart. Once in, type List Volume to see all partitions on disk. Select volume and then assign a drive letter to it. You can now edit grub.cfg.
Open grub.cfg from efi/boot and add Windows 10 entry as follows. This is a one time process, you dont have to redo this if you upgrade RemixOS, but if you over-write grub, this is needed.
Code:
set timeout=30
set gfxmode=1024x768
terminal_output gfxterm
menuentry "Remix OS" {
search --set=root --file /android-2016-03-01/kernel
linuxefi /android-2016-03-01/kernel quiet root=/dev/ram0 androidboot.hardware=remix_x86 androidboot.selinux=permissive
initrdefi /android-2016-03-01/initrd.img
}
menuentry "Windows 10" {
search --file --no-floppy --set=root /EFI/Microsoft/Boot/bootmgfw.efi
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi
}
We are not done yet . Now lets go back into Windows and open EasyUEFI
Create a new Linux or Other OS entry and select bootia32.efi from EFI partition. Make this first boot option as we will load Windows too from this. You should already have Windows entry pointing to right efi,
Second partition should just have Microsoft related files. If you see something that does not belong here, use Diskpart in Windows or Disks in Ubuntu to delete them.
Finally after 30 steps, restart and you have your RemixOS. Go ahead and install Google Play and if you get any error installing apps from play store, just remove your account from the device and add it again.
Enjoy....
Dude thanks I have a t100 that I could install the alpha on and this one nothing. I also have a Minix that run windows and I could never get the alpha working. The beta couldn't work on anything. What I did after a lot of tries was just copy all the files to a USB stick and use your grub file but I removed the 0,5 part for the HD. What happen was that when it loaded resident mode, it just formated the stick by itself and now it works !
Thanks you so much
Thanks bro, finally my VivoTab M81C its working with your method. Do you have all yours sensors working? (WiFi, bluetooth, gyroscope and GPS) I can just makeit work WiFi.
Still doesn't help those of us on Dell Venue 8 Pro.......
Glad it worked for you.
-Dante- said:
Thanks bro, finally my VivoTab M81C its working with your method. Do you have all yours sensors working? (WiFi, bluetooth, gyroscope and GPS) I can just makeit work WiFi.
Click to expand...
Click to collapse
Lets list the things that DON'T work: Camera (The light is always on but no video in Skype), Bluetooth (Can see a MISC device in my phone but cannot pair), Screen rotation, audio works but crashes often (I just restart the device). Hey, I can atleast run MS Word on it and play android games on it, so no complaints.
Take it step-by-step
meebner said:
Still doesn't help those of us on Dell Venue 8 Pro.......
Click to expand...
Click to collapse
I know how frustrating it is when everyone in the world can install it except us, all I can say is take it in steps. If your device does not even boot when you select Recovery or Guest mode, just press c and go to grub> prompt. From there try playing with grub commands as listed at http://www.gnu.org/software/grub/manual/grub.html#Commands. It might or might not work but you will learn something about grub
<Edit> Wanted to to add, when at grub> prompt type ls. It will list out your partitions, then if you try ls (hd0, gptN) where N is your partition, you will know what file system it is. You can they enter that info in grub.cfg or reboot and command edit (e) and add it there.
Depending on how much time you are ready to spend on getting RemixOS installed, you can search askubuntu. Usually you will get an idea about what is involved in getting ISO to boot in 32 bit EFI. See http://askubuntu.com/questions/392719/32-bit-uefi-boot-support.
Good luck.
Thanks for sharing your grub.cfg. I was already on the right track, but since I didn't know the syntax or the path to the Windows bootloader I couldn't do much more than make a Windows entry in the boot menu that didn't actually do anything. I was going nuts trying to find the proper grub entry for Windows. Now my Toshiba Encore 2 is dual booting perfectly. If only there was a way to install Remix on a NTFS partition, instead, so I could have more than 4gb of data... Just FYI, the 64-bit Remix works just fine; just point grub to the 64-bit file instead of the 32-bit file in your cfg.
Nice share
I tried almost everything, but nothing worked for 32-bit UEFI Windows users, because my system is legacy only and I couldn't test any of the methods myself but you can help them. Can I post a link to your post on my post?
Sent from my Moto G using XDA Labs
Sure, no problem
SalarX said:
Nice share
I tried almost everything, but nothing worked for 32-bit UEFI Windows users, because my system is legacy only and I couldn't test any of the methods myself but you can help them. Can I post a link to your post on my post?
Sent from my Moto G using XDA Labs
Click to expand...
Click to collapse
Sure you can. More people helped the better.
I feel lot of people have these great budget ultrabooks/netbooks which for any corporate reason never got software that the hardware deserved.
I modified this to run on my 64-bit T100HA, but just changing the 32-bit references to 64. It boots, but I am stuck with the same black screen I had when I used the bundled in Installer. I guess it just doesn't work for me. I'm giving it to my wife, and buying a Nook or Kindle Fire for comics. Kinda bummed.
Does it sleep properly?
Shanesgc said:
Does it sleep properly?
Click to expand...
Click to collapse
No it does not. The screen goes dim but does not go off completely.
TP4LG said:
No it does not. The screen goes dim but does not go off completely.
Click to expand...
Click to collapse
I don't think any version of android sleeps properly on this thing. Super frustrating.
Hurray! This worked for me - at least Remix OS is creating data right now. i just had to do one more thing:
- add the bootia32.efi from remix os volume into the efi trusted file and put remix os at the top of boot list directly from efi setup
- everything works. Clearly for Play store to work decently you need to remove unknown source AND set good time zone.
- now i was wondering if there is a way to change the size of the data.img to use most of my 16gb partition for remix os
lilins said:
Hurray! This worked for me - at least Remix OS is creating data right now. i just had to do one more thing:
- add the bootia32.efi from remix os volume into the efi trusted file and put remix os at the top of boot list directly from efi setup
- everything works. Clearly for Play store to work decently you need to remove unknown source AND set good time zone.
- now i was wondering if there is a way to change the size of the data.img to use most of my 16gb partition for remix os
Click to expand...
Click to collapse
Try RMXtools by @imadlatch
Sent from my Moto G using XDA Labs
SalarX said:
Try RMXtools by @imadlatch
Sent from my Moto G using XDA Labs
Click to expand...
Click to collapse
Thanks. that worked but as an internal drive can only be ntfs or fat32 i assume it is not possible to boot the remix pc from ntfs... so is there a way to tell android x 86 base boot files to look for data.img on my sdcard reader or use the whole sdcard as data disc ?
it would be the best way to have enought space to enjoy
lilins said:
Thanks. that worked but as an internal drive can only be ntfs or fat32 i assume it is not possible to boot the remix pc from ntfs... so is there a way to tell android x 86 base boot files to look for data.img on my sdcard reader or use the whole sdcard as data disc ?
it would be the best way to have enought space to enjoy
Click to expand...
Click to collapse
What format is your SD card?
I've not tried it, but maybe, you can keep your boot files (efi or isolinux) to the fat32 drive and move your all other files such as kernel, data.img, system.img, etc to an NTFS drive, overcoming the size limitation.
Sent from my Moto G using XDA Labs
---------- Post added at 04:32 PM ---------- Previous post was at 04:07 PM ----------
TP4LG said:
7. Added a new entry for Other OS and selected partition E and pointed to efi file at E:\efi\boot\bootia32.efi
Click to expand...
Click to collapse
If you could try one thing that would great. This might help many to achieve a data size partition greater than 4 gb
1. Moving all the files to an NTFS drive (keeping the EFI and isolinux folders in your current FAT32).
2. If that doesn't work, moving the kernel file back to your FAT32 drive.
3. If that fails too, moving initrd.img back to your FAT32 drive too.
4. If that fails, moving system.img back to your FAT32 partition too. (means in the end just leaving data.img on an NTFS partition)
Share your finding, by hit n trial
Sent from my Moto G using XDA Labs
I already tried something similar. I tried to install RemixOS on ext4 partition. It uses the entire partition size for OS, no data.img needed at all. But the downside is it does not turn WIFI ON. I can see lot of "intent" errors in logcat when I switch to prompt window by pressing ALT+F1 in RemixOS and typing logcat at the prompt.
I will try your suggestion later today and post results to this thread.
SalarX said:
What format is your SD card?
I've not tried it, but maybe, you can keep your boot files (efi or isolinux) to the fat32 drive and move your all other files such as kernel, data.img, system.img, etc to an NTFS drive, overcoming the size limitation.
Sent from my Moto G using XDA Labs
---------- Post added at 04:32 PM ---------- Previous post was at 04:07 PM ----------
If you could try one thing that would great. This might help many to achieve a data size partition greater than 4 gb
1. Moving all the files to an NTFS drive (keeping the EFI and isolinux folders in your current FAT32).
2. If that doesn't work, moving the kernel file back to your FAT32 drive.
3. If that fails too, moving initrd.img back to your FAT32 drive too.
4. If that fails, moving system.img back to your FAT32 partition too. (means in the end just leaving data.img on an NTFS partition)
Share your finding, by hit n trial
Sent from my Moto G using XDA Labs
Click to expand...
Click to collapse
I agree to test, but which file holds the args to look for the "ntfs drive" files instead of the fat32 drive where boot.efi file is?
Envoyé de mon SM-A510F en utilisant Tapatalk
lilins said:
I agree to test, but which file holds the args to look for the "ntfs drive" files instead of the fat32 drive where boot.efi file is?
Envoy�© de mon SM-A510F en utilisant Tapatalk
Click to expand...
Click to collapse
set root='(hd0,gpt5)'
This tells the boot manager to look for the kernel file to boot and initrd.img.
Regarding to look for boot.efi, that you already specify in your bios settings.
Now the question is, do we need to specify an argument to detect system.img and data.img or is that automatically done?
Sent from my Moto G using XDA Labs
Hello everyone!
After a long day yesterday trying to install Remix OS alongside my already existing Windows 10 and Fedora 24 installations, managed by GRUB2, I finally completed the task.
I decided that I'm going to save other people wanting to do this some trouble, and post the updated guide, since personally I couldn't find it anywhere. It's mainly based on this guide and other similar ones (including the one by @remixtester here on XDA), and since RemixOS changed the install process a little bit, now it's actually done in 10 easy steps.
Recommended system requirements:
2 GHz dual core processor or better
2 GB system memory
Minimum 8 GB of free hard drive space
Internet access is helpful
1. Download the official latest Remix OS 3.0
2. Install Remix OS to a flash drive, using the provided Windows tool. If you don't have Windows, use Rufus or similar piece of software for your OS.
3. Create an at least 8 GB ext4 partition, and disable secure boot. Remember the partition number you are assigned
4. Boot from the flash drive, from the menu that follows click "e" on Resident Mode.
5. Delete > DATA= USB_DATA_PARTIOTION=1 and replace it with > INSTALL=1
6. Select your partition number, format it to ext4
7. Skip GRUB2, skip EFI GRUB and skip Write/Read Access
8. Reboot back to your Linux distro and open the Terminal
9. Log in as superuser and input: > gedit /etc/grub.d/40_custom
Add (do not remove the existing text in the file) the following text to the file. Replace the "X" in set root='(hd0,gptX)' with your partition number. Also paste the text exactly as is, the formatting is crucial for it to work:
HTML:
menuentry 'Remix OS' --class android-x86 {
insmod part_gpt
insmod ext2
set root='(hd0,gptX)'
linuxefi /RemixOS/kernel root=/dev/ram0 androidboot.hardware=remix_x86_64 androidboot.selinux=permissive SRC=/RemixOS UVESA_MODE=1920x1080 verbose logo.showlogo=1
initrdefi /RemixOS/initrd.img
}
10. Rebuild your GRUB:
For Fedora distribution:
grub2-mkconfig -o /boot/efi/EFI/Fedora/grub.cfg
For other Linux distributions:
grub2-mkconfig -o /boot/grub2/grub.cfg
Alternatively:
update-grub
Upon reboot you'll see Remix OS added to your OS entries and you should be able to boot up and use it just fine.
@engmia Great guide! Although I prefer Grub-Customiser!
The GUI makes everything so easy!
Just to be sure...
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
If that's my partition list, and that the 20 GO is the partition I created for Remix OS, then I should write set root='(hd0,gpt4)' ?
7. SKIP GRUB2, EFI GRUB and Write/Read Access
Click to expand...
Click to collapse
So thats skip Grub2, skip EFI grub and Yes to W/R Access?
set root='(hd0,gptX)'
Click to expand...
Click to collapse
https://drive.google.com/open?id=0B9L5kBcmfDqVbWxRU29CbDh4S00
This means it will read set root='hd2,gpt4)'?
Another thing is it cant find /RemixOS/kernel
any ideas?
Ok followed each step by step and i end up with
something (hd2,gpt4) something
must load kernel first
Click to expand...
Click to collapse
on bootup.
Now previously i had it installed via windows 10 on my ssd where i deleted the entry from windows boot manager and put the entry in grub. Everything booted fine. But i didnt want it on my ssd. So i followed this to put it on its own partition on a hdd with ubuntu on it. Also when i try to do the grub2-mkconfig it says "command not recognized did you mean grub-mkconfig"
Vodkanakas said:
Ok followed each step by step and i end up with
on bootup.
Now previously i had it installed via windows 10 on my ssd where i deleted the entry from windows boot manager and put the entry in grub. Everything booted fine. But i didnt want it on my ssd. So i followed this to put it on its own partition on a hdd with ubuntu on it. Also when i try to do the grub2-mkconfig it says "command not recognized did you mean grub-mkconfig"
Click to expand...
Click to collapse
In Ubuntu you can just do
Code:
sudo update-grub
Ok still cannot get this thing going. So heres the run down
UEFI Boot only in bios
sda1,2,3,4 Only windows 10 it makes 4 partitions
sdb1 storage
sdc1 efi
sdc2 ubuntu
sdc3 RemixOS
sdc4 Swap
so i do everything that the instructions say and i get an error for unable to find /RemixOS/kernel and i need to load the kernel first. i think its detecting the partition now due to no having the disk hd2,gpt3 error
Is it possible to install grub/theme using Windows?
Wryth said:
Just to be sure...
If that's my partition list, and that the 20 GO is the partition I created for Remix OS, then I should write set root='(hd0,gpt4)' ?
Click to expand...
Click to collapse
Yes, correct.
Vodkanakas said:
Ok still cannot get this thing going. So heres the run down
UEFI Boot only in bios
sda1,2,3,4 Only windows 10 it makes 4 partitions
sdb1 storage
sdc1 efi
sdc2 ubuntu
sdc3 RemixOS
sdc4 Swap
so i do everything that the instructions say and i get an error for unable to find /RemixOS/kernel and i need to load the kernel first. i think its detecting the partition now due to no having the disk hd2,gpt3 error
Click to expand...
Click to collapse
This sounds like an error due to a wrong path set in the GRUB configuration. Are you certain you have set the correct number for your device? Do you have 3 separate hard drives on your device?
engmia said:
This sounds like an error due to a wrong path set in the GRUB configuration. Are you certain you have set the correct number for your device? Do you have 3 separate hard drives on your device?
Click to expand...
Click to collapse
Yes three seperate hdd in computer and set root='(hd2,gpt3)'
Vodkanakas said:
Yes three seperate hdd in computer and set root='(hd2,gpt3)'
Click to expand...
Click to collapse
Sorry for the late reply. Frankly I don't know how to help you, I can only repeat that to me it looks an error in the partition path. Try double checking what number has your distribution been assigned to terminal.
Guys, FYI we are reworking the INSTALL=1 installer. It should be done within 2-3 weeks. Initial release might be unofficial.
i clicked remix os on the grub and this messages shows up
error: cant find command `linuxefi';
error: cant find command `initrdefi'.
Press any key to continue.....
Click to expand...
Click to collapse
what should i do now? my resolution is 1366x768, http://imgur.com/a/yz4xs
@Ravagioli in grub customizer change linuxefi to linux and initrdefi to initrd.
Can I set the data partition to a specific partiorion on my hdd ??
I have booted RemixOS with no problems however i think it would be better if i could mount one of my hard disk partition as the data partition !!
How can I do that ??
I'm on Kali linux and refind bootmanager !!
Is there a way to disable the Flashing Remix OS logo and see exactly what's going on in the terminal?
It seems to stick for an awful long time on this screen. I've put the files in a seperate partition in Ubuntu /dev/sda3 (hd0,3)
The boot sequence seems to go fine right until this screen, and I'm using the UVESA=1920x1080
I have a Lenovo laptop, booting in legacy mode with an intel chipset.
Thanks for your help
Lisa
This can only be done when install Remix to flash drive? What about hard drive?
uttarayan21 said:
I have booted RemixOS with no problems however i think it would be better if i could mount one of my hard disk partition as the data partition !!
How can I do that ??
I'm on Kali linux and refind bootmanager !!
Click to expand...
Click to collapse
pipyakas said:
This can only be done when install Remix to flash drive? What about hard drive?
Click to expand...
Click to collapse
This guide is for installing it to the hard drive?
Just make sure to check what the updates in the install procedure are, as you were informed the INSTALL=1 will be reworked and something might've changed.
lisa107b said:
Is there a way to disable the Flashing Remix OS logo and see exactly what's going on in the terminal?
It seems to stick for an awful long time on this screen. I've put the files in a seperate partition in Ubuntu /dev/sda3 (hd0,3)
The boot sequence seems to go fine right until this screen, and I'm using the UVESA=1920x1080
I have a Lenovo laptop, booting in legacy mode with an intel chipset.
Thanks for your help
Lisa
Click to expand...
Click to collapse
I'm quite sure there was a full text boot option somewhere, try Googling it. As far as I could remember, the flashing logo was there when the install procedure wasn't completed successfully. Can you boot from a USB drive?
Make sure to see the last few posts. @Vioner informed the install=1 will be reworked.
engmia said:
This guide is for installing it to the hard drive?
Just make sure to check what the updates in the install procedure are, as you were informed the INSTALL=1 will be reworked and something might've changed.
I'm quite sure there was a full text boot option somewhere, try Googling it. As far as I could remember, the flashing logo was there when the install procedure wasn't completed successfully. Can you boot from a USB drive?
Make sure to see the last few posts. @Vioner informed the install=1 will be reworked.
Click to expand...
Click to collapse
Thanks, but I managed to work out what my problem was, you need to ensure the SRC= command points to the remix 'system.img' I wrote everything up here for those still having problems:
https://forum.xda-developers.com/re...oot-screen-t3329554/post70838891#post70838891
lisa107b said:
Thanks, but I managed to work out what my problem was, you need to ensure the SRC= command points to the remix 'system.img' I wrote everything up here for those still having problems:
https://forum.xda-developers.com/re...oot-screen-t3329554/post70838891#post70838891
Click to expand...
Click to collapse
Awesome, happy to hear you worked it out.
------
TLDR
---
As most people know, 8GB is not enough for modern smartphones. With this mod, I provide a modified 'fstab' file and instructions on how to expand '/data' to install apps without root and in a universal way. All apps will install as if in internal storage.
Furthermore, given the old age of these phones, internal eMMC will progressively degrade until the phone dies completely. I have experienced going from 10MB/s writes, to 5, to 2 and then a completely dead phone. This extends the life of eMMC by only writing Android updates to eMMC and will improve responsiveness in phones with very worn eMMC flash.
This is work in progress (some slowdowns occur depending on the card), but I have been daily driving this mode for two months now. I have made adjustments so that the microSD stalls less than stock 'fstab' and EXT4 filesystem.
Example of 64GB card, w/ backup partition (p2) created, still 26GiB free for apps:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
---
THIS MAY DELETE YOUR DATA OR SOFT-BRICK YOUR PHONE. Be careful beforehand and backup your data to another microSD card.
IF YOUR PC HAS eMMC DRIVE, /dev/mmcblk1 MAY BE YOUR OS. Check before doing anything and after each reboot, as sometimes Linux reassigns them on machines with eMMC + card reader.
---
TODO/BUGS
---
- Used space will be messed up if you use more than one partition (can't be mounted as removable storage) but free space will be correct.
- Sometimes I have experienced reboots, with no data loss that I can find. I don't think it is related to this ROM mod.
- F2FS is still experimental and has no way to recover from a corrupted drive/card. If something goes wrong, your only option is to dump the files with PhotoRec software and try to recover what you can.
The data will be there but F2FS can't seem to recover from a damaged superblock.
I have used on one phone without issues for 3+ years but when there is SB corruption it can't recover.
- Push this to a 16.0 ROM, which is lighter on the RAM and has ambient display. (just personal preference) This requires a custom ROM.
---
HARDWARE
---
First you need a capable microSDXC card, I have only tested SanDisk Ultra A1 which are not perfect. SanDisk Extreme 64GB A2 class are probably good but please report performance if you try it. I only recommend this class of cards.
The problem with Sandisk Ultra is that sometimes they stall doing GC and the phone also stalls. This is quite random and will be worse if you use the phone for extended periods without time for background GC to run.
The advantages is they do some kind of wear-levelling and I am yet to see one of these cards die to wear out, despite being used on RPi machines 24/7.
SanDisk Ultra cards (A1 class) and most SanDisk USB drives have issues where they perform great when new but don't do proper garbage collection and will get very slow after a couple of days. So benchmarks look fine but real world it becomes really bad. I had a USB drive that only recovered to 5MB/s writes, that was the baseline, after three or four sequential wipes to most of the drive. These types of cards will also be very slow if you try them as adoptable storage.
Any microSD will work but choose a fast one and please help test different brands.
You also need a PC, preferably with Linux, and a card reader of any kind. This can be done in Windows through TWRP and ADB access but I don't recommend it.
---
BASICS
---
We will format the microSD card with one or two partitions. If you split it, you can do manual backups for the second partition but you can't mount it. Remember that by using /data on the SD card, you cannot use TWRP to backup to it. The modded '/data' partition will mount as a removable SD card in stock TWRP.
Download files:
Arco68's LineageOS 17.1 ROM
The new 'fstab' file from Pastebin: fstab.qcom.
Process flow:
Install 'adb' and enter TWRP mode to access shell,
Use fdisk to create a DOS partition table
Add a new partition with half or full size, starting at block 32768. Leave 1 or 2GiB space free and don't touch it with data. Some types of cards will be able to use these for better performance.
(OPTIONAL) Create 2nd partition right after the first one.
Change the partition(s) type to 'Linux' and spare space as 'Hidden HPFS/NTFS'.
Format partition(s) as F2FS (can also do ext4 but should be unusable),
After this, we will install arco68's 17.1 ROM and push a new 'fstab.qcom' file that will mount the microSD partiton as '/data' and the phone can use it to install apps and user data.
Encryption has not been tested and is not expected to work.
---
PREPARE microSDXC CARD
---
You should also format the card on a Linux PC if you can, as recovery has outdated f2fs-progs or not at all. The ROM has modules and will boot F2FS when instructed to do so.
Check that /dev/mmcblk1 is your microSD card reader BEFORE PROCEEDING! Otherwise, you may nuke your OS!
Do the procedure as listed before, first thing is to 'p' to check you are on the right microSD drive.
Then create the new DOS table and the partitions. This is for expert users only, at this time I will not post detailed fdisk commands.
The output from 'p' print command looks something like this:
Disk /dev/mmcblk1: 31.00 GiB, xxx bytes, 16252928 sectors
Disk model: Sandisk Ultra
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xZZZYYYXXX
Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 * 32768 62947327 62914560 30G 83 Linux
/dev/mmcblk1p2 62947328 yyyyyyyy xxxxxx 900M 17 Hidden HPFS/NTFS
Click to expand...
Click to collapse
You have to manually type '62947328' for the start of the hidden partition. This is only required if you had put data on the card, upon which you should TRIM the unused blocks:
blkdiscard -v /dev/mmcblk1p2
Click to expand...
Click to collapse
If you have a partition to do backups, this moves to p3. Next we format p1 to use as '/data':
mkfs.f2fs -s 2 -z 1 -g android /dev/mmcblk1p1
Click to expand...
Click to collapse
Now we move the card into the phone.
---
ADB COMMANDS
---
This tutorial assumes you have arco68's LineageOS 17.1 from this ROM already installed.
You need to boot the phone in recovery mode by rebooting with VOLUME UP + HOME pressed, until you see 'recovery booting' on the top of the screen.
Next, mount the /system partition and push the new 'fstab' file from your PC:
adb push fstab.qcom /system/vendor/etc/fstab.qcom
Click to expand...
Click to collapse
After this is completed wait a few seconds, unmount system and reboot the phone. It should take a while for the first boot but you should see the setup screen and everything should be running.
If it is not booting, go to recovery or remove the microSD card and check if files are being created on the drive. If yes, everything seems ok. S4 Mini has a very long first boot, for some reason.
Enjoy your new S4 Mini storage of 32/64/128 GB!
RESERVED FOR microSDXC user reports.
I already have LOS 17.1 on my gt-i9192, is there any video tutorial to help out in the SDCARD mod process?
Not really. Are you familiar with Linux and formatting hard drives? If you are, it's mostly install the software and run the commands. You need to know how to find the sdcard device node in /dev (if it's sdX or mmcblk0/1, depending on the PC).
I can help you out or post a preformatted MBR file so you can just write it to the SDCard.
As my 18.1 phone has eaten it's eMMC, I think I'll do this on my next one. Have you used this with Magisk?
ivorget said:
As my 18.1 phone has eaten it's eMMC, I think I'll do this on my next one. Have you used this with Magisk?
Click to expand...
Click to collapse
I definitely recommend doing this then, as I had my eMMC also down to something like 2MiB/s sequential writes before it died - after a few months - and killed the phone completely.
I have never used Magisk nor really understand it's purpose. What would you want to accomplish?
so it's possible format microSD as EXT4?
Yes, it is but you would need to change the above FSTAB file entry for 'mmcblk1p1' from F2FS to:
/dev/block/platform/msm_sdcc.3/mmcblk1p1 /data noatime,nosuid,nodev,auto_da_alloc
I would advise you to not use EXT4 as that is usually more suited to flash with advanced FTL and even TRIM support.
tM&M said:
I definitely recommend doing this then, as I had my eMMC also down to something like 2MiB/s sequential writes before it died - after a few months - and killed the phone completely.
I have never used Magisk nor really understand it's purpose. What would you want to accomplish?
Click to expand...
Click to collapse
Sorry, just saw this now. Yeah I went and ahead and did on 18.1 and it's working great so thanks for making this guide. I guess it's not really necessary as it hasn't caused you issues but I also fixed the relevant userdata partition line in /vendor/etc/selinux/vendor_file_contexts.
A GPT partition table also works fine now, maybe was just lucky as I saw afterwards that was a recent fix lifted into our kernel. Using gparted and mkfs.f2fs from a recent linux system doesn't seem to have caused any issues either.
I'm using a V10 speed card which I think is about the speed of the original eMMC so should probably be the suggested minimum.
Magisk I use for root, mainly for a Tasker setup to tweak charging to extend battery life. I'll tidy it up enough to share at some stage.
Anyway I took a chance and Magisk does work on this setup too.
ivorget said:
Sorry, just saw this now. Yeah I went and ahead and did on 18.1 and it's working great so thanks for making this guide. I guess it's not really necessary as it hasn't caused you issues but I also fixed the relevant userdata partition line in /vendor/etc/selinux/vendor_file_contexts.
A GPT partition table also works fine now, maybe was just lucky as I saw afterwards that was a recent fix lifted into our kernel. Using gparted and mkfs.f2fs from a recent linux system doesn't seem to have caused any issues either.
I'm using a V10 speed card which I think is about the speed of the original eMMC so should probably be the suggested minimum.
Magisk I use for root, mainly for a Tasker setup to tweak charging to extend battery life. I'll tidy it up enough to share at some stage.
Anyway I took a chance and Magisk does work on this setup too.
Click to expand...
Click to collapse
If you can share the context file that would be great. I was having some issues with contexts but this was not MOD related - happened wit the stock ROM - and had to manually fix contexts on TWRP. So maybe that was the issue.
Do please post what card you are using and if you experience performance degradation after a couple of weeks. SanDisk cards are notorious for only running well the first couple of days as they don't have background GC and maybe are not suited to F2FS/EXT4 at all.
tM&M said:
If you can share the context file that would be great. I was having some issues with contexts but this was not MOD related - happened wit the stock ROM - and had to manually fix contexts on TWRP. So maybe that was the issue.
Do please post what card you are using and if you experience performance degradation after a couple of weeks. SanDisk cards are notorious for only running well the first couple of days as they don't have background GC and maybe are not suited to F2FS/EXT4 at all.
Click to expand...
Click to collapse
OK I've attached the file - remove the .txt extension. Search for mmcblk1p1 to see the changes - one line referencing mmcblk1p1 commented out and another line where the data partition is changed to that.
(Full disclosure: I'm using partition 4 so I didn't need to comment out the mmcblk1p1 partition line in my setup.)
Reminder that the file is for 18.1 (unless you find that it's the same for 17.1). And to be clear for anyone else reading the full path it goes under is:
/system/vendor/etc/selinux/
My SD card is a Kingston Canvas Select Plus. The package indicates Class 10 U1 so maybe better to say that as the V10 only appears on the card label.
I am a little concerned that the default android 3-day trim seems to be taking longer but I'll keep an eye on it:
$ logcat | grep -E 'trim |Trimmed'
02-04 06:50:34.969 191 9173 D vold : Starting trim of /data
02-04 06:51:09.778 191 9173 I vold : Trimmed 397697024 bytes on /data in 34799ms