Database Info

[ROM] Inspire 4G Stock Rom w/Root, HSUPA, and Sideloading

Last updated 2/28/2011
This is a pure stock rom with root+hsupa+sideload.
Warning: the following steps to flash the rom will wipe your data.
- Use HTC Inspire Hack Kit or some other way to get S-off so that you can flash custom roms.
- Download the rom, rename it to PD98IMG.zip, put it to the sdcard.
- Go to Settings -> Applications, turn off fast boot and then power down the phone.
- Boot into hboot by pressing volume down + power button and flash.
After flashing you should have a pure stock rom rooted, with hsupa on, and sideloading as an option. I don't have any problem with this rom while I got superuser permission, sideloading back on and noticed a higher upload speed.
Some people report to have problem with ClockWorkMod recovery on the stock rom. You can try the suggestion from this thread.
Link for the ROM: http://www.multiupload.com/93I04ACXYU

--------------------------------
Below are the steps that I took to made this rom, you can ignore it if you are not interested into know how to cook system.img or hack a rom.
I basically added the root files to the system.img and change ro.ril.hsxpa=1 inside of the build.prop file to ro.ril.hsxpa=3 to make hsupa work, edit the customize/CID/default.xml file and change <item name="unknown_sources_visibility">false</item> to <item name="unknown_sources_visibility">true</item> to enable the sideloading option in settings, no need to flash any custom radio or kernel.
Here's how to do it:
- Download the RUU for the stock rom.
- Open the RUU you downloaded, wait for the screen that says Welcome to the Rom Update Utility to come out, but don't flash yet!
- Navigate to the temporary folder and locate rom.zip, which is a file that the installer extracted. I found it by navigating the folder with the most recent Date modified.
- Copy rom.zip to some other folder. This is the zip file which you can use on the phone to flash back to stock.
- Extract android-info.txt and system.img from rom.zip and put system.img in a place where Linux can access.
Right now for the cooking part linux is required. I used Ubuntu to do it.
Code:
sudo mkdir /mnt/system
sudo mount -o loop,norelatime /path to/system.img /mnt/system
Code:
nano /mnt/system/build.prop
update ro.ril.hsxpa to 3 to enable hsupa
You also need the root files busybox, su, and Superuser.apk, which can be found at ace-hack-kit-v002/tools/root
Code:
sudo
cp /path to root files/busybox /mnt/system/xbin/busybox
chmod 4755 /mnt/system/xbin/busybox
cp /path to root files/Superuser.apk /mnt/system/app/Superuser.apk
chmod 644 /mnt/system/app/Superuser.apk
cp /path to root files/su /mnt/system/bin/su
chmod 4755 /mnt/system/bin/su
nano /mnt/system/customize/CID/default.xml
(update <item name="unknown_sources_visibility">false</item> to <item name="unknown_sources_visibility">true</item> to enable the sideloading option in the menu.)
umount /mnt/system
Right now you have a cooked system.img
- extract all files from rom.zip, replace system.img with the one we just cooked, then put all the files back to a new zip named PD98IMG.zip.
--------------------------------

Couldn't you post your cooked PD98IMG.zip for us? Shouldn't it work for all Inspire devices if it was taken from the official RUU?

it is very big, hold down. The phone needs to be S-off first in order to flash.

angelchen1111 said:
it is very big, hold down. The phone needs to be S-off first in order to flash.
Click to expand...
Click to collapse
Yeah... but you should still be able to post it. That would be a WHOLE lot easier than every one of us making the exact same file when we could just flash the one you made. Make sense?
If you want to share, try uploading it to multiupload.com

Pre-rooted stock system.img
File name: PD98IMG.zip File size: 242.81 MB
More links
have fun

Here's the link [removed]. Revert back to stock after being S-off to flash it. Also flashing system.img seem to factory reset the phone, so back up your data inside of your phone if any before flashing.

I just tried it and it did give me root access. Upload speeds are still crappy for me. It was worth the time just for root access. Thanks!

so let me ask a question. If someone were to use temp root with say visionary, can S-off be set from there without a gold card?

angelchen1111 said:
I found a way to enable hsupa and root the phone on the stock rom by "cooking" system.img from the stock rom and flash it over after the phone has been S-off and returned to stock.
I basically added the root files to the system.img and change ro.ril.hsxpa=1 inside of the build.prop file to ro.ril.hsxpa=3 to make hsupa work, no need to flash any custom radio or kernel.
Here's how to did it (this still looks kind like rough draft, I don't know if someone can help me to edit this to make it better or if I can put it up to wiki):
- use HTC Inspire Hack Kit or some other way to get S-off so that you can flash custom roms.
- Download the RUU for the stock rom.
- Open the RUU you downloaded, wait for the screen that says Welcome to the Rom Update Utility to come out, but don't flash yet!
- Navigate to the temporary folder and locate rom.zip, which is a file that the installer extracted. I found it by navigating the folder with the most recent Date modified.
- Copy rom.zip to some other folder. This is the zip file which you can use on the phone to flash back to stock.
- After done copying rom.zip proceed with RUU to flash back to stock.
- Extract android-info.txt and system.img from rom.zip and put system.img in a place where Linux can access.
Right now for the cooking part linux is required. I used Ubuntu to do it.
Code:
sudo mkdir /mnt/system
sudo mount -o loop,norelatime /path to/system.img /mnt/system
use an editor to edit /mnt/system/build.prop and update ro.ril.hsxpa to 3 to enable hsupa
You also need the root files busybox, su, and Superuser.apk, which can be found at ace-hack-kit-v002/tools/root
Code:
sudo
cp /path to root files/busybox /mnt/system/xbin/busybox
chmod 4755 /mnt/system/xbin/busybox
cp /path to root files/Superuser.apk /mnt/system/app/Superuser.apk
chmod 644 /mnt/system/app/Superuser.apk
cp /path to root files/su /mnt/system/bin/su
chmod 4755 /mnt/system/bin/su
umount /mnt/system
Right now you have a cooked system.img
put android-info.txt and the cooked system.img to a zip named PD98IMG.zip and put it to the sd card.
boot into hboot by pressing volume down and power button and flash.
After flashing you should have a pure stock rom rooted and with hsupa on. I don't have any problem with this rom while I got superuser permission and noticed a higher upload speed.
Click to expand...
Click to collapse
The install was fine and i have not had any fc yet. the only problem that i have is that i cant install non market apps. any suggestions on how to allow restore from titanium backup?

farmercyst said:
The install was fine and i have not had any fc yet. the only problem that i have is that i cant install non market apps. any suggestions on how to allow restore from titanium backup?
Click to expand...
Click to collapse
Once it is rooted, it is trivial to enable sideloading.
Code:
adb shell
su
busybox cp /data/data/com.android.providers.settings/databases/settings.db /sdcard/settings.db
exit
exit
adb pull /sdcard/settings.db settings.db
echo update secure set value = 1 where name = 'install_non_market_apps';|sqlite3 settings.db
adb push settings.db /sdcard/settings.db
adb shell
su
busybox cp /sdcard/settings.db /data/data/com.android.providers.settings/databases/settings.db
chown system.system /data/data/com.android.providers.settings/databases/settings.db
chmod 660 /data/data/com.android.providers.settings/databases/settings.db
exit
exit
After thar reboot and you should have sideloading
if it says command not found, try to append busybox in front of the commands.

thanks a lot. stock with root and sideloading is what i have been wanting.

Guess I will be going this route in the meantime as well. Can't handle the "tinny" audio in DHD ROMs.
Sent from my Desire HD using XDA App

So with the way you have this setup as of right now, it only works with a computer running the Linux OS?
Sent from my Inspire 4G.

slapdaddy said:
So with the way you have this setup as of right now, it only works with a computer running the Linux OS?
Sent from my Inspire 4G.
Click to expand...
Click to collapse
You need Linux to open the system.img in order to cook.

angelchen1111 said:
Once it is rooted, it is trivial to enable sideloading.
Code:
adb shell
su
cp /data/data/com.android.providers.settings/databases/settings.db /sdcard/settings.db
exit
exit
adb pull /sdcard/settings.db settings.db
echo update secure set value = 1 where name = 'install_non_market_apps';|sqlite3 settings.db
adb push settings.db /sdcard/settings.db
adb shell
su
cp /sdcard/settings.db /data/data/com.android.providers.settings/databases/settings.db
chmod 666 /data/data/com.android.providers.settings/databases/settings.db
chown system.system /data/data/com.android.providers.settings/databases/settings.db
After thar reboot and you should have sideloading
if it says command not found, try to append busybox in front of the commands.
Click to expand...
Click to collapse
After "cp /data/data/com.android.providers.settings/databases/settings.db /sdcard/settings.db", I get "cp: not found".

after using this method getting everything setup I ran across one issue so far
ROM manager "clockworkmod" issue ,,when rebooting into recovery, screen freaks out white then fading to black ,wait for a while & nothing ,hit power button phone reboots like nothing happend.

How is this done with the file that I'm downloading? The "cooked" file

how do you boot into hboot?

i wish you guys would enlighten me! I guess it's hard for a noob to get any help! Maybe I should just go back to modmyi and be a snob.

[Q] ADB problem

I switched to a 2.3.3 based rom today, and now adb won't allow me to remount or push. I can pull just fine. But if I type adb remount, I get the error, "remount failed: operation not permitted."
If I boot into CWM and mount /system or /data, I can remount, push, or pull with adb with no problems. But once I boot into the rom, all I can do is pull.
I am using a rooted rom with the latest superuser and busybox.
Anyone have any ideas?

Still really needing some help with this, please.

If you type adb shell, do you get a $ or a #?
Try opening the SuperUser app on your phone then doing adb remount.
Sent from my LG-P999 using XDA App

mmapcpro said:
I switched to a 2.3.3 based rom today, and now adb won't allow me to remount or push. I can pull just fine. But if I type adb remount, I get the error, "remount failed: operation not permitted."
If I boot into CWM and mount /system or /data, I can remount, push, or pull with adb with no problems. But once I boot into the rom, all I can do is pull.
I am using a rooted rom with the latest superuser and busybox.
Anyone have any ideas?
Click to expand...
Click to collapse
Look at the default.prop file on the root of your device. I bet that there's a line that says: "ro.secure=1".
For whatever reason, the maker of your ROM set ro.secure to be on, which limits a lot of what you can do via adb. No pushing to /system, no remounting in rw mode. This is part of the boot.img file in the ROM, and is set with every reboot. Ask the maker of the ROM to set ro.secure to 0.
I had this problem with EaglesBlood Froyo until I *****ed enough that the dev changed it on the next release.

Try typing in adb remount then adb push your files.
Sent from my LG-P999

mstrk242 said:
Try typing in adb remount then adb push your files.
Sent from my LG-P999
Click to expand...
Click to collapse
Ah, he says in the first post that he tries that but gets an error.

Still having the issue.
I searched through default.prop and ro.secure=0.
I also attempted to adb remount while running superuser, with no success.
I am on EB1.08 for 2.3.3 currently, but I also tested this on Weapon G2x 2.3.3 with the same results.

mmapcpro said:
Still having the issue.
I searched through build.prop and there is no ro.secure line at all...not set to 1, not set to 0...not there.
I also attempted to adb remount while running superuser, with no success.
I am on EB1.08 for 2.3.3 currently, but I also tested this on Weapon G2x 2.3.3 with the same results.
Click to expand...
Click to collapse
Not build.prop, but *default.prop*, should only be a few lines long, in the root of your phone's filesystem:
adb shell
ls
you should see the file. Mine looks like (minus the -----):
----------------------------------
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
ro.serialno=******* (censored by me)
----------------------------------

wewoapsiak said:
If you type adb shell, do you get a $ or a #?
Try opening the SuperUser app on your phone then doing adb remount.
Sent from my LG-P999 using XDA App
Click to expand...
Click to collapse
when I type "adb shell", it displays: sh-3.2$

lannister80 said:
Not build.prop, but *default.prop*, should only be a few lines long, in the root of your phone's filesystem:
adb shell
ls
you should see the file. Mine looks like (minus the -----):
----------------------------------
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=1
ro.debuggable=1
persist.service.adb.enable=1
ro.serialno=******* (censored by me)
----------------------------------
Click to expand...
Click to collapse
Yeh, I went back and edited my post because I re-read your response and realized I was looking at the wrong file...but default.prop says ro.secure=0

mmapcpro said:
Yeh, I went back and edited my post because I re-read your response and realized I was looking at the wrong file...but default.prop says ro.secure=0
Click to expand...
Click to collapse
Well crap, scratch that idea. But the behavior you describe is exactly what happened when ro.secure=1 was set in EB Froyo, so it must be something...similar?

Problem with ROM!
Sorry for the late reply, but this seems close to the answer.You must be using a custom ROM not Stock GingerBread ,right? Well, some initialisation script(files like init.rc) are responsible for setting the state of adb daemon at boot time. There scripts normally check files like build.prop, default.prop,local.prop, environment variables and stuff like that and accordingly setup many features like heapsize, display mode, adb secure or insecure,etc. There should be something different with your ROM's initialization scripts.
Oh, and i forgot! You can't change default.prop like that. Every time you reboot, default.prop'll be reloaded from boot partition image, effectively undoing any changes you made. Flashing a better boot.img may solve the problem.

[ROOT][HOWTO] WIP: Root the Verizon GSIII without flashing a ROM

UPDATE: I created a tool based on this method. Head over to the new thread.
---
WARNING: This is WIP for now. Don't run it if you aren't comfortable with the possibility of having something go wrong and having to re-Odin back to stock or worse. I was already rooted and had Busybox installed, so even though I temp-unrooted first, I don't know for certain if this will work on a stock device. If anyone wants to flash back to pure stock and give it a shot, I'd appreciate it. If it works, I'll try and make it easier to use.
NOTE: This may give you the custom unlock screen! I'm not 100% certain it was this root method that did it, though, as I had installed BusyBox and frozen several system apps with TiBu before my most recent reboot. I need someone willing to test. I don't have time to backup, flash to stock, and retry at the moment.
Background: Since some people seem to have mysterious issues after flashing the root66 image, I've been looking at existing ICS root methods which don't require flashing ROMs to see if any work on the GSIII. I think I've found one.
This is an adaptation of miloj's root method for the Asus TF300T. All credit goes to him and anyone else he mentioned in his post.
Instructions:
Install the USB drivers if you don't have them already: Verizon_Wireless_I535_GSIII_Samsung_USB_Driver_v1_4_6_0.exe
Download the attached binary package and extract them somewhere
Set up adb and make sure you can see your phone
Run the following commands in a shell. Red is a prompt you will see on the screen, black is something you type, blue is a comment.
Code:
adb push debugfs /data/local/
adb push su /data/local/
adb shell
[COLOR="Red"]$[/COLOR] cd /data/local/
[COLOR="Red"]$[/COLOR] mv tmp tmp.bak
[COLOR="Red"]$[/COLOR] ln -s /dev/block/mmcblk0p14 tmp
[COLOR="Red"]$[/COLOR] exit
adb reboot
[COLOR="RoyalBlue"]... wait for phone to reboot ...[/COLOR]
adb shell
[COLOR="Red"]$[/COLOR] cd /data/local
[COLOR="Red"]$[/COLOR] toolbox chmod 755 /data/local/debugfs
[COLOR="Red"]$[/COLOR] /data/local/debugfs -w /data/local/tmp
[COLOR="Red"]debugfs:[/COLOR] cd xbin
[COLOR="Red"]debugfs:[/COLOR] rm su
[COLOR="Red"]debugfs:[/COLOR] write /data/local/su su
[COLOR="Red"]debugfs:[/COLOR] set_inode_field su mode 0106755
[COLOR="Red"]debugfs:[/COLOR] set_inode_field su uid 0
[COLOR="Red"]debugfs:[/COLOR] set_inode_field su gid 0
[COLOR="Red"]debugfs:[/COLOR] quit
[COLOR="Red"]$[/COLOR] rm /data/local/tmp
[COLOR="Red"]$[/COLOR] mv /data/local/tmp.bak /data/local/tmp
[COLOR="Red"]$[/COLOR] exit
adb reboot
[COLOR="RoyalBlue"]... wait for phone to reboot ...[/COLOR]
adb shell
[COLOR="Red"]$[/COLOR] /system/xbin/su
[COLOR="Red"]#[/COLOR] id
[COLOR="RoyalBlue"]You should see: id=0(root) gid=0(root) ....[/COLOR]
[COLOR="Red"]#[/COLOR] exit
[COLOR="Red"]$[/COLOR] rm /data/local/su
[COLOR="Red"]$[/COLOR] rm /data/local/debugfs
[COLOR="Red"]$[/COLOR] exit
This is using miloj's insecure su, so you should install the superuser app and immediately use its binary update feature to install a proper binary. Otherwise, you're just asking to get malware.

I very much like this root method. Would be interested to see if anyone else is able to get this successfully done on their stock devices.

Worst case, I'll be getting a replacement phone on Wednesday due to some minor screen issues, so I'll be forced to try it then.

Let US know if it works...I have slow connection that times out at 80% because of these huge Rom files
Sent from my SCH-I535 using xda app-developers app

Thanks for working on this Ninja, and thanks for sharing with us. :good:
Sounds like it will be the cleanest root method yet.

$ mv /data/local/tmp.back /data/local/tmp
should be
$mv /data/local/tmp.bak /data/local/tmp
---------- Post added at 05:46 PM ---------- Previous post was at 05:38 PM ----------
This is CONFIRMED working on my VIRGIN SGS3 I got today. had to fix the one typo above. No problems yet. just don't break things freezing too many apps. Somone script up a one click root. If you dont, I will tonight. (In about 3 or four hours or so.)

FlyingPoo said:
$ mv /data/local/tmp.back /data/local/tmp
should be
$mv /data/local/tmp.bak /data/local/tmp
Click to expand...
Click to collapse
The perils of copy/pasting half from the original post and half from my local shell.
FlyingPoo said:
This is CONFIRMED working on my VIRGIN SGS3 I got today. had to fix the one typo above. No problems yet. just don't break things freezing too many apps. Somone script up a one click root. If you dont, I will tonight. (In about 3 or four hours or so.)
Click to expand...
Click to collapse
I'm working on one now. It's about 2/3 done. I have to go run a couple errands before I can finish it, though.

alrighty, cool beans!

FlyingPoo, did you get the "custom unlock" boot screen after adding the su binary?

May have to try this one out! Thanks

Tool here: http://forum.xda-developers.com/showthread.php?t=1792342

Did not want to post in the tool thread to confuse people so maybe this can be used a basic research to make this method as seamless as possible? Let us know what you prefer Ninja.
Wanted to give some more details on the "custom unlock" boot screen. There was some new findings from Lee (aka ralekdev) who is working on unlocking the bootloader.
Ralekdev said:
In other news, I found what keeps resetting the 16 byte encrypted romtype in param.img. It's libcordon.so, which is from /system/app/SysScope.apk (it'll also be copied to /system/lib/libcordon.so). It's using quite a few checks to see if you've modified your system.
There's an adb scanner, checking to see if you've changed the ro.secure or ro.debuggable props.
The root process scanner checks running processes and returns true if any are found running as root that are not one of:
"debuggerd", "init", "installd", "servicemanager", "vold", "zygote", "netd", "ueventd", "dock_kbd_attach", "pppd", "pppd_runner", "mpdecision", "thermald", "hdmid", "sec_keyboard", "seccmmond", "mfsc", "mfdp"
There's also a partition check, kernel checker, su scanner, and a file scanning mechanism using data from a sqlite db
So to completely remove the Samsung custom screen on bootup and 5 second delay you'd need to disable the SysScope.apk, then encrypt and write the 16 bytes yourself using 0xFF000000 as the first int to mark yourself as official
Click to expand...
Click to collapse
If I understand correctly, there is a SysScope.apk that does various checks detailed in that post so I'm assuming if that apk is disabled on a "virgin" system after doing this process would ensure that the custom flag never gets touched. There is also mention of a system dynamic library that does some checks but not sure impact of disabling that as well, maybe makes more sense to see what would other process would be using it besides SysScope.apk.

Interesting stuff. Sounds like just freezing/removing them will still give custom unlock, but it might be possible to write replacements which don't actually do the checks.
Unfortunately, I won't have a huge amount of time to spend on research for the next two weeks, but I'll see what I can do, and see what the other devs have done with reversing SysScope and libcordon.

This root method reminds me of Motorola's infamous "zergRush" root exploit. A great way to root the device without even touching the ROM.

Noxious Ninja said:
Interesting stuff. Sounds like just freezing/removing them will still give custom unlock, but it might be possible to write replacements which don't actually do the checks.
Unfortunately, I won't have a huge amount of time to spend on research for the next two weeks, but I'll see what I can do, and see what the other devs have done with reversing SysScope and libcordon.
Click to expand...
Click to collapse
Sounds good.
I could be wrong but I'd imagine that since that by default the flag is not set so we should be good by just disabling them. I might just be the guinea pig and immediately rename SysScope and the libcordon after rooting to see if flag gets tripped.
Based on Lee's analysis what doesn't add up is why people who flash the full rooted "stock image" have not reported this flag being tripped yet...

lowg said:
Sounds good.
I could be wrong but I'd imagine that since that by default the flag is not set so we should be good by just disabling them. I might just be the guinea pig and immediately rename SysScope and the libcordon after rooting to see if flag gets tripped.
Based on Lee's analysis what doesn't add up is why people who flash the full rooted "stock image" have not reported this flag being tripped yet...
Click to expand...
Click to collapse
It might be that if you disable them while you don't have custom unlock, it works, but if you already have custom unlock you would have to reset it somehow.
If you decide to try it, see if you can still bring up the Settings ––> About device ––> Status menu to see Device status, or if that crashes.

Noxious Ninja said:
It might be that if you disable them while you don't have custom unlock, it works, but if you already have custom unlock you would have to reset it somehow.
If you decide to try it, see if you can still bring up the Settings ––> About device ––> Status menu to see Device status, or if that crashes.
Click to expand...
Click to collapse
Ok, after rooting, I immediately disabled only SysScope.apk by renaming it, installed Superuser from market and updated binary, rebooted no unlock screen. Settings -> About device -> Status works fine. Device status section shows "Scanning..." for about two minutes after rebooting then simply "Modified".
After this tried soft reboot, hard reboot numerous times and still no "custom unlock" boot screen.

lowg said:
FlyingPoo, did you get the "custom unlock" boot screen after adding the su binary?
Click to expand...
Click to collapse
hmm. actually i do. Altho my Device status says normal.

FlyingPoo said:
hmm. actually i do.
Click to expand...
Click to collapse
hmmm, maybe it does have something to do with that apk then. originally that's all I renamed but since then froze a lot of apps and still no unlock, only showing modified status
Sent from my SCH-I535

FlyingPoo can you post more about what you did after rooting?
Did you immediately installs the ChainsDD version of su (via the binary updater in the Superuser market app) or did you stick with the version of su that came with the script for a while?
Did you ever enter "Odin/Download" mode of your device?
Just trying to figure out how our devices could have a different status if we both started from "virgin" GS3s.. Don't want to assume it's just SysScope either since I never disabled the libcordon.so and maybe it's used in other places in the system...

[Nook HD+] Nook HD and HD+ rooting instructions (now permanent)

How to root Nook HD+ (and Nook HD too, I guess).
(Thanks for some useful ideas to sparkym3: http://forum.xda-developers.com/member.php?u=4411543 )
(tested only on 2.0.0 version (as comes out of the box), also works on 2.0.2
Get one of the attached files: root_win.zip if you are on windows, or root_unix.tgz if you are on Linux or Mac.
unpack the file to some dir and run "makeroot" on Windows or "sh makeroot.sh" on Mac/Linux
After a couple of reboots you should be able to do
adb shell and issue a "su" command in the shell and get the root prompt (#).
Thanks to someone0 for his prior investigations here.
Known bugs:
Superuser.apk does not really install because package manager could not be contacted.
Oh, and I think you'll find this interesting too:

Hai.
Kind of a two-fer, eh?

I noticed that people see their Nook HDs restoring to factory settings after 8 unsuccessful reboots next time you boot after rooting, so possibly there's some extra check somewhere.
Very sneaky on the B&N side, I'd say.

Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.

roustabout said:
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
Click to expand...
Click to collapse
Do the new HD & HD+ still allow you boot from the external sd card ?

roustabout said:
Hm, the 8 failed boot = wipe and restore has been true since the NC, and is valuable because it helps keep the device from getting bricked, also triggerable if the registration token doesn't match BN's reg token. I learned this early on by restoring a backup made before I'd erased and deregistered. I forget where the token lives, in /data/ somewhere.
I'll take a look at this on 2.0.2 this weekend - mine updated before I got ADB working so it restores to 2.0.2 now...
OK, so this approach does work with the 2.0.2 OS, and restarting the device does put it into a boot cycle. Very nasty.
Before I rebooted, I removed the post_boot_hook file and also got rid of the symlink; I'd say BN is doing some kind of inventory of what's in system and driving a reflash based on that.
My guess is it's not a very careful inventory, but it'll certainly be amenable to study now that we can get, at least temporarily, root.
Hm. Interesting -- my ability to mkdir /data/su is now gone after the restore. I wasn't able to do it the first time I tried, either - I suspect that there's something keeping some level of eye on that.
Oh, very uncool - in addition to resetting the system, they wipe personal data in the process. Losing the apps doesn't surprise me much. Losing the books I'd sideloaded surprises me.
Click to expand...
Click to collapse
if you put your books into /system/media, it will back them up to the cloud

Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.

leapinlar said:
Is it possible to push a new recovery with adb after rooting? The 8 failed boot repair is only possible with the stock recovery. But then again you may end up in an endless bootloop without it there to finish it's task. But maybe you can find and delete the trigger flag that starts the process.
Click to expand...
Click to collapse
stuff is best to be not mentioned. /sarcasm.....

recovery is signed, so it's not super easy to replace it with anything that would run.
The unsigned bootloader trick at the moment requires a boot from sdcard.

shouldn't step 8 & 9 be outside the code block?

verygreen:
I just want to thank you for your all your work on the Nook series. I've been using your "size-agnostic method ..." tools and process to run from the SD card on my Nook Color since you created the method, and now I'm excited to use your work on my new Nook HD+ (just received yesterday) !

just got mine and got an update notification. turned off wifi so it didnt complete.any word if it breaks root ir bootloader?

CWM is now possible too.

Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.
Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.
I also rewrote your code into a batch file. You can double check it I guess.
Code:
@echo off
cls
@echo .
@echo wait for it
@echo .
adb devices
@echo .
@echo if you do not see you device listed above hit ctrl+c and exit the script
@echo then check adb on your PC and device then try again.
@echo .
@echo reroute /data/local/tmp
adb wait-for-devices shell rm -r /data/local/tmp
adb shell ln -s /data/ /data/local/tmp
@echo .
@echo Now rebooting
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and making directory /data/su
adb wait-for-devices shell mkdir /data/su
@echo uploading su
adb push su /data/su/
@echo uploading busybox
adb push busybox /data/su/
@echo uploading boot_complete_hoot
adb push boot_complete_hook.txt /data/boot_complete_hook.sh
adb shell chmod 755 /data/boot_complete_hook.sh /data/su/*
@echo .
@echo Now rebooting again
@echo .
adb reboot
@echo .
@echo waiting for reboot to finish and getting shell
adb wait-for-devices shell

someone0 said:
Something is interesting, eventhough mine originally got automatically updated to 2.0.2, but after the factory reset, it went back to 2.0.0. But for some weird reason I can't get root.
Maybe this will help, the build number is 2.0.0.1031.lithium01.ovation.rldp.s68403 with the manufactured date 10/22/2012
please compare mine to your.
I also rewrote your code into a batch file. You can double check it I guess.
Click to expand...
Click to collapse
so, when you run this, after the final adb shell, what are the permissions on /system/xbin/su?
run su and you should get the root prompt.

I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.
Code:
/data/
-rwxr-xr-x shell shell 167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell shell 586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell shell 22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell shell 2012-11-10 06:20 tmp -> /data/
cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
everything is in place and correct, but no dice. either boot_complete_hook.sh didn't get executed or it did but never get launched with root permission.

someone0 said:
I don't get root prompt, su never get copied to /system/xbin/su
here is the list of my finding.
Code:
/data/
-rwxr-xr-x shell shell 167 2012-11-10 05:52 boot_complete_hook.sh
/data/su
-rwxr-xr-x shell shell 586212 2012-11-10 06:07 busybox
-rwxr-xr-x shell shell 22364 2012-11-10 06:07 su
/data/local
lrwxrwxrwx shell shell 2012-11-10 06:20 tmp -> /data/
cat boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
everything is in place and correct, but no dice.
Click to expand...
Click to collapse
well, there should be more stuff in the shell file, you miss the final chown line: chmod 06755 /system/xbin/su

It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.

someone0 said:
It did, I just didn't copy and paste the output correctly. But regardless, since the foulder /system/xbin don't have the su file, this mean as I suspected earlier, either it wasn't executed or lauched w/ root permission.
Click to expand...
Click to collapse
check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh

verygreen said:
check if your /system/bin/clrbootcount.sh calls /data/boot_complete_hook.sh
Click to expand...
Click to collapse
This is interesting, it look as if it won't launch the /data/boot_complete_hook.sh
Code:
cat /data/boot_complete_hook.sh
#!/system/bin/sh
/data/su/busybox mount /system -o remount,rw
/data/su/busybox cp /data/su/su /system/xbin/su
chown 0.0 /system/xbin/su
chmod 06755 /system/xbin/su
[B][email protected]:/data $ /data/boot_complete_hook.sh
/data/boot_complete_hook.sh
/system/bin/sh: /data/boot_complete_hook.sh: No such file or directory
1|[email protected]:/data $
[/B]
Yub it does
Code:
cat clrbootcount.sh
#!/system/bin/sh
################################################################################
##
#
# File clrbootcount.sh
# Description Clear the bootcount variable to 0 on successful boot
#
##
# Run potential hook first.
[B]/data/boot_complete_hook.sh[/B]
# Zero the boot count
cat /system/etc/zerobootcnt > /bootdata/BootCnt

[APP/FIX] Date/Time 1970 bug workaround v2.2

Hope this helps someone. I got fairly sick of the date/time bug giving me error alerts upon reboot. This fix takes the RTC date/time and applies an offset specific to your own phone to set the correct date/time at startup. I have attached an APK to make life easy. It should also give the ability to have recovery use the files it creates to set the clock correctly on startup.
The app requires root. If running AOSP, your ROM must have initscript support.
The app has 3 functions:
Install offset only (for use with a compatible recovery, not used by the ROM)
Install offset and initscript (to correct ROM clock offset, also for use with a compatible recovery)
Uninstall (Remove /data/local/userinit.sh /data/media/rtc_offset and /sdcard/rtc_offset)
Feel free to include the app in your own ROMs, just give me credit
As of version 2.0, the script will create /data/media/rtc_offset which can be used by recovery to correct the date/time on boot. Note this will require the recovery to specifically support this correction.
Version 2.1 uses /system/bin/toolbox for compatibility across roms (rather than relying on whatever /system/bin/date points to)
Version 2.2 places the rtc_offset file both in /sdcard/rtc_offset and also in /data/media/rtc_offset if available. The initscript will use either file that is available. This is for possible compatibility with older phones that may not have /data/media, at the request of Phil3759
Special thanks to Atze001, sniperle and Phil3759.
Hope this helps, enjoy.

dougiebee said:
Hope this helps someone. I got fairly sick of the date/time bug giving me error alerts upon reboot. My solution was to get the modification date of the /data/system directory and set that as the current date at boot time. Not great, but better than 1970. This or something similar may be posted elsewhere but I haven't seen it.
I'm running CM11 - not sure whether this works on other AOSP ROMS.
1) Create a file named 01datehack with the following content:
Code:
#!/system/bin/sh
olddate=`ls -ld /data/system | awk '{print $4, $5}' | sed -e 's/-//g' -e 's/ /./g' -e 's/://g' -e 's/$/00/g'`
date -s $olddate
Then run the following commands:
Code:
adb root
adb shell "mkdir -p /data/local/userinit.d"
adb push 01datehack /data/local/userinit.d
adb shell "chmod 755 /data/local/userinit.d/01datehack"
As it lives in /data it will survive flashing an update as long as you don't wipe. It's only a couple of fairly noddy linux commands, there's quite possibly a command line switch that would negate the need for all the SED'ing - also possibly a better directory/file to look at.
Hope this helps, enjoy.
Click to expand...
Click to collapse
I'm on the latest cm11 nightly. Tried your code but didn't make any difference. Phone still started up in February and then changed to today's date after network/WiFi started.

murdoch1 said:
I'm on the latest cm11 nightly. Tried your code but didn't make any difference. Phone still started up in February and then changed to today's date after network/WiFi started.
Click to expand...
Click to collapse
What do you get from "adb shell ls -ld /data/system"? Have you enabled ADB root access in developer options?

1970
dougiebee said:
What do you get from "adb shell ls -ld /data/system"? Have you enabled ADB root access in developer options?
Click to expand...
Click to collapse
Yes enabled ADB root access in Developer options. Running the command you provided results me with the following:-
drwxrwxr-x system system 2013-12-23 08:47 system
Cheers

deleted

Try this. I have made a flashable zip for TWRP
http://forum.xda-developers.com/showpost.php?p=48760802&postcount=13
Its a userinit.sh script in data/local

Atze001 said:
Try this. I have made a flashable zip for TWRP
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix.zip[/U
Its a userinit.sh script in data/local
Click to expand...
Click to collapse
Will this work for me as I'm running philz cwm?

You can try it. If it dont work you get an Installation error and nothing more happens.
If you get an Error please tell me i will fix it for CWM.

Atze001 said:
You can try it. If it dont work you get an Installation error and nothing more happens.
If you get an Error please tell me i will fix it for CWM.
Click to expand...
Click to collapse
Just installed. Worked perfectly phone booted up with the correct date immediately.
Many thanks. Have a good Xmas.

Thanks go to dougiebee for this work.

Works perfectly on CM11 and TWRP.
Thanks a lot dougiebee and Atze001. :laugh:

Works on CM11/D802/TWRP!
Gesendet von meinem LG-D802 mit Tapatalk

Here are the new Links for the flashable fix.
This one ist with userinit.sh in data/local
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix/TimeDateFix_Local.zip
and this ist the original with 01datehack in data/local/userinit.d
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix/TimeDateFix_org.zip

Atze001 said:
Here are the new Links for the flashable fix.
This one ist with userinit.sh in data/local
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix/TimeDateFix_Local.zip
and this ist the original with 01datehack in data/local/userinit.d
https://dl.dropboxusercontent.com/u/20033515/TimeDateFix/TimeDateFix_org.zip
Click to expand...
Click to collapse
thanks, but you didn't set permission to 755 in your script, that's why it doesn't work. i'm sure you can fix it

I personally use the first zip and it works. Many people confirmed that it works.
But if you want i can set the permissons to 755
Permissions fixed

I now have a much better fix. It uses the RTC rather than relying on file timestamps. It's easy to implement, but creation of a flashable zip will not be straight forward.
I ran the following using ADB once the system was up and the date/time was correct:
Code:
expr $(date +%s) - $(cat /sys/class/rtc/rtc0/since_epoch)
Which gave me 1384422218 - which is "Thu Nov 14 09:43:38 GMT 2013" - the exact date/time I first powered on my phone after I got it.
So I edited my userinit file to read:
Code:
#!/system/bin/sh
realdate=$(expr 1384422218 + `cat /sys/class/rtc/rtc0/since_epoch` | awk '{print strftime("%Y%m%d.%H%M%S",$1)}')
date -s $realdate
This takes my hard-coded (device-specific) power-on time and adds the current RTC time since then to give me the correct date/time, much better than using the timestamp of a file or directory.
I'll update the OP if others confirm this works for them. Note: you need to replace 1384422218 with the number specific to your phone. Creating a flashable zip would be a bit of a challenge, as it would need to be device specific.

Wouldn't it be possible to add a script to the flashable zip that determines the correct value and modifies the flashable file with the value before or after flashing?
PS: I don't know anything about this stuff...

dougiebee said:
I now have a much better fix. It uses the RTC rather than relying on file timestamps. It's easy to implement, but creation of a flashable zip will not be straight forward.
I ran the following using ADB once the system was up and the date/time was correct:
Code:
expr $(date +%s) - $(cat /sys/class/rtc/rtc0/since_epoch)
Which gave me 1384422218 - which is "Thu Nov 14 09:43:38 GMT 2013" - the exact date/time I first powered on my phone after I got it.
So I edited my userinit file to read:
Code:
#!/system/bin/sh
realdate=$(expr 1384422218 + `cat /sys/class/rtc/rtc0/since_epoch` | awk '{print strftime("%Y%m%d.%H%M%S",$1)}')
date -s $realdate
This takes my hard-coded (device-specific) power-on time and adds the current RTC time since then to give me the correct date/time, much better than using the timestamp of a file or directory.
I'll update the OP if others confirm this works for them. Note: you need to replace 1384422218 with the number specific to your phone. Creating a flashable zip would be a bit of a challenge, as it would need to be device specific.
Click to expand...
Click to collapse
Just applied your new version. Works a treat. As you say its better than basing the date on a file timestamp. I basically used the flash zip and amended the unserinit.sh script with the code generated on my device.
All done.
Cheers again.

With 01datehack in userinit.d it dont work for me. With userinit.sh in local it works.
I will take a look to make a Batch or a zip out of this.

dougiebee said:
I now have a much better fix. It uses the RTC rather than relying on file timestamps. It's easy to implement, but creation of a flashable zip will not be straight forward.
I ran the following using ADB once the system was up and the date/time was correct:
Code:
expr $(date +%s) - $(cat /sys/class/rtc/rtc0/since_epoch)
Which gave me 1384422218 - which is "Thu Nov 14 09:43:38 GMT 2013" - the exact date/time I first powered on my phone after I got it.
So I edited my userinit file to read:
Code:
#!/system/bin/sh
realdate=$(expr 1384422218 + `cat /sys/class/rtc/rtc0/since_epoch` | awk '{print strftime("%Y%m%d.%H%M%S",$1)}')
date -s $realdate
This takes my hard-coded (device-specific) power-on time and adds the current RTC time since then to give me the correct date/time, much better than using the timestamp of a file or directory.
I'll update the OP if others confirm this works for them. Note: you need to replace 1384422218 with the number specific to your phone. Creating a flashable zip would be a bit of a challenge, as it would need to be device specific.
Click to expand...
Click to collapse
Does this survive flashing or do I need to do this every time I flash?
Sent from my LG-VS980 using Tapatalk