Related
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).
Welcome to LunarTools
Download standalone: Link
Can find older versions here along with some other rom mods: Link
Download compatibility test script: Link
Link to script source
Link to app source
Q: What is this?
Breif explanation of LunarCmdline & LunarMenu:
LunarCmdLine: It's intended use is for getting rid of the need of a cpu control app. This script allows the end user to change kernel defaults as a boot.img for either immediate flashing or saving for later on a storage option. Can only be implemented if your kernel supports showp1984's command line options.
LunarInitd: Same as Cmdline but more universal to any kernel when paired with init.d supported roms. Be aware, even though this may be safer it may also not be quite as stable as Cmdline.
LunarMenu: This coincides with the boot.img's created from invoking LunarCmdline. It lists the boot.img's created that are found on internal storage in lunar directory. Also has the ability to flash a recovery for you. Also those rom dev's who wish to implement it later you will be able to switch your boot.img using this script.
Think of them as my implementation of TWRP's Dumlock option that works with with every recovery. AS WELL -DO NOT SET A HOTPLUG GOVERNOR WITH CMDLINE! This *might* result in a softbrick only recoverable by reflashing your rom's boot.img.
Q: Oh neat ok, ..... but how do I run them?
Using a terminal emulator app, allow superuser permissions (su then enter), then invoke either script (menu then enter or cmdline then enter).
Q: There was mention earlier about recoveries or switching boot.img's, how do I use that feature?
Place the recovery you wish to flash in the lunar folder on internal storage(Sense)/external (AOSP) in this name format "recovery<name><version of recovery>.img". You will also be prompted if you wish to create a recovery backup if you wish to use the feature. Examples: recovery_CWMTouch6.0.3.1.img or boot_Rage2.5.img
Q: Would I be able to use this with other boot.img's/kernels?
Currently, if your rom dev supports the feature.
Q: Do you plan to support XxYzZ feature?
Post some feedback. I might consider it.
Q: I have a question not listed here, what information would you need if I had an issue?
Filename of the latest boot/recovery you intended to flash & of course your patience while we work on the issue at hand.
Q: I'm a kernel/rom dev, can I use these for HTC xYzzYx device in my android project ?
This is freely distributed for use, all I ask is if you do use it refer back to this thread. If assistance is needed please PM me or post in thread. You may need to modify some values in cmdline.sh for proper implementation and will need abootimg & unzip in system/bin as part of busybox/toolbox.
Known Bugs:
If flashing a recovery, remember to rename your recovery_backup.img to proper format (recovery<name><version>.img). If you don't and attempt to flash it using the same backup filename, you will just be reflashing your current recovery. No longer a bug
Remember to reboot to recovery if it doesn't automatically.
To do or possibly implement:
zImage flashing similar to AnyKernel. Done!
Known Compatible Devices:
HTC Rezound
Credits @d.kozzer - Without your knowledge & assistance the GUI wouldn't exist
PS: REMEMBER THIS IS ALL AT YOUR OWN RISK AND PURE BETA!!!! YOU CAN POTENTIALLY SOFTBRICK BUT CAN ALSO EASILY RESTORE FROM THAT SOFTBRICK!
A quick how-to from a good friend that's been using this since release candidates:
kcirtap420 said:
Here's a quick rundown of what I came up:
LunarTools(menu only currently) Options Explained
NOTE: If you are prompted to reboot or it fails to auto-reboot please do so
and follow instruction.(auto-reboot doesn't work with sense roms)
Option 1 will give you the ability to flash saved boot.img configurations from the cmdline feature or apply those same settings via init.d , eliminating the need for a cpu or kernel modifing app.
Once selected to will be prompted to choose which boot configuration to flash/appl. If command line, reboot to recovery (auto wipes cache and dalvik) for settings to apply. If init.d a simple reboot will do.
Option 2 has the ability to flash a recovery for you, and also backup your current one!
To do this you must first place a recovery image in the lunar folder, rename it to look like this recovery"name""version" enter recovery name and version without quotes.
Once selected it will ask which recovery to flash(if it's not there make sure it's named correctly and in the lunar folder!)
It will then ask you if you would like to backup your current recovery.(this will be in the lunar folder ready to
go!) Enjoy your new recovery once it's completed! No reboot needed.
Option 3 can be used for a couple things, you can update your kernel, or flash a whole new one!
To flash a new one place kernel zip in the lunar folder. If you would like to update your current kernel, place the zimage from a kernel zip in the lunar folder.
Select either file from the list, Once it's done reboot to recovery if not done automatically ( auto wipes cache and dalvik)
Option 4 is the answer for S-on users and boot.img's, REJOICE!! This option will flash a boot.img from a ROM zip!
To do this first place the ROM zip inside the lunar folder and select it, it will continue to flash the boot.img. Once it's done
reboot to recovery and go about usual ROM flashing habits such as perform factory reset and wipe system, then install your ROM and reboot!
Enjoy your new ROM flashed without fastboot commands!
Click to expand...
Click to collapse
Please try to take any questions/bugs to this thread
http://forum.xda-developers.com/showthread.php?p=41634758
or here
http://themikmik.com/showthread.php?16096-LunarTools-ChitChat-amp-Bugs-Thread
For now, the source that's on git is for AOSP roms(place boot.img's on sdcard/lunar). Bare with me while working on getting insecured boots for AOSP to get the scripting to work properly.
Snuzzo said:
For now, the source that's on git is for AOSP roms(place boot.img's on sdcard/lunar). Bare with me while working on getting insecured boots for AOSP to get the scripting to work properly.
Click to expand...
Click to collapse
wow wait for this to be stable. cheers!
Watching
sexy
lookin sexy!
First bug found
Problem
When choosing recovery_backup<DATE>.img and today's date is the same recovery doent seem to flash.
Solution
Rename recovery_backup<DATE>.img to a proper filename. recovery_<name><version>.img and flash the file under the new filename.
Just a small bug found which I will be rectifying very VERY soon.
Nearing release as standalone flashables.
https://github.com/Snuzzo/LunarTools/commit/9bd3b14b2f6a23172da957ae893fea9f5bb0f766
For those who have been following this; do you see anything that you would like implemented?
Standalone flashables posted in the OP for download.
OK so far heroes what i got in a new menu addition...
Pulls boot.img from zip
Flashes it
Creates a recovery script which right now only flashes the zip you chose
Then auto reboots.
May need some assistance with this as it needs to wipe data cache. I probably could do this with a rm command prior to auto reboot.
Thoughts?
Sent from my Nexus 7 using Tapatalk HD
Snuzzo said:
OK so far heroes what i got in a new menu addition...
Pulls boot.img from zip
Flashes it
Creates a recovery script which right now only flashes the zip you chose
Then auto reboots.
May need some assistance with this as it needs to wipe data cache. I probably could do this with a rm command prior to auto reboot.
Thoughts?
Sent from my Nexus 7 using Tapatalk HD
Click to expand...
Click to collapse
I like the idea of it just auto booting into recovery only after flashing boot.img
Edit: or maybe have the script prompt if you want to reboot
Sent from my ADR6425LVW using xda premium
Bug: mismatched boot and rom in a backup
Solution: before using the 4th option to flash a boot.img from zip run your optional nandroid prior.
Sent from my Nexus 7 using Tapatalk HD
Test builds sent out as extensions to busybox placed in /system/bin.
So far that has been working nicely. If those testers find any softbricks today I won't be releasing.
Next to do:
write a how to even though the menus are rather straight forward.
Add implementation of auto reboot to recovery to finish flashing a zImage from a zip.
Further reduce bootsize buffer for compression of output boot.imgs.
Finalize LunarCmdline.
Write a script to test compliance.
Sent from my ADR6425LVW using Tapatalk 2
Updated OP with a v1 release. Still has some work but 99% of it is completed.
Next to do:
write a how to even though the menus are rather straight forward.
Add implementation of auto reboot to recovery to finish flashing a zImage from a zip. Done
Further reduce bootsize buffer for compression of output boot.imgs. Done
Finalize LunarCmdline.
Write a script to test compliance of other devices.
Footnotes:
1st menu option- Not completely implemented yet. Could be used if wishing to restore a backup from Amon RA/CWM, I have further plans for it
3rd menu option- Use zImage from zip if fresh flashing. Use straight zImage if updating/downdating.
DO NOT PUT INVALID CHARACTERS IN ANY REQUESTED INPUTS! This could lead to unwanted results. Please PLEASE ask questions, don't let curiosity get the best of you.
Sent from my ADR6425LVW using Tapatalk 2
Had to re-upload a fixed AOSP/SDCARD zip. It was attempting to source a file from sdcard2.
http://www.androidfilehost.com/?fid=13858035414129967316
Major thanks, this is a really simple way to make use of cmdline features. :thumbup:
Sent from my ADR6425LVW using xda premium
ezpz
Gotta say this is a very handy tool to have around. I've flashed a bunch of different roms/boot.img/zimage and its pretty simple, especially after doing it at least once.
would this finally be an app to make it noob friendly
Sent from my MIUIFIED using xda premium
live2die said:
would this finally be an app to make it noob friendly
Sent from my MIUIFIED using xda premium
Click to expand...
Click to collapse
A walk thru is in the works but its pretty straight forward
Sent from my ADR6425LVW using xda premium
Still got some minor kinks to work. Mainly on the Sense portion. Some of the ported roms are being a pain. The cmdline script runs beatifully. If you're s-off, mainly going to be interested in menu options 1 & 3. Both scripts work brilliantly with s-on and s-off alike without using fastboot.
Next to do:
write a how to even though the menus are rather straight forward.
Clean up some of the script to make it more efficient.
Create a boot.img to command line bootimg.cfg converter.
Add implementation of auto reboot to recovery to finish flashing a zImage from a zip. Done
Further reduce bootsize buffer for compression of output boot.imgs. Done
Finalize LunarCmdline. Done
Write a script to test compliance of other devices. Done
PLEASE READ NEW FLASHING INSTRUCTIONS
Disclaimer:
I am not responsible for any bricks. By flashing this you understand that no one involved with the making of this Rom is responsible for a brick. However, if two nations go to war, that's okay, because they will destroy themselves and their people will worship me, THE BUTTAHLORD OF BUTTERNOOBIA!!!
I mean uhh... No, very bad thing, no countries should not go to war *cough* destroy yourselves *cough*
PLEASE READ ENTIRE THREAD BEFORE FLASHING, D/Ls and Changelog in 2nd Post
Okay past the joking, this is a stock, rooted KitKat ROM for the ZTE ZMAX. The deodexed version would not boot, so this is odexed. However, this version is free of any King Related apps and I've also removed the little bit of crapware in the device.
FEATURES:
Removal of All King Related Apps
Pre-Rooted
Clear of Bloatware
Added Xposed
Added SuperSU
Removed crappy ZTE/Metro/TMO apps
Overall Clean experience
HOW TO FLASH (NEW INSTRUCTIONS):
1. Place ZIP on SD Card
2. Reboot Into TWRP
3. NANDROID (DO NOT SKIP THIS FOR YOUR SAKE)
4. Don't factory reset the normal way, go to wipe > advanced wipe and click "dalvik cache", "data", "cache" and "system". If you don't, you run the risk of getting an updater-script error (not from the zip, it's a bug in some TWRP builds).
5. New Step: Reboot recovery (in the recovery menu). It will ask if you want to install su, press do not install.
5. Flash the ROM
6. Reboot and rep Butternoob!
BUGS:
Free and clear, you tell me!
ADDITIONAL INFORMATION:
Butternoob has been confirmed to work on all variants of the ZTE ZMAX by at least two people on each variant. THIS IS NOT SUPERBUTTER! For those that don't know, Superbutter will be a heavily modified custom rom. Butternoob was designed to be a stock, clean experience with solid performance. I may add tweaks, but you won't find a lot beyond the stock experience.
CREDITS:
-XDA User Mazer.One for the Bootanimation. I made some edits to his and don't take credit for the original work.
-JCase for helping us get root
-Hroark13 for helping me fix the wifi issue in the updater-script
-ZTE Because I have to... They are banished from ButterNoobia though...
-Masterchief87 for the 4.4.4 base and boot.img
ENJOY, REPORT BUGS, FEEL FREE TO USE AS A BASE AND GIVE PROPER CREDITS!
People have asked what my PayPal email is for donations, it is [email protected] . Never required but always appreciated, I'll give 100% regardless
Changelog:
V2:
-Updated to Android 4.4.4 base
-Band 12 Ready
-Replaced Google Launcher with Apex
--Advice on Apex: Go into menu > apex settings > drawer settings > drawer animation > circle to enable Lollipop-style animation for the drawer opening!
-Fixed SuperUser (All binaries updated)
-Fixed Gapps Force Closes
- New Wallpaper, taste of the SuperButter
-All bugs are squashed
V1:
-Initial Release
-Android 4.4.2
-Removed T-Mobile Apps
-Removed ZTE Apps (i.e. music, file manager, etc.)
DOWNLOAD:
BUTTERNOOB Stock 4.4.4 v2.0
md5: E44F1F84B47D3C4401DA522D0A7494F5
BUTTERNOOB Stock 4.4.2 v1.0
md5: 092cee0504d07fa4decde02d2206a2b7
Mine again
Cricket Zte Z987
Will this work on Cricket ZTE Z987 model
How to enable VOLTE on this rom?
work
will this work on ZMAXX Z958 ?
kas hif said:
will this work on zmaxx z958 ?
Click to expand...
Click to collapse
no. Don't try it. Unless you want to buy another phone.
Having an odd issue with LTE. When I call with LTE enabled, it tries to force the call through VOLTE, rather than handing off to a 4g (or whatever) local band. The call, of course, fails with no audio in or out; is this a known issue, is there a workaround, do I need to re-flash, or is this something weird that nobody's heard about before?
Does this work on Grand X Max + Z987?
Sent from my Z987 using Xparent Blue Tapatalk 2
Zmax Z970 RamDisk Boot.img packing problem
Hi,
Im attempting to repack the ram-disk image for my boot img on my ZTE Zmax z970 running the BN 2.0-oxed ROM. I was trying to use gzip with mkbootimg and it is not working, im assuming due to the fact that my newly repacked ram-disk cpio compressed file was not the same size as the original making the phone fail to boot when the boot.img was sent back to the boot block. My pc is running Ubuntu 14.04-32 bit. I know that the unpack-bootimg and mkbootimg scripts are working correctly because when i repack an unchanged boot.img-ramdisk.cpio.gz file (unpack the img and recreate the boot.img file) and re-upload it to the boot block, the phone boots correctly so I know that my procedures outside of the ram-disk cpio file are correct. My question is, How can I find out how much padding i need on the ram-disk file, where the padding should go, and how to apply the padding to get the file the correct size so that it will work as intended? Any help you can give me would be greatly appreciated.
P.S. I only unpackaged the boot image to change one entry in the ramdisk to the default.prop file. If there is a way to open the compressed cpio file with an archive manager and could update the file once i make my change. that would work as well. I can open the gz file with the archive manager but can not open the cpio folder contained inside.
Thanks,
Much appreciation.....f20062e
I followed your directions. Surprisingly it was super easy! Thanks!!!!!
Does this work on 6.0.1 Zmax Pro Tmobile?
link
Need link to root the z981 and link for twrp to install the recovery image. Thanks all for the hard work this excellent community pours out on a daily basis!
Hi there! I just got this flashed, and I need to know if it's safe to do an OTA update over your ROM.
Thanks a ton!
ZTE 982
Hi there good morning I have a big question, I have the ZTE z982 from MetroPCS I went ahead and rooted and installed TWRP on it. Now I was having some issues trying to flash a custom rom Slimrom to be exact (https://forum.xda-developers.com/zte-zmax/development/slimrom-5-0-2-t3161888) but I kept getting errors about legacy property? So something along those lines. Well I then read somewhere that it could be because of TWRP being outdated. I took it upon myself to look and find an .IMG witch I then flashed and now am stuck with a sorta bootloop flashes on but the screen goes black. Any suggestions? I would really appreciate it.
how did you get past fastboot. my z982 cant find device there?
soLo1Blue said:
Hi there good morning I have a big question, I have the ZTE z982 from MetroPCS I went ahead and rooted and installed TWRP on it. Now I was having some issues trying to flash a custom rom Slimrom to be exact (https://forum.xda-developers.com/zte-zmax/development/slimrom-5-0-2-t3161888) but I kept getting errors about legacy property? So something along those lines. Well I then read somewhere that it could be because of TWRP being outdated. I took it upon myself to look and find an .IMG witch I then flashed and now am stuck with a sorta bootloop flashes on but the screen goes black. Any suggestions? I would really appreciate it.
Click to expand...
Click to collapse
No matter what I do I cannot get this vile little phone to root. It is located in adb but fastboot just isnt there or doesnt' want to find it. I have tried every dang driver you can think of and still nothing in fastboot. I must know its driving me crazy. I have got to where i absolutely hate this phone!
works on z981 ??
I have a system.img file, which I extracted from a 20J KDZ. I would now like to convert it into a flashable zip. I have 2 reasons for this. One, I dont want to have to use LGUP to revert my phone to a 100% stock system. It is much easier to just flash a zip of the system partition. Two, I would like to get into modding and ROM development. I believe that it is best to start from pure stock and make changes from there, instead of basing your work off of something that someone else has already modded.
I found these threads but they're a bit old (Lollipop):
1. http://forum.xda-developers.com/lg-v10/development/lg-h901-stock-img-files-boot-recovery-t3238638
2. http://forum.xda-developers.com/tmobile-lg-v10/development/lg-h901-stock-images-device-restore-t3241170
In one of them a member provided img's for recovery, boot, and system. In the other thread flashable zips of these img's were posted. These are for the Tmo v10. So it's not a matter of whether it can be done, but how. What tools are needed?
I downloaded the zip from one of the aforementioned threads, deleted the boot.img, replaced his system.img with mine, edited updater-script, and zipped up the meta-inf and system.img files with 7zip. I also checked to be sure that the block to be flashed was correct, it is the same (even though my img is for MM). I tried flashing with TWRP, I immediately get an error code 6.
What should I do?
Just off the subject slightly...but Eliminater74 already has a flashable zip (thought TWRP) for the 20J release. Its a 2 Part System.
Eliminator74's zip is modified. I want to take a 100% pure stock system.img (extracted from stock firmware) and put it into a zip that can be flashed in TWRP. When I say stock, that's what I mean. No root, no Xposed, no BusyBox, nothing. This has already been done for Lollipop on the v10, but I have MM. I have already explained why I want to do this. I'm currently looking into whether Superr's Kitchen can accomplish this.
He has a Fully Stock 20J release..just gotta read the thread..
AnonVendetta said:
I have a system.img file, which I extracted from a 20J KDZ. I would now like to convert it into a flashable zip. I have 2 reasons for this. One, I dont want to have to use LGUP to revert my phone to a 100% stock system. It is much easier to just flash a zip of the system partition. Two, I would like to get into modding and ROM development. I believe that it is best to start from pure stock and make changes from there, instead of basing your work off of something that someone else has already modded.
I found these threads but they're a bit old (Lollipop):
1. http://forum.xda-developers.com/lg-v10/development/lg-h901-stock-img-files-boot-recovery-t3238638
2. http://forum.xda-developers.com/tmobile-lg-v10/development/lg-h901-stock-images-device-restore-t3241170
In one of them a member provided img's for recovery, boot, and system. In the other thread flashable zips of these img's were posted. These are for the Tmo v10. So it's not a matter of whether it can be done, but how. What tools are needed?
I downloaded the zip from one of the aforementioned threads, deleted the boot.img, replaced his system.img with mine, edited updater-script, and zipped up the meta-inf and system.img files with 7zip. I also checked to be sure that the block to be flashed was correct, it is the same (even though my img is for MM). I tried flashing with TWRP, I immediately get an error code 6.
What should I do?
Click to expand...
Click to collapse
What tool did you use to extract the KDZ? I am trying to get a stock boot.img for the H901J build and I cannot seem to find it. I used the WindowsLGFirmwareExtract 1.2.5.0 release and all I see are a ton of .bin files and system.img. Is boot.img inside system.img?
@Sippi4x4man: I also used WindowsLGFirmwareExtract. Inside the KDZ there is a DZ and DLL file. Just extract the DZ, then you see lots of BINs. The system.img is split up (since it's around 4GB alone), but the tool can combine the pieces into one file. I was able to figure out how to manually flash the IMG, by running a dd command with TWRP's terminal emulator.
dd if=/external_sd/system.img of=/dev/block/platform/f9824900.sdhci/by-name/system
It takes a few minutes to finish, followed by a message that says no more space is available (I guess /system got filled up). I think when you dd anything you are copying both free and used space, since an IMG is usually just a (sometimes raw) disk image. TWRP will also initially say that no system is installed, I just ignored it, the device boots fine, everything is pure stock, no issues at all. System is mountable after subsequent boots into recovery. I used Magisk and the phh Superuser Magisk module to gain root without modding system partition, and the Magisk version of Xposed. But I would still like to create a flashable zip to automate this. If I figure it out I don't mind uploading it so the community can benefit.
As for the stock boot.img, I would imagine that the boot.bin inside the DZ is probably what you're after. The file size seems about right. However, I tried renaming boot.bin to boot.img and flashing from TWRP. Device wouldn't boot. So maybe there is some other conversion process that needs to be done. I can't think of any other way to obtain a pure stock boot image, extracting it from stock firmware seems like a sure way. If you ever figure it out then please provide a copy. Make sure it isn't patched by SuperSU, Xposed, Magisk, etc. I could maybe merge it into a stock zip.
AnonVendetta said:
@Sippi4x4man: I also used WindowsLGFirmwareExtract. Inside the KDZ there is a DZ and DLL file. Just extract the DZ, then you see lots of BINs. The system.img is split up (since it's around 4GB alone), but the tool can combine the pieces into one file. I was able to figure out how to manually flash the IMG, by running a dd command with TWRP's terminal emulator.
dd if=/external_sd/system.img of=/dev/block/platform/f9824900.sdhci/by-name/system
It takes a few minutes to finish, followed by a message that says no more space is available (I guess /system got filled up). I think when you dd anything you are copying both free and used space, since an IMG is usually just a (sometimes raw) disk image. TWRP will also initially say that no system is installed, I just ignored it, the device boots fine, everything is pure stock, no issues at all. System is mountable after subsequent boots into recovery. I used Magisk and the phh Superuser Magisk module to gain root without modding system partition, and the Magisk version of Xposed. But I would still like to create a flashable zip to automate this. If I figure it out I don't mind uploading it so the community can benefit.
As for the stock boot.img, I would imagine that the boot.bin inside the DZ is probably what you're after. The file size seems about right. However, I tried renaming boot.bin to boot.img and flashing from TWRP. Device wouldn't boot. So maybe there is some other conversion process that needs to be done. I can't think of any other way to obtain a pure stock boot image, extracting it from stock firmware seems like a sure way. If you ever figure it out then please provide a copy. Make sure it isn't patched by SuperSU, Xposed, Magisk, etc. I could maybe merge it into a stock zip.
Click to expand...
Click to collapse
It's been a while from this post... But I'm looking after the same goal you were and got the same error 6 trying the same things you described in your previous posts. Despite of these long 4 years, let me try: did you finally achieve to make the flashable zip with system.img?
I do not own an LG V10 anymore.....it is the most garbage phone I've ever had.
I now use SuperR's Kitchen to create flashable zip from system.img. Works like a charm every time. Downside is that you need a PC to use it. It works for all phones (but you must also have an unlocked bootloader and custom recovery, or you will not be able to flash the zip). There are both free and donate versions, both will work fine.
AnonVendetta said:
I do not own an LG V10 anymore.....it is the most garbage phone I've ever had.
I now use SuperR's Kitchen to create flashable zip from system.img. Works like a charm every time. Downside is that you need a PC to use it. It works for all phones (but you must also have an unlocked bootloader and custom recovery, or you will not be able to flash the zip). There are both free and donate versions, both will work fine.
Click to expand...
Click to collapse
Thank you for your reply. My device is Lenovo Z6 Pro but I thought this wouldn't make a difference.
Just to be sure, what you get with SuperR's Kitchen is a zip including system.img file and not the /system folder, right? Thank you in advance.
Edit: I had tried with other kitchen softwares with no success but SuperR's Kitchen did the job as you said, like a charm. Tons of thanks.
@descarao81: No, SuperR's Kitchen does not include system.img/boot.img, you must provide them yourself. They are device-specific. And system.img is a very large file, so it cannot reasonably be included in the Kitchen zip.
Yeah, maybe I wasn't clear, I meant if the resultant zip would include those raw image files being the original image files provided by the user. It's clear now. Thank you.
Here is how to do it...
1. Go to:
https://forum.xda-developers.com/tm.../lg-h901-stock-images-device-restore-t3241170
Download from the link he provided.
2. Extract the .zip file that you downloaded.
3. Make a new folder called "rom"
4. Copy the META-INF folder from the folder you extracted and place it into the "rom" folder.
5. Download any other flashable rom for your device. Extract it.
6. Go to {EXTRACTED_FLASHABLE_ROM}\META-INF\com\google\android\update-binary in your flashable extracted rom folder. Copy the "update-binary" . Got to the "rom" folder and go to META-INF\com\google\android. Delete the update-binary there and replace it with the one you have copied.
7. Now copy the boot.img from the other rom that is for your device. And place it into the "rom" folder.
8. Now Finally Compress the all the files.
9. Now you will have a flashable system.img.
10. Go to TWRP and flash the .zip that you have just made!
Upytry2 said:
Here is how to do it...
1. Go to:
https://forum.xda-developers.com/tm.../lg-h901-stock-images-device-restore-t3241170
Download from the link he provided.
2. Extract the .zip file that you downloaded.
3. Make a new folder called "rom"
4. Copy the META-INF folder from the folder you extracted and place it into the "rom" folder.
5. Download any other flashable rom for your device. Extract it.
6. Go to {EXTRACTED_FLASHABLE_ROM}\META-INF\com\google\android\update-binary in your flashable extracted rom folder. Copy the "update-binary" . Got to the "rom" folder and go to META-INF\com\google\android. Delete the update-binary there and replace it with the one you have copied.
7. Now copy the boot.img from the other rom that is for your device. And place it into the "rom" folder.
8. Now Finally Compress the all the files.
9. Now you will have a flashable system.img.
10. Go to TWRP and flash the .zip that you have just made!
Click to expand...
Click to collapse
Trying that exactly when im home! Thank you!
Haven't seen anyone else discussing this particular solution yet so figured I'd share that we can boot multiple roms using dual boot patcher by @chenxiaolong.
*The only things I'd recommend are the following:
*MAKING A BACKUP FIRST IN RECOVERY. Especially if you've never used the app, this helps in case you misunderstood something or didn't read enough or didn't think enough or the dog ate your homework.
*I recommend using TWRP version 3.0.3-0 which can be found here - https://dl.twrp.me/angler/
* I have not tried this with f2fs only ext4 so naturally I'd only recommend using ext4 partitioning on your device.
* If your device is encrypted in any way booting multiple roms will not work, which should be obvious but I'll state that anyways. Thanks @JKforUA for helping us figure this out.
*If you want to boot more than just two roms, that you use the data slot options for your roms which can be named anything you'd like and they will be stored on the phones internal storage.
* Make sure you're on the latest Radio and Bootloader for the nexus 6p, I flashed this and it works fine and is backwards compatible with Marshmallow roms.
Radio & Bootloader link -
https://forum.xda-developers.com/nexus-6p/general/nexus-6p-radio-bootloader-recovery-t3433637
* Use the patcher app to update the ramdisk and set your primary rom's kernel as Primary before patching or flashing anything.
*If you use the fingerprint scanner you'll have to delete the file /data/system/locksettings.db in each multi boot directory, this disables getting an incorrect pin error when switching roms.
*If using a marshmallow and nougat rom you'll need to flash the appropriate vendor image in recovery before boot.
*Vendor images should not be patched.
This process is fairly simple to me because I've been using it for years but if you have any questions feel free to ask in this thread and hit thanks if I helped ya.
* Before reporting errors I would suggest you try the following steps-
1. Make sure you're using this version of the patcher app because it is the one I have been using without issue -
Version 9.1.0r80-
https://dbp.noobdev.io/files/9.1.0....atcherAndroid-9.1.0.r80.gd5920b2-snapshot.apk
2. Make sure you have enough free space to have two of the zips you want to use because that is what you will have after you patch.
3. Make sure your path to the zip is correct when browsing for the zip, go through internal storage to the directory where the zip is.
4. If you get any error patching, uninstall the patcher app, re-download it, and reinstall it.
5. There is also a Windows version you can try if you prefer.
*If you are still having issues we can discuss it here, and if nobody can seem to come up with a fix in this thread then errors can further be reported by following instructions here - https://dbp.noobdev.io/downloads/
Credits - @chenxiaolong for the patcher app!
Links :
Dual boot patcher (All versions) - https://dbp.noobdev.io
Original forum - https://forum.xda-developers.com/showthread.php?t=2447534
* Screen shots of my current setup attached below for additional guidance if desired.
Status - sharing, using, in some cases testing, always learning (^_-)...
Thanks for sharing, I've never heard of this before. A few questions;
How similar/dissimilar to multirom is this?
Do I need a specific kernel, or will it with with any kernel?
I briefly read through the original thread, am I creating a zip that flashes two Roms, or is the zip something that flashes alongside the ROM I currently have?
Thanks for sharing. Used this on my further G4. Didn't know that our device is supported. So no need to wait until multirom is working on 7.1.1. Gonna play around now.
Where do we report errors? I was about to patch several files and the app crashed. I have a couple log files.
DaringDomino3s said:
Thanks for sharing, I've never heard of this before. A few questions;
How similar/dissimilar to multirom is this?
Do I need a specific kernel, or will it with with any kernel?
I briefly read through the original thread, am I creating a zip that flashes two Roms, or is the zip something that flashes alongside the ROM I currently have?
Click to expand...
Click to collapse
I actually prefer it because it's what I'm used to, you can patch whatever kernel you choose and flash it in recovery, reboot into that rom, open the patcher app, set kernel, profit.
Basically you patch the rom zip you want to flash as secondary, or in my case data slot, naming them 2 and 3 because the Multislot options won't flash anything for me but using data slots works fine. Patch rom, patch gapps, patch whatever kernel, flash all in the whatever succession recommended by the rom op, and you'll automatically boot into the newly flashed rom when you reboot.
OmegaBlaze said:
Where do we report errors? I was about to patch several files and the app crashed. I have a couple log files.
Click to expand...
Click to collapse
Hmmm I found this
https://forum.xda-developers.com/showpost.php?p=64727670&postcount=8259
I would try re-downloading the app because I haven't had it crash in any roms I've used yet, I just grabbed the latest build, installed, opened, granted root when prompted, updated the ramdisk if needed which is indicated the app, rebooted when prompted, set kernel, and done.
If it's still crashing for you there's the usual force closing the app from your roms settings and clearing the apps cache and data but you probably already tried that?
t83wood said:
I actually prefer it because it's what I'm used to, you can patch whatever kernel you choose and flash it in recovery, reboot into that rom, open the patcher app, set kernel, profit.
Basically you patch the rom zip you want to flash as secondary, or in my case data slot, naming them 2 and 3 because the Multislot options won't flash anything for me but using data slots works fine. Patch rom, patch gapps, patch whatever kernel, flash all in the whatever succession recommended by the rom op, and you'll automatically boot into the newly flashed rom when you reboot.
Click to expand...
Click to collapse
I'm gonna play with this over the weekend, I like new stuff!
So whatever fkashable zip I patch will be designated during the flash as secondary (or whatever) and won't overwrite my current ROM allowing it to exist along side it?
DaringDomino3s said:
I'm gonna play with this over the weekend, I like new stuff!
So whatever fkashable zip I patch will be designated during the flash as secondary (or whatever) and won't overwrite my current ROM allowing it to exist along side it?
Click to expand...
Click to collapse
Correct, so long as you don't patch it as Primary. It will tell you where it's flashing to in recovery. You can also use the dual boot patcher recovery zip for things like switching roms from recovery and wiping roms, wiping multiboot files will get rid of a rom in its entirety if you wanted to replace it with something else. I've always installed the patcher app in my other roms after first boot and used it to set the kernel for that rom too.
t83wood said:
Correct, so long as you don't patch it as Primary. It will tell you where it's flashing to in recovery. You can also use the dual boot patcher recovery zip for things like switching roms from recovery and wiping roms, wiping multiboot files will get rid of a rom in its entirety if you wanted to replace it with something else. I've always installed the patcher app in my other roms after first boot and used it to set the kernel for that rom too.
Click to expand...
Click to collapse
If I'm patching for the data partition, am I correct in making all zips (ROM, Gapps, and su) to the same name? (Ex. I named the ROM zip slot "rom2", and then used the same name for the other zips)
DaringDomino3s said:
If I'm patching for the data partition, am I correct in making all zips (ROM, Gapps, and su) to the same name? (Ex. I named the ROM zip slot "rom2", and then used the same name for the other zips)
Click to expand...
Click to collapse
Yep looks good!
t83wood said:
Yep looks good!
Click to expand...
Click to collapse
Awesome, thanks, I'll see what happens :good:
Edit: it worked! It's a little more involved than multirom, but it seems to be fine! Easier than I thought.
I've not yet switched between the two, but the app on the secondary (data slot) recognizes the primary
Wow great. Running great on data-slot. Even magisk is supported. Good to have a new playground. Happy to have the 128 GB variant. Gonna do some test with Viper.
How do I switch roms
All perfect. Viper running with magisk. Every rom i tried booting without any problem. So atm the perfect tool to test other rom!
---------- Post added at 11:45 AM ---------- Previous post was at 11:43 AM ----------
DEVILOPS 007 said:
How do I switch roms
Click to expand...
Click to collapse
Install dualpatcher app and choose rom in 'ROMs'. Then reboot. Or run utulities in twrp (install).
What do I do? It says failed error code - 1 tried doing cortex rom and selecting data. Is there something I need to do?
DEVILOPS 007 said:
What do I do? It says failed error code - 1 tried doing cortex rom and selecting data. Is there something I need to do?
Click to expand...
Click to collapse
Cortex also flashes the vendor. Maybe this gives the error because in dualboot all roms use the same vendor partition (could be a problem to flash vendor through dualpatcher...). All other roms i tried vendor was not included to flash (only rom und gapps separately). I am just trying cortex too (just ready to flash). Gonna report, if i succeed.
Donric13 said:
Cortex also flashes the vendor. Maybe this gives the error because in dualboot all roms use the same vendor partition (could be a problem to flash vendor through dualpatcher...). All other roms i tried vendor was not included to flash (only rom und gapps separately). I am just trying cortex too (just ready to flash). Gonna report, if i succeed.
Click to expand...
Click to collapse
Okay thanks Bro, I might try out lineage. Also open gaps failed for me bit do I need the rom first or do I need to use dynamic gaps? I appreciate the help!
DEVILOPS 007 said:
What do I do? It says failed error code - 1 tried doing cortex rom and selecting data. Is there something I need to do?
Click to expand...
Click to collapse
Cortex rom running fine on multiboot on my device. So no problem with vendor in multiboot. I can also switch back to another rom. As gapps i suggest you to use only dynamic gapps (banks gapps). I always use mini dynamic gapps. Opengapps give many problems.... On primary i got rr oms-release from 12.01. ATM running with 3 different rom all on internal sd card. Just pay attention to give always the same name when patching a zip file in dualpatcher.
Donric13 said:
Cortex rom running fine on multiboot on my device. So no problem with vendor in multiboot. I can also switch back to another rom. As gapps i suggest you to use only dynamic gapps (banks gapps). I always use mini dynamic gapps. Opengapps give many problems.... On primary i got rr oms-release from 12.01. ATM running with 3 different rom all on internal sd card. Just pay attention to give always the same name when patching a zip file in dualpatcher.
Click to expand...
Click to collapse
What do you mean by same name? I am on pimps rr oms and whenever I flash any rom it says error code - 1. Any idea what I can do?
DEVILOPS 007 said:
What do you mean by same name? I am on pimps rr oms and whenever I flash any rom it says error code - 1. Any idea what I can do?
Click to expand...
Click to collapse
Did you flash in twrp (3.0.3.0)? I only use twrp to flash a new multiboot rom. Before flashing a new rom just make sure, you patch all necessary zip files (rom, gapps, etc.). Same name means u choose where (on angler i always choose Data slot - this is internal sd card). Then you give the name (no capital letters) and choose the directory to save the patched file. This you do with every zip file for the rom u gonna flash. The new zip file have the original name and the text "....._data-slot-namegiven.zip" (example for data-slot). The part "data-slot-namegiven" should appeir in every name of the patched zip file. I think with our device it's goot to use the data-slot if you have enough space on your internal sd-card. Using Multi Slot could lead to space problems on system partition of the device. Then just flash the patched files one after another in twrp. Don't forget to flash also patched supersu.zip oder magisk.zip to get root (if it's not in the rom included). You need to patch gapps and supersu or magisk for each slot separately. The name of the patched file just says the path for the multiboot rom. So twrp flashes the patched zip to the right place. Sorry if i wrote to much. Hope it's gonna give you some help. More information you find in the original thread of multiboot.