• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root Returning a Rise to the stock build

O

oliver

Newbie
Can someone help me with a procedure on returning my Rise (on Virgin Mobile running 1.004VM) to the stock build?

The original system/recovery/boot images are on this site (can't post links yet) but I'm assuming I only need to copy the system one back into place.

The phone is currently rooted and I've messed with so many things (removed system apps; converted 3rd party apps to system; modified boot animation etc) that I could never undo it manually.

I'm giving the phone away which is why I'd like it to be vanilla.

Here's what I plan on doing:
1) run 'factory reset' from the phone to remove my personal data
2) linux$ adb push mmcblk0p12 /sdcard/mmcblk0p12 (to push the system image to the SD card)
3) linux$ adb wait-for-device shell (get an adb shell)
4) shell@android:/ $ su (get root)
5) root@android:/ # dd if=/sdcard/mmcblk0p12 of=/dev/block/mmcblk0p12 (to copy the image over)
6) reboot the phone

One thing worries me a little - I ran dd on the recovery partition and was expecting it to match the file in the downloadable bundle of images but 'diff' told me they differed. Not sure whether that means I messed something up or whether it means I somehow modified the real recovery data.

Other open questions I have are:
a) should the phone be booted up as normal when the dd is run? Seems like the system partition should be unmounted for dd to successfully run - but I'm not sure how to put it into any kind of recovery mode where adb will see the device
b) I realise everything has risk, but does what I'm doing sounds reasonably safe (barring typoes etc)?
c) any reason to also dd the recovery/boot images?

Edit - one more thing. Can the images be mounted on a loop device to view the contents?
 
2 things: First, the images that were posted on my compilation thread are not factory images, I Have yet to develop a route to capture a factory image on the VM Rise so I do not expect them to be so. That being said, you usually only have to remove the su binary and if the user who uploaded the image did anything special like install busybox, custom /system apps or a init.d system for example would make it very complicated to get it back to factory.

Secondly there is no currently known way to flash one of those system images very well, after we found out that the Virgin Mobile version of the phone is locked out of bootloader mode, we are unable to boot into any sort of recovery environment so it would be very complicated to flash it (albeit there is a way involving the editing of install-recovery.sh to stop services and unmount the system partition and getting creative about flashing the image) and it could end up bricking your phone. I would suggest going through your system partition and looking at dates where the files were edited, and remove them to change them back to stock.
tl;dr (I don't like my rambling either)
a. It should not be ran while the system is mounted and you are correct. There is currently no known way to boot into recovery, you would have to manually stop services reliant on the system partition and unmount the device.
b. In any normal situation it would be, but the rise has a locked bootloader and if you mess up your system partition you could be bricked for good.
c. The phone refuses to write to the kernel and recovery block devices using normal means
Response to edit: That is a great idea, but there are variables that could wrong. mounting a loop device would allow you to replace files that are not currently in use, and there is a good chance that the files you changes are not in use (unless you have set up an init.d system, in which case I would trust you understand how to remove it)

So my final suggestion would be to just remove the su binary and any non OEM apps on /system. Most people wouldn't notice busybox or a init.d system or anything else not apparent.

Also, as a reminder to future readers of this, we are on the verge of making this whole situation much easier and I would strongly suggest looking into it more than just taking my current word for it. For example on sprint based phones one can simply use the fastboot tool in bootloader mode to launch a temporary recovery image and do this so much easier.
 
Well, if we took system images of a freshly rooted VM rise that had not had any other alterations, I think that would be about as close to stock as you could get. It doesn't solve the problem of overwriting the system partition while it's mounted however.
 
cooldudezach said:
Well, if we took system images of a freshly rooted VM rise that had not had any other alterations, I think that would be about as close to stock as you could get. It doesn't solve the problem of overwriting the system partition while it's mounted however.
Click to expand...

My guess would be flash the partitions from the Sprint rise(all but the system, data, cache and boot). Then the reboot bootloader command should work. then run modified recovery with fastboot boot... then flash all the vm partitions with adb while in recovery...it's so risky tho highly experimental and I'm not even sure that 1 you have enough time while in modified recovery and 2 that the vm rom will work with the Sprint firmware...
 
smartmanvartan said:
My guess would be flash the partitions from the Sprint rise(all but the system, data, cache and boot). Then the reboot bootloader command should work. then run modified recovery with fastboot boot... then flash all the vm partitions with adb while in recovery...it's so risky tho highly experimental and I'm not even sure that 1 you have enough time while in modified recovery and 2 that the vm rom will work with the Sprint firmware...
Click to expand...

True. I was thinking maybe we could get away with just flashing the Sprint bootloader onto the VM rise and seeing what happens. Although, I'm not sure if the bootloader resides entirely on just one partition.

EDIT:
Also, you have to remember that some of the partitions contain device sensitive data, so it would not be the best idea to just start flashing everything across devices.
 
cooldudezach said:
True. I was thinking maybe we could get away with just flashing the Sprint bootloader onto the VM rise and seeing what happens. Although, I'm not sure if the bootloader resides entirely on just one partition.

EDIT:
Also, you have to remember that some of the partitions contain device sensitive data, so it would not be the best idea to just start flashing everything across devices.
Click to expand...

Since the partitions layout is the same on both c5155i would say it would probably work but your right...but the bootloader has different stages we haven't fully mapped out on different partitions...like I said its really risky..maybe leave out misc and carrier too....
 
smartmanvartan said:
Since the partitions layout is the same on both c5155i would say it would probably work but your right...but the bootloader has different stages we haven't fully mapped out on different partitions...like I said its really risky..maybe leave out misc and carrier too....
Click to expand...

I did manage to map out all but 6/7 and 9-11

[HIGH]mmcblk0p1: AMSS.MBN (the baseband?)
mmcblk0p2: I'm pretty sure this one is for the radio(modem?).
mmcblk0p3: OSBL (Couldn't find much info about this. Seems to be a download mode of sorts)
mmcblk0p4: This is simply an extended partition table. Nothing fancy.
mmcblk0p5: Bootloader (aboot)
mmcblk0p6/7: (empty)
mmcblk0p8: Boot
mmcblk0p9-11: no idea
mmcblk0p12: System
mmcblk0p13: Cache
mmcblk0p14: Persist
mmcblk0p15: Recovery
mmcblk0p16: FOTA (for over the air) (no, f doesnt stand for for)
mmcblk0p17: Sysprop
mmcblk0p18: Carrier
mmcblk0p19: System crash logs
mmcblk0p20: Data
mmcblk1p1: Sdcard[/HIGH]
 
smartmanvartan said:
no they would be on other partitions..I just meant because its a weird place to put the radio.. maybe p9 to p11...
Click to expand...

ah, gotcha. I have no idea. p1 is a mountable image. Most of the others are not.

Here is the partition table with partition types:
[HIGH] Disk /dev/mmcblk0: 7948 MB, 7948206080 bytes
1 heads, 16 sectors/track, 970240 cylinders, total 15523840 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/mmcblk0p1 1 65536 32768 c W95 FAT32 (LBA)
/dev/mmcblk0p2 * 65537 66560 512 4d QNX4.x
/dev/mmcblk0p3 66561 69120 1280 46 Unknown
/dev/mmcblk0p4 69121 3907584 1919232 5 Extended
/dev/mmcblk0p5 73728 81919 4096 47 Unknown
/dev/mmcblk0p6 81920 90111 4096 5d Unknown
/dev/mmcblk0p7 90112 98303 4096 58 Unknown
/dev/mmcblk0p8 98304 114687 8192 48 Unknown
/dev/mmcblk0p9 114688 131071 8192 50 OnTrack DM
/dev/mmcblk0p10 131072 139263 4096 4a Unknown
/dev/mmcblk0p11 139264 147455 4096 4b Unknown
/dev/mmcblk0p12 147456 770047 311296 83 Linux
/dev/mmcblk0p13 770048 1589247 409600 83 Linux
/dev/mmcblk0p14 1589248 1605631 8192 83 Linux
/dev/mmcblk0p15 1605632 1622015 8192 60 Unknown
/dev/mmcblk0p16 1622016 1736703 57344 61 SpeedStor
/dev/mmcblk0p17 1736704 1753087 8192 83 Linux
/dev/mmcblk0p18 1753088 1835007 40960 83 Linux
/dev/mmcblk0p19 1835008 1859583 12288 62 Unknown
/dev/mmcblk0p20 1859584 3907583 1024000 83 Linux [/HIGH]Maybe this will help? QNX is a special partition type, but my linux kernal isnt built with it into it, so I cant read/mount it. Couldn't find much on SpeedStor or OnTrackDM. Obviously no info about the Unknown formats.

Doing some quick research on the partition ID's gives some more (mostly non-helpful) information:

[HIGH]
Block ID Format
p2: 4D QNX
p3: 46 EUMEL/Elan
p5: 47 EUMEL/Elan
p6: 5D NOTHING FOUND
p7: 58 NOTHING FOUND
p9: 50 Ontrack Disk Manager, read-only, FAT (Logical sector size varies)
p10: 4A ALFS/THIN lightweight filesystem for DOS
p11: 4B NOTHING FOUND
p16: 61 Storage Dimensions SpeedStor
[/HIGH]Sources for this:
FreeBSD Partition Types (Paultastic.com)
Partition types: List of partition identifiers for PCs

Partition 2 is where everything starts booting from, if only we could open it up. I dont know how to build a custom linux kernal though. -_-
 
dtalley11 said:
a. It should not be ran while the system is mounted and you are correct. There is currently no known way to boot into recovery, you would have to manually stop services reliant on the system partition and unmount the device.
Click to expand...

Thanks... this sounds like a little more than I want to risk right now :-)

I'm hardly an expert but I ran fuser on /sdcard and it told me pid 1 was running... so if I kill that in order to umount, my phone will presumably reboot. Oh well.

edit - tried killing pid1 with -9 and nothing happened so I assume it respawned rather than reboot the phone. Essentially the same result, just more graceful
 
Wow! This thread exploded!

I have been working on finding out if there is a way to stop all running services and init, modify some early scripts and the run the scripts again (init.rc). In all reality this is all we need for a good recovery. There is something called 2nd-init but the phone reboots when going through the init scripts again.

Also, FOTA stands for Firmware Over-the-Air, it's sometimes used in the OTA update process.
 
I've been racking my brain trying to remember who posted an interesting method for mounting partitions on Android devices... the procedure involved booting into a adb enabled recovery and mounting any of the partitions to the sd card and then you can pull from the sd card to your pc with adb and essentially retrieve what is in any partition. I don't remember the specifics and who posted this...
 
well if I had to do this I would probably make a script like this as /system/etc/install-recovery.sh:

PHP: 
#!/system/bin/sh
if [ -f "/data/copy"]; then
    #mount rootfs as writable
    mount -wo remount rootfs /
	#give us a way to do commands once system is unmounted
    cp /system/xbin/busybox /sbin/busybox
	#make busybox executable
	chmod 777 /sbin/busybox
	#stop services
    stop ueventd
    stop console
    stop stopmanager
    stop vold
    stop netd
    stop debuggerd
    stop ril-daemon
    stop wvnvd
    stop surfaceflinger
    stop zygote
    stop drm
    stop media
    stop bootanim
    stop dbus
    stop bluetoothd
	#unmount system
	/sbin/busybox/umount /system
	#flash new partition
	/sbin/busybox/dd if=/data/mmcblk0p12 of=/dev/block/mmcblk0p12
	#get ready for stage2, to fix any issues that could cause a brick
	rm /data/copy
	touch /data/stage2
	/sbin/busybox/reboot
fi
if [ -f "/data/stage2"]; then # might wanna nest another if in here to make sure system is not mounted otherwise this could send you off into a loop
    mount -o loop -t ext4 /data/mmcblk0p12 /system  #this command is off, I don't have the time to fix it
	rm /data/stage2
	#adb shell should work now if something didn't go right you can fix it
fi

By relying on /data/copy and stage2 to be there, you can easily get out of any problem this script may dircetly cause by simple doing a factory reset, the only thing we can do with stock recovery
 
You must log in or register to reply here.
Back
Top Bottom