Related
I Highly suggest you follow the steps in this post first (http://forum.xda-developers.com/showthread.php?t=920347)
Froyo is completely stable and will give you a back up OS in case anything happens or you want to do something that doesn't work in HC.
Steps:
If anyone knows how to shrink a partition using parted please let me know. This would eliminate steps 2 & 3
QUICK EDIT WARNING: PLEASE READ: THIS IS BASED ON THE DUAL BOOT FROM ROOKIE1. FROM WHAT I KNOW THIS DOES NOT WORK ON 1.1.0 ONLY 1.0.1
(Note: Requires adb)
1 ) Have a working honeycomb v02 sd card (v03 has a custom kernel which causes rotation issues on the eMMC).
2) Install EASEUS (Windows) or gParted (Linux)
(if you need help with this just PM me)
3) Shrink the second partition of the SD card to 400mb
4) Download and extract my zip to your android/platform-tools folder
5) Run Internal.bat
Make sure not to format your sdcard from your nook while using this.
< standard disclaimer - I'm not responsible for whatever damage you did to your NC >
Also, the reason I did not post a clockwork zip or a dd img for system is I'm unsure of the legality of it, if someone else would like to then by all means do so.
PM me for any questions, and I would like to say thanks to samuelhalff, as without his help I never would've gotten it running from internal memory
Also, please make sure you know how to recover your nook color back to stock. Not only if something goes wrong, but since honeycomb isn't fully working yet.
That being said, if you run the dual-boot script first from rookie1 you'll always be able to fall back onto froyo to fix any issues.
----------------------------------------------------------------------------
How this works:
It copies the system partition from honeycomb onto the internal memory.
It then pushes my boot.img to your sd card.
Finally it overwrites your boot.img with mine
(My boot.img contains everything from rookie1's dual boot alongside the needed jar files included on honeycombs boot.img)
Download link:
http://www.multiupload.com/0TTH2OJS3C
Uploading fixed version now
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
And for those who like doing everything manually. Here is Sam's modified uRamdisk. Make sure its on the bootpartiton alongside the jar files included in deeper-blue's release
Ramdisk: http://www.multiupload.com/90H38OX0S9
Also, the first time it starts up may take a few min. So be patient before trying to restart it
Thanks this will be very useful for myself and others. I'll report back with any issues.
Why must my laptop break today of all days?
Sent from my SPH-D700 using XDA App
marcusant said:
Why must my laptop break today of all days?
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Sorry to hear that. I would say you could do it without one but you need the modified ramdisk inside my boot.img
Hey maybe i'm doing something wrong but i keep getting this error message:
rm failed for *, no such file or directory
i am not an expert on adb so this may be my fault, just reporting feedback for you.
tgallant21 said:
Hey maybe i'm doing something wrong but i keep getting this error message:
rm failed for *, no such file or directory
i am not an expert on adb so this may be my fault, just reporting feedback for you.
Click to expand...
Click to collapse
its not rm * its "rm * -r" as that is the recursive switch...
MattJ951 said:
I Highly suggest you follow the steps in this post first (http://forum.xda-developers.com/showthread.php?t=920347)
Froyo is completely stable and will give you a back up OS in case anything happens or you want to do something that doesn't work in HC.
Steps:
QUICK EDIT WARNING: PLEASE READ: THIS IS BASED ON THE DUAL BOOT FROM ROOKIE1. FROM WHAT I KNOW THIS DOES NOT WORK ON 1.1.0 ONLY 1.0.1
(Note: Requires adb)
1 ) Have a working honeycomb v02 sd card (v03 has a custom kernel which causes rotation issues on the eMMC).
2) Download and extract my zip to your android/platform-tools folder
3) Run Internal.bat
Make sure not to format your sdcard while using this.
Note: I'm not sure if you need to clear your data partition or not. I did, but it may not be required.
the steps under froyo would be : something similar to this (I dd'd HC data partition to the internal, so i'm not 100% sure of this)
Code:
adb shell
mount -o remount,rw /dev/block/mmcblk1 /
mkdir data_temp
mount /dev/block/mmcblk0p6 data_temp
cd /data_temp [B]MAKE SURE THIS COMMAND WORKS BEFORE CONTINUING[/B]
rm * -rf
exit
< standard disclaimer - I'm not responsible for whatever damage you did to your NC >
Also, the reason I did not post a clockwork zip or a dd img for system is I'm unsure of the legality of it, if someone else would like to then by all means do so.
PM me for any questions, and I would like to say thanks to samuelhalff, as without his help I never would've gotten it running from internal memory
Also, please make sure you know how to recover your nook color back to stock. Not only if something goes wrong, but since honeycomb isn't fully working yet.
That being said, if you run the dual-boot script first from rookie1 you'll always be able to fall back onto froyo to fix any issues.
----------------------------------------------------------------------------
How this works:
It copies the system partition from honeycomb onto the internal memory.
It then pushes my boot.img to your sd card.
Finally it overwrites your boot.img with mine
(My boot.img contains everything from rookie1's dual boot alongside the needed jar files included on honeycombs boot.img)
Click to expand...
Click to collapse
You have verified this working with your boot.img? Mine gets hampered during the boot and locks up... I had the same issue when I was building my ramdisk for this purpose.... I am going to continue to look into this and will post anything I find.
Cheers!
A quick question:
You say not to format the SDCard while using this. Does this mean that there are still some system files on the SDCard after the procedure is done or can I format my card as FAT32 once the whole operation is done?
Ooglez said:
A quick question:
You say not to format the SDCard while using this. Does this mean that there are still some system files on the SDCard after the procedure is done or can I format my card as FAT32 once the whole operation is done?
Click to expand...
Click to collapse
I believe I may have included an incorrect boot.img in my original upload, im reuploading it now.
As for formatting the sd card, i'll clairfy that in the OP. Don't format the sd card from inside the nook. formatting it inside a computer is fine.
MattJ951 said:
How this works:
It copies the system partition from honeycomb onto the internal memory.
It then pushes my boot.img to your sd card.
Finally it overwrites your boot.img with mine
(My boot.img contains everything from rookie1's dual boot <B>alongside the needed jar files included on honeycombs boot.img)</B>
Click to expand...
Click to collapse
I think I see the issue, your dd image is lacking those jar files... I am going to try and add those files to my boot partition and go from there.... Disregard! per the post above this one.......
modembug said:
I think I see the issue, your dd image is lacking those jar files... I am going to try and add those files to my boot partition and go from there.... Disregard! per the post above this one.......
Click to expand...
Click to collapse
The boot.img must be from another project I was working on. It's using the wrong u-boot.bin and is missing the jar files. Updating main post in 20 seconds once it finishes uploading
And its up.
http://www.multiupload.com/KPDAPGYXSI
Also thanks for the feedback.
MattJ951 said:
The boot.img must be from another project I was working on. It's using the wrong u-boot.bin and is missing the jar files. Updating main post in 20 seconds once it finishes uploading
And its up.
http://www.multiupload.com/KPDAPGYXSI
Click to expand...
Click to collapse
Thanks for updating so quickly. I've been waiting to run Honeycomb off of EMMC. I'll let you know how it goes.
MattJ951 said:
The boot.img must be from another project I was working on. It's using the wrong u-boot.bin and is missing the jar files. Updating main post in 20 seconds once it finishes uploading
And its up.
http://www.multiupload.com/KPDAPGYXSI
Also thanks for the feedback.
Click to expand...
Click to collapse
I am getting ready to dd that image over as we speak, i will report back shortly...
No problem, let me know if it works and if it doesn't ill try updating it again. (I personally have it working but I didn't use a script, i entered the commands manually. Also make sure youre using v02 [though note: HC runs faster for some reason if you copy the data partition from v03 and dd it to the internal while running v02's system. v03 has problems with the kernel due to the 90degrees thing deeper added]
MattJ951 said:
No problem, let me know if it works and if it doesn't ill try updating it again. (I personally have it working but I didn't use a script, i entered the commands manually. Also make sure youre using v02 [though note: HC runs faster for some reason if you copy the data partition from v03 and dd it to the internal while running v02's system. v03 has problems with the kernel due to the 90degrees thing deeper added]
Click to expand...
Click to collapse
I am having issues with it locking up on "Android _ " could be due to crap on the data partition from the last boot.img... cleaning it off and trying again. Yeah I took a look at your bat file and just ran things manually... i have issues with unknown bat/sh files lol
UPDATE: okay, so its still locking up... did you dd the data partition or any of that stuff over as well? as of right now, i am running your boot.img and i DD'd the system partition from a working HC-SD, and i removed all files from the internal /data partition....
modembug said:
I am having issues with it locking up on "Android _ " could be due to crap on the data partition from the last boot.img... cleaning it off and trying again. Yeah I took a look at your bat file and just ran things manually... i have issues with unknown bat/sh files lol
Click to expand...
Click to collapse
Let me know if it works. The "Android _" screen originally locked up for me because of the uRamdisk. I'll upload the one Sam sent me which is included in the boot.img but maybe is causing problems for you.
The modified uRamdisk is now in the OP.
Nada, still no dice.... I have all the folders from HC /Boot with your boot files replacing uboot, uramdisk etc.. Still running into the same issue, might need to work busybox into this thing to see what is going on...
UPDATE: going to try dd'ing the /data part over to emmc /data..
modembug said:
Nada, still no dice.... I have all the folders from HC /Boot with your boot files replacing uboot, uramdisk etc.. Still running into the same issue, might need to work busybox into this thing to see what is going on...
UPDATE: going to try dd'ing the /data part over to emmc /data..
Click to expand...
Click to collapse
Thats not the problem. I realized my mistake.
where i wrote
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p1
it should be
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p2
if you run that it should boot correctly.
uploading a fixed version to the OP now
MattJ951 said:
Thats not the problem. I realized my mistake.
where i wrote
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p1
it should be
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p2
if you run that it should boot correctly.
uploading a fixed version to the OP now
Click to expand...
Click to collapse
which is why i run commands manually ;-) yeah I double check prior to DD and i have pushed the correct partition to /system... i have now pushed /data over and still no love... Can you dd your /boot and post it?
modembug said:
which is why i run commands manually ;-) yeah I double check prior to DD and i have pushed the correct partition to /system... i have now pushed /data over and still no love... Can you dd your /boot and post it?
Click to expand...
Click to collapse
That actually is my current /boot inside the 7z. Also i can't think of a reason why it wouldn't work.
I'll format my NookColor and try it to see if I can figure out whats going wrong.
I had downloaded a version of this file from a post embedded deep inside one of the threads over here (sorry can't find it right now), but upon examination of its contents, I discovered some issues:
1. The checksums on the files in contained in the the original zip file showed that B&N had at least two versions of 1.3.0 update you can download from them, and the zip I got contained an older version so I put in the latest files in there.
2. There were unnecessary files included inside the original zip file, I deleted those, and only included what was needed.
3. There were errors in the script syntax, which I corrected, so that the proper commands are run during the update, and the proper sed substitutions are made during the editing of the unpacked init.rc inside the ramdisk.
What this zip will do is replace any older version of a B&N ROM on the alternate eMMC partitions of a dual booting configurations to the latest versions. This will prevent B&N from pushing the 1.3.0 update to you OTA, and messing up your dual boot setup. Just put the zip on your sdcard, boot into CWM recovery, and apply the zip. I apologize in advance for not giving credit to the original creators of the scripts here.
Note: There have been two different protocols for a dual booting u-boot.bin, with an older one relying on the files u-boot.altimg, and u-boot.altram to specify the names of the secondary boot ramdisk and kernel, and a newer one assuming that they are named uAltRam, and uAltImg respectively. This update conforms to the new u-boot.bin protocol. If you are still using the old one, you will have to get root access to /boot and edit the two files to point to uAltRam and uAltImg.
So if you want try it out, here it is:
http://www.mediafire.com/?gcrpzzc0kdoxcjx
MD5 Sum: 51e24c1e5eff11ba5ea481a63f7404eb
Update
I have now uploaded files for B&N Update 1.4.1.
The first file (MD5 Sum: 4ff1d9764663278c3f51e2e2c9d841a6) is meant to update a pre 1.4.1 Stock B&N ROM on secondary /system through CWM:
https://rapidshare.com/files/52135913/secondary_update_NC_stock_1_4_1.zip
The second file (MD5 Sum: c1506816fbfb8c419fbbc4afe1b12887) is meant to update a pre 1.4.1 Stock B&N ROM on primary /system through CWM without messing with recovery;
https://rapidshare.com/files/869435270/primary_update_NC_stock_1_4_1_keep_CWM.zip
The third file (MD5 Sum: ab1307c55a2c35c91d339c8037ce9a78) is meant to update a pre 1.4.1 Stock B&N ROM on primary /system through CWM, replacing recovery and all:
https://rapidshare.com/files/2059644016/primary_update_NC_stock_1_4_1.zip
None of these files will wipe user apps and data, so if you wish to do that, boot into recovery and wipe from there. [This will work on primary /data partition only]
Please note: If the B&N Stock ROM is rooted, you will lose root upon updating.
Thanks!
This worked beautifully! I flashed it from my sdcard after booting into CWM on my primary partition on emmc.
I'm betting you got the original from jasoraso in this dual boot thread: http://forum.xda-developers.com/showpost.php?p=17122342&postcount=142
What I would love is a straight CWM-flashable 1.3 ROM, to include in my up-to-date (for now) guide for setting up the dual boot, rather than having to set up and move 1.2, then update to 1.3.
That is possible to do by combining three of the steps. You need commands from the scripts from the prepare dual boot zip to resize /media and create the secondary system and data partitions, then the part of the script from the file that copies the contents of /data from primary to secondary and replaces u-boot.bin , and then my file which formats secondary /system and puts 1.3.0 there, and copies the latest kernel and patched ramdisk onto /boot. I can put such a file together, but I wouldn't be able to test it. The Nook belongs to my wife, and and you get the rest of the drift.
PS - You can use my file as is after running prepare dual boot and copy stock to secondary. It is not necessary to update secondary to 1.2 before going to 1.3.
Sent from my SAMSUNG-SGH-I897 using XDA App
rajendra82 said:
That is possible to do by combining three of the steps. You need commands from the scripts from the prepare dual boot zip to resize /media and create the secondary system and data partitions, then the part of the script from the file that copies the contents of /data from primary to secondary and replaces u-boot.bin , and then my file which formats secondary /system and puts 1.3.0 there, and copies the latest kernel and patched ramdisk onto /boot. I can put such a file together, but I wouldn't be able to test it. The Nook belongs to my wife, and and you get the rest of the drift.
Click to expand...
Click to collapse
Wait...what? What I'm talking about is a 1.3 zip made to work with CWM and in no way doctored to account for dual booting, just like the 1.2 zip one would otherwise use.
rajendra82 said:
PS - You can use my file as is after running prepare dual boot and copy stock to secondary. It is not necessary to update secondary to 1.2 before going to 1.3.
Click to expand...
Click to collapse
Have you tested this theory? I found that when I did not register my B&N install while it was on the primary partition, I was unable to boot into it on the secondary partition.
Taosaur said:
Wait...what? What I'm talking about is a 1.3 zip made to work with CWM and in no way doctored to account for dual booting, just like the 1.2 zip one would otherwise use.
Click to expand...
Click to collapse
Are you talking about updating an already rooted 1.0/1.1/1.2 Nook Color. I am sure the scripting to do that is exactly the same as what is in the 1.2 zip file. Just replace the 1.2 files inside the zip with the equivalent files from the 1.3 update. Make sure the portions which install su and busybox are included, and build.prop spoofig is applied. I am not sure it is worth it building such a zip file though. One is better off just applying the B&N update, and then rerooting with manual nooter. What I created was for people that have already doctored the setup for dual booting. In such a case, the B&N update would either fail, or would replace the primary partition instead.
Taosaur said:
Have you tested this theory? I found that when I did not register my B&N install while it was on the primary partition, I was unable to boot into it on the secondary partition.
Click to expand...
Click to collapse
No way to get around having to register the primary partition image first. Once that is done it could be moved to secondary and then updated straight to 1.3 instead of going 1.2 first.
I have a dual boot eMMC NC. I am not sure which setup I use but the last time I updated the CM7 nightly, I lost the dual boot until I installed the u-Boot again. I suspect I have the setup that looks for altFImg. So this is not going to work for me. I have 1.2 rooted which I use only occasionally. I am not even sure what is in 1.3 but I am curious.
yelloguy said:
I have a dual boot eMMC NC. I am not sure which setup I use but the last time I updated the CM7 nightly, I lost the dual boot until I installed the u-Boot again. I suspect I have the setup that looks for altFImg. So this is not going to work for me. I have 1.2 rooted which I use only occasionally. I am not even sure what is in 1.3 but I am curious.
Click to expand...
Click to collapse
All you need to do is boot into CM7, mount /boot as root, and then rename uFImg to uAltImg, uFRam to uAltRam, and then change the text inside u-boot.altimg and u-boot.altram to point to the new names instead of the old ones. This will keep you dual booting under the old u-boot.bin, and even after a new protocol u-boot.bin (like that installed by CM7) gets pushed to your Nook Color. Once you have done that, you can update the secondary to 1.3 using my zip file if you want.
rajendra82 said:
Are you talking about updating an already rooted 1.0/1.1/1.2 Nook Color. I am sure the scripting to do that is exactly the same as what is in the 1.2 zip file. Just replace the 1.2 files inside the zip with the equivalent files from the 1.3 update. Make sure the portions which install su and busybox are included, and build.prop spoofig is applied. I am not sure it is worth it building such a zip file though. One is better off just applying the B&N update, and then rerooting with manual nooter. What I created was for people that have already doctored the setup for dual booting. In such a case, the B&N update would either fail, or would replace the primary partition instead.
Click to expand...
Click to collapse
I wouldn't know what to change and what to leave alone, myself, but I think you're making this more complicated than it needs to be. I'm talking about installing 1.3 using CWM, regardless of how the device is partitioned or what was on the primary partition previously. Like the files in this thread, but 1.3: http://forum.xda-developers.com/showthread.php?t=1050520.
I understand that you were just cleaning up jaso's update-dualboot-to-1.3 file. I used the original and it worked fine, but it would have saved me a couple steps (and would be more useful in a guide for setting up dualboot) to simply install 1.3 rather than 1.2 to the primary partition when setting up. The reason I started with 1.2 is because it is the most current stock ROM available for CWM. What I would like is to avoid a historical re-enactment of stock OS development altogether. A general-purpose, CWM-flashable 1.3 ROM would be broadly useful, but is so far lacking as far as I've seen.
1. Do you envision this to be an uprooted stock 1.3 update ROM (either as primary or the only boot option) ? I just don't see the need for this to be CWM flashable. It is very easy to get there by resetting the device to stock, and then updating the device to 1.3.0 using the B&N file, and restoring dual boot as need be. If one has any older stock ROM running on primary, the B&N update will get them to 1.3 while losing root. There is no need to apply 1.2 update first.
2. Do you envision this to be for already rooted single or primary booting 1.1/1.2 users? There is once again no need to create any file for this. One can simply apply the B&N update, and then rerun manual nooter, and restore dual booting to the secondary.
3. The only users with no clear upgrade path are those who have already moved the B&N ROM to secondary. That's why I fixed up the zip file, and shared it. I am glad the original file worked for you despite the script errors. I can see other setups where it would have failed though.
I am not trying to make this more complicated than it needs to be. The Nook Color is just capable of being set up in so many ways, there isn't simply going to be a single update method that will work in all scenarios.
Sent from my SAMSUNG-SGH-I897 using XDA App
I'm envisioning it as a one step, starting-point-agnostic means of establishing a 1.3 stock install, whether for setting up a dualboot or for any other purpose. Its usefulness is made evident by the three-page thread devoted to CWM-flashable 1.2 images: http://forum.xda-developers.com/showthread.php?t=1050520
Taosaur said:
I'm envisioning it as a one step, starting-point-agnostic means of establishing a 1.3 stock install, whether for setting up a dualboot or for any other purpose. Its usefulness is made evident by the three-page thread devoted to CWM-flashable 1.2 images: http://forum.xda-developers.com/showthread.php?t=1050520
Click to expand...
Click to collapse
Then the best bet is two step process:
1. Wipe device and restore to factory stock.
2. Download B&N 1.3 update file from website and place it on the root of SD card. Let the device recognize it, and apply it.
Once the 1.3 update gets applied, you are free to reroot, install CWM, set up dual booting, or whatever the next step may be.
It is the only method that will work in all circumstance as it involves starting from scratch regardless of setup. If want to preserve any of your current setup, no one step file will work for all circumstances. Some people have the stock firmware rooted, others do not. Some have the stock as the only internal boot, others have it as primary option of a dual booting configuration, while others have it as a secondary option. Some have stock recovery and run CWM off the sdcard when needed and want to update their recovery to the latest stock version, others want to keep the CWM recovery, and not update the recovery. There simply is no way file to cope with all these options.
rajendra82 said:
All you need to do is boot into CM7, mount /boot as root, and then rename uFImg to uAltImg, uFRam to uAltRam, and then change the text inside u-boot.altimg and u-boot.altram to point to the new names instead of the old ones. This will keep you dual booting under the old u-boot.bin, and even after a new protocol u-boot.bin (like that installed by CM7) gets pushed to your Nook Color. Once you have done that, you can update the secondary to 1.3 using my zip file if you want.
Click to expand...
Click to collapse
You lost me at mount
Seriously, I am trying to see if what I have is compatible with your update before I apply the update. I have a couple of useful apps on my CM7 and I have lost the password. I don't want to be stuck without CM7 or start over again. I can live without the 1.3 update though. So I want to make sure I am up to the task of finding and renaming these files if I have to.
With that said, how do I mount the /boot partition? I go into terminal emulator and give the su command. Then I tried mount /boot but that didn't work.
Thanks for your help.
rajendra82 said:
1. Wipe device and restore to factory stock.
Click to expand...
Click to collapse
...the only means of doing so "that will work in all circumstance" and in any way resembles a single step is flashing a stock zip via CWM. Why not use an up-to-date zip? The usefulness of such files is demonstrated by the fact that:
such files exist for past stock versions
those files are in use
files like yours are used to work around the non-existence of up-to-date stock zips
If you're so comfortable working with update files, you very likely could have produced such a file in less time than you've spent rationalizing away the clearly demonstrated need for them. Tell you what, in all likelihood I can just swap a few files from B&N's 1.3 zip into the existing CWM-flashable 1.2 zips, correct? Which files do I replace?
Anyone?
---------- Post added at 02:15 PM ---------- Previous post was at 01:58 PM ----------
yelloguy said:
You lost me at mount
Seriously, I am trying to see if what I have is compatible with your update before I apply the update. I have a couple of useful apps on my CM7 and I have lost the password. I don't want to be stuck without CM7 or start over again. I can live without the 1.3 update though. So I want to make sure I am up to the task of finding and renaming these files if I have to.
With that said, how do I mount the /boot partition? I go into terminal emulator and give the su command. Then I tried mount /boot but that didn't work.
Thanks for your help.
Click to expand...
Click to collapse
I don't know for sure, but wouldn't rajendra's update create properly-named boot files alongside the old, improperly named ones? Wouldn't the multiboot built in to recent CM7 builds then look for and boot from the more recent, properly named files? I can't confirm that's how it would work, but it's what I would expect.
Taosaur said:
I don't know for sure, but wouldn't rajendra's update create properly-named boot files alongside the old, improperly named ones? Wouldn't the multiboot built in to recent CM7 builds then look for and boot from the more recent, properly named files? I can't confirm that's how it would work, but it's what I would expect.
Click to expand...
Click to collapse
Yes they would create properly named boot files. But I suspect my nook looks for improperly named files since I updated my u-boot after the CM7 nightly update.
The fix is simple: to rename the files. But I need to know how before I take the plunge.
yelloguy said:
Yes they would create properly named boot files. But I suspect my nook looks for improperly named files since I updated my u-boot after the CM7 nightly update.
Click to expand...
Click to collapse
Right, but if you run a CM7 update, it would replace your uboot again. I'm not saying do it, just wondering out loud if it would work.
yelloguy said:
Yes they would create properly named boot files. But I suspect my nook looks for improperly named files since I updated my u-boot after the CM7 nightly update.
The fix is simple: to rename the files. But I need to know how before I take the plunge.
Click to expand...
Click to collapse
In order to rename the files, you can do the following:
1. Boot into CM7 (or any other place where you have command line root access)
2. Create a temporary directory at a location where you have read write access.
3. Type su in a terminal session to gain root access and then mount mmcblk0p1 at the temporary location you created using the command:
mount /dev/block/mmcblk0p1 <full path to the directory you created>
4. Now use Astro to go over to the directory you created and mounted mmcblk0p1 into. You should see:
u-boot.bin which is the bootloader
u-boot.bin.stock which is the backup of the old stock bootloader
uImage and uRamdisk which are your primary kernel and ramdisk
uFImg and uFRam which are your secondary kernel and ramdisk (and whose names are mismatching the CM7 bootloader protocol)
u-boot.altimg and u-boot.altram, which are text files per the old bootloader method containing names of uFImg and uFRam
5. Rename uFImg to uAltImg, uFRam to uAltRam. And edit the contents of u-boot.altimg and u-boot.altram to match the new file names.
6. Reboot as usual into primary or secondary.
Now if an CM7 update ever replaces your u-boot.bin, you will not lose dual boot, as you have it set up as uAltImg and uAltRam per the new protocol.
Sent from my SAMSUNG-SGH-I897 using XDA App
---------- Post added at 03:24 PM ---------- Previous post was at 03:06 PM ----------
Taosaur said:
...the only means of doing so "that will work in all circumstance" and in any way resembles a single step is flashing a stock zip via CWM. Why not use an up-to-date zip? The usefulness of such files is demonstrated by the fact that:
such files exist for past stock versions
those files are in use
files like yours are used to work around the non-existence of up-to-date stock zips
If you're so comfortable working with update files, you very likely could have produced such a file in less time than you've spent rationalizing away the clearly demonstrated need for them. Tell you what, in all likelihood I can just swap a few files from B&N's 1.3 zip into the existing CWM-flashable 1.2 zips, correct? Which files do I replace?
Anyone?
Click to expand...
Click to collapse
I am sorry if you think I am rationalizing, but that was not my intention. I just wanted to point out that the files you linked to do not meet your own criteria.
Take for example the file update-nc-stock-1.2-keepcwm-signed.zip that you point to as missing in an up to date 1.3 version. That file will update a Nook Color to 1.2, but will keep CWM recovery. It however will make someone whose Nook Color 1.1 was rooted using autonooter lose root. A person that has been dualbooting to CM7 on secondary will lose that ability as well after applying that update. So unlike what you think, this is not a file to update stock 1.2 update under all circumstances regardless of what the starting point is. It has a specific use (update fro, a pre 1.2 stock primary eMMC boot, no dualboot, CWM recovery installed). Creation of an all situation stock restore file is impossible IMO, and the best you can do is wipe and apply 1.3 B&N stock update. You or I could technically create another equivalent file with update-nc-stock-1.3-keepcwm.zip /system files, kernel, ramdisk, etc., but this file would be subject to the same side effects as the original.
---------- Post added at 03:30 PM ---------- Previous post was at 03:24 PM ----------
Taosaur said:
Right, but if you run a CM7 update, it would replace your uboot again. I'm not saying do it, just wondering out loud if it would work.
Click to expand...
Click to collapse
It would work. If you apply my zip, there will be a uAltImg and uAltRam in /boot (in addition to uFImg and uFRam). If you apply another update that pushes the CM7 bootloader, it will then look for these files with trying to do an alternate boot, and would boot into a unrooted stock 1.3.
rajendra82 said:
In order to rename the files, you can do the following:
1. Boot into CM7 (or any other place where you have command line root access)
2. Create a temporary directory at a location where you have read write access.
3. Type su in a terminal session to gain root access and then mount mmcblk0 at the temporary location you created using the command:
mount /dev/block/mmcblk0 <full path to the directory you created>
Click to expand...
Click to collapse
I get an error:
mounting <paths> failed: Device or resource busy
Any ideas?
yelloguy said:
I get an error:
mounting <paths> failed: Device or resource busy
Any ideas?
Click to expand...
Click to collapse
I see a typo in my command (stupid Swiftkey X). It should be:
mount /dev/block/mmcblk0p1 <some directory>
Also try typing just mount in terminal to see if /dev/block/mmcblk0p1 is already mounted somewhere else.
rajendra82 said:
Take for example the file update-nc-stock-1.2-keepcwm-signed.zip that you point to as missing in an up to date 1.3 version. That file will update a Nook Color to 1.2, but will keep CWM recovery. It however will make someone whose Nook Color 1.1 was rooted using autonooter will lose root. A person that has been dualbooting to CM7 on secondary will lose that ability as well after applying that update. So unlike what you think, this is not a file to update stock 1.2 update under all circumstances regardless of what the starting point is. It has a specific use (update fro, a pre 1.2 stock primary eMMC boot, no dualboot, CWM recovery installed). Creation of an all situation stock restore file is impossible, and the best you can do is wipe and apply 1.3 B&N stock update. You or I could technically create another equivalent file with update-nc-stock-1.3-keepcwm.zip /system files, kernel, ramdisk, etc., but this file would be subject to the same side effects as the original.
Click to expand...
Click to collapse
Riiiiight... it would install stock 1.3 to the device. That's the intended behavior. The point is to avoid the unnecessary step of updating in any process that includes flashing stock to the sole or primary partition. One example of such a process would be a fresh dual boot setup. That it does not update or otherwise rely upon an existing install is the point.
Granted, such a file would not repartition the device, but it would install up-to-date stock in one step regardless of how a device is partitioned (1/5, 2/5, 5/1 or dual boot).
UPDATED 2016-08-12 I HIGHLY RECOMMEND A BETTER METHOD FOUND HERE:
http://forum.xda-developers.com/remix/remix-os/guide-using-jides-remountrw1-method-to-t3431595
FEWER CHANCES OF ERROR :laugh:
UPDATED 2016-08-09 TO INCLUDE 32 BIT DIRECTIONS MANY THANKS TO @ireMaN FOR INPUT
THIS IS MODIFIED NOW FOR BOTH 32 AND 64 BIT!
THIS IS ALSO ONLY FOR HDD INSTALLATIONS
Fellow Remixers:
As many have found out, version 3 of RemixOS doesn't allow changes to the system. This is because instead of a system.img it now uses a system.sfs. For most of us there is no advantage to this, and it makes it impossible to perform even simple mods to the build.prop.
So we must convert that pesky system.sfs to a system.img and substitute a modified initrd.img.
There has been so much interest in this that I have tried to write a guide. I hope it is accurate, but I encourage feedback to improve it. EDIT 2016-08-03: WORKS FOR 3.0.102 ALSO
EDIT: 2016-08-09 WORKS FOR 3.0.103 ALSO
Here it goes:
ALL OF THIS IS DONE FROM WINDOWS. From File Explorer, navigate to your partition with RemixOS folder. Note the drive letter; mine was d:
1 Open the RemixOS folder on that drive; you should see a system.sfs file.
2 First you need to download the correct (32 or 64) modified initrd.img from here:
https://drive.google.com/folderview?id=0B3gcDbDvV4MkTm5raUZRZXl4NkE
3 Use File Explorer to navigate to the Downloads folder; you should see a file named initrd_(32 or 64)_rw_3.0.101.img
4 Copy that file into the RemixOS folder on the drive where you installed Remix.
5 Open the RemixOS folder; you should see both the original initrd.img and the new initrd_(32 or 64)_rw_3.0.101.img
6 Rename the initrd.img to oldinitrd.img to save it in case you need it
7 Rename the initrd_(32 or 64)_rw_3.0.101.img to initrd.img
8 Next convert that system.sfs file to a system.img file
9 Using your web browser, download and install RMXTools from http://forum.xda-developers.com/remix/remix-os/rmxtools-remix-os-data-img-t3308158
10 Then in File Explorer, navigate to Downloads folder and extract the RMXTools zip. (EDIT: You may need 7zip to extract it)
11 Then navigate to the newly created RMXTools folder and navigate to the bin64 folder
12 Open a command window by using shift&right mouse button and selecting the Open command window here
13 Assuming that your RemixOS folder is on drive c: type unsquashfs.exe -d c:\temp c:\RemixOS\system.sfs
If your drive letter is e: for example, you would substitute e: for c: (EDIT: Do not change the -d as it is part of the command)
You should see it writing blocks for a few seconds
This should create a new system.img file on drive d: in folder temp
14 Now you need to navigate again to the drive with the RemixOS folder. You should see your newly created system.img in the temp folder
15 Copy it into the RemixOS folder
16 Now open the RemixOS folder; you should see your new system.img alongside the original system.sfs.
17 Rename the system.sfs to oldsystem.sfs to keep it in case you need it again
OK now time to reboot into Remix
You should now have writable system
Hope this helps
If it works for you please hit the "thanks" and if you're REALLY happy then I can always use coffee money
NOTE: TO TAKE OTA UPDATE YOU NEED TO DO THE Following FROM WINDOWS:
A In File Explorer, navigate to the RemixOS folder
B Find and rename the initrd.img to initrd_(32 or 64)_rw_3.0.101.img depending on your version
C Find and delete system.img
D Rename oldsystem.sfs to system.sfs
E Reboot ti RemixOS and download the update and select the Reboot option.
F After the OTA is installed and you are at the desktop you need to repeat steps 6 through 17 above
Any suggestions to make this easier please let me know. Please PM me and I will answer your questions.
Thanks a lot... Will try and reply you soon.... But I'm sure it works
Sent from my S II using XDA Labs
changing orientation
Thanks a lot. Not only you are a very helpful person , you have lots of patience. Thanks for all your inputs and guidance. I checked using CPU-Z and find all sensors are working including rotation sensor. I alos see that the new build.prop has the line ro.remixos.box is set to flase. But still my surface pro does not auto rotate to portrait mode. I am also not able to force it into portrait mode. Can you help please?
Thanks
lollyjay said:
Fellow Remixers:
There has been so much interest in this that I have tried to write a guide. I hope it is accurate, but I encourage feedback to improve it.
Here it goes:
All of this is done from Windows. From File Explorer, navigate to your partition with RemixOS directory. Note the drive letter; mine was d:
Open the RemixOS folder on that drive; you should see a system.sfs file.
First you need to download a modified initrd.img from here:
https://drive.google.com/folderview?id=0B3gcDbDvV4MkTm5raUZRZXl4NkE
Use File Explorer to navigate to the Downloads folder; you should see a file named initrd_rw_3.0.101.img
Copy that file into the RemixOS folder on the drive where you installed Remix.
Open the RemixOS folder; you should see both the original initrd.img and the new initrd_rw_3.0.101.img
Rename the initrd.img to oldinitrd.img to save it in case you need it
Rename the initrd_rw_3.0.101.img to initrd.img
Next convert that system.sfs file to a system.img file
Using your web browser, download and install RMXTools from http://forum.xda-developers.com/remix/remix-os/rmxtools-remix-os-data-img-t3308158
Then in File Explorer, navigate to Downloads folder and extract the RMXTools zip.
Then navigate to the newly created RMXTools folder and navigate to the bin64 folder
Open a command window by using shift&right mouse button and selecting the Open command window here
Assuming that your RemixOS folder is on drive d: type
unsquashfs.exe -d d:\temp d:\RemixOS\system.sfs
If your drive letter is e: for example, you would substitute e: for d:
You should see it writing blocks for a few seconds
This should create a new system.img file on drive d: in folder temp
Now you need to navigate again to the drive with the RemixOS folder. You should see your newly created system.img in the temp folder
Copy it into the RemixOS folder
Now open the RemixOS folder; you should see your new system.img alongside the original system.sfs.
Rename the system.sfs to oldsystem.sfs to keep it in case you need it again
Rename the initrd_rw_3.0.101.img to initrd.img
OK now time to reboot into Remix
You should now have writable system
Hope this helps
If it works for you please hit the "thanks" and if you're REALLY happy then I can always use coffee money
Any suggestions to make this easier please let me know.
Click to expand...
Click to collapse
Some Question
Any suggestions to make this easier please let me know.
Click to expand...
Click to collapse
how to mount HDD Partition like previous version? is there any trick to show it again?
Hope Anyone Here Can Help
rajnallan said:
Thanks a lot. Not only you are a very helpful person , you have lots of patience. Thanks for all your inputs and guidance. I checked using CPU-Z and find all sensors are working including rotation sensor. I alos see that the new build.prop has the line ro.remixos.box is set to flase. But still my surface pro does not auto rotate to portrait mode. I am also not able to force it into portrait mode. Can you help please?
Thanks
Click to expand...
Click to collapse
Thank you for the compliment. My knowledge does not extend to that area; perhaps @HypoTurtle can help?
asuduakali said:
Any suggestions to make this easier please let me know.
how to mount HDD Partition like previous version? is there any trick to show it again?
Hope Anyone Here Can Help
Click to expand...
Click to collapse
I wish I knew...
Edit: I suspect that they locked access to speed up the system by disabling disk i/o
lollyjay said:
I wish I knew...
Edit: I suspect that they locked access to speed up the system by disabling disk i/o
Click to expand...
Click to collapse
I succeed to do it using stickmount after i copied these imgs .
just check usbstorage folder with file explorer ( i'm using ES)
lollyjay said:
Fellow Remixers:
There has been so much interest in this that I have tried to write a guide. I hope it is accurate, but I encourage feedback to improve it.
Here it goes:
All of this is done from Windows. From File Explorer, navigate to your partition with RemixOS directory. Note the drive letter; mine was d:
Open the RemixOS folder on that drive; you should see a system.sfs file.
First you need to download a modified initrd.img from here:
https://drive.google.com/folderview?id=0B3gcDbDvV4MkTm5raUZRZXl4NkE
Use File Explorer to navigate to the Downloads folder; you should see a file named initrd_rw_3.0.101.img
Copy that file into the RemixOS folder on the drive where you installed Remix.
Open the RemixOS folder; you should see both the original initrd.img and the new initrd_rw_3.0.101.img
Rename the initrd.img to oldinitrd.img to save it in case you need it
Rename the initrd_rw_3.0.101.img to initrd.img
Next convert that system.sfs file to a system.img file
Using your web browser, download and install RMXTools from http://forum.xda-developers.com/remix/remix-os/rmxtools-remix-os-data-img-t3308158
Then in File Explorer, navigate to Downloads folder and extract the RMXTools zip.
Then navigate to the newly created RMXTools folder and navigate to the bin64 folder
Open a command window by using shift&right mouse button and selecting the Open command window here
Assuming that your RemixOS folder is on drive d: type
unsquashfs.exe -d d:\temp d:\RemixOS\system.sfs
If your drive letter is e: for example, you would substitute e: for d:
You should see it writing blocks for a few seconds
This should create a new system.img file on drive d: in folder temp
Now you need to navigate again to the drive with the RemixOS folder. You should see your newly created system.img in the temp folder
Copy it into the RemixOS folder
Now open the RemixOS folder; you should see your new system.img alongside the original system.sfs.
Rename the system.sfs to oldsystem.sfs to keep it in case you need it again
Rename the initrd_rw_3.0.101.img to initrd.img
OK now time to reboot into Remix
You should now have writable system
Hope this helps
If it works for you please hit the "thanks" and if you're REALLY happy then I can always use coffee money
Any suggestions to make this easier please let me know.
Click to expand...
Click to collapse
Tried it now. Worked like a charm. killing the thanks button
Everything working fine... I'd clean install replacing both files, thank you very much, and also i installed SuperSU for better root magement and besides.. with this one StickMount works perfectly...
doing this Adaway can work?
dark8899 said:
doing this Adaway can work?
Click to expand...
Click to collapse
Yes, of course
asuduakali said:
how to mount HDD Partition like previous version? is there any trick to show it again?
Hope Anyone Here Can Help
Click to expand...
Click to collapse
Try changing ro.remixos.scan_all_parts=false
rajnallan said:
Thanks a lot. Not only you are a very helpful person , you have lots of patience. Thanks for all your inputs and guidance. I checked using CPU-Z and find all sensors are working including rotation sensor. I alos see that the new build.prop has the line ro.remixos.box is set to flase. But still my surface pro does not auto rotate to portrait mode. I am also not able to force it into portrait mode. Can you help please?
Thanks
Click to expand...
Click to collapse
Haven't found what's forcing landscape; yet... maybe see what changing ro.remixos.has_adjust_display=false does; but it's probably nothing
xSilverLight said:
Everything working fine... I'd clean install replacing both files, thank you very much, and also i installed SuperSU for better root magement and besides.. with this one StickMount works perfectly...
Click to expand...
Click to collapse
Yea, stickmount seems to need the [updated] superSU su binary; so either system.img rw or systemless root would do [also the build.prop edit mentioned above might be an alternative to stickmount but editing build.prop needs system rw anyway].
Addendum; if anyone is using my 32bit su.img; you need to make a /su/xbin_bind folder and reboot before SuperSU will update the binary
HypoTurtle said:
Yea, stickmount seems to need the [updated] superSU su binary; so either system.img rw or systemless root would do [also the build.prop edit mentioned above might be an alternative to stickmount but editing build.prop needs system rw anyway].
Addendum; if anyone is using my 32bit su.img; you need to make a /su/xbin_bind folder and reboot before SuperSU will update the binary
Click to expand...
Click to collapse
Exactly, also I'll try that you mention and thanks for the info..
And also.. thanks for all your contributions
HypoTurtle said:
Try changing ro.remixos.scan_all_parts=false
Haven't found what's forcing landscape; yet... maybe see what changing ro.remixos.has_adjust_display=false does; but it's probably nothing
IT is already showing ro.remixos.has_adjust_display =false
The latest remix OS based on Marshmallow carries all these changes.
Click to expand...
Click to collapse
Thanks. Now I can use stick mount and access my hdd.
hhaiwzz said:
Thanks. Now I can use stick mount and access my hdd.
Click to expand...
Click to collapse
You're very welcome my pleasure
I'm at a loss as to how to get this working on a USB install on my system. Are people using hard drive installs or USB flash drive ones? I'm using a 64gb Sandisk Extreme flash drive.
1st off - using the Windows tool that comes in the installer from Jide's website (downloaded file I have is Remix_OS_for_PC_Android_M_64bit_B2016072603.zip ) to "install" RemixOS onto the flash drive works flawlessly but after that I'm unable to see any other volumes other than one called REMIX_OS which is not a system volume. I've formatted the flash drive 4 times already and redid the installation each time. Each time the install is perfectly bootable but in terms of being able to boot into windows and brows the RemixOS folder to modify system files there is no change, I'm unable to see all volumes on the flash drive. I only see one volume while in windows and that one appears to be an SD CARD (It's called REMIX_OS and only has an Android and Lost folder in it) rather than the system volume for Android.
If I insert the flash drive into my Macbook I'm able to see two volumes, the volume called REMIX_OS I referred to earlier and another volume called REMIXOSSYS which does have the system files in it (with the initrd.img and system.sfs that need to be replaced) . .
So after using the RMXTools on my Windows machine to create a system.img file (which ends up ballooning to 2.6gb, is that the right size?) and downloading the requisite initrd_rw_3.0.101.img and renaming both original files on the REMIXOSSYS volume (using my Mac) and copying the new ones onto the flash drive volume I'm able to boot into RemixOS on my PC normally.
Everything works fine until I actually try to edit build prop as a test at which point I'm unable to. The system itself operates just fine otherwise but system still isn't writeable.
I'm not quite sure why others are easily able to do everything they need to do on their PC's using windows explorer to modify the system files and I'm not. I tried it on both my home and work PCs and the result is the same. Nonetheless I'm thinking that since all that is supposed to be required to make system writeable is to replace the initrd.img and system.sfs with the modified initrd.img and a system.img file then it really shouldn't matter if I do it using a Mac or a PC . . i'm confused at this point lol.
Any thoughts?
rajnallan said:
HypoTurtle said:
Try changing ro.remixos.scan_all_parts=false
Haven't found what's forcing landscape; yet... maybe see what changing ro.remixos.has_adjust_display=false does; but it's probably nothing
IT is already showing ro.remixos.has_adjust_display =false
The latest remix OS based on Marshmallow carries all these changes.
Click to expand...
Click to collapse
Yea; I said change it. i.e. to true
Click to expand...
Click to collapse
muzzy996 said:
I'm at a loss as to how to get this working on a USB install on my system. Are people using hard drive installs or USB flash drive ones? I'm using a 64gb Sandisk Extreme flash drive.
1st off - using the Windows tool that comes in the installer from Jide's website (downloaded file I have is Remix_OS_for_PC_Android_M_64bit_B2016072603.zip ) to "install" RemixOS onto the flash drive works flawlessly but after that I'm unable to see any other volumes other than one called REMIX_OS which is not a system volume. I've formatted the flash drive 4 times already and redid the installation each time. Each time the install is perfectly bootable but in terms of being able to boot into windows and brows the RemixOS folder to modify system files there is no change, I'm unable to see all volumes on the flash drive. I only see one volume while in windows and that one appears to be an SD CARD (It's called REMIX_OS and only has an Android and Lost folder in it) rather than the system volume for Android.
If I insert the flash drive into my Macbook I'm able to see two volumes, the volume called REMIX_OS I referred to earlier and another volume called REMIXOSSYS which does have the system files in it (with the initrd.img and system.sfs that need to be replaced) . .
So after using the RMXTools on my Windows machine to create a system.img file (which ends up ballooning to 2.6gb, is that the right size?) and downloading the requisite initrd_rw_3.0.101.img and renaming both original files on the REMIXOSSYS volume (using my Mac) and copying the new ones onto the flash drive volume I'm able to boot into RemixOS on my PC normally.
Everything works fine until I actually try to edit build prop as a test at which point I'm unable to. The system itself operates just fine otherwise but system still isn't writeable.
I'm not quite sure why others are easily able to do everything they need to do on their PC's using windows explorer to modify the system files and I'm not. I tried it on both my home and work PCs and the result is the same. Nonetheless I'm thinking that since all that is supposed to be required to make system writeable is to replace the initrd.img and system.sfs with the modified initrd.img and a system.img file then it really shouldn't matter if I do it using a Mac or a PC . . i'm confused at this point lol.
Any thoughts?
Click to expand...
Click to collapse
Method works only for hdd installations afaik
wow thanks for this, now since we have an open system, can we install xposed framework?
dear i need help
due to many reasons i installed remix os on ext4 partition scheme without data.img and placed boot efi to other partition and everything is fine except now when i am going to update to 3.203 from 3.202, at restart em gotting "update failed" at boot.
plz help
http://forum.xda-developers.com/showpost.php?p=66455430&postcount=7
Ota updating has not being fixed (did it? Ever work?)
*when you download the iso... there a known issues list...that incl Ota not working
Goodluck
mitchell4you said:
http://forum.xda-developers.com/showpost.php?p=66455430&postcount=7
Ota updating has not being fixed (did it? Ever work?)
*when you download the iso... there a known issues list...that incl Ota not working
Goodluck
Click to expand...
Click to collapse
OTA updates of installed RemixOS versions never worked. But you can perform a new installation keeping your data directory. Updating version 3.0.202 you have to rename directory "android-2016-08-23" into "RemixOS" (probably this renaming of the installation directory is necessary the last time) and to delete all directories and files contained by "RemixOS" other than "data". In the next step you have to install Remix OS 3.0.203 without formatting your ext4 partition and with creating a new grub entry. That's all.
remixtester said:
OTA updates of installed RemixOS versions never worked. But you can perform a new installation keeping your data directory. Updating version 3.0.202 you have to rename directory "android-2016-08-23" into "RemixOS" (probably this renaming of the installation directory is necessary the last time) and to delete all directories and files contained by "RemixOS" other than "data". In the next step you have to install Remix OS 3.0.203 without formatting your ext4 partition and with creating a new grub entry. That's all.
Click to expand...
Click to collapse
I've used the ota updater and it worked fine. i didn't test 2.0 to 3.0 ota(it was faster downloading separate and manually update). I have been using the same /remix/data folder since the 2.0(I manually patched /data when going from 2.0 to 3.0). I also keep backups of the data folder.
Maromi said:
I've used the ota updater and it worked fine. i didn't test 2.0 to 3.0 ota(it was faster downloading separate and manually update). I have been using the same /remix/data folder since the 2.0(I manually patched /data when going from 2.0 to 3.0). I also keep backups of the data folder.
Click to expand...
Click to collapse
remixtester said:
OTA updates of installed RemixOS versions never worked. But you can perform a new installation keeping your data directory. Updating version 3.0.202 you have to rename directory "android-2016-08-23" into "RemixOS" (probably this renaming of the installation directory is necessary the last time) and to delete all directories and files contained by "RemixOS" other than "data". In the next step you have to install Remix OS 3.0.203 without formatting your ext4 partition and with creating a new grub entry. That's all.
Click to expand...
Click to collapse
i know the directry is "android-2016-08-23". how i rename it ? i cannot read ext4 from os x not intrested to install fuse.etc
remixtester said:
OTA updates of installed RemixOS versions never worked. But you can perform a new installation keeping your data directory. Updating version 3.0.202 you have to rename directory "android-2016-08-23" into "RemixOS" (probably this renaming of the installation directory is necessary the last time) and to delete all directories and files contained by "RemixOS" other than "data". In the next step you have to install Remix OS 3.0.203 without formatting your ext4 partition and with creating a new grub entry. That's all.
Click to expand...
Click to collapse
Maromi said:
I've used the ota updater and it worked fine. i didn't test 2.0 to 3.0 ota(it was faster downloading separate and manually update). I have been using the same /remix/data folder since the 2.0(I manually patched /data when going from 2.0 to 3.0). I also keep backups of the data folder.
Click to expand...
Click to collapse
There never was a 2.0 to 3.0 ota afaik. The data would have caused a system stall if there was - as it [X86update] isn't setup to clear the system app app-data.
ext4 data shouldn't have any bearing on OTAs and neither should the name of the folder being used [as long as it is correctly labelled in grub as SRC=${folder_name}. ext4 system would be a problem [but as long as there is also a system.sfs in the $SRC folder - that you'll use to remake the system folder - you'll be fine]
Only real issue is if you have grub at a non-standard location [i.e. not sda1/efi] but they have added the grub arg. REMIXOS_EFI=/dev/sda1 or something that you can use to get around that - or just manually fixing the grub.cfg with whatever the OTA is attempting to change it to.
karamatks said:
i know the directry is "android-2016-08-23". how i rename it ? i cannot read ext4 from os x not intrested to install fuse.etc
Click to expand...
Click to collapse
You have to start your computer using a pendrive containing an operating system which can mount your RemixOS partition. Examples are a pendrive containg Ubuntu or PartedMagic. Directory android-2016-08-23 has to be renamed into RemixOS. After opening the renamed directory RemixOS don't forget to delete all files and directories other than "data".
remixtester said:
You have to start your computer using a pendrive containing an operating system which can mount your RemixOS partition. Examples are a pendrive containg Ubuntu or PartedMagic. Directory android-2016-08-23 has to be renamed into RemixOS. After opening the renamed directory RemixOS don't forget to delete all files and directories other than "data".
Click to expand...
Click to collapse
I try to update my RemixOS but suddenly power off I wait about half hour then power back my PC then I can't boot to RrmixOS. I dual boot with Lubuntu 16.X with HP ProBook 4410
Sent from my HM NOTE 1LTEW using Tapatalk
@itsAril Since the system crashed whilst updating, the /system partition probably got corrupted. If you have a recent Remix OS installation .iso file, then you can open it and extract system.sfs file into the directory where you installed RemixOS (replace the old one). Then reboot to check if it helped.
Most likely your storage medium also got affected - it may have badblocks in the filesystem. To make sure that's not the case do the following from Windows:
Start cmd.exe as administrator.
Run this command but change X: to drive where RemixOS is installed:
Code:
chkdsk X: /f /r /x
Once it's done, make a screenshot/picture or save the contents of the console in notepad to show results to us.
Reboot into Remix and check if it helped.
If that doesn't help, then next thing you can do is:
Backup the data.img file onto your other partition.
Uninstall Remix
Install it again, but don't reboot.
Restore the data.img file.
Reboot to test.
If that also doesn't help, then use this guide. But ommit/do NOT perform command “resize2fs data.img 16G”.
Vioner said:
@itsAril Since the system crashed whilst updating, the /system partition probably got corrupted. If you have a recent Remix OS installation .iso file, then you can open it and extract system.sfs file into the directory where you installed RemixOS (replace the old one). Then reboot to check if it helped.
Most likely your storage medium also got affected - it may have badblocks in the filesystem. To make sure that's not the case do the following from Windows:
Start cmd.exe as administrator.
Run this command but change X: to drive where RemixOS is installed:
Code:
chkdsk X: /f /r /x
Once it's done, make a screenshot/picture or save the contents of the console in notepad to show results to us.
Reboot into Remix and check if it helped.
If that doesn't help, then next thing you can do is:
Backup the data.img file onto your other partition.
Uninstall Remix
Install it again, but don't reboot.
Restore the data.img file.
Reboot to test.
If that also doesn't help, then use this guide. But ommit/do NOT perform command “resize2fs data.img 16G”.
Click to expand...
Click to collapse
Thanks you very much it work now..
Sent from my HM NOTE 1LTEW using Tapatalk
@itsAril That's great! Can you share with us how far did you have to go with these tips? After what did it start to work?
It's useful info for others with the issue.
I just uninstall and install backup data.img I have to do twice fist try doesn't work. I got video coming I will post here when done editing. Maybe will help someone got same problem like me
Sent from my HM NOTE 1LTEW using Tapatalk