Database Users

G1 just stopped working?

So, I've had this rooted G1 for a long time. It was running Flan, and quite well, today, i kept getting errors, so I rebooted, after reboot, it would not go past the first bootscreen, I can still access recovery mode, but I have no idea what is going on, I tried to reflash Flan, and I kept getting error in sector E, or something like that, anyone know what's up?

I think I had a similar problem. It just died on me randomly and immediately started to reboot. It got stuck on the bootscreen (mine was the second I believe; the one after Tmobile G1). I did an alt+w wipe and rebooted. It took a long time, but just be patient and see if it will boot.

Didn't boot, I unrooted, and it booted, but now I'm stuck at the activation screen, Win 7, will not get the damn driver right, and Mint doesn't know what ADB is, even thought I installed correctly, or so I think, It's been so long since I've used ADB.

Since Mint is just ubuntu in a nice frock, follow this to get adb talking to your phone:
wddglr said:
You will now set up your bashrc file and UDEV to recognize your HTC Device.​
!!START -------------------------------------- ADB + FASTBOOT --------------------------------------
The Android Debug Bridge (adb) is one of the tools that will help you the most when you run into flashing problems or running shell commands directly from your machine. UDEV will not recognize your G1 out of the box, but we will configure it with some rules so it can connect.
We will work with /AndroidSDK as the location of your sdk. If this is not your setup, I think you're smart enough to figure it out.
Editing .bashrc file to use tools from /AndroidSDK/tools/ directory -
Go to your home folder.Example: /home/wddglr/​
Press Control + H to view hidden files.
Look for your .bashrc file and double click to open it with gedit.
Add the following lines to the top of the file:
Code:
#AndroidDev PATH
export PATH=${PATH}:/AndroidSDK/tools
IMPORTANT NOTE​
Setting up UDEV to recognize HTC Device -
Type the following into a terminal (Applications > Accessories > Terminal):
Code:
gksudo gedit /etc/udev/rules.d/51-android.rules
Now add the following line to the blank file:
Code:
SUBSYSTEM=="usb", SYSFS{idVendor}=="0bb4", MODE="0666"
Click save and close.
To restart udev, open up a terminal and enter:
Code:
sudo /etc/init.d/udev restart
Setting up fastboot -
Download this fastboot binary from http://android-dls.com.130.4 KB [http://android-dls.com/files/linux/fastboot]​
Once downloaded to your desktop, right click and select Properties.
Navigate to the Permissions tab and configure the following option:Execute: [√] Allow executing file as program​
Click Close.
Move the fastboot bianary to your /AndroidSDK/tools/ directory.
Reboot.
-------------------------------------- ADB + FASTBOOT -------------------------------------- END!!​
Click to expand...
Click to collapse

I got it working, I forgot to do the root exploit thing, anyways, I installed the Danger SPL, newest radio, Cyan works, all of the 2.1+ builds don't, they just stay at the first boot screen, I even left one going over night, never got past the first boot screen, I'm annoyed as hell with this. Could it be something to do with the newest radio? The one after 26I?

Just womdering?
did yyou have your sdcard patitioned? If so you may want to wipe your ext partition and also repair your ext partition and then reflash a flan rom?

That's what I thought, because I had a second SD card, just Fat32, and it booted after a reroot, so I formatted the whole SD, but now I'm scared of using anything but Cyan.

Ok, new issue, I tried putting SuperEclair V8 on the G1, and I get this error:
E:Can't symlink /system/xbin/bb/
[
E:Failure at line 61:
symlink /system/xbin/busybox SYS
TEM:xbin/bb/[
Installation Aborted
So what's the issue with this, gives me that error after a complete reroot, and multiple wipes.

Godfrd824 said:
Ok, new issue, I tried putting SuperEclair V8 on the G1, and I get this error:
E:Can't symlink /system/xbin/bb/
[
E:Failure at line 61:
symlink /system/xbin/busybox SYS
TEM:xbin/bb/[
Installation Aborted
So what's the issue with this, gives me that error after a complete reroot, and multiple wipes.
Click to expand...
Click to collapse
I am having the same exact issue with the same exact rom, if anyone can help it would be much appreciated
thanks
nate

[Q] no /sbin/am

Hi.
My problem is on a SGSII, but I suppose it could be on any phone.
All last rom I flashed had problems with adb : after flashing, I am unable to use some adb command. For example :
Code:
$ adb uninstall <mypackage>
/sbin/sh: pm: not found
the pm script exists in /system/bin, but is not useable "as is" because it lacks of "#!/system/bin/sh" on the first line.
What I have to do is
Code:
mount -o remount,rw - /
echo '#!/system/bin/sh' >/sbin/am
cat /system/bin/am >>/sbin/am
chmod 0777 /sbin/am
echo '#!/system/bin/sh' >/sbin/pm
cat /system/bin/pm >>/sbin/pm
chmod 0777 /sbin/pm
mount -o remount,ro - /
And then it works again.
But my problem is that on each reboot I have to do this again.
So my questions are :
- do you know why those rom (I'm actually using Lite'ning) does not have those scripts ?
- how can I make those change permanent ? how /system is build ? for example, there is a "build.prop" file in it but it is nowhere else on my phone ...
Thanks a lot for your help !
Mike

The problem is twofold. First, a proper shell script should have the first line as a path to the command interpreter ("#!/system/bin/sh"), but for some reason, am and pm scripts don't have this. The second part of the problem is that the default shell as shipped in the AOSP code base ignores that line and happily executes these broken shell scripts. Depending on just how your rooted ROM was cooked, you may have any of a number of shell interpreters; bash, busybox sh, and the original sh being the most common. Bash is more tolerant of broken scripts, but the busybox interpreter won't execute these.
I don't know why your editing doesn't keep between boots though. It seems it should based on what's posted above. I don't have any knowledge of the internals of the SGSII so you probably need to ask that question in a forum dedicated to that device.

Tanks for your reply.
OK, it don't work anymore because default shell has been changed.
2 questions remains :
- why those scrips are not any more in /sbin
- why they don't stay when I reboot.
If anybody knows ...
I'll try to ask on the rom maker thread ...
Mike

I must have missed that. /sbin is part of the ramdisk. It is stored in the boot image and gets expanded to RAM at every boot, so any changes in /sbin will be destroyed on next boot.

all I have to do then is find where this ramdisk and update it ? ...
I'll try and let you know
Thanks again !

mbaroukh said:
all I have to do then is find where this ramdisk and update it ? ...
I'll try and let you know
Thanks again !
Click to expand...
Click to collapse
The ramdisk is a cpio archive gzipped to save space, then concatenated with a kernel into a single file. A short header on the whole thing tells where to split the two, and the kernel command lines and some other housekeeping tasks. Together that all makes up the boot.img partition (at least this is how it is on most androids I've played with). When the bootloader launches, it loads the header that tells where the kernel is in the file. It then loads the kernel into RAM. It then passes control to the kernel. The kernel knows how to gunzip the cpio archive and how to create a ramdisk partition of the required size. It then un-archives it into the newly created ramdisk, then passes control to `init' to do the rest of the boot process.
You can't just modify the ramdisk on the device. You have to extract the whole boot.img from flash, then separate its two parts (ramdisk and kernel) then gunzip and un-archive the cpio filesystem somewhere (preferably a *nix system that understands unix permissions, simlinks, etc), then modify whatever it is you want, then archive the contents again to a cpio archive, gzip it up, then recombine it with the kernel and the appropriate header for the whole thing, then re-flash it to the NAND partition on your device where the boot.img normally resides.

Thanks !
This is my next week-end task to try all this.
I'll let you know if I succeed or not.

[Q] Nexus 7 stuck on Google logo

Hi everyone,
my N7 (unlocked, stock, latest OTA, maybe was rooted) is not booting past the Google logo. I can access bootloader and recovery and through custom recoveries adb shell sbin/dmesg. also in stock adb sideload works. but when it is stuck in google logo it is detected as nexus 7 but I can't access it through adb (no devices listed).
What I did already:
stock recovery: factory reset
cwm recovery: wipe dalvik cache, fix permissions
reflashed factory image JZO54K and JOP40D
formatted /system and reflashed
fastboot oem lock & fastboot oem unlock: after this it will show the boot animation for ~7s and reboot
also i waited 20mins after flashing factory images - enough so it at least can show the boot animation
this is what fastboot currently shows:
FASTBOOT MODE
product name - grouper
variant - grouper
hw version - ER3
bootloader version - 4.13
baseband version - n/a
serial number - 015d2109f31c0415
signing - not defined yet
LOCK STATE - UNLOCKED
here are two dmesgs: http://pastebin.com/T8pexUa3 and http://pastebin.com/y2sXSC5n
and here's the video of a startup after fastboot oem lock + unlock: http://www.youtube.com/watch?v=Sj3E3Emkz2U
and here's a log of one flash: http://pastebin.com/z5Bue4jL where everything seems perfectly fine
Some more symptoms: non of openrecovery-twrp-{2.3.3.0, 2.4.0.0, 2.4.1.0}-grouper.img are properly booting (only splash screen is displayed) and when I try to do some tasks like mount /system with cwm 6.0.1.0 or factory reset with twrp 2.2.1 (part of galaxy nexus 7 toolkit) the recovery will freeze so I have to reboot. also cwm gets awfully slow after some tasks.
I am out of my wits, can anyone help? If you give me instructions I can provide more dmesgs.

hi aha27,
Sorry about your problem. You are to be commended though, for the preparation and detail you provided in describing your situation - too bad most are not that thorough.
That video is an unusual bootloop. With "normal" bootloops the kernel stays up and the android layer cycles endlessly in it's startup checks - but your video looks much more like a kernel panic occurs, as the screen goes back to a bootloader display.
I looked briefly through one of your dmesg boot logs, and didn't spot anything unusual. The facts that:
(a) you can successfully re-flash stock roms, including file system re-creation
(b) you can run adb shell commands interactively
is evidence that the kernel has no difficulty booting and that perhaps the flash filesystems are all OK too.
What sticks out is your report that the recoveries also do not proceed completely to show their touchscreen interfaces.
Here is something to try
(1) perform soft-boots of the recovery with fastboot, for example:
fastboot boot openrecovery-twrp-2.3.3.0-grouper.img
As this requires no writing nor reading of the eMMC Flash memory, if it fails to setup the display correctly, perhaps you have a hardware problem that is unrelated to flash memory. (As you tried multiple recoveries, you may have already done this - it wasn't evident whether you flashed your different recoveries or soft-booted them)
Note also that you can run several adb sessions simultaneously, so in separate windows with the recovery running you can certainly be doing
C:\fubar> adb shell logcat > logcat_output.txt
and
C:\fubar> adb shell cat /proc/kmsg > kernel_log_output.txt
[ If you are using cygwin or linux you can spice this up a little, e.g.
$ adb shell logcat 2>&1 | tee logcat_output.txt
$ adb shell cat /proc/kmsg 2>&1 | tee kernel_log_output.txt
... as both of these block waiting for more output, in the latter case you get to see things happening in real time as well as capturing the output for later analysis ]
(2) see if anything is leftover in /proc/last_kmsg on the boot cycle immediately following the "bootloop". It might be possible to jump the device into fastboot mode by pressing Vol-Down the moment the Google logo first reappears. From there, soft-boot a recovery and capture the output of
adb shell cat /proc/last_kmsg
(3) Start your adb server on the PC and launch the "bootloop" and see if you can get a shell before the crash occurs. If you can get one before the crash occurs maybe you will be lucky enough to catch a problem via
adb shell cat /proc/kmsg
or
adb logcat -v threadtime
Note that if you have installed a fresh ROM, you can toggle ADB debugging on by mounting /data and
# mkdir /data/property
# chmod 700 /data/property
# echo -n 'mtp,adb' > /data/property/persist.sys.usb.config
# chmod 600 /data/property/persist.sys.usb.config
(4) I also noted your comment about "freezing if I mount /system". Note that when you flash the factory image, /data and /cache are handled differently than /system, even though all 3 are ext4 filesystems. For the first two, the process is "erase, mkfs, write", whereas for /system all you get is a "erase, write". So here is the deal - if a mke2fs filesystem is created, that means for /data and /cache that the bootloader is actually mounting those partitions (as ext4 filesystems) and restoring into them file by file. Otherwise, a "blob"-type write would just overwrite the newly created ext4 filesystem metadata.
/system is handled differently though - notice in the factory install logs there is no detail about filesystem creation for the /system partition? That's because Google is using a "sparse ext4 image" format for the system.img file, and it can actually write this to the /system partition as a binary blob.
So, on the chance that there is something wrong with the system partition, why don't you manually create the /system filesystem by hand to see if any errors occur? e.g.
mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
If this proceeds without error, try installing a dev ROM (not a factory ROM) and see if you can get further along.
The one thing which is fortunate about your situation is that you can return your device through flashing to complete factory stock, including locking the bootloader... if returning the device (via a warranty return/RMA) process is an option for you.
Whew that was a lot of typing. I think I am done for the day.
bftb0

bftb0 said:
That video is an unusual bootloop. With "normal" bootloops the kernel stays up and the android layer cycles endlessly in it's startup checks - but your video looks much more like a kernel panic occurs, as the screen goes back to a bootloader display.
Click to expand...
Click to collapse
This is the bootloop occurring once after doing fastboot oem lock / fastboot oem unlock - after the next reboot it stays at the Google logo without rebooting again.
(1) perform soft-boots of the recovery with fastboot, ... As this requires no writing nor reading of the eMMC Flash memory, if it fails to setup the display correctly, perhaps you have a hardware problem that is unrelated to flash memory. (As you tried multiple recoveries, you may have already done this - it wasn't evident whether you flashed your different recoveries or soft-booted them)
Click to expand...
Click to collapse
some were soft-boots some were with flashing of recovery, but CWM recovery hangs in either boot type after mount /sdcard or mount /user and mount /system.
I also tried some different versions of openrecovery-twrp-XXXX-grouper.img and none of it would start up.
Note also that you can run several adb sessions simultaneously, so in separate windows with the recovery running you can certainly be doing
C:\fubar> adb shell logcat > logcat_output.txt
and
C:\fubar> adb shell cat /proc/kmsg > kernel_log_output.txt
Click to expand...
Click to collapse
Ok, when I am in recovery I can mount /system and use /system/bin/logcat but there are only three lines with "scanline" something (do you need this?)
(2) see if anything is leftover in /proc/last_kmsg on the boot cycle immediately following the "bootloop". It might be possible to jump the device into fastboot mode by pressing Vol-Down the moment the Google logo first reappears. From there, soft-boot a recovery and capture the output of
adb shell cat /proc/last_kmsg
Click to expand...
Click to collapse
I couldn't go to fastboot when the Google logo appears but last_kmsg is this -> http://pastebin.com/VkmNdM5d
After oem lock / oem unlock and the reboot (like in the video) I managed to get into fastboot and recovery, here is the last_kmsg -> http://pastebin.com/wR1yptWr
(3) Start your adb server on the PC and launch the "bootloop" and see if you can get a shell before the crash occurs. If you can get one before the crash occurs maybe you will be lucky enough to catch a problem via
adb shell cat /proc/kmsg or adb logcat -v threadtime
Click to expand...
Click to collapse
nope. wasn't able to get a shell although I activated debugging with your procedure:
Note that if you have installed a fresh ROM, you can toggle ADB debugging on by mounting /data and
# mkdir /data/property
# chmod 700 /data/property
# echo -n 'mtp,adb' > /data/property/persist.sys.usb.config
# chmod 600 /data/property/persist.sys.usb.config
Click to expand...
Click to collapse
Still no adb while stuck at Google logo
/system is handled differently though - notice in the factory install logs there is no detail about filesystem creation for the /system partition? That's because Google is using a "sparse ext4 image" format for the system.img file, and it can actually write this to the /system partition as a binary blob.
So, on the chance that there is something wrong with the system partition, why don't you manually create the /system filesystem by hand to see if any errors occur? e.g.
mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
If this proceeds without error, try installing a dev ROM (not a factory ROM) and see if you can get further along.
Click to expand...
Click to collapse
wow - why would they do that? Anyway, I flashed recovery-clockwork-6.0.2.3-grouper.img and was able to format:
Code:
~ # mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
mke2fs -T ext4 -m 0 /dev/block/mmcblk0p3
mke2fs 1.41.11 (14-Mar-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
41664 inodes, 166400 blocks
0 blocks (0.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=171966464
6 block groups
32768 blocks per group, 32768 fragments per group
6944 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 39 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
and with adb sideload tried to install pa_grouper-3.00-09FEB2013-203806.zip. But it stopped at "Installing update..." (the cat /proc/kmsg is here: http://pastebin.com/rjd3b1iZ). I tried it again and again it stopped at Installing update, and here is the last_kmsg and the kmsg again: http://pastebin.com/gPBe7JFD and http://pastebin.com/uXHbX3we.
The one thing which is fortunate about your situation is that you can return your device through flashing to complete factory stock, including locking the bootloader... if returning the device (via a warranty return/RMA) process is an option for you.
Click to expand...
Click to collapse
Since everything failed I guess that's my only option, unless there is something in the logs ... maybe you could take another look?
Whew that was a lot of typing. I think I am done for the day.
Click to expand...
Click to collapse
And I am very thankful for your help!

aha,
I am travelling now, so there is a bunch of stuff I can't do easily right now... but I will have a look at the pastebins to see if anything jumps out at me.
Stay tuned.

aha27,
I looked at your pastebins. The only thing that seemed odd was the complaints about the cache partition (mmcblk0p4) in the kmsg logs. But it only appeared one time - hardly compelling.
The only other thing I could suggest is perhaps look in the recovery logs ( /cache/recovery/recovery.log or /tmp/recovery.log) for the recoveries that hang (but you can still communicate with). Maybe there are some crumbs in there that will put you on the correct trail.
FWIW, when I boot my N7 (JOP40D), it does take quite a bit of time for adb to come up - so if the initial OS boot was getting wedged before that happened maybe that explains why you are not seeing it even though you diddled with /data/property/persist....
I haven't looked into this, but is it possible to modify default.prop in the ramdisk so that the adb service gets started earlier? You would have to unpack & repack a boot image to do this. Actually, now that I think of it, you could just modify the "adbd" service definition in the /init.rc file in the ramdisk so that adb is not contingent on a getvar/setvar variable. Perhaps that would get adb running earlier in the OS boots that are hanging, and you might have a chance of observing more things.
I seem to be running out of ideas. With a lot more work, you could implement all sorts of unattended/blind captures though. For instance, a "one-shot" service definition can call a script that starts yet another script - but puts the 2nd one into the background. That way the oneshot service does not block init - and the second script can do strange things such as periodically record dmesg output or logcat output into files in /tmp and then copy them to the /sdcard once it is mounted. This would give you a way to observe stuff going on in the Android boot (after the fact) even if you can't gain realtime access via adb. But, this does require that you unpack, modify, and re-pack boot images.
Well, there's a few ideas. They seem to require progressively more work, though.
Good luck with your tab.

Thanks thanks thanks, but ...
Thank you very very much for the time you invested in my problem, :good:
but this:
bftb0 said:
aha27,
I haven't looked into this, but is it possible to modify default.prop in the ramdisk so that the adb service gets started earlier? You would have to unpack & repack a boot image to do this. Actually, now that I think of it, you could just modify the "adbd" service definition in the /init.rc file in the ramdisk so that adb is not contingent on a getvar/setvar variable. Perhaps that would get adb running earlier in the OS boots that are hanging, and you might have a chance of observing more things.
I seem to be running out of ideas. With a lot more work, you could implement all sorts of unattended/blind captures though. For instance, a "one-shot" service definition can call a script that starts yet another script - but puts the 2nd one into the background. That way the oneshot service does not block init - and the second script can do strange things such as periodically record dmesg output or logcat output into files in /tmp and then copy them to the /sdcard once it is mounted. This would give you a way to observe stuff going on in the Android boot (after the fact) even if you can't gain realtime access via adb. But, this does require that you unpack, modify, and re-pack boot images.
Click to expand...
Click to collapse
is too time consuming for me and as the tab is not too old, I will reflash it with stock, lock it and send it back. Initially I thought it could be solved, then I hoped that you could help me proving it is a hardware problem, so I'd have no problem getting it replaced, but let's see what Google tells me.
Good luck with your tab.
Click to expand...
Click to collapse
Thank you. Although it is off-topic: I talked to Google support (Germany) and they were absolutely not helpful. On the contrary, after I told them that I unlocked it to flash the previous image they told me, that as I have voided my waranty the could not guarantee that the tab will be replaced. And: they won't tell me (even after I asked twice), which options I'll have and what they will costcost, if it's a problem due to unlocking thus not covered by guarantee. That was no nice exceperience so far.

Well, if it turns out that Google/Asus refuses to do anything for you (seems hard to imagine, but I suppose all things are possible) and they return the tablet to you in the same condition, send me a PM or come back to this thread.
best

bftb0 said:
Well, if it turns out that Google/Asus refuses to do anything for you (seems hard to imagine, but I suppose all things are possible) and they return the tablet to you in the same condition, send me a PM or come back to this thread.
best
Click to expand...
Click to collapse
Hi I have almost the same problem, the thing is I'm using Mac and i don't have pc.
And my mac can't recognize my n7. I have installed TWRP v2.4.3.0
Please advice me.
Thank you

coszy said:
Hi I have almost the same problem, the thing is I'm using Mac and i don't have pc.
And my mac can't recognize my n7. I have installed TWRP v2.4.3.0
Please advice me.
Thank you
Click to expand...
Click to collapse
fastboot and adb work perfectly on the Mac.
http://developer.android.com/sdk/index.html
In fact, of the three platforms (Windows, Linux, Mac) setting up fastboot/adb on the Mac requires the least effort.

stuck on google logo after factory reset
My Nexus 7 locked up, got it to the recovery screen and did a factory reset. now I am stuck in a loop... it opens to the black screen with GOOGLE and stays there. I can get it to the bootloader screen but nothing more. Help please... I am NOT tech saavy!

mac20132 said:
My Nexus 7 locked up, got it to the recovery screen and did a factory reset. now I am stuck in a loop... it opens to the black screen with GOOGLE and stays there. I can get it to the bootloader screen but nothing more. Help please... I am NOT tech saavy!
Click to expand...
Click to collapse
I sent mine to Google and got a new one ...

[Solution] Customize or update the factory image for stock recovery

The stock recovery on the Nook Simple Touch has a routine to restore the device to factory state, wiping everything in the process. It is initiated on the 8th unsuccessful boot (unsuccessful := interrupted before the boot counter could be reset). The image is stored on the "/misc" partition, /dev/block/mmcblk0p3, as /factory.zip. On my device, it's version 1.0.1 (file size: 108460423, MD5 sum: 3ae0d4d9869330dec639a7da9c50fa72). Not very useful. So, how about customizing it? Or at least upgrading it to stock 1.2.1?
When restoring to factory state, the /cache and /data partitions are wiped independently by the stock recovery. As for the files inside the ZIP, there is no difference between the factory image and the OTA (over-the-air) update (nook_*_update.zip). The format of both files is the standard Edify ("updater-script") style. If you have your own script you can put it there for easy restoration. If you don't, you can at least upgrade the factory image there to 1.2.1, the latest version. The example is for the latter case, but all the steps will be the same, except the first one.
Please do not follow these instructions blindly. Instead, read them critically and adjust to your situation, adding extra steps such as backups where necessary. Make sure that you don't mind if everything from your device is erased in the process.
Remove B&N cruft from the ZIP update header
Start with the file nook_1_2_update.zip (get it here from B&N). Make sure you have the right file: size 121323347, MD5 sum: 30822c2927482380c325a47dc060daee. Note that while a well-formed ZIP file starts with the letters "PK" (from the initials of Phil Katz, the original developer of the ZIP format), the B&N ZIP has some proprietary gibberish at the beginning:
Code:
...............'1.2.1.24.carbon1_2.gossamer.rrdp.s70455.......XOLBsPWsxv0saXev7rdGBBrQLzdM74ai2CM4h6oD/D3S9xeKq8eFYW7j0+MgLohN4x/3tyIYaZV6YiLEi7gLXq+7XjvWV4KaTGvNw0wM6x11IPOEzYwmHryagnY91XjkfKTjwKR8XC3SkSRu4TT01DZ6lfqsw6MZO18AFz48GEjXcxKy8SQZyhA++kobYWlcC8jNa/EmkGgVJien7QJ4LvR8N5Bftk11WRTOy6+BSQQgdBh4K/i2WI0TqfpH7JC+6vNp5rb61KTXpZIMLHGyZloYca68mnn4rmr1SKqodpffgSmYI+f7DPt7RgBEkXGz20x+3kKA+OcPbd1QKvIwd+A==.........;=.
First 418 bytes of nook_1_2_update.zip. Unprintable characters replaced with dots.
Unzip and other unpackers will get through this just fine so you might not even notice it but it will prevent the file from working as factory image for the stock recovery, so let's start by getting rid of the cruft. There are at least three options here: (1) use dd(1) (UNIX shell or Windows CLI), (2) use Free Hex Editor (Windows GUI), (3) unzip and repack again. The dd command if you're lucky to have a recent version is:
Code:
dd if=nook_1_2_update.zip of=factory.zip skip=418bytes
- or -
Code:
dd if=nook_1_2_update.zip of=factory.zip iflag=skip_bytes skip=418
Option (3) will break the B&N signature on the ZIP. Theoretically, if the signature is preserved, the file should work as-is as the new factory image as it matches the key stored in the recovery). It didn't work for me but I didn't try too hard because what I want to do is to use a custom image anyway so feel free to check for yourself (skip to the last step).
Otherwise, if you are using the stock update file that you want to sign again, you need to remove the signature that is already there. Supposing your soon-to-be new factory image file is called factory.zip, the way to do it is:
Code:
zip -d -q factory.zip META-INF\CERT.SF META-INF\CERT.RSA META-INF\MANIFEST.MF
Insert your key into stock recovery RAM disk image
For customized factory.zip signed with your own key, we need to tweak the recovery image a bit.
Extract the image from the update ZIP:
Code:
unzip -j nook_1_2_update.zip ramdisk-recovery.img
Replace the file res/keys (see attachment) in the image, using XDA user Renate NST's bootutil.exe tool:
Code:
bootutil /r ramdisk-recovery.img res\keys
You can also leave the old key in place and append the new one, just make sure there is nothing in between them (not even whitespace). And here are the alternative steps to unpack and repack the image using just the standard tools, which might come handy on UNIX:
Unpack:
Code:
dd if=ramdisk-recovery.img bs=64 skip=1 | gzip -cd | cpio -id
Repack:
Code:
find . -not -name ramdisk-recovery.img | cpio -oc | gzip -c9 | mkimage -A arm -O linux -T ramdisk -C gzip -a 0 -e 0 -d - ramdisk-recovery.new.img
Now the image just needs to be installed:
Code:
adb shell mkdir /data/boot
adb shell mount -t vfat /dev/block/mmcblk0p1 /data/boot
adb push ramdisk-recovery.img /data/boot/uRecRam
adb shell umount /data/boot
adb shell rm /data/boot
Sign and install the customized factory image ZIP
Suppose our new factory image is called factory.zip. Then to sign it:
Code:
java -jar signapk.jar [B]-w[/B] testkey.x509.pem testkey.pk8 factory.zip factory.signed.zip
See the attachment below for the necessary files. Note the -w switch, which is particularly important in this case.
Now just for the installation part:
Code:
adb shell mkdir /data/factory
adb shell mount -t ext2 /dev/block/mmcblk0p3 /data/factory
adb push -p factory.signed.zip /data/factory/factory.zip
adb umount /data/factory
adb rm /data/factory
Restore to factory image to check if it works
For an easy alternative to the power button marathon:
Code:
adb shell
echo -n -e "\x08\x00\x00\x00" >/rom/devconf/BootCnt
reboot
Warning: this wipes everything, all your data on the device will be lost.
Bonus: What if you want to use your own key?
The testkey.{pk8,x509.pem} is one of these ubiquitous Android debug keys, used all around. Apparently, it was good enough for B&N as well, as they used a version of it too for their OTAs (see /system/etc/security/otacert.zip). If it's not good enough for you though, and you have your own key, the attached keys file will not work for you; instead, you need to generate the key dump in the right format for yourself using the dumpkey utility also provided in the attachment:
Code:
java -jar dumpkey.jar testkey.x509.pem >>res/keys
Replace the references to testkey with the name of your key throughout the examples. If you're doing this on Windows, remember to convert the line ending to UNIX format (CR+LF to LF), not doing so might make the key not work.
General note: If at any stage you need to debug why a key is rejected, there is a log being saved by the stock recovery under /cache/recovery/log.
Disclaimer: Please do not follow these instructions blindly, but instead adjust them to your situation. This is the minimal set of necessary actions, with any optional steps removed for the clarity of illustration. I don't do it this way myself: personally, I'd make a backup here and there, verify MD5 sums after copying large files, etc. In any case, if something goes wrong, you will have to boot from SD card and restore your device. If everything goes right, you will lose all the data on the device. These instructions are provided on an "as is" basis. I will not provide support if anything doesn't work as expected for you. Anything you decide to do based on the above instructions is your sole responsibility.

dumpkey.jar really helped, thanks for that. Had to make exponent 3 type android key else it gets rejected, if you compiled the class, can you remove that check? Out of thanks for today.

Just a short note:
"bootutil" is now called "imgutil" and can be found in the signature.
There are more options than before, but I forget which ones.

Make ROOT Permanet / System Read and Write to all Android ROMS for Tenderloin

Extracting ramdisk image to change fstab.tenderloin to make system read and write allowing permanent root access using any ROM ever created for the HP Touchpad.
I am using Ubuntu 18.04.1 LTS 64-bit (All the software is open source and free, you can get the packages necessary for your distro)
Create a folder in /home (root) name it hpboot ( on the PC ) all work is done on the PC.
Open the custom ROM zip file and extract boot.img to the created directory hpboot
Open Terminal in the hpboot directory, all the commands needs to be enter there.
Text beginning with –>># are for information only. Do not paste into the Linux terminal window.
–>># The following will extract images from boot.img file located in the hpboot direcory.
–>># Copy and paste each individual line in the Terminal window one by one and wait until each command finish processing.
dumpimage -i boot.img kernel.uImage
dumpimage -i boot.img -p 1 ram
dd if=ram of=ramdisk.img.gz bs=64 skip=1
gunzip ramdisk.img.gz
mkdir ramdisk; cd ramdisk
cpio -i < ../ramdisk.img
–>>#The ramdisk files are uncompress in the hpboot/ramdisk directory
–>>#Open file fstab.tenderloin using (text editor) change mnt_flags of/system ext4 from ro to rw
–>>#Look like this when change from (ro ) read only to ( rw ) read and write.
–>>#<src> <mnt_point> <type> <mnt_flags and options>
–>>#/dev/store/cm-system /system ext4 rw,errors=panic
–>># Save and close the fstab.tenderloin file
–>># The next 3 steps will repack the files into the ramdisk and merge Kernel to create the finish boot image.
find . | cpio --create --format=’newc’ | gzip > ../ramdiskRW.img
cd ~/hpboot
mkimage -A arm -O linux -T ramdisk -C none -a 0x00000000 -n “TENDERLOIN RW SYSTEM RAMDISK” -d ./ramdiskRW.img ./ramdisk.uImage
mkimage -A arm -T multi -C none -n “Tenderloin RW System” -d kernel.uImage:ramdisk.uImage uImage.Android_RW
–>>#Boot the touchpad into TWRP, connect to PC, copy uImage.Android_RW to the external Micro SDCard.
–>>#Select MOUNT and touch Boot, go back, touch Advanced, File Manager, touch external_sd, select uImage.Android_RW, touch Copy File, touch boot, touch select Current Folder.
–>>#You should have free space on your boot for both images. At the boot screen you will have the option of Android (with no permanet ROOT access) and Android_RW (RW System), you need to install SuperSu. You can use any of the two options or delete uImage.Android and then rename uImage.Android_RW to uImage.Android for one boot option.
You do not need to re flash the ROM, you can add this boot file and use it with your current installed working ROM.
The process works for all boot.img created for the HP Touchpad. If you have a ROM and would like to have system read and write access then you can do this.
Hopefully a Linux Guru will create a script for this, which will automate the process to 3 seconds!

I like tinkering with my TP but I am running @Windows 7 on a 32 bit.. any suggestions?

Android is base on Linux OS.
Install vmware player and run ubuntu as a virtual machine, both are free.

--SNIP--
Hopefully a Linux Guru will create a script for this, which will automate the process to 3 seconds!
Click to expand...
Click to collapse
Here's a shell script that automates the process (rename the extension from .txt to .sh). Put the script and boot image file in any directory and type
Code:
./rwcreate.sh
If it doesn't execute, it probably needs its permissions changed.. Right click the file you created, select 'properties'. In the properties window, select "Permissions" and check "allow executing as ..." or type
Code:
chmod +x rwcreate.sh
in a terminal window

Thanks for your help and dedicating your time to make it easier for others.
I made suggestion to the script on correcting an error, on DU forum.
Now is just a click to get it done, but if we were in a perfect computer world, it could be even easier as to connect the HP Touchpad to PC using USB.
Then run the script and everything is complete!
Using adb pull command to get (boot.uImage) from hp boot directory, to PC.
Changes are done as per script.
adb push command new boot.uImage to hp boot directory, all done!
But making it easier, will make it more complicated and having to install more software and confusing!

HP_TOUCHPAD said:
Thanks for your help and dedicating your time to make it easier for others.
I made suggestion to the script on correcting an error, on DU forum.
Now is just a click to get it done, but if we were in a perfect computer world, it could be even easier as to connect the HP Touchpad to PC using USB.
Then run the script and everything is complete!
Using adb pull command to get (boot.uImage) from hp boot directory, to PC.
Changes are done as per script.
adb push command new boot.uImage to hp boot directory, all done!
But making it easier, will make it more complicated and having to install more software and confusing!
Click to expand...
Click to collapse
Done. Thanks.

shumash said:
Done. Thanks.
Click to expand...
Click to collapse
The script on this forum is correct, but in the DU the file was wrong, corrected now.
Thanks for the fix and help!