I'm trying to get my own ROM working, and it currently locks up in the middle of booting. Here's logcat (had to use pastebin):
http://pastebin.com/SwFCJzDH
dementio said:
I'm trying to get my own ROM working, and it currently locks up in the middle of booting. Here's logcat (had to use pastebin):
http://pastebin.com/SwFCJzDH
Click to expand...
Click to collapse
there are a few things which fail during your boot up process. the only major issue I see is the signature mismatch. this seems to prevent the system from loading a required apk file which later on is the source of the crash .. at least that is my guess.
once you wipe the settings file in the /data partition which stores the signatures of each .apk file, they should process correctly. i think the exact file is /data/system/packages.xml which stores signatures for .apk files.
it is really hard to say with 100% confidence no information is provided as to what you've changed to get your "own ROM", but I would start by working on the signature mismatch issues.
hope that helps!
Related
Does anyone know how to fix a e:/tmp/sideload has perms 40755 issue?
I was flashing a rom and got stuck there.
Any help will be appreciated.
Thank you!
Whenever I used to get that I'd pull battery do a full wipe and try again. Later I flashed my recovery again and the problem has stopped entirely. I flash ROMs as much as 5 times a day (on a good day).
proxhack said:
Does anyone know how to fix a e:/tmp/sideload has perms 40755 issue?
I was flashing a rom and got stuck there.
Any help will be appreciated.
Thank you!
Click to expand...
Click to collapse
I haven't seen this error come up before on the q&a board, but I very well could have missed it.
The recovery outputs the details around the error in a /tmp/recovery.log file. Once the error occurs, its best to check this file, /tmp/recovery.log for the details around the error. In order to really troubleshot the specific issue, we'd need a copy of the /tmp/recovery.log and the .zip file being loaded.
Sorry that doesn't directly answer the question, but it will lead to the best technical solution possible! Hope that helps provide some light around recovery .zip flashing troubleshooting!
I just got this trying to install sick sense rom. There is no log file in tmp/
MikeC84 said:
I just got this trying to install sick sense rom. There is no log file in tmp/
Click to expand...
Click to collapse
whenever the recovery first boots, it will create a log file in /tmp/recovery.log. this file will get wiped on reboot. the best time to pull and examine the /tmp/recovery.log file is right after the recovery throws the installing error.
if, for some odd reason, there is a recovery.log in /tmp, you can also try checking /cache/recovery.log.
if you can post the file contents up we can help troubleshoot!
i know i've seen people post back, after attempting to flash 2-3 times the error would disappear. i also know i've seen people post that re-flashing the custom recovery, or flashing an updated version helps clear the issue.
hope that helps!
I had this problem too after trying to flash Viper-Rom RC2 version 4. The problem did not occur during the first installation, but after realizing I forgot to format the data partition, and going back and formatting everything and trying the install again, I had the perms 40755 issue. It appears that having a rom that tweaks the file system and permissions will cause this issue on occasion. After pulling the battery like triscuit suggested, it worked just fine. Unfortunately I scoured the entire phone for a recovery.log file and it was nowhere to be found. We may not have a technical reasoning for this issue exactly, but triscuit's workaround appears to take care of the problem.
This thread will be a compilation of findings and references along the way as we make attempts to modify and hack our Nook Tablets. If you would like to add anything, please post it and I can compile into the OP posts. This is beyond rooting and bootloader bypass/bootstrap (for the most part), there are separate threads for those.
This will be for posting what certain files are found to do or involve, and which files to STAY AWAY FROM to prevent bootloops and forced recovery, and other findings that will help others to avoid issues or save time by learning from our discoveries. As we get CWM and the ability to replace entire ROMs, some of those risks will go away.
We are the Pioneers of the Nook Tablet, lets document our findings to keep track of them and to help others who will be making the NT an even better tablet.
Again, this is not to duplicate what is going on in the Dev Progress threads, but to help compile all of the scattered findings to compliment those threads.
System Recovery (Factory Restore):
There has been some question about the factory restore as to whether it just wipes data or does a complete /system restore as well.
There are two different modes of restore that can kick in, if you bork the system files or need to force a complete restore, you can do so.
Data only wipe:
The fastest and best way to get to this is to hold down the "n" button while powering on the tablet. This will wipe your side loaded or installed apps as well. If something gets messed up on your tablet and is forced into a recovery, this is the default recovery that will kick in after about 8 failed boot attempts.
Full system restore:
If your tablet continues to have failed boots after initiating the data wipe restore, it will force into a complete restore without even asking. First it will do the data wipe like normal, followed by a restore of factory software. Once done, your Nook Tablet will be restored to the way it was the first time you powered it on.
I have been able to force the full restore by powering off repeatedly during the data wipe. Once you see the restore kick in without giving the usual prompt to hit "n" or home to continue, just let it run and the complete restore will run.
Partition Files and Information:
"Factory" partition, this is where the factory restore pulls the files from (ROM, etc)
/dev/block/platform/mmci-omap-hs.1/mmcblk0p7 or /dev/block/platform/mmci-omap-hs.1/by-name/factory
DOWNLOAD ZIP FILE OF FACTORY PARTITION FILES HERE - There appears to be a Recovery image and boot image in this as well
I did try to alter the factory.zip rom file by not disturbing it's signature. I then mounted the factory partition and added the modded factory.zip
I forced a full restore but about 1/4 of the way into the factory software restore it aborted and told me to reboot. It did not install the modded rom files. So it checks beyond just the signature on the rom file, maybe md5 checks.
Working on other partitions and will add those as done....
Recovery Partition
/dev/block/platform/mmci-omap-hs.1/mmcblk0p3 or /dev/block/platform/mmci-omap-hs.1/by-name/recovery
Boot Partition
/dev/block/platform/mmci-omap-hs.1/mmcblk0p4 or /dev/block/platform/mmci-omap-hs.1/by-name/boot
Reserved.....
In trying to add new library files to /system/lib, I will get FC errors when testing changes and in reviewing the logcat, it is as if the files does not exist. The error will say the lib file is not found. Permissions are correct, and a full reboot has been done as well. I ran into a similar problem where an FC error was looking for a java class, and when the APK was decompiled, it was right there in the location it was suppoed to be.
I found a file, /system/manifest that has a list of the libs and framework files, along with a long code. Does anyone know what this is? It appears the ROM has a manifest of what is supposed to be in place, and if it falls outside of that it gets ignored. Editing this manaifest could be a critical piece at this point in doing some serious modifications.
There are also a couple of manifest files in the root (/) path as well.
Anyone familiar with this and can expand further?
Here is a few lines from the Manifest files.
/system/lib/libstagefright.so:99208dff1b94c6955e72abdfc8bc70fc020a113a
/system/lib/libsqlite_jni.so:df4a43e08d9a2c02aaed47ccbecba6be3d4b3e33
/system/lib/libsmapi.so:6c4761d3bbc3c18fa11d1d59ea7ae295d0874752
/system/lib/libsensorservice.so:654b3d705b4220441d819f337eef201d979a0003
/system/framework/com.bn.service.devicemanager.jar:144dfb6833f4ddf52bdd4f5cabf163aaf4724252
/system/framework/com.bn.app.deviceinfo.jar:9256951bbfe5126e54dade8d5ef3878ae0a05f20
/system/framework/services.jar:51c05355e9165b5683f0b40106e70fdfd7be41aa
/system/framework/pm.jar:0bc6fe41c40dc6205bac73443d0c771d9fa718e5
/system/framework/framework.jar:0f5b44a0c264061c5ba6efb9f04112fe752dea38
/system/lib/libstdc++.so:bd50887222d9a03ed683bcc94525b32b1405c0a7
I'd guess that's the MD5 sum of each file. Perhaps file integrity is confirmed by calculatung the current sum and comparing it to the stored value in this file. Any files you update in your image, consider calculating the new checksum and putting it here next to the right file?
Sent from my BNTV250 using Tapatalk
t-r-i-c-k said:
I'd guess that's the MD5 sum of each file. Perhaps file integrity is confirmed by calculatung the current sum and comparing it to the stored value in this file. Any files you update in your image, consider calculating the new checksum and putting it here next to the right file?
Sent from my BNTV250 using Tapatalk
Click to expand...
Click to collapse
That is what I was thinking, and hoping but wanted to confirm. Thanks !
Used dsixdas Rom kitchen.
Built my own Rom using rogers stock RUU
starts to flash, then I get, error in sd card installation aborted
(status 0)
the last thing it was doing
minzip: extracted file "system/cuE:Error in /sdcard/marksrom
any takers??!!
Thanks guys
markdexter said:
Used dsixdas Rom kitchen.
Built my own Rom using rogers stock RUU
starts to flash, then I get, error in sd card installation aborted
(status 0)
the last thing it was doing
minzip: extracted file "system/cuE:Error in /sdcard/marksrom
any takers??!!
Thanks guys
Click to expand...
Click to collapse
What type of zip file is it?
its just the one that dsxidas tool spits out, although I did notice some differences.
If i click on the Rom.zip file, go to properties, then security. The only 2 that where check-marked was "modify" and "read & execute" So i compared that to a Rom that works on my device and noticed that in that same box they where all checked. - full control
modify
Read & execute
Read
Write
Special permissions
I changed those in my Rom so there all checked,however cant flash till tonight.
Just wondering if that could possibly be an, or the, issue
Not sure how to check what type of .zip file it is??
markdexter said:
Used dsixdas Rom kitchen.
Built my own Rom using rogers stock RUU
starts to flash, then I get, error in sd card installation aborted
(status 0)
the last thing it was doing
minzip: extracted file "system/cuE:Error in /sdcard/marksrom
any takers??!!
Thanks guys
Click to expand...
Click to collapse
markdexter said:
its just the one that dsxidas tool spits out, although I did notice some differences.
If i click on the Rom.zip file, go to properties, then security. The only 2 that where check-marked was "modify" and "read & execute" So i compared that to a Rom that works on my device and noticed that in that same box they where all checked. - full control
modify
Read & execute
Read
Write
Special permissions
I changed those in my Rom so there all checked,however cant flash till tonight.
Just wondering if that could possibly be an, or the, issue
Not sure how to check what type of .zip file it is??
Click to expand...
Click to collapse
Lol .. the "check boxes" you're referring to only indicate the access permissions for the specific .zip file. When in recovery mode, everything runs as root. If there is any read permission on the file, recovery should be able to acces it without any issues. Further, you mentioned above the recovery was in the process of flashing the file indicating the recovery has no issues accessing the file.
If the recovery has no issues accessing the file, there shouldn't be any issues with the specific permissions of the ROM .zip file on that specific file system in recovery mode.
As a ROM developer, the next step to troubleshooting and understanding errors when flashing a ROM is by becoming familiar with the custom recovery error log.
The custom recovery shows very limited information on the display, but in the log shows much more detail. The logs are generally kept at /tmp/recovery.log and /cache/recovery.log.
The best process is to process the .zip file and when the recovery errors, open up the recovery log. If you can paste back here the few lines before the error occurred including the error we can start working on the issue.
We might need a copy of the .zip file to match up with the recovery log to understand how much progress was made in order before the error occured.
The only other common place for ROM flashing errors when developing a ROM will be in the updater-script file. Might need a copy of this posted also.
In summary, the two most common places for issues occur either in the file name/structure of the .zip or in the updater-script.
Hope that helps! Good luck!
joeykrim said:
Lol .. the "check boxes" you're referring to only indicate the access permissions for the specific .zip file. When in recovery mode, everything runs as root. If there is any read permission on the file, recovery should be able to acces it without any issues. Further, you mentioned above the recovery was in the process of flashing the file indicating the recovery has no issues accessing the file.
If the recovery has no issues accessing the file, there shouldn't be any issues with the specific permissions of the ROM .zip file on that specific file system in recovery mode.
As a ROM developer, the next step to troubleshooting and understanding errors when flashing a ROM is by becoming familiar with the custom recovery error log.
The custom recovery shows very limited information on the display, but in the log shows much more detail. The logs are generally kept at /tmp/recovery.log and /cache/recovery.log.
The best process is to process the .zip file and when the recovery errors, open up the recovery log. If you can paste back here the few lines before the error occurred including the error we can start working on the issue.
We might need a copy of the .zip file to match up with the recovery log to understand how much progress was made in order before the error occured.
The only common place for ROM flashing errors when developing a ROM will be in the updater-script file. Might need a copy of this posted also.
In summary, the two most common places for issues occur either in the file name/structure of the .zip or in the updater-script.
Hope that helps! Good luck!
Click to expand...
Click to collapse
Amazing answer, thank you so much for taking your time with me, appreciate it, I'll try the recovery log, see what I get, as you can tell I'm pretty new to this, everyone has to start somewhere!
Thanks again buddy
Sent from my HTC EVO 3D X515a using xda premium
A little background first. Flashed stock recovery and my original first backup in order to take OTA for Marshmallow. OTA wouldn't take so I downloaded / installed MM update successfully. Currently at 6.0, 3.38.502.12. Then, re-unlocked bootloader (S-ON) and flashed TWRP 3.0.2.0. I then immediately created a full backup successfully before rooting.
Since that point, I've been unable to create another backup. I've also had countless problems trying to flash anything at all like custom ROMs and such. Keep having to revert to my unrooted backup post-MM update. The problem had to occur somewhere after my first successful TWRP backup post-MM update and now. Puzzling part is that I restored this same successful backup then without leaving TWRP, I immediately tried to do another backup and it fails the exact same way.
Recovery.log shows:
* MD5 Created.
Backing up System...
Error opening: '/system/app/Ds' (Not a directory)
I:Error in Generate_TarList!
Error creating backup.
createTarFork() process ended with ERROR: 255
Backup Failed. Cleaning Backup Folder.
I've tracked this down and it does indeed appear to be a directory "Ds". Inside as a sub-directory called 'oat' with Ds.apk inside of that, which is the Dolby Audio service.
I'm completly stumped. Any ideas?
Update, in the /system/app/ (list of apps) it looks like there is an oat subdirectory followed by arm64 then filename.odex:
/system/app/BasicDreams/oat/arm64/BasicDreams.odex
However, when I browse to the problem app "Ds"... oat does not appear as a directory.
This could be a simple fix then?? Coudn't I just obtain root again, somehow change that oat to a directory and hope I see the rest of the subdirectories and files there?
OR... could I find Ds.odex somewhere and re-create the file structure?
Better yet! Would someone out there be able to give me or post a link for Ds.odex? Would it be as easy as me making a sub-directory called oat/arm64 and placing this Ds.odex file in there??
Any help would be much appreciated.
sirvalence said:
Update, in the /system/app/ (list of apps) it looks like there is an oat subdirectory followed by arm64 then filename.odex:
/system/app/BasicDreams/oat/arm64/BasicDreams.odex
However, when I browse to the problem app "Ds"... oat does not appear as a directory.
This could be a simple fix then?? Coudn't I just obtain root again, somehow change that oat to a directory and hope I see the rest of the subdirectories and files there?
OR... could I find Ds.odex somewhere and re-create the file structure?
Better yet! Would someone out there be able to give me or post a link for Ds.odex? Would it be as easy as me making a sub-directory called oat/arm64 and placing this Ds.odex file in there??
Any help would be much appreciated.
Click to expand...
Click to collapse
I don't have any oat directories under /system/app/(app name)/oat/ARM64/...
Only thing that is in the app directory (for me) is the .apk, and at times, a lib subdirectory (webviewgoogle is like that, which has an arm and arm64 directory under that).
I'm running VenomRom which may handle this differently.. it's prerooted and whatnot.
I also disabled boomsound which I think also disabled the Dolby sound system app from running. Viper is better [emoji2]
Id back up your internal storage again, ruu, flash twrp 3.0.0-2, boot into recovery, let it make system writable, reboot into recovery again, and see what happens.
Or flash a pre-rooted sense rom instead of stock.
I honestly couldn't get this stupid AT&T varient working correctly until I s-off'd, updated Sid to developer, then run dev ruu. Works great now.
Sent from my HTC One M9 using XDA-Developers mobile app
grandpajiver said:
I don't have any oat directories under /system/app/(app name)/oat/ARM64/...
Only thing that is in the app directory (for me) is the .apk, and at times, a lib subdirectory (webviewgoogle is like that, which has an arm and arm64 directory under that).
I'm running VenomRom which may handle this differently.. it's prerooted and whatnot.
I also disabled boomsound which I think also disabled the Dolby sound system app from running. Viper is better [emoji2]
Id back up your internal storage again, ruu, flash twrp 3.0.0-2, boot into recovery, let it make system writable, reboot into recovery again, and see what happens.
Or flash a pre-rooted sense rom instead of stock.
I honestly couldn't get this stupid AT&T varient working correctly until I s-off'd, updated Sid to developer, then run dev ruu. Works great now.
Sent from my HTC One M9 using XDA-Developers mobile app
Click to expand...
Click to collapse
Thanks, yeah I'm having nothing but trouble since moving to MM. Each time, I can RUU back to stock ATT US and everything is fine. Not sure if it happens during my first TWRP pre-root backup, or the restore process. I looked at the recovery.log of said backup and nothing looked different regarding the /system/apps. I've since tried a few times and it just seems to throw a few /system/apps into another directory altogether, no rhyme or reason. Last try, there wasn't even a Ds directory as it disappeared. A Ds 0 byte file then appeared at /system level. This happened with 10 or so other random system apps. WEIRD! Maybe I should just S-OFF. I've never done that or changed my MID or SID for that matter. I'm still fairly new to this.
sirvalence said:
Thanks, yeah I'm having nothing but trouble since moving to MM. Each time, I can RUU back to stock ATT US and everything is fine. Not sure if it happens during my first TWRP pre-root backup, or the restore process. I looked at the recovery.log of said backup and nothing looked different regarding the /system/apps. I've since tried a few times and it just seems to throw a few /system/apps into another directory altogether, no rhyme or reason. Last try, there wasn't even a Ds directory as it disappeared. A Ds 0 byte file then appeared at /system level. This happened with 10 or so other random system apps. WEIRD! Maybe I should just S-OFF. I've never done that or changed my MID or SID for that matter. I'm still fairly new to this.
Click to expand...
Click to collapse
So worth the 25 dollars. But you need your system up and rooted for that to work.
But yeah, the dev edition SID 01 worked for me.
Made it way easier to work with and taking that ruu was magic.
Oh, also, do you have an sdcard? There is always the rom.zip method... placing the appropriate 0PJAIMG.ZIP in the root of the sdcard then rebooting into download mode works nicely.
Sent from my HTC One M9 using XDA-Developers mobile app
I guess I'm a moron and can't figure this out :v
Using stock rooted Oreo, Magisk, edXposed, everything that goes with them. TWRP 3.2.3-7.
Lately, I've been using my headphones while driving to work. I need a touch more volume over stock to deal with wind noise.
The problem is, I absolutely can't get /system/vendor/etc into a writable state.
Attempts to modify mixer_paths_tavil.xml whilst booted up fail, either resulting in an unreadable file (Total Commander) or just not working (Root Explorer).
Trying to flash a modified zip (just grabbed a dual-speaker mod and replaced the xml) in TWRP results in no file being created; it doesn't seem to throw an error, just silently fails.
Manually copying the xml to /system/vendor/etc using TWRP's file manager ~appears~ to work, but attempts to set permissions results in error code 1. The file doesn't exist upon reboot.
Remounting manually as RW in TWRP's terminal doesn't seem to help. And yes, "mount System as read-only" is unchecked.
I can make build.prop changes, so I know /system is writable. The only way I can get anything written to /system/vendor/etc is restoring a full system backup.
I've modified this file before; I manually tweaked the call volume higher and enabled "fake" high-impedance mode.
So I'm sure I'm doing something really stupid here. Help.
Septfox said:
I guess I'm a moron and can't figure this out :v
Using stock rooted Oreo, Magisk, edXposed, everything that goes with them. TWRP 3.2.3-7.
Lately, I've been using my headphones while driving to work. I need a touch more volume over stock to deal with wind noise.
The problem is, I absolutely can't get /system/vendor/etc into a writable state.
Attempts to modify mixer_paths_tavil.xml whilst booted up fail, either resulting in an unreadable file (Total Commander) or just not working (Root Explorer).
Trying to flash a modified zip (just grabbed a dual-speaker mod and replaced the xml) in TWRP results in no file being created; it doesn't seem to throw an error, just silently fails.
Manually copying the xml to /system/vendor/etc using TWRP's file manager ~appears~ to work, but attempts to set permissions results in error code 1. The file doesn't exist upon reboot.
Remounting manually as RW in TWRP's terminal doesn't seem to help. And yes, "mount System as read-only" is unchecked.
I can make build.prop changes, so I know /system is writable. The only way I can get anything written to /system/vendor/etc is restoring a full system backup.
I've modified this file before; I manually tweaked the call volume higher and enabled "fake" high-impedance mode.
So I'm sure I'm doing something really stupid here. Help.
Click to expand...
Click to collapse
Don't know, but tonight or tomorrow I'll shoot you a file to test.
ChazzMatt said:
Don't know, but tonight or tomorrow I'll shoot you a file to test.
Click to expand...
Click to collapse
Appreciated, but I think something's going pear-shaped and I just need to reflash the ROM; setting up for the drive home last night, it seems I've lost the ability to use direct output in Poweramp. I don't know how, since the system+system image backup I restored is known-good and audio is otherwise working.
Good ol' bitrot, I suppose.
Septfox said:
Appreciated, but I think something's going pear-shaped and I just need to reflash the ROM; setting up for the drive home last night, it seems I've lost the ability to use direct output in Poweramp. I don't know how, since the system+system image backup I restored is known-good and audio is otherwise working.
Good ol' bitrot, I suppose.
Click to expand...
Click to collapse
See my PM.