Hi devs,
hoping on help of people who better know about this materia than me, I hope to create a workaround for OTA repair on faulty Iconia B1-A71 from Acer.
In this case we need devs who has knowledge about stock JB and also testers, who has a B1 with problems on installing OTA Updates with "Invalid partition settings" on FAT.
Status:
More and more user of B1 report the problem of updating their device by OTA. It appears to be a mass problem, which Acer has no solution for.
After checking on rooting issues we already know, that there is a difference in dumchar_info between "normal" and "faulty" B1´s:
Android Partition:
http://forum.xda-developers.com/showpost.php?p=40987372&postcount=197
Normal - android 0x0000000026500000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Faulty - android 0x0000000015e00000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Furthermore there is a difference (and this I assume is the problem for OTA routines) on FAT partition:
Normal - fat 0x0000000148638000 0x00000000882e8000 2 /dev/block/mmcblk0p6
Faulty - fat 0x00000001b0a38000 0x00000000232e8000 2 /dev/block/mmcblk0p6
Those who was in charge of rooting the B1 knows, that we have dumped the android partition by dd using the offset shown in dumchar_info.
In this logic it would be impossible to dump a faulty B1 system.img by using the normal offests - you would not "meet the partition/bits", if you use wrong data.
BUT - as we found out it was possible to dump the system.img from a faulty B1 using the offset of a normal B1! User agentdeep confirms a successful root from scratch on Linux base using the normal offsets: http://forum.xda-developers.com/showpost.php?p=40988791&postcount=202
Now my idea:
- According entonjackson pawitp already assume, that the dumchar_info may be wrong, since otherwise agentdeep would have a bricked device. IF we can proof that OTA checks this value - would it make sense to push a corrected dumchar_info through the ENGMODE backdoor? Anyone out there, who is able to save and extract the OTA, to see the routine?
- If it dont work, does it make sense to try a root from scratch on Linux - and fix the dumchar_info afterwards? Is it possible?
- How can I check a report of existing partitions on Android? Do I have to run busybox from terminal, to start fdisk? I would like to validate the partition information inside the dumchar_info...
This subject may be not as hot as a rooting thread - but more and more user report their problem with update errors, and we may help lots of them ... and show Acer, how this work has to be done...
Thank you in advance!
Sub.
I would like to try that procedure enton asked me by replacing 15e to 265 in dumchar_info. But knowing there is no way I can restore my nandroid backup if something bad happens, I will hold for now
Nice to meet you here, agentdeep I was hoping you will join this thread, since you are the one who made me thinking about this solution...
From my point of view the risk of bricking the tab after changing the dumchar_info is ... pretty low. As long as we have a working system you still can switch back to your origin value. But at that point I would also like to get some more background from the Linux masters in here. Currently I have a problem to understand about the dumchar_info - what is it? How it is created? Do I understand right, that it is an output from Linux kernel?
When this file is accessed? On boot? Which result we will have, if we change it? Is it a properties file, used to set up partitions - or just an info? IF it is only an information we can change it without any fear...
https://github.com/ameer1234567890/...To-Gather-Information-About-Partition-Layouts
This page gives us the information, that "fat" is not just the format - it is the internal memory on MTK based devices. Which finally gives me more inscentive to believe that we have an issue with 8gb and 16gb versions. On that I have seen a thread in a different forum, where a user reported to have opened the B1 and found out that there were 16gb internal memory instead of 8gb as shown in the device properties.
Probably we have "masked" 16gb-versions declared as 8gb???
alba81 said:
Nice to meet you here, agentdeep I was hoping you will join this thread, since you are the one who made me thinking about this solution...
From my point of view the risk of bricking the tab after changing the dumchar_info is ... pretty low. As long as we have a working system you still can switch back to your origin value. But at that point I would also like to get some more background from the Linux masters in here. Currently I have a problem to understand about the dumchar_info - what is it? How it is created? Do I understand right, that it is an output from Linux kernel?
When this file is accessed? On boot? Which result we will have, if we change it? Is it a properties file, used to set up partitions - or just an info? IF it is only an information we can change it without any fear...
Click to expand...
Click to collapse
1st, thanks for the thread! It's really been time to create one for this issue.
I will put a link on the 1st post of my thread to this one, for people experiencing this issue.
Regarding agentdeep, I also think changing the dumchar_info won't brick the device. But we should first make sure it won't brick.
Although I'm using Linux for like 10 years now, I cannot help a lot at this moment.
But if there will be a solution, I will put it immediatly into my toolkit
So, I made a small calculation for the offsets, and this seems to confirm a wrong information in the dumchar_info:
Normal B1 Offset Android size:
Hex: 26500 Dez: 156928 Multiplied with 4096=642777088 Divided by 1024 = 627.712kB
Faulty B1 Offset Android size:
Hex: 15e00 Dez: 89600 Multiplied with 4096=367001600 Divided by 1024 = 358.400kB
If you take into consideration, that the system.img.gz takes (in packed form!) about 350 MB, unpacked even 627,712kB (size of the parition, see above) - then it appears that the information MUST be wrong - if I am right with my calculation...
Following this we have these values for internal memory on both versions:
Normal B1 Offset FAT size:
Hex: 148638 Dez: 1345080 Multiplied with 4096=5509447680 Divided by 1024 = 5.380.320kB
Faulty B1 Offset FAT size:
Hex: 1b0a38 Dez: 1772088 Multiplied with 4096=7258472448 Divided by 1024 = 7.088.352kB
Anyone with 15e can check available space on internal memory? In fact it should be about 5GB as I remember (have the B1 not with me now).
Maybe I am writing complete bull**** here? Anyone can confirm my calculation..??
Thanks in advance!
alba81 said:
So, I made a small calculation for the offsets, and this seems to confirm a wrong information in the dumchar_info:
Normal B1 Offset Android size:
Hex: 26500 Dez: 156928 Multiplied with 4096=642777088 Divided by 1024 = 627.712kB
Faulty B1 Offset Android size:
Hex: 15e00 Dez: 89600 Multiplied with 4096=367001600 Divided by 1024 = 358.400kB
If you take into consideration, that the system.img.gz takes (in packed form!) about 350 MB, unpacked even 627,712kB (size of the parition, see above) - then it appears that the information MUST be wrong - if I am right with my calculation...
Following this we have these values for internal memory on both versions:
Normal B1 Offset FAT size:
Hex: 148638 Dez: 1345080 Multiplied with 4096=5509447680 Divided by 1024 = 5.380.320kB
Faulty B1 Offset FAT size:
Hex: 1b0a38 Dez: 1772088 Multiplied with 4096=7258472448 Divided by 1024 = 7.088.352kB
Anyone with 15e can check available space on internal memory? In fact it should be about 5GB as I remember (have the B1 not with me now).
Maybe I am writing complete bull**** here? Anyone can confirm my calculation..??
Thanks in advance!
Click to expand...
Click to collapse
Yeah internal space is 5.12 GB like posted here in bullbrands post:
{
"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"
}
Note: this is after swapping internald and external sd...
The calculation looks good, but i don't know why the f... you multiply with 4096 and divide by 1024... I'm working as a developer and now I really feel stupid, because I really just don't know.
entonjackson said:
The calculation looks good, but i don't know why the f... you multiply with 4096 and divide by 1024... I'm working as a developer and now I really feel stupid, because I really just don't know.
Click to expand...
Click to collapse
Dont worry I could explain as follows: 4096 is the qty of bits you write at once on dd, and 1024 - logically to convert bits to KB.
Well, so we see that nothing is right in the dumchar_info, at least on Android and FAT partition, on faulty B1´s. Now we know there is a mistake - and need to validate the right offsets. Anyone has experience with fdisk on Android? Do I have to run it from busybox from terminal emulator?
And can anyone experienced tell us the specifications of dumchar_info? I found out it is a MTK-own chart, which is not existing on other CPU based devices .... which means for me - it can not be that critical in regards to format table, right?
On a rooted device - can we use a log to see when the dumchar_info is triggered?
alba81 said:
Dont worry I could explain as follows: 4096 is the qty of bits you write at once on dd, and 1024 - logically to convert bits to KB.
Well, so we see that nothing is right in the dumchar_info, at least on Android and FAT partition, on faulty B1´s. Now we know there is a mistake - and need to validate the right offsets. Anyone has experience with fdisk on Android? Do I have to run it from busybox from terminal emulator?
And can anyone experienced tell us the specifications of dumchar_info? I found out it is a MTK-own chart, which is not existing on other CPU based devices .... which means for me - it can not be that critical in regards to format table, right?
On a rooted device - can we use a log to see when the dumchar_info is triggered?
Click to expand...
Click to collapse
Ah I see. very easy. so bs=4096 is blocksize and well ok 1024 I already guessed could be convertion from bits to bytes. alright.
Then I would say, yes. the calculation makes sense indeed.
Now we only need someone that tries to write the right parition info into dumchar_info.
volunteers hands up! :victory:
entonjackson said:
Now we only need someone that tries to write the right parition info into dumchar_info.
volunteers hands up! :victory:
Click to expand...
Click to collapse
The biggest problem on that point is - you need to have either root, or do it by obtaining "temporary backdoor root" through ENGMODE. And the qty of user having root on faulty B1 is still pretty low...
alba81 said:
The biggest problem on that point is - you need to have either root, or do it by obtaining "temporary backdoor root" through ENGMODE. And the qty of user having root on faulty B1 is still pretty low...
Click to expand...
Click to collapse
i know busybox has fdisk binary.
adb doesn't know fdisk?
Where can I call it thru ADB?
Starting busybox from internal memory thru Terminal Emulator also makes me problems ... permission denied.
alba81 said:
Where can I call it thru ADB?
Starting busybox from internal memory thru Terminal Emulator also makes me problems ... permission denied.
Click to expand...
Click to collapse
There is none. I thought fdisk comes with adb, but... no.
But maybe we need no fdisk. If i understood it right, wie only must edit the dumchar_info so the system "believes" it has the right partitions again.
Yes, obviosly the update process checks this value. As you already checked the /proc/emmc shows different values, and /proc/mtd is empty. /proc/partitions contain different information type.
Before changing an important value I think we need to validate that any change in dumchar_info remains after reboot, since the update failure notification appears in recovery mode during update - right?
Edit:
I do not get access to dumchar_info. Going through ES File Manager I set the properties, and even it shows after changing its saved - its not. How can I get the rights? And how I can take the rights for system away to not be able to access it any more? Each time I open the properties of it I see a different date ... is it in permanent access?? Or do I need a different file Explorer?
Edit2:
Wikipedia is my friend. Ok, now I know - dumchar_info is a procfs, generated by the kernel during boot and not saved. So I am affraid ... we are stuck on a faulty kernel issue?
Where does the kernel gain this Information from during boot? Anybody an idea?
I hope this helps
agentdeep said:
I hope this helps
Click to expand...
Click to collapse
Thank you - I will validate later on, once I am at home ... have now only my n8000 with me.
Ok, checked - my version is the same, except:
[email protected] (after Linux version 3.4.0)
which I think can not be that important, since all other release data is similar. So it is not the kernel we have to fight with - at least...
Ok, so following on this subject we need to see what comes up in the future:
http://forum.xda-developers.com/showpost.php?p=41168837&postcount=295
At least the reason seems to be confirmed from Acer site - a faulty format which is reported.
IMHO it can not be only the update with the problem, the device itself reports a different format in dumchar_info, not the update.
Well - we´ll stay tuned...
hi there,
i have a faulty B1 with root....also i tried the Factory Reset Workaround several times, it does not work for me....everytime about 10-15% i got the message "partition error...bla".
So if you want me to to test things...go on
I'm new here, however I successfully rooted my device using the "toolkit" even though I have
Code:
Faulty - android 0x0000000015e00000 0x00000000020e8000 2 /dev/block/mmcblk0p3
Thanks to Enton.
My internal storage is reported to be just 5.17GB (not 8GB as expected) confirming the figures in a previous post.
I complained to acer support about the size of the internal storage being nearly 3GB short of what it should be and that I thought it was down to a "memory allocation error".
There response was " As you have mentioned in the previous e-mail internal storage shows as a 5.17GB, I would like to inform you that the other space of the unit is occupied by Android Operating System, customer will not be able to use the complete 8GB from the unit, as Operating system needs a space. "
Is this complete and utter BS? I understand 4.1.2 Jelly Bean is just over 200MB.
Can someone please confirm.
BTW if any dumps are required from my "faulty" device (I do not have the partition error though) I'm happy to try.
BTW2 I've installed the new PMTUpdate patch "FixG1PMT" and that did nothing for my problem.
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!
I haven't had enough to get a One now, but I'm pretty interested in the phone. Yesterday I saw a thread on Chinese forum, saying that LOGO.bin contains the image shown in fastboot mode, and thus everyone can choose his preferred image (like CM's) even if he uses ColorOS. So I tried to extract the bitmap from LOGO.bin and replace it with my own picture.
Now I've succeed PARTIALLY in identifying the BIN file format and extracting the images. There's no enough time to dig into replacing the pictures though, but I think it won't be hard.
Here is what I find, for those "aggressive" themers and ROM devs who want custom boot splash screen:
The BIN file starts with the following structure:
C:
struct SPLASHHEADERINDEX {
char magic_code[8]; // = { 'S', 'P', 'L', 'A', 'S', 'H', '!', '!' };
int img_width;
int img_height;
int reserved; // What's this? I haven't figured that out.
int img_offset[6];
char padding[468]; // The header is 512 bytes. Thanks [user=5757424]@chillstep1998[/user] !
};
Right after this structure, the raw data of boot splash image begins. Every pixel is described by 3 bytes in B-G-R order. The pixels begin at the upper left corner and then stored in the order of left to right & up to down. You can read (img_width * img_height * 3) bytes and write them into a BMP file. NOTE that BMP files require 4-pixel alignment for every horizontal row (Google that for details, otherwise you will get a "Broken image" info in image viewers) In order to avoid this problem, I wrote a simple program in VB.NET and used Bitmap.SetPixel and Bitmap.Save to solve it.
This is the VB code for this procedure. (I can't do GUI programs in C++...)
Code:
Dim bmp As New Bitmap(img_width, img_height)
Dim color As Color
For y = 0 To img_height - 1
For x = 0 To img_width - 1
b = fs.ReadByte 'fs is the FileStream of BIN file. Already sought to correct offset.
g = fs.ReadByte
r = fs.ReadByte
If b = -1 Then b = 0
If g = -1 Then g = 0
If r = -1 Then r = 0
color = color.FromArgb(r, g, b)
bmp.SetPixel(x, y, color)
Next
Next
There are some zeros after (img_width * img_height * 3) bytes. I don't know what's for...
Then let's look at the other images. Their offsets are in the img_offset array of SPLASHHEADERINDEX. They have headers like this:
C:
struct SPLASHHEADERNONINDEX {
char magic_code[8]; // "SPLASH!!" without \0
int img_width;
int img_height;
int reserved; //Still don't know
char padding[492];
};
Right after the structure is the raw data. Process that as mentioned above.
The image at img_offset[0] is the one shown in fastboot mode
[1] is AT current test (original Chinese: AT电流测试. What's AT?)
[2] is RF test
[3] is WLAN test
[4] is charging
[5] is low battery warning
Previews for new images are coming soon...
However: there is one bug: the images extracted are "mis-placed". You need to move 0x0 to 164xHEIGHT (163xHEIGHT maybe) area to the right side of the image to get the correct pic. The images extracted from ColorOS' LOGO.bin are listed as follows:
SPOILER:
[0]
{
"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"
}
[1]
[2]
[3]
[4]
[5]
Boot splash
Does anyone know the cause of this mis-place problem? Although that can be solved easily in the code, but it's not very reliable. Maybe it's related to the "reserved" member?
Since the format is rather simple, modding and repacking will be easy. When I get some free time I'll make a tool for this...
still dangerous. We don't know whether there's logo signiture check, even if we know how to make a logo.bin.
But good job!
dlhxr said:
still dangerous. We don't know whether there's logo signiture check, even if we know how to make a logo.bin.
But good job!
Click to expand...
Click to collapse
Can't come up with any reason why there should be signature check for logo, especially when we can use home-made modem fimwares and kernels without any problem... But it's worth considering since there's "reserved" member. ColorOS gets 0x00 0x00 0x00 0x00 and CM 0x00 0x00 0x00 0x01 in boot splash's "reserved" int. Haven't checked other 6 images though.
We already know how to make our own logo.bin...there's a thread in the "Themes and Apps" section.
treChoy said:
We already know how to make our own logo.bin...there's a thread in the "Themes and Apps" section.
Click to expand...
Click to collapse
Wow I didn't notice it before... This thread is revealing secrets of the magic and pushing it further
But he says the header is 512 bytes, which is different from what I've found. I will take a look. However, since there are pics as small as ~300*30, skipping 512bytes may cause visible loss of the content. Maybe that's for splash screen only.
updateing said:
Wow I didn't notice it before... This thread is revealing secrets of the magic.
But he says the header is 512 bytes, which is different from what I've found. I will take a look. However, since there are pics as small as ~300*30, skipping 512bytes may cause visible loss of the content. Maybe that's for splash screen only.
Click to expand...
Click to collapse
As far as they've discovered on the thread, they've only really uncovered the workings of the splash screen. We know that fastboot is also affected by the LOGO partition, but we don't know how that ties in with the bootloader. The ColorOS LOGO.bin displays, "已進人fastboot..." when in fastboot mode, and the International LOGO.bin displays "Fastboot Mode" with the Cyanogen mascot.
One thing is for certain though: this is DANGEROUS. There's a very good possibility of bricking because of the LOGO partition's relationship with the bootloader. I was talking to another developer here about his work with the LOGO partition, and he said he bricked his phone, but recovered it by holding the power button, and then manually writing the correct LOGO partition using the 'dd' command.
I've contacted OnePlus support about this, so we should hear word back around Easter.
treChoy said:
As far as they've discovered on the thread, they've only really uncovered the workings of the splash screen. We know that fastboot is also affected by the LOGO partition, but we don't know how that ties in with the bootloader. The ColorOS LOGO.bin displays, "已進人fastboot..." when in fastboot mode, and the International LOGO.bin displays "Fastboot Mode" with the Cyanogen mascot.
One thing is for certain though: this is DANGEROUS. There's a very good possibility of bricking because of the LOGO partition's relationship with the bootloader. I was talking to another developer here about his work with the LOGO partition, and he said he bricked his phone, but recovered it by holding the power button, and then manually writing the correct LOGO partition using the 'dd' command.
I've contacted OnePlus support about this, so we should hear word back around Easter.
Click to expand...
Click to collapse
Hope OnePlus support team is open to this kind of mod...
As for the developer you mentioned, could you please ask him if he entered Qualcomm DLOAD mode and used some .hex file to boot the phone into mass-storage mode? I know when this (QHSUSB DLOAD device) shows up, the bootloader has already failed and this is the last recovering method of the phone. Seen it on my Xperia TX...
And the method mentioned in this thread will also work on CM's LOGO.bin, except for the 164xH issue.
updateing said:
Hope OnePlus support team is open to this kind of mod...
As for the developer you mentioned, could you please ask him if he entered Qualcomm DLOAD mode and used some .hex file to boot the phone into mass-storage mode? I know when this (QHSUSB DLOAD device) shows up, the bootloader has already failed and this is the last recovering method of the phone. Seen it on my Xperia TX...
And the method mentioned in this thread will also work on CM's LOGO.bin, except for the 164xH issue.
Click to expand...
Click to collapse
The developer is @demkantor . And I was wrong about how he unbricked his device. He said that after messing around with the LOGO partition, he got the dreaded "QHUSB_BULK" error, but after a few seconds, his OPO rebooted on his own. He had to 'dd' the regular LOGO partition to get his bootloader up and running. Original thread here: http://forum.xda-developers.com/oneplus-one/help/qhsusbbulk-help-t2848238
treChoy said:
The developer is @demkantor . And I was wrong about how he unbricked his device. He said that after messing around with the LOGO partition, he got the dreaded "QHUSB_BULK" error, but after a few seconds, his OPO rebooted on his own. He had to 'dd' the regular LOGO partition to get his bootloader up and running. Original thread here: http://forum.xda-developers.com/oneplus-one/help/qhsusbbulk-help-t2848238
Click to expand...
Click to collapse
I have once seen somewhere that you can find specific .hex file (e.g. MPRG8960.hex for MSM8960) to download into the phone by QPST Service Programming. Then the phone will boot into mass storage mode, where computer will recognize the phone as a removable disk drive. Now the whole internal storage is "mounted" on the computer and you can use dd to restore then.
(Google'd and it says only QHSUSB_DLOAD need the hex file. QHSUSB_BULK should be mounting the internal storage to computer automatically and dd will be available. Not sure about that. Example: http://forum.xda-developers.com/showthread.php?t=2582142&page=1)
yeah the header is 512 bytes. Now the images are all correct :victory:
Flashing a bad LOGO.bin did send me to the QHSUB_DLOAD mode and I tired rebooting holding down all three buttons. It did seem to work but after a bit it seemed to just boot on its own. Then I just used an adb shell to run dd commands to flash the proper .bin and all has been well since then
Still have been to busy with our newborn to look into anything deeper but between this thread and the one by @chillstep1998 and treChoy and other it looks to be all good!
Glad all is coming together on this end, keep up the great work all
dear thread creater.. i tell u what is that zeros after anything.
actualy android reads anything in block size.. like this
4,4,4,4,4.....
or 8,8,8,8,8.....
or 16,16,16,16...
or....
or...
or...
or 512,512,512,512...
or......
so.. if block size is 512 then it would read 512 bytes first..
now think what if there is only 50 or 51 bytes.. if will be a error.. if it has code to handle errors.. it is slow.
this is called alignment.. we say header is aligned to 512 bytes.
to make alignment it would add padding of NULLs(chr(0) in vb)
same nulls for the end of file to make it aligned to some size.
thank you.
m9j_cfALt said:
dear thread creater.. i tell u what is that zeros after anything.
actualy android reads anything in block size.. like this
4,4,4,4,4.....
or 8,8,8,8,8.....
or 16,16,16,16...
or....
or...
or...
or 512,512,512,512...
or......
so.. if block size is 512 then it would read 512 bytes first..
now think what if there is only 50 or 51 bytes.. if will be a error.. if it has code to handle errors.. it is slow.
this is called alignment.. we say header is aligned to 512 bytes.
to make alignment it would add padding of NULLs(chr(0) in vb)
same nulls for the end of file to make it aligned to some size.
thank you.
Click to expand...
Click to collapse
Thanks! I know there are some alignment rules, but didn't expect them to be here. I've seen aligning the whole file to 4 bytes or so, but little do I know that a section header needs alignment as well. I guess that's because this LOGO.bin is used in such a low-level "environment" that we don't have enough time & space to handle the non-aligned data. Am I right?
updateing said:
Thanks! I know there are some alignment rules, but didn't expect them to be here. I've seen aligning the whole file to 4 bytes or so, but little do I know that a section header needs alignment as well. I guess that's because this LOGO.bin is used in such a low-level "environment" that we don't have enough time & space to handle the non-aligned data. Am I right?
Click to expand...
Click to collapse
Hi man!
Do you know how change the battery animation when the phone is charging(when is off)?
I've tried to change the imgs in /res/images/charger, but you know, it doesn't work eheheh...
Can you help me?
Reive said:
Hi man!
Do you know how change the battery animation when the phone is charging(when is off)?
I've tried to change the imgs in /res/images/charger, but you know, it doesn't work eheheh...
Can you help me?
Click to expand...
Click to collapse
I don't have a OPO to test, all these analysis are theoretical. So I may not be able to help. Sorry...
I have a HP Pavillion 15 laptop core i7 intel HD witn nvidia 840m onboard graphics.
I have tried installing remix os a hundred times now. no kidding
messing up bcd entries along the way but anyhoo,
here is what I do,
Disable Secure boot
Create a new NTFS 32GB partition.
Install Remix OS on it. with 16gb data partition.
Reboot , select Remix OS from os selection screen.
Now androidx86 logo comes up , formats the partition, I get a warning "Warning had difficulty in writing superblocks" something like that, then it takes me to remix os boot screen and thats it!
it has been hours now but it won't move beyond that point.
The Remix os logo simply keeps flashing infinitely. At this stage even the hard drive activity led on the laptop goes off....
I even tried setting noveau.modeset=0 i915.modeset=1 but nothing helps.
The Remix OS screen just keeps flashing.
I cannot find any solution to this,
Has anyone ever encountered this or know how to fix it?
tried androidboot.swrast=1
still nothing.
Running with DEBUG=1 gives some mount errors.
any help guys ?
any Jide staff members here?
vikas_toad said:
tried androidboot.swrast=1
still nothing.
Running with DEBUG=1 gives some mount errors.
any help guys ?
any Jide staff members here?
Click to expand...
Click to collapse
Try 'REMOUNT_RW=1'
Example:
Code:
default 0
timeout 10
title Resident mode - All your data and apps are saved
find --set-root /RemixOS/kernel
kernel /RemixOS/kernel root=/dev/ram0 androidboot.hardware=remix_x86 androidboot.selinux=permissive quiet SERIAL=random logo.showlogo=1 SRC=RemixOS/[B][COLOR="Red"] REMOUNT_RW=1 [/COLOR][/B]DATA= CREATE_DATA_IMG=1
initrd /RemixOS/initrd.img
boot
It will convert the system.sfs file to system_dev.img and allow read/write!
Maybe that is the issue?
Good luck!
moman2000 said:
Try 'REMOUNT_RW=1'
Example:
Code:
default 0
timeout 10
title Resident mode - All your data and apps are saved
find --set-root /RemixOS/kernel
kernel /RemixOS/kernel root=/dev/ram0 androidboot.hardware=remix_x86 androidboot.selinux=permissive quiet SERIAL=random logo.showlogo=1 SRC=RemixOS/[B][COLOR="Red"] REMOUNT_RW=1 [/COLOR][/B]DATA= CREATE_DATA_IMG=1
initrd /RemixOS/initrd.img
boot
It will convert the system.sfs file to system_dev.img and allow read/write!
Maybe that is the issue?
Good luck!
Click to expand...
Click to collapse
nope still the same.
anything that I can do to atealst understand whats going wrong ?
anyone?
vikas_toad said:
nope still the same.
anything that I can do to atealst understand whats going wrong ?
anyone?
Click to expand...
Click to collapse
Try using a different hard drive, the one you're using may be damaged in some way !
vikas_toad said:
tried androidboot.swrast=1
still nothing.
Running with DEBUG=1 gives some mount errors.
any help guys ?
any Jide staff members here?
Click to expand...
Click to collapse
Any chance those 'mount errors' are that /data is read-only?
If so from DEBUG=1 try:
Code:
cd /mnt/RemixOS
e2fsck -f data.img
reboot
moman2000 said:
Try using a different hard drive, the one you're using may be damaged in some way !
Click to expand...
Click to collapse
Using a laptop. Using a different harddrive isn't really an option
HypoTurtle said:
Any chance those 'mount errors' are that /data is read-only?
If so from DEBUG=1 try:
Code:
cd /mnt/RemixOS
e2fsck -f data.img
reboot
Click to expand...
Click to collapse
not sure what they are. any way I can capture logs so that I can post them here ??
I think that will better ..
Hi, i have the same problem, installed latest version, had to set nouveau.modeset=1 i915.modeset=0 because i have a Geforce 710m graphics card. I have an i3 laptop.
After i set these in menu.lst it boots till the Remix Os logo, but doesn't go past.
I have no idea what to try, i have windows 10
vikas_toad said:
Using a laptop. Using a different harddrive isn't really an option
not sure what they are. any way I can capture logs so that I can post them here ??
I think that will better ..
Click to expand...
Click to collapse
You can easily replace a hard drive in a laptop... I have done it hundreds of times, there should be a panel with a few screws on it!
Not so sure on capturing logs, maybe you can use "DEBUG=1"
@vikas_toad ""Warning had difficulty in writing superblocks" - your HDD is not up for the job. You need to try and fix the bad blocks or if it fails you need to replace the drive. @HypoTurtle gave you the best solution.
1. Boot Remix
2. In Grub selection select Remix and press "e" to edit the menuentry
3. If you are on legacy boot then use arrows to go to the kernel line and press "e" / if you are in UEFI boot (Grub2) then just move to the kernel line with arrows
4. Now add "DEBUG=1" without the quotation marks anywhere withing that kernel line, but after the kernel word.
5. On legacy press enter and then F10 / ON UEFI only press F10
6. Now follow @HypoTurtle tips:
HypoTurtle said:
Code:
cd /mnt/RemixOS
e2fsck -f data.img
reboot
Click to expand...
Click to collapse
7. Now try to boot Remix. If it fails I advise you to run disk checking and fixing for your whole drive.
If you are still unsure how to enter the DEBUG mode, you can go to this guide: http://support.jide.com/hc/en-us/articles/218463867-How-to-increase-the-memory-size-
If this helped remember to hit thanks for @HypoTurtle and me
This is what i got after i used DEBUG:
VFS: could not find a valid V7 on sda.
VFS: could not find a valid V7 on sda1.
VFS: could not find a valid V7 on sda2.
EXT4-fs (loop1): couldn't mount az ext3 due to feature incompatibilities.
What should I try?
Edit: i was able to boot fine with nomodeset vga="xxx"
But this is not ideal, no hardware acceleration and not good resolution.
@Szighy I don't know if your nvidia GPU is well supported, but I'm pretty sure that the Intel will work better, so instead of disabling Intel, disable nvidia. Use nouveau.modeset=0 and try to boot.
If that won't allow for complete boot then most likely you must disable nvidia GPU completely. Some devices allow that via BIOS settings - find graphics options and make sure the integrated GPU and only it is enabled.
If you don't have that option in BIOS then I'm sorry, but you will have to wait for new releases with fixes and better drivers or use software renderer (androidboot.swrast=1) or the nomodeset with properly picked resolution.
Remember that nvidia drivers are unofficial, they are actually reverse engineered and then adjusted to work on Linux. As far as I know Nvidia doesn't officially create Android drivers "we are on our own".
That's why nouveau will probably never be good enough.
Sent from mobile
Thanks for your detailed reply, already tried the first too methods, nouveau.modeset=0 fails, i am able to boot fine with vga=791 and and 794, everything else fails, if i set the exact resolution (using vga=ask, then selecting from the list, that fails too). So no way to adjust the resolution.
"androidboot.swrast=1" - i didnt hear about this one, do i add this like the flags? I have to do some research about it
EDIT: no option to selected integrated graphics in bios
EDIT 2: WOW, i was able to boot fine with androidboot.swrast=1.
You made my day, resolution is perfect now, i cant be thankful enough, i was trying the whole night.
@Szighy that's great Remember to report your problems here https://docs.google.com/forms/d/1cZNesOmnmO2esilFpvMzFZ874rvwsiKgWIX2fo9QsDk/viewform
androidboot.swrast=1 means Remix OS graphics are rendered by the CPU - games and 3D rendering will most likely be much slower and the whole system may be less stable, because in some cases the software renderer crashes.
I'd say swrast is a temporary solution. I hope your device gets better GPU support.
Sent from mobile
Vioner said:
@Szighy that's great Remember to report your problems here https://docs.google.com/forms/d/1cZNesOmnmO2esilFpvMzFZ874rvwsiKgWIX2fo9QsDk/viewform
androidboot.swrast=1 means Remix OS graphics are rendered by the CPU - games and 3D rendering will most likely be much slower and the whole system may be less stable, because in some cases the software renderer crashes.
I'd say swrast is a temporary solution. I hope your device gets better GPU support.
Sent from mobile
Click to expand...
Click to collapse
yep, definitely not ready to daily usage this way, i'll wait some time and hope it will get better support, but at least I could try it
HypoTurtle said:
Any chance those 'mount errors' are that /data is read-only?
If so from DEBUG=1 try:
Code:
cd /mnt/RemixOS
e2fsck -f data.img
reboot
Click to expand...
Click to collapse
Vioner said:
@vikas_toad ""Warning had difficulty in writing superblocks" - your HDD is not up for the job. You need to try and fix the bad blocks or if it fails you need to replace the drive. @HypoTurtle gave you the best solution.
1. Boot Remix
2. In Grub selection select Remix and press "e" to edit the menuentry
3. If you are on legacy boot then use arrows to go to the kernel line and press "e" / if you are in UEFI boot (Grub2) then just move to the kernel line with arrows
4. Now add "DEBUG=1" without the quotation marks anywhere withing that kernel line, but after the kernel word.
5. On legacy press enter and then F10 / ON UEFI only press F10
6. Now follow @HypoTurtle tips:
7. Now try to boot Remix. If it fails I advise you to run disk checking and fixing for your whole drive.
If you are still unsure how to enter the DEBUG mode, you can go to this guide: http://support.jide.com/hc/en-us/articles/218463867-How-to-increase-the-memory-size-
If this helped remember to hit thanks for @HypoTurtle and me
Click to expand...
Click to collapse
I tried that but it failed
Superblock invalid, trying bakup superblock
bad magic number in super block while trying to open data.img
The superblock cannot be read or does not describe a correct ext2 filesystem.
...............
you might try running e2fsck with an alternate superblock
e2fsck -b 8193 <device>
formatted the drive now.
I am running chkdsk with /x /f /r on the drive where Reix was isntalled
Let's see
C:\WINDOWS\system32>chkdsk G: /f /x /r
The type of the file system is NTFS.
Stage 1: Examining basic file system structure ...
256 file records processed.
File verification completed.
0 large file records processed.
0 bad file records processed.
Stage 2: Examining file name linkage ...
276 index entries processed.
Index verification completed.
0 unindexed files scanned.
0 unindexed files recovered to lost and found.
Stage 3: Examining security descriptors ...
Security descriptor verification completed.
11 data files processed.
CHKDSK is verifying Usn Journal...
1632 USN bytes processed.
Usn Journal verification completed.
Stage 4: Looking for bad clusters in user file data ...
240 files processed.
File data verification completed.
Stage 5: Looking for bad, free clusters ...
8393768 free clusters processed.
Free space verification is complete.
Windows has scanned the file system and found no problems.
No further action is required.
33653759 KB total disk space.
30804 KB in 7 files.
8 KB in 12 indexes.
0 KB in bad sectors.
47871 KB in use by the system.
45664 KB occupied by the log file.
33575076 KB available on disk.
4096 bytes in each allocation unit.
8413439 total allocation units on disk.
8393769 allocation units available on disk.
no problems found :/
reinstalling and trying again now
chkdsk shows no problems
Still no progress... I get the same error.. about writing to superblocks.
What else can I do ?
how do I capture logs so that I can post them here.
@vikas_toad please make a screenshot of SMART status of your hard drive.
Use AIDA64 for it - portable .exe here: http://download.aida64.com/aida64extreme575.zip
In Aida go to Storage -> SMART -> Select your drive -> Make screenshot
Should look like this:
{
"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"
}
Sent from mobile
vikas_toad said:
I had a similar problem lately. Trying to format a hard drive to ext4. I kept getting the warning message about the super blocks. The answer was pretty simple.
Give this a try, reformat the partition as NTFS and and use the long formatting process where it writes zeros all the way across the partition.
It works for me.
Click to expand...
Click to collapse
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.
------
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