I am trying to make the Galaxy Xcover 4 boot automatically when power is connected. The model number is SM-G390F. I have rooted the device through ODIN/CF Auto Root found on androidmtk (apparently I cannot post links yet due to being a new user).
My first thought was to use fastboot ("fastboot oem off-mode-charge 0"), but since the phone doesn't have fastboot that option is out of the question. I have searched the forums, and found some threads mentioning that I should modify the /system/bin/lpm file. Specifically, the suggestions I found were to replace the contents of the /system/bin/lpm file with
Code:
#!/system/bin/sh
/system/bin/reboot
I tried the above, but to no avail. After changing the /system/bin/lpm file with the above contents, making sure that the file uses Unix EOL characters (no carriage returns, only line feeds), and giving it the correct permissions, the phone just displays an empty battery icon (as opposed to a battery charging animation) upon inserting the power cord, and doesn't boot. It also makes it so that the physical power button stops working; I now have to boot via volume-/home/power. Does anyone have any suggestions or solutions?
Thanks!
In the end I managed to accomplish what I wanted to, but I had to do it in a very fiddly way. Posting it here for future reference for anyone else who might have similar troubles.
The TLDR: I had to edit some init.*.rc files found on the ramdisk. The problem with editing these files directly is that as the name implies, any changes made to the ramdisk during runtime aren't persisted. So what I had to do was to extract the boot partition of the device as an ".img" file onto my development computer, modify a few init.*.rc files, repack the changes as a .img file, and flash it back onto the phone.
Extracting the boot partition
To extract the boot partition, I first found where it is:
Code:
> ls -l /dev/block/platform/13540000.dwmmc0/by-name
lrwxrwxrwx 1 root root 21 2018-08-06 11:00 BOOT -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 2018-08-06 11:00 BOTA0 -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 2018-08-06 11:00 BOTA1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 21 2018-08-06 11:00 CACHE -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 20 2018-08-06 11:00 CARRIER -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 21 2018-08-06 11:00 CDMA-RADIO -> /dev/block/mmcblk0p13
...
As we see, the boot partition lies in /dev/block/mmcblk0p10. So the next step was to
Code:
cat /dev/block/mmcblk0p10 > /sdcard/boot.img
which resulted in a boot.img in the /sdcard/ directory, which I then copied onto my development PC.
Unpacking boot.img
To unpack boot.img, I used a program called Android Image Kitchen. I still cannot post links, so just search for it. After unpacking boot.img, I got a folder called "ramdisk" which contained, among other things, a bunch of init.*.rc files.
Editing the init.*.rc files
I had to make changes to two files, init.rc and init.samsungexynos7570.rc.
For init.rc, I made the following changes:
Removed the lpm service. Example:
Code:
#service lpm /system/bin/lpm
# class charger
# critical
Removed the "on charger" trigger.
Added the following trigger:
Code:
on property:ro.bootmode=charger
trigger late-init
and for init.samsungexynos7570.rc I made these changes:
Removed the lpm service.
Removed the "on property:ro bootmode=charger" triggers.
Repacking the edited ramdisk
To repack the edited ramdisk I once again used Android Image Kitchen.
Flashing the modified ramdisk
To flash the modified ramdisk I used ODIN version 3.12.5. In order for it to be flashable through ODIN the .img file needs to be turned into a .tar file. I used 7zip for this. It is also very important that .img file is called "boot.img" before being tar-ed. Not sure if the .tar file has such stringent naming requirements as well.
The phone now boots automatically when connecting power (if powered off). Caveat: The touch screen does not work when booting via connecting power, but for my own specific scenario this is not a problem as I am going to use the phone as a kiosk device without touch functionality. To enable the touch screen I suspect I just need to preserve some of the stuff in the init.samsungexynos7570.rc file that I initially removed.
Does the device also turn on when you try to power it off if it is still plugged in?
Related
Hi all,
I'm after a system.img that's going to allow me to run adb shell sessions as root. That's all I need. I don't need any of the normal phone fuctions or devices. I'd imagine disabling these would overcome any incompatibility issues... but I don't know.
Naturally, it'd be easier if such an image already existed, but I should be able to follow instructions on how to reconfigure a normal system and pack it to yaffs2 image.
How about the ramdisk of most custom recoveries- or is that too spare? It will give you a kernel, adb, and busybox if you are lucky.
sent from my android tablet
gee one said:
How about the ramdisk of most custom recoveries- or is that too spare? It will give you a kernel, adb, and busybox if you are lucky.
Click to expand...
Click to collapse
As long as I can do an adb shell as root then it's good enough.
I haven't found any compatible custom recovery images that I can flash. Everything I read seems to endup point to clockworkmod and I can't find flashable images for that. It seems to be flashed through rom manager only. I'm probably wrong though.
Depending on your device, there are several ways to flash. These may or may not apply to you:
1) some recovery installer app that you can download, similar to rom manager, or even rom manager itself!
2) a zip file that you make or modify yourself
3) flash through the staging partition, which may or may not be available on your device
4) copy directly into a recovery partition
5) who knows?
What device are you using and what rom and recovery are you using?
Sorry, I should have given you some info about my situation.
My phone is a chinese mt6516 iClone: W008+. It's currently without a working system partition so I flash images via pc using Mediatek flash tool.
For a recovery, I'd need an image file to flash directly. For a system partition I could flash and image file or I can pack a dir structure into a yaffs2 image file for flashing.
That seems above my paygrade... when you say image file, do you mean a packed boot.img that starts with ANDROID!
sent from my cyanogen(mod) vision
gee one said:
That seems above my paygrade... when you say image file, do you mean a packed boot.img that starts with ANDROID!
Click to expand...
Click to collapse
Well, a boot.img would go on the boot partition for booting into android normally. A recovery.img would also start with ANDROID but would go on the ... er... recovery partition. A system image would be different starting something like:
Code:
03 00 00 00 01 00 00 00 ff ff
Ok, it looks like the system.img is yaffs.
I was asking about the boot partition because most recovery images are just boot.img's with the recovery binary in the ramdisk. I made a boot.img once from a recovery partition and flashed it, so I had two recoveries on the same device, and no system! I thought this might be something of what you are looking for. You won't have or need a system since everything will load from the boot.img.
sent from my cyanogen(mod) vision
Yes, anything that gives me a root shell via adb would be good. It's just a question of finding something appropriate to try...
Are there any roms or system images available for your device now? Or can you pull the boot.img from your current device.
sent from my cyanogen(mod) vision
I can't find anything 3rd party for it. But I do have a boot.img that I extracted.
Send me a link and I'll poke around. Do you have a way to flash the boot.img?
sent from my cyanogen(mod) vision
Nice one.
This was ripped with dump_image:
boot.zip
OK, I extracted the ram disk- it was in an odd format. They sure talk funny.
ramdisk_2bb4ad9697.tar
So all the inits are for a fully working system, which you don't have. I guess the next step would be to strip out the inits to just a few basic mount points and then have it start adb. After that, add busybox and whatever goodies, repack it, and then flash away.
I really don't know my way around the init files, so it's mostly hack and slash. If you have any insight on how to strip them down, let's hear it. I'll try to read up on how linux boots. Also, knowing the partition mounts would be helpful, although I suppose you could figure that out with adb, if this actually works.
Cheers for that. Looks quite intriguing... I'm going to need a good deal more reading to make use of it though.
OK, here is a first stab- I modified the default.prop and added busybox and su. I did not touch any of the init's.
Here is the default.prop- insecure and adb enabled. I didn't change the inits, but it does look like they will start adb. They will probably fail to start everything else that it expects to find in system and frameworks, so your syslog will probably be littered with error messages, if there is even a syslog.
Code:
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.secure=0
ro.allow.mock.location=0
ro.debuggable=1
persist.service.adb.enable=1
Here is the ramdisk. I added busybox and su. I'm not sure if these will be helpful, but I figured it couldn't hurt.
edit: I just realized that /xbin is not in the path. "export PATH $PATH:/xbin" should fix it?? "/xbin/busybox --install /system/xbin" should install busybox to /system/xbin.
Code:
total 212
-rw-r--r-- 1 root root 20175 2012-03-08 18:26 advanced_meta_init.rc
drwxrwx--x 2 root root 4096 2012-03-08 18:26 data
-rw-r--r-- 1 root root 118 2012-03-08 20:11 default.prop
drwxr-xr-x 2 root root 4096 2012-03-08 18:26 dev
-rwxr-x--- 1 root root 107436 2012-03-08 18:26 init
-rwxr-x--- 1 root root 5828 2012-03-08 18:26 init.factory.rc
-rwxr-x--- 1 root root 1677 2012-03-08 18:26 init.goldfish.rc
-rwxr-x--- 1 root root 2263 2012-03-08 18:26 init.mt6516.rc
-rwxr-x--- 1 root root 20514 2012-03-08 18:26 init.rc
-rw-r--r-- 1 root root 5529 2012-03-08 18:26 meta_init.rc
drwxr-xr-x 2 root root 4096 2012-03-08 18:26 proc
lrwxrwxrwx 1 root root 11 2012-03-08 18:34 res -> /system/res
drwxr-x--- 2 root root 4096 2012-03-08 20:16 sbin
drwxr-xr-x 2 root root 4096 2012-03-08 18:26 sys
drwxr-xr-x 2 root root 4096 2012-03-08 18:26 system
drwxr-xr-x 2 root root 4096 2012-03-08 18:06 temp
drwxr-xr-x 2 root root 4096 2012-03-08 20:16 xbin
./data:
total 0
./dev:
total 0
./proc:
total 0
./sbin:
total 368
-rwxr-x--- 1 root root 138372 2012-03-08 18:26 adbd
-rwxr-x--- 1 root root 107436 2012-03-08 18:26 advanced_meta_init
-rwxr-x--- 1 root root 103116 2012-03-08 18:26 meta_init
-rwxr-x--- 1 root root 18012 2012-03-08 18:26 meta_tst
./sys:
total 0
./system:
total 0
./temp:
total 0
./xbin:
total 828
-rwxrwxr-x 1 root root 821340 2012-03-08 20:14 busybox
-rwsr-sr-x 1 root root 22364 2012-03-08 20:15 su
I did not change the kernel at all. The kernel and ramdisk have a 512 byte header file- it seems to have a file marker, size of package, and type of partition encoded into it. I'm not even sure this is android? I am certainly NOT an expert at this. For the record, I know nothing about the device that you have. I didn't even google it to see if was indeed an android phone.
All that being said, I will be surprised if this works and I would not be surprised if you end up with a brick. If it were my device, I would only flash this if I had a 100% bulletproof way to flash the stock boot.img externally without relying on the software on the phone. There is no system or frameworks, so it will most likely look like a stuck boot, but adb should be enabled. There is no boot animation or friendly little green android to greet you. I don't know if more stuff is needed in bin or sbin?
Now the disclaimers-
Code:
[SIZE="5"][COLOR="Red"][B]ALL WARRANTIES REGARDING
MERCHANTABILITY AND FITNESS OF PURPOSE,
EXPRESSED OR IMPLIED, ARE DISCLAIMED.
Flashing this boot image can cause
loss of data, loss of device, inability to use device,
spontaneous bricking, and other grave consequences.
Use at your own peril.
If anything bad happens, it's not my fault.[/COLOR][/B]
[/SIZE]
.
Good Luck! If in doubt, don't flash it!
https://rapidshare.com/files/1856533633/boot_adb_4026ab44b0.img
Well, I can't say I understand what you've done here but...
I've now got a working phone with root adb. Brilliant!!! Thanks.
I had to flash another system image (meant for a different phone) so that I could get a shell working otherwise I'd get a 'can't find /system/bin/sh' error. But having done that, it works a treat. The system still needs a bit of work to get my phone as it should be but that's another story.
I'm really interested in how you've managed to do this. How do you unpack/repack the boot.img? I'd love to mess about with this and see how long it takes to blow my phone up. I tried to follow one guide on the net but it just wasn't happening.
Ok, I found the ROOTFS section and pulled it out. So I can see how it all fits together.
According to 7zip, this is a 'Cpio' archive inside a 'Gzip' archive. What's 'Cpio'?
That's the funny part- there is a 512 byte header that has a few id characters, the file size and then "ROOTFS". The kernel image is similar. All the android parts that I've pulled apart didn't have the 512 byte header.
If you strip that out, then you will have a gzipped cpio archive. You can extract it with "gunzip -c <the ramdisk> | cpio -i"
To recompress it, "find . | cpio -o -H newc | gzip >> ../your-new-ramdisk"
You'll have to reattach the 512 byte header and adjust the file size.
sent from my cyanogen(mod) vision
Well I got round to having a little play with this. Thanks for the info Gee, it's been filed safely.
I looked at the recovery image and the init.rc doesn't do alot; Ideal starting place. Nothing is mounted by default so I put a couple of commands to mount /sdcard and /system normally just to test it. I also had to enable adb in the default.prop file as you did before. This was pretty straight forward and worked. I got into adb shell with root, no problem.
Now I thought it would be ideal if I could mount the sdcard as /system and put '/bin/sh' on the sdcard. Androids sh isn't a link like it is on Linux so I thought this should work. It didn't! On issuing the 'adb shell' command, I got:
Code:
link_image[2030]: failed to link /system/bin/sh
CANNOT LINK EXECUTABLE
So I thought I'd try the cache partition. I copied /bin/* to /cache, put the mount commands for /sdcard and cache as /system and this time... I got the same error. I'm surprised the cache partition didn't work. I was able to 'adb pull' the /system/bin/ files from it so I don't know why adb couldn't just execute one of them???
I don't know what to try next as I don't want to be forced to have the system partition mounted just for the sake of adb finding sh. I wouldn't mind if I could just umount it once I'm in the shell... but that would be to easy, wouldn't it.
I flashed a I9100 firmware on my I9100M on bell and now I don't have the M on the bootlogo anymore. Also, the bell stock download mode start directly to downloading, but now it ask for downloading or cancel with volume up/down.
Does anybody have a way to fix this (like have the original boot.bin, sbl.bin and param.lfs from bell firmware I9100MUGKG2) because I downloaded the original firmware and these files are not included.
If you have a rooted I9100M running stock firmware, use this step and upload me the file please:
adb shell
$ su
# dd if=/dev/block/stl6 of=/sdcard/param.lfs bs=4096
or you can use terminal emulator if you prefer (remove adb shell).
The param.lfs will be in your internal sd card.
But if you have all the file I ask (if you did a nandroid backup with CWM before upgrading or modding the phone), please upload for me.
I need warranty and now my phone isn't stock.
Thankx
Download full stock rom from Samfirmware.com & extract the files yourself.
NLSGS2beast said:
I flashed a I9100 firmware on my I9100M on bell and now I don't have the M on the bootlogo anymore. Also, the bell stock download mode start directly to downloading, but now it ask for downloading or cancel with volume up/down.
Does anybody have a way to fix this (like have the original boot.bin, sbl.bin and param.lfs from bell firmware I9100MUGKG2) because I downloaded the original firmware and these files are not included.
If you have a rooted I9100M running stock firmware, use this step and upload me the file please:
adb shell
$ su
# dd if=/dev/block/stl6 of=/sdcard/param.lfs bs=4096
or you can use terminal emulator if you prefer (remove adb shell).
The param.lfs will be in your internal sd card.
But if you have all the file I ask (if you did a nandroid backup with CWM before upgrading or modding the phone), please upload for me.
I need warranty and now my phone isn't stock.
Thankx
Click to expand...
Click to collapse
I too have a simular problem, I dont need to send it in for warranty but am wanting to get the Sbl.bin file and param.lfs for Bell Canada's GT-i9100M phone, I downloaded the old GB KG2 FM and also have the new ICS LD3 FM and none contain the Sbl.bin file or the param.lfs that Bell uses.
I have access to another i9100M that has not been changed with anything custom, does anyone know of a way that I can get the Sbl.bin data and how to get the param.lfs off of another phone?.
Thank you.
OK I think I figured this out, I found out the partitions to backup by listing them by name
Code:
[email protected]:/sdcard # ls -l /dev/block/platform/dw_mmc/by-name/
lrwxrwxrwx 1 root root 20 May 12 21:24 CACHE -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 May 12 21:24 DATAFS -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 May 12 21:24 EFS -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 May 12 21:24 FACTORYFS -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 May 12 21:24 HIDDEN -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 20 May 12 21:24 KERNEL -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 20 May 12 21:24 MODEM -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 May 12 21:24 PARAM -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 May 12 21:24 RECOVERY -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 20 May 12 21:24 SBL1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 May 12 21:24 SBL2 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 21 May 12 21:24 UMS -> /dev/block/mmcblk0p11
Then I just did a dd on partitions 2 and 3 I didn't do the param because I have modified my boot logo and know enough from changing it before Hellcats easy app to know it is not specific to the phone since it has all variant logos at the same time and it shows the correct one by file name.
shadowofdarkness said:
OK I think I figured this out, I found out the partitions to backup by listing them by name
Code:
[email protected]:/sdcard # ls -l /dev/block/platform/dw_mmc/by-name/
lrwxrwxrwx 1 root root 20 May 12 21:24 CACHE -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 May 12 21:24 DATAFS -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 May 12 21:24 EFS -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 20 May 12 21:24 FACTORYFS -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 May 12 21:24 HIDDEN -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 20 May 12 21:24 KERNEL -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 20 May 12 21:24 MODEM -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 May 12 21:24 PARAM -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 May 12 21:24 RECOVERY -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 20 May 12 21:24 SBL1 -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 May 12 21:24 SBL2 -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 21 May 12 21:24 UMS -> /dev/block/mmcblk0p11
Then I just did a dd on partitions 2 and 3 I didn't do the param because I have modified my boot logo and know enough from changing it before Hellcats easy app to know it is not specific to the phone since it has all variant logos at the same time and it shows the correct one by file name.
Click to expand...
Click to collapse
Lol I was on the toliet and found the directory too, I already found out that the MMCBLK's where the data to dump and was cross refernceing from PIT file information, but then low and behold looking by name confirmed for sure which one, however how did you extract the exact data from those mmcblocks? , when I do a data partition dump, it dumps the whole partition so for example the param.lfs partition is 8MBs, how were you able to access the specific data and convert it/get it out of those blocks?, I will need to repeat this process on my family members phone so that I can get the param file, also how did you tar them up so that they are Odin flash-able?.
Also will it be fine to flash both sbl 1 and 2 bins just as they are and will Odin properly flash them in the correct sections? or should I just use sbl1 to be safe and rename it to sbl.bin ?(since that is how it comes in firmware packages etc)
In my picture here I was using Yaffs Explorer app but the options are very limiting.
dbzgod said:
Lol I was on the toliet and found the directory too, I already found out that the MMCBLK's where the data to dump and was cross refernceing from PIT file information, but then low and behold looking by name confirmed for sure which one, however how did you extract the exact data from those mmcblocks? , when I do a data partition dump, it dumps the whole partition so for example the param.lfs partition is 8MBs, how were you able to access the specific data and convert it/get it out of those blocks?, I will need to repeat this process on my family members phone so that I can get the param file, also how did you tar them up so that they are Odin flash-able?.
Also will it be fine to flash both sbl 1 and 2 bins just as they are and will Odin properly flash them in the correct sections? or should I just use sbl1 to be safe and rename it to sbl.bin ?(since that is how it comes in firmware packages etc)
In my picture here I was using Yaffs Explorer app but the options are very limiting.
Click to expand...
Click to collapse
I didn't do anything special and those should be entire partition images. I doubt that tar is Odin flashable since the filenames will be off. I just put them in a tar.bz2 by right clicking the files on my Desktop and selecting compress since xda wouldn't allow me to attach bin files
shadowofdarkness said:
I didn't do anything special and those should be entire partition images. I doubt that tar is Odin flashable since the filenames will be off. I just put them in a tar.bz2 by right clicking the files on my Desktop and selecting compress since xda wouldn't allow me to attach bin files
Click to expand...
Click to collapse
Ah okay, yeah thats what I was able to do as well just got copys of the partitions from 2 ways, one was using the partition raw dump that makes a .raw file from within Yaffs Explorer, and the second was just using the shell cmds
dd if=/dev/block/mmcblk0p4 of=/sdcard/param.lfs
dd if=/dev/block/mmcblk0p2 of=/sdcard/Sb1l.bin
dd if=/dev/block/mmcblk0p3 of=/sdcard/Sbl2.bin
So now im thinking that they probably arnt Odin flash-able and what I will half to do is just:
dd if=/sdcard/param.lfs of=/dev/block/mmcblk0p4 to copy them over? or would that be bad/corrupt the the mmc partitions?
The raw data dumps from Yaffs Explorer makes them just to be their names mmcblk0p4.raw so would it be better to just use those raw dumps instead when copying over to the dev/block section?
Ever wanted to backup your device without the hassle of flipping SD cards or USB sticks?
Maybe there is no TWRP recovery available for your device but you still want to make a backup?
Why not use the computer directly over your network?
All you need is a rooted device, might work without root but I never tried.
I always disliked that TWRP does not include user data in a backup.
And at some stage I got sick and tired of botting into recovery and flipping SD cards, so I tried this:
Connect a USB cable to the box and use ADB to make a backup.
As you guessed it the box does not really support this
No fastboot either
Then I remembered that ADB works over the network too and to my surprise the box agreed to let me use it.
As said I only test on my X96 but the same should work on most if not all Amlogic boxes.
Please see this as a work in progress as I would like to encourage more people to use this way of making backups.
It could also be a very easy way to provide modded firmwares as there is no need for a custom recovery.
Simply create your firmware and then make a backup, if you want even with all userdate included - just make sure to remove account, network and other personal settings first
I think you know hat I mean
But how exactly do we make use of this now?
Download the supplied archive and unpack to a folder on your PC - I named it tools so we have a reference here..
I have a fully working SDK, Java and all on my system but assume the tools should work as standalone versions too.
Start your box and check your IP in the network settings - you need it.
Open a command prompt with Admin rights in the Tools folder.
Now type adb connect YOURIP where YOURIP is the IP address of the box.
For example adb connect 192.168.1.9
The deamon will start and connect to your box, you can confirm by typing adb devices.
It will show the IP as a connected device.
Now, of course we could use some weird commands and type them into our command prompt...
I suggest to simply type backup and press enter
This will start the batch file that creates images of the following partitions:
Boot
Bootloader
Recovery
System
After this it will create a folder "sdcard" in the Tools folder and copy your userdata from the internal memory there.
The backup is complete now.
I inlcuded another batch file (backup_all) which tries to create images of all accessible partitions that I find on the OTA firmware.
Here the loop and mmcblk partitions are excluded as I assume there should be no real need for them.
With this you have full backup to restore a messed up device assuming the mount points and partitions were not changed by your modded rom.
The last (backup_all_full) includes all available partitions and some might not be fully accessible, so only try if you must and have enough space on your drive.
Again, not all partitions might work, try at your own discretion.
If you only want to backup and restore the userdate then please use the userbackup and restore files.
Restore:
I only included a restore.bat to write the following partitions:
Boot
Bootloader
Recovery
System
Plus the created userdata.
This will only work if the rom you tried out did not change vital parts of the system layout.
For example if the device tree blob, partition sizes, mount points were not changed from the original.
As long as you use roms designed for your device it will always get you back and running.
Of course you need to be able to get an IP connection through ADB - if that no longer works you have to flash the original firmware with the Amlogic tools.
The backup of the internal memory can laways be copied back to a working device.
What to expect from all this?
Nothing really! It is a simple creation with no additional checks, you could say "quick and dirty".
It should work for all X96 models that run the OTA firmware or one of my mods.
For other devices you might have to change the partition names in the batch files.
In my case they are found in /dev/block/, so a simple ls /dev/block from the ADB shell will give you these names.
IMHO the real benefit apart from having a complete backup directly on the computer is for people without a TWRP recovery.
Not only can you get all you need to port one but you can also modify your system by using the image files in a ROM kitchen (or do it manually).
If you like the idea then please check your system and try it out!
Upload or post your modifications to the batch files together with the device name and type so other can benefit too.
Let me know how it works!
Edit:
Changed the batch files a bit to get the best possible speed and added Testdisk for those who want to check the created image files.
All batch files starting with X96 are the current ones, the old ones are still included for reference.
Download the backup tools here.
Hello man, quite an interesting tool you've developed!! Lemme bother you with an issue I'm having please
I have the x96, a newer version, I suppose, than the one you have. Its running on Android 7.1. I'm trying to backup using your method, thing is, when I type backup in the console, after successfully connecting through adb to my box, I get the message "Simple ADB backup for the X96 by Downunder35m" , no logs in the console nor nothing(its been like that for half an hour). Am I doing something wrong there? adb devices echoes my device correctly. The device in stake is normally powered on, not in recovery mode, should it be on recovery mode?? should I be seeing logs in the console? what is the usual approximate time it should take? I know it depends on the local network speed and all, but It'd be cool to have an estimate...
Thanks!!!
ismasasoel said:
Hello man, quite an interesting tool you've developed!! Lemme bother you with an issue I'm having please
I have the x96, a newer version, I suppose, than the one you have. Its running on Android 7.1. I'm trying to backup using your method, thing is, when I type backup in the console, after successfully connecting through adb to my box, I get the message "Simple ADB backup for the X96 by Downunder35m" , no logs in the console nor nothing(its been like that for half an hour). Am I doing something wrong there? adb devices echoes my device correctly. The device in stake is normally powered on, not in recovery mode, should it be on recovery mode?? should I be seeing logs in the console? what is the usual approximate time it should take? I know it depends on the local network speed and all, but It'd be cool to have an estimate...
Thanks!!!
Click to expand...
Click to collapse
i havent checked his batch file but im assuming your device has different partitions.
just do it manually. heres a couple links and some simple directions.
This link covers it all: https://forum.xda-developers.com/showthread.php?t=2450045
simply get Adb, connect with IP. Adb shell, then su.
The key is to find your directory with your partitions by name.
Try looking in these directory with this command
Code:
ls -al /dev/block/platform/*
Your looking for output like this
Code:
drwxr-xr-x 3 root root 400 2014-12-31 19:00 .
drwxr-xr-x 3 root root 60 2014-12-31 19:00 ..
lrwxrwxrwx 1 root root 15 2014-12-31 19:00 boot -> /dev/block/boot
lrwxrwxrwx 1 root root 21 2014-12-31 19:00 bootloader -> /dev/block/bootloader
drwxr-xr-x 2 root root 300 2014-12-31 19:00 by-num
lrwxrwxrwx 1 root root 16 2014-12-31 19:00 cache -> /dev/block/cache
lrwxrwxrwx 1 root root 16 2014-12-31 19:00 crypt -> /dev/block/crypt
lrwxrwxrwx 1 root root 15 2014-12-31 19:00 data -> /dev/block/data
lrwxrwxrwx 1 root root 14 2014-12-31 19:00 env -> /dev/block/env
lrwxrwxrwx 1 root root 15 2014-12-31 19:00 logo -> /dev/block/logo
lrwxrwxrwx 1 root root 15 2014-12-31 19:00 misc -> /dev/block/misc
lrwxrwxrwx 1 root root 18 2014-12-31 19:00 mmcblk0 -> /dev/block/mmcblk0
lrwxrwxrwx 1 root root 23 2014-12-31 19:00 mmcblk0boot0 -> /dev/block/mmcblk0boot0
lrwxrwxrwx 1 root root 23 2014-12-31 19:00 mmcblk0boot1 -> /dev/block/mmcblk0boot1
lrwxrwxrwx 1 root root 22 2014-12-31 19:00 mmcblk0rpmb -> /dev/block/mmcblk0rpmb
lrwxrwxrwx 1 root root 19 2014-12-31 19:00 recovery -> /dev/block/recovery
lrwxrwxrwx 1 root root 19 2014-12-31 19:00 reserved -> /dev/block/reserved
lrwxrwxrwx 1 root root 14 2014-12-31 19:00 rsv -> /dev/block/rsv
lrwxrwxrwx 1 root root 17 2014-12-31 19:00 system -> /dev/block/system
lrwxrwxrwx 1 root root 14 2014-12-31 19:00 tee -> /dev/block/tee
In that example my system is /dev/block/system
so I use this to copy it to internal sd card
Code:
dd if=/dev/block/system of=/sdcard/system.img
This isnt detailed, read that link. Good Luck!
X96 mini backup problem
Hello! The following problem arises with me: When writing on the console "adb connect 192.168.3.194", it says the following
D: \ X96 ADB Backup Restore> adb connect 192.168.3.194
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
unable to connect to 192.168.3.194:5555: can not connect to 192.168.3.194:5555: H
a connection could be established because the target computer actively denied it. (10
061)
and I can not bind to boxing. What does this mean. Is boxing any protection set up?
Hi guys. Does any of you know how to push su.d directory into su folder? I mean I need radio.sh script in su/su.d to get root call sms manager working. Every time I try it disappears after reboot.
Rooted rom 34.3.A.0.217 with TWRP.
Anyone?
It's late though, but for the guidance of other noobs like me. /su/su.d/ can't be flashed in recovery because this isn't available. For system-less roots, binaries/libraries required to start supersu daemon and to manage root permissions, don't reside in /system/bin but in /data/su.img while (at least) two files reside in boot.img i.e. boot.img/ramdisk/init.supersu.rc and boot.img/ramdisk/sbin/.*daemonsu*.sh. When ROM boots, init.supersu.rc mounts /data/su.img on /su directory and calls /sbin/*daemonsu*.sh for initial setup which starts /su/bin/daemonsu and other se-linux related stuff and then executes any scripts found in /su/su.d/ and /system/su.d.
You can find this:
Code:
mido:/ # mount | grep loop
/dev/block/loop0 on /su type ext4 (rw,seclabel,noatime,data=ordered)
So, the init.d scripts placed in /su/su.d actually reside in /data/su.img which isn't mounted in recovery mode and anything flashed to /su/su.d goes to volatile rootfs which is gone on reboot. Either mount su.img in recovery, or place this script while ROM is running or instead flash to /system/su.d which is permanent filesystem unlike rootfs (which lives in RAM). And finally don't forget to set permissions to 0700 as advised here. Another thing, mostly init.d scripts don't work with .sh extension. Avoid this too.
In Samsung Devices PARAM Partition Location Can Be Different. Before You Get PARAM.bin file You Need To Locate Correct Partition.
1. Run These Commands
adb shell
ls /dev/block/platform
In Results you can find blocks (ex: 13540000.dwmmc0/ 13560000.dwmmc2/ -Result can be Different in your device)
2. Now Run ls Command against these blocks to get partition names by-name
ls /dev/block/platform/<insert block here without <> ex:13540000.dwmmc0>/by-name
Repeat This Command Until you find a partition List that Contain PARAM
Now You Can Dump and Pull Partition
AUPMA said:
In Samsung Devices PARAM Partition Location Can Be Different. Before You Get PARAM.bin file You Need To Locate Correct Partition.
1. Run These Commands
adb shell
ls /dev/block/platform
In Results you can find blocks (ex: 13540000.dwmmc0/ 13560000.dwmmc2/ -Result can be Different in your device)
2. Now Run ls Command against these blocks to get partition names by-name
ls /dev/block/platform/<insert block here without <> ex:13540000.dwmmc0>/by-name
Repeat This Command Until you find a partition List that Contain PARAM
Now You Can Dump and Pull Partition
Click to expand...
Click to collapse
greeting, p.s i attached the image in case heat read a lot.
1- thanks for your efforts. but when follow the instruction, the second command line
"ls /dev/block/platform" return "soc.0". when try run third command line "ls /dev/block/platform/soc.0>/by-name" it return nothing, as appears in attached screenshot .
2- my phone is j500h. the palam file (10 MiB "Mebibytes" = 10.5 MB file without any extension) is stored in "/dev/block/bootdevice/byname" and also stored in "/dev/block/platform/soc0/7824900.sdhci/byname". i take copy from this file using file manager app with root premsion but i can not find any way to extract it. also the blocks stored in "/dev/block/platform/soc0/7824900.sdhci/byname".
3- i try reset your command to match my phone storage. so i use this command "ls /dev/block/platform/soc.0/7824900.sdhci" and the result was 29 block+by-name folder.
but when i try the scond command "ls /dev/block/platform/soc.0/7824900.sdhci/mmcblk0>/by-name", i get nothing.
any help to solve this are very welcome
Hi, I'm trying to kill off the annoying Samsung unlock warning on my Tab A 8.0 LTE SM-T295.
On another post , I got some support to get close to the param.bin file. I was schooled to type this in a command window:-
I was then passed a comment that my param.bin file is located in the "mmcblk0p47" section
SM-T295 - Finally rooted tablet!! (updated 19-March-2021)
I have root on my SM-T295 A8 tablet!! See my new post: How to Install TWRP and Root T295 Update 19 March 2021 Tested on T295XXU3BUC3 ROM Prerequisites: Bootloader unlocked - search forums.xda-developers for instructions how to do this. OEM...
forum.xda-developers.com
...but from here I'm lost.
Can anyone lead me towards the right string of actions to kill off this annoying unlock warning ?