I'm starting this thread to document the work on creating a custom recovery image for the Tattoo.
The main goal is to provide a recovery image that will serve as the launchpad for flashing custom roms.
The Tattoo Custom Recovery Image will provide:
1) A way to use an update.zip signed with test-keys (already accomplished);
2) A way to perform a full backup of mtd2,mtd3,mtd4 and mtd5 (boot,system,cache and data).
3) A way to perform a full restore of the backup achieved by 2);
4) Adb support (already accomplished);
4.1) Adb shell support.
I'm open to input about using nandroid. Right now, without a S-OFF/ENG SPL this looks useless.
Also, if you have any other special need for recovery, please feel free to express it
Alpha release
Tattoo's Custom Recovery Image, Alpha Release
This first release includes:
- ADB enabled recovery
- ADB enabled root shell
- Accept update.zip signed with test keys
- All partitions mounted
- Custom recovery program (the last two options are stubs, not really working yet)
- Included in /sbin: busybox, flash_image and BART
- I've not used BART and, at the moment, cannot attest if it works or not.
- Backup script in /sbin/backup.sh
- Restore script in /sbin/restore.sh
With this custom recovery you can now do a full backup of your unit, by dumping the mtd block devices to your sdcard. Afterwards, you can use flash_image to recover your Tattoo to it's previous state.
I'm releasing this image as is. This is not a point-and-click recovery tool. If you don't know what you're doing, you can seriously damage your unit. The only reason I'm releasing this is in an effort to provide other devs with a way to easily recover their units, back to day-to-day configuration, while experimenting with them.
To flash:
Copy TCRI.alpha.img to /sdcard.
Run "flash_image recovery /sdcard/TCRI.alpha.img"
To reboot into recovery (quickest way)
adb reboot recovery
Please comment
thanks for you work
i try to flahs and get permission denied, do you know why?
flash_image: permission denied
chusen said:
i try to flahs and get permission denied, do you know why?
Click to expand...
Click to collapse
Partition remounted writeable from a fresh rebooted system with the tattoo-hack.ko module inserted??
But I'm sure you did that before because of:
I'm releasing this image as is. This is not a point-and-click recovery tool. If you don't know what you're doing...
Click to expand...
Click to collapse
;-)
-bm-
Thank you very much for your excellent job
Someone could install custom alpha recovery?
thx
@-bm-:yes I will try that way since the beginning. i mount with rw permissions /system and /data. i know is not a point-and-click recovery tool but i think i need more permissions but where?
Where did you guys get your flash_image binary from ?
The error you're getting is from flash_image, not from my recovery image.
I'll attach the flash_image I've been using to this post.
Please tell me if this solves your problem. You need tattoo-hack.ko module inserted, if you're using a release kernel.
Edit: You have the correct permissions in your flash_image binary, right ? After pushing it to the device, don't forget to chmod 755
It works I like drawing, jejeje.
Backup and Restore functionality appears to have no further
The adb root shell is perfect
Very good Work
for when the beta version? and the final version? lol
I try to dump the system userdata and boot.img and when i try to extract with unyasffs and i get this when i try to extract system.img
Code:
4 [main] unyaffs 3940 handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
644 [main] unyaffs 3940 open_stackdumpfile: Dumping stack trace to unyaffs.exe.stackdump
and this with others
Code:
broken image file
Code:
[email protected]:~/Tattoo/images/boot/1$ ../../unpack.pl ./boot.1.img
Page size: 2048 (0x00000800)
Kernel size: 1899580 (0x001cfc3c)
Ramdisk size: 160952 (0x000274b8)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1 console=null
Writing boot.1.img-kernel ... complete.
Writing boot.1.img-ramdisk.gz ... complete.
528 blocks
[ boot.1.img-ramdisk.gz decompressed to boot.img-ramdisk ]
My image dumping script is OK
Take a look here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
The boot.img is not a yaffs2 image. It's a special format, comprised by a 2k header, a kernel image and a ramdisk.
The system.img is a yaffs2 image. From unyaffs's homepage: "Unyaffs is a program to extract files from a yaffs file system image. Now it can only extract images created by mkyaffs2image."
Chusen, I think it would be better to create a new thread for this, since it doesn't concern the custom recovery image directly.
Thank god for custom recovery!
Now we can really start cooking ROMs... gonna break out the tools tonight and get Android 1.6/2.1 sources ready to compile.
leon1984 said:
for when the beta version? and the final version? lol
Click to expand...
Click to collapse
You tell me
Next in line is to tie the backup/restore scripts to the UI, which won't be too hard.
Later, I may mess around with nandroid and bart, to see if they provide something more than my scripts.
Afterwards, when we have some custom roms available, I may create a downloader/updater option, to make it easier to install those.
Also, I'm taking requests for new features
suggestions about scripts
Excellent work, mainfram3. Thank you.
I have extracted the img file, and check backup.sh and restore.sh scripts. The code for checking sdcard remaining space is done. Here it is:
Code:
## TEST: Check free space in sdcard
NEED_KB="200000"
REM_KB=`du /sdcard | awk '{print $6}'`
if [ ${REM_KB%K} -lt $NEED_KB ]; then echo "Not enough space in /sdcard, exiting"; exit; fi
backup space min set to 200MB.
There is another suggestion about restore.sh. Because of backing up img to /sdcard/Backup, $1 might not be needed, right?
mainfram3 said:
Code:
[email protected]:~/Tattoo/images/boot/1$ ../../unpack.pl ./boot.1.img
Page size: 2048 (0x00000800)
Kernel size: 1899580 (0x001cfc3c)
Ramdisk size: 160952 (0x000274b8)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1 console=null
Writing boot.1.img-kernel ... complete.
Writing boot.1.img-ramdisk.gz ... complete.
528 blocks
[ boot.1.img-ramdisk.gz decompressed to boot.img-ramdisk ]
My image dumping script is OK
Take a look here: http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images
The boot.img is not a yaffs2 image. It's a special format, comprised by a 2k header, a kernel image and a ramdisk.
The system.img is a yaffs2 image. From unyaffs's homepage: "Unyaffs is a program to extract files from a yaffs file system image. Now it can only extract images created by mkyaffs2image."
Chusen, I think it would be better to create a new thread for this, since it doesn't concern the custom recovery image directly.
Click to expand...
Click to collapse
and if you want to extract the boot.img here are the two scripts you need to fully extract the kernel(zImage) and ramdisk
split_bootimg.pl
and
extract-ramdisk.sh
they are attached below
jamezelle:
extract-ramdisk.sh missed #!, and the ramdisk zip file should be passed to $1 of this script.
mainfram3 said:
1) A way to use an update.zip signed with test-keys (already accomplished);
Click to expand...
Click to collapse
Hi mainfram3,
I don't want to jack your thread - could you add a little elaboration on this point, or provide a URL so I can learn a little more? The SPL on the phone (oem-78 or fastboot mode) accepts updates signed with the test key from the SDK? (Or some other key?) (On the Eris, the "rom.zip" files unpacked by the RUU are prepended with a mystery blob of 256 bytes - s'pose it could be a mic/sig, but if that's what it is, it don't appear to be in a standard DSA/RSA format, and those .zip files are not signed using the .apk/.jar manifest-signing method)
FYI here's an entertaining story of an epic fail in a related area. After reviewing the fastboot sources from the android tree, I decided that I wanted to spy on the (Windows) RUU update program by sniffing the USB bus - in particular to see if it was explicitly passing signatures in .sig files. (That's an undocumented command-line behavior in fastboot.)
Turns out that recent versions of libpcap and Wireshark allow for USB bus capture on Linux - and using the "usbmon" kernel module in Ubuntu 8.04 LTS, sniffing the USB (5k packet size) seems to work without hitch, even at USB 2.0 speeds. So I took it one step further, and installed WIn Xp SP3 in a QEMU VM on the Ubuntu machine, with the intention of running the RUU updater inside the Xp VM and sniffing the USB bus in the host OS (Linux) machine.
The result? QEMU/Win Xp VM can talk to the phone in either fastboot or adb mode, but bluescreens as soon as you start to move data at any appreciable rate. Doesn't seem to be dependent on whether monitoring is taking place. I might try putting the phone behind a cheapo USB 1.1 hub, and see if that helps, but for the moment I am stopped out on this hack.
bftb0
cn.fyodor said:
jamezelle:
extract-ramdisk.sh missed #!, and the ramdisk zip file should be passed to $1 of this script.
Click to expand...
Click to collapse
it works yea sorry about the
#/bin/sh
i didnt write the scripts btw
In case it's unclear, I have CM7 on eMMC and am setting up a Honeycomb/Phiremod dual-boot on SD, and would like all three ROMs to use the storage partition (7th in this case) on the card. The following post suggests to me that it's possible:
racks11479 said:
No need to root your stock nook. If you have a CM7 sdcard, root explorer or file expert(free from market), and a terminal emulator app. Which you should have with cm7. Try the following steps.
-using root explorer or file expert. Mount system as R/W
-open up a terminal emulator and run the following commands
Code:
$ su
# mkdir /mnt/nooksys
# mount /dev/block/mmcblk0p5 /mnt/nooksys
-now exit out of terminal emulator
-open up root explorer/file expert
-navigate to /mnt/nooksys
-you should now be able to see the stock nook system partition
-open up the /etc directory
-long press the vold.fstab file.
-it should give you an option to open with text editor
-change the line where it mounts the /sdcard from auto to 4
-exit out of root explorer
-reboot to stock
-it should now mount the 4th partition of your sdcard
Click to expand...
Click to collapse
The file path specified, however, did not work, and I don't know enough about linux in general or the specific file structures to figure out the necessary changes. The system I want to redirect is the CM7.1 beta running dalingren's 5/13 OC kernel.
I also don't know for sure whether the above works for redirecting a stock 1.2 install.
Hi everyone, I modified the stock uRamDisk for CM11 by decompressing it, editing the fstab.encore.rc file, and switching up the part with sdcard0 and sdcard1.
P.S. I removed the zram (compressed RAM) option in the fstab because the Nook Color has a crappy enough CPU as is, so it wont help with zram. Use a swap partition on SDcard if needed.
P.S.2. This ramdisk is from the most recent nightly build (Jan 11, 2015). It may or may not work with older CM11 builds.
It's attached here. It wont let me upload the file as is, so I renamed it to uRamDisk.7z; rename it back to uRamDisk. After that, follow these steps:
0. MAKE A BACKUP OF THE /boot PARTITION IN YOUR RECOVERY JUST IN CASE. If anything happens, restore the /boot partition's backup.
1. Mount /boot partition at /root (it's an unused mountpoint in Android)
adb root && adb shell
# mount -t vfat /dev/block/mmcblk0p1 /root
2. Change directory to /root, rename the original ramdisk
# cd /root && mv uRamDisk uRamdisk.orig
3. Copy over the new ramdisk
adb push uRamDisk /root/
4. Reboot and profit
The internal sdcard will now be seen as external. You no longer need to have an SD card inside to have many apps like Kodi (XBMC), Firefox, etc, asking for external SD.
If it doesn't work for you for some reason, remount the /boot partition again, and copy over the original uRamDisk ( # cp -f uRamDisk.orig uRamDisk ).
I used parts of this script to figure out how to mod the ramdisk: https://gist.github.com/aperezdc/6533546
Any feedback on this one?
les02jen17 said:
Any feedback on this one?
Click to expand...
Click to collapse
Huh, what do you mean? If you have feedback for me, please do post it.
hi,could you compile a flasheable zip file?because many people like me dont know how to use adb or you can explain these steps a bit better, other thing is that i cant change the name to uramdisk(i cant delete .7z) windows 7 and winrar wont let me
btw good work!!
omars44 said:
hi,could you compile a flasheable zip file?because many people like me dont know how to use adb or you can explain these steps a bit better, other thing is that i cant change the name to uramdisk(i cant delete .7z) windows 7 and winrar wont let me
btw good work!!
Click to expand...
Click to collapse
1. Do you have adb installed for Windows? If not, do that first.
2. I don't know how to make a flashable zip. Someone else might. Anyone wanna do that? I don't have time atm since college started. Sorry for the late reply.
3. The instructions are about as simple as they get. You should study the "mount," "cp," and "mv" commands. They are, respectively, for mounting partitions, copying files/folders, and moving/renaming files/folders.
4. You can't rename the file because by default, Windows doesn't show file types' endings (like .exe, .zip, .rar, etc). You need to enable that. Google it.
hello, maybe you still have this nigtly cm11 system of 11Jan, 2015? thank's
I was experimenting how to modify system files on a stock system image without installing superuser and thought I'd share what I found:
What you need:
android platform tools (ADB and related files, FASTBOOT)
custom recovery (I used TWRP). You need to be able to gain adb root access, which is not possible using a 'production' image (to quote google's error message when I tried this) which is why you need to have a custom recovery. WARNING!! If you perform an oem unlock of your device to unlock the bootloader, you will be forced to wipe your device, proceed at your own risk! I am not responsible for what you do with your device.
Administrator access on your pc (if using windows)
In my example I was modifying /system/etc/gps.conf to use local time servers for faster GPS lock. To do this I rebooted into my custom recovery, mounted the system partition (rw) and used:
Code:
adb pull /system/etc/gps.conf
I then edited the file locally to use the desired NTP server with notepad++.
following this I used:
Code:
adb push gps.conf /system/etc/gps.conf
At this point I rebooted and used:
Code:
adb shell
to run the cat command on /system/etc/gps.conf and confirm my updates were now visible in the updated gps.conf file.
Hi friend! Can you help me?
C:\adb>adb push gps.conf /system/etc/gps.conf
failed to copy 'gps.conf' to '/system/etc/gps.conf': Read-only file system
reijr said:
Hi friend! Can you help me?
C:\adb>adb push gps.conf /system/etc/gps.conf
failed to copy 'gps.conf' to '/system/etc/gps.conf': Read-only file system
Click to expand...
Click to collapse
In TWRP mount system
I've used this before to change my build.prop
After updating to the latest build on Nexus 5, this no longer works.
I can pull and push the build.prop boot on reboot the original file returns.
Any ideas ?
There have been quite a bit of people with issues with Systemless root, there are some apps that are not recognizing root, i had this issue with my Oneplus One on COS 13.1 and now the same thing works with our OnePlus 3 on OxygenOS
I had come across this on another forum, i don't recall where so i don't want to take the credit for this, i just want to provide the fix for people who have this phone and having issues
Download Terminal from app store and type
Code:
su
mount -o remount,rw /system
touch /system/bin/su
mount -o remount,ro /system
reboot
Thank you ! Before I try this , can you tell me what this method is doing ? All I can tell is that it is mounting something as read only instead of read write
I belive it creates a dummy file bc some apps require it to show as a system file
SDMU said:
Thank you ! Before I try this , can you tell me what this method is doing ? All I can tell is that it is mounting something as read only instead of read write
Click to expand...
Click to collapse
Code:
1. su
2. mount -o remount,rw /system
3. touch /system/bin/su
4. mount -o remount,ro /system
5. reboot
1. To get root privileges
2. Remounts /system partition in writable mode
3. Creates an empty file called su to /system/bin/ folder
4. Remounts /system partition to read only mode.
5. reboot
Edit. As stated above, some apps still check root access by looking su file in /system/bin folder
Squabl said:
1. To get root privileges
2. Remounts /system partition in writable mode
3. Creates an empty file called su to /system/bin/ folder
4. Remounts /system partition to read only mode.
5. reboot
Edit. As stated above, some apps still check root access by looking su file in /system/bin folder
Click to expand...
Click to collapse
This defeats the purpose of a system less su, I.e., not modifying the system partition. Step 3 modifies the system partition.
The reason apps are not seeing the su in system less state is because they have been written incorrectly. Chainfire already said these apps should be re written
candiesdoodle said:
This defeats the purpose of a system less su, I.e., not modifying the system partition. Step 3 modifies the system partition.
The reason apps are not seeing the su in system less state is because they have been written incorrectly. Chainfire already said these apps should be re written
Click to expand...
Click to collapse
Yes, it "disables" systemless root and afterwards it is just a root and banking apps and ota updates etc will fail. I don't need systemless root so I have modified my system partition to get some poorly coded apps to function. This method is not recommended if you need systemless root and it's a good thing that you pointed that out!