I'm having trouble with fastboot (see my thread here: https://forum.xda-developers.com/xperia-xz1-compact/help/issues-fastboot-t3971227, maybe you can help). However, I can seem to flash sony signed software in sony-service mode using newflasher. That's nice, but I haven't used stock android in years. I am very used to lineageos without gapps---nice and clean. So, for me, until I get rid of stock and get a clean flash of lineage, I'm really not happy.
Given my state of affairs, I'm wondering about flashing one of the exploitable sony stocks and to get root, then flashing the recovery partition with twrp from userland. Then, potentially, i could boot to that recovery and maybe (idk) flash a new system ROM. Does anyone have any tips or suggestions?
It should work as you outlined.
Still having BL unlocked and not usable fastboot seems like a major disadvantage to me.
Did you try with different PC to see if it is not due to usb chipset or something?
Preferably using usb 2.0 only chipset?
Maybe trying that from different OSes too - linux vs win?
Thanks for the reply. I got the exploitable firmware downloaded and flashed as well as your renosploit kit. Hasn't found a root shell yet although I'm hopeful it will eventually (I haven't read the details but I understand that the underlying vuln is a race condition).
One question: I suppose that given that tmp root status, it should be possible to copy a su binary over and make root permanent, that would make experimentation easier, I think. And if whatever I try fails the first time I wouldn't want to have to wait for the race condition exploit every time I wanted to reboot. Am I on the right track? If so, I suppose I need to either compile or download a su binary and possibly a supersu.apk in order to manage it. Are those already available for the xz1 compact?
@apexofservice, planting su binary is possible into /oem for example, it would switch the user to root, but without any better permissions, due to selinux, so it is useless.
But since you have your BL unlocked, you do not need that. As soon as you have twrp, you can flash magisk to have root on runtime easily. Or just enter twrp to have root in recovery.
j4nn said:
@apexofservice, planting su binary is possible into /oem for example, it would switch the user to root, but without any better permissions, due to selinux, so it is useless.
But since you have your BL unlocked, you do not need that. As soon as you have twrp, you can flash magisk to have root on runtime easily. Or just enter twrp to have root in recovery.
Click to expand...
Click to collapse
Got it. Thank you for this detail. So you think my best bet is to just use the root shell to `dd` the twrp image directly to some /dev? And then I would just `adb reboot recovery` and in theory I'm good to go.
Cool. I got a root shell with your exploit kit. I've got two questions at this point.
1) If my bootloader unlock had fully succeeded, would I have expected to find all 0x0 in the TA partition? In fact, there is data in there, so I went ahead and downloaded it. I skimmed the data with xxd and there are some sections of 0x0 as well though.
2) Second question, I've read that xperia's don't have a proper "recovery" partition the way some other boards do. So is FOTAkernel actually where I want to write twrp.img? Also, it would seem that this info is actually encoded somewhere in the fastboot client since on a working fastboot, you can just say "flash recovery" and it knows what part of the disk to write to. Any info about partition layouts on lilac and xperia's in general would be greatly appreciated.
apexofservice said:
Cool. I got a root shell with your exploit kit. I've got two questions at this point.
1) If my bootloader unlock had fully succeeded, would I have expected to find all 0x0 in the TA partition? In fact, there is data in there, so I went ahead and downloaded it. I skimmed the data with xxd and there are some sections of 0x0 as well though.
2) Second question, I've read that xperia's don't have a proper "recovery" partition the way some other boards do. So is FOTAkernel actually where I want to write twrp.img? Also, it would seem that this info is actually encoded somewhere in the fastboot client since on a working fastboot, you can just say "flash recovery" and it knows what part of the disk to write to. Any info about partition layouts on lilac and xperia's in general would be greatly appreciated.
Click to expand...
Click to collapse
1 - The TA partition contains significant amounts of other information as well. So it won't be empty.
The standard way of dealing with it is to not mess with it at all.
2 - The FOTAkernel is the recovery.
2a - The partition layout can be found from the stock firmware image in the "partition-image-LUNZ_X-FLASH-ALL-C93B.sin" file where "Z" is the LUN number. Once you extract the SIN file, you're left with an EFI partition header.
I've attached a CSV file that contains the layout as specified in the "partition-image-LUN0_X-FLASH-ALL-C93B.sin" file.
The layout for LUNs 1 and 2 both contain a single 4MB partition for "xbl" and "xblbak" respectively, so they're not as interesting.
@pbarrette, thanks! I tried the naive approach:
Code:
d if=twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img of=/dev/block/bootdevice/by-name/FOTAKernel <
60128+0 records in
60128+0 records out
30785536 bytes transferred in 2.100 secs (14659779 bytes/sec)
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # reboot recovery
Alas, it just rebooted back to system. It did seem to take a bit longer, so it's possible that it tried to boot from FOTAKernel and failed then fell back to system. I've just got a new root shell so I can look in startup logs from dmesg to see if there's anything of interest.
Also, I'm probably missing something really obvious. Thanks for any insight!
Reading dmesg now, this seems quite relevant (I recall booting to recovery on my z3 compact by touching a file in /cache/recovery). I'll post it here but I'm still reading the dmesg.
Code:
[ 7.406109] bs_roots: recovery filesystem table
[ 7.406120] bs_roots: =========================
[ 7.406125] bs_roots: 0 /data ext4 /dev/block/bootdevice/by-name/userdata
[ 7.406130] bs_roots: 1 /oem ext4 /dev/block/bootdevice/by-name/oem
[ 7.406134] bs_roots: 2 /cache ext4 /dev/block/bootdevice/by-name/cache
[ 7.406139] bs_roots: 3 /rca ext4 /dev/block/bootdevice/by-name/appslog
[ 7.406143] bs_roots: 4 /idd ext4 /dev/block/bootdevice/by-name/diag
[ 7.406148] bs_roots: 5 /storage/sdcard1 vfat /devices/soc/c0a4900.sdhci/mmc_host*
[ 7.406153] bs_roots: 6 none swap /dev/block/zram0
[ 7.406157] bs_roots: 7 /persistent emmc /dev/block/bootdevice/by-name/frp
[ 7.406162] bs_roots: 8 /misc emmc /dev/block/bootdevice/by-name/misc
[ 7.406167] bs_roots: 9 /firmware vfat /dev/block/bootdevice/by-name/modem
[ 7.406172] bs_roots: 10 /bt_firmware vfat /dev/block/bootdevice/by-name/bluetooth
[ 7.406177] bs_roots: 11 /dsp ext4 /dev/block/bootdevice/by-name/dsp
[ 7.406182] bs_roots: 12 /persist ext4 /dev/block/bootdevice/by-name/persist
[ 7.406187] bs_roots: 13 /boot/modem_fs1 emmc /dev/block/bootdevice/by-name/modemst1
[ 7.406191] bs_roots: 14 /boot/modem_fs2 emmc /dev/block/bootdevice/by-name/modemst2
[ 7.406195] bs_roots: 15 auto auto /devices/soc/a800000.ssusb/a800000.dwc3/xhci-hcd.0.auto/usb*
[ 7.406199] bs_roots: 16 /qns ext4 /dev/block/bootdevice/by-name/Qnovo
[ 7.406203] bs_roots: 17 /tmp ramdisk ramdisk
[ 7.406206] bs_roots:
[ 7.408585] MR: Mounting /cache ourselves
[ 7.412318] EXT4-fs (sda53): recovery complete
[ 7.412666] EXT4-fs (sda53): mounted filesystem with ordered data mode. Opts:
[ 7.413213] MR: fopen() failed -/cache/recovery/command (No such file or directory)
[ 7.413219] MR: Unmounting /cache
[ 7.413959] MR: Fail to get command from /cache/recovery/command, trying /misc
[ 7.414272] MR: Unknown wipe command
[ 7.414280] MR: Buffer is empty from /dev/block/bootdevice/by-name/misc with command 0
[ 7.417568] MR: TA_MASTER_RESET value = 0
[ 7.418475] init: Service 'exec 3 (/sbin/mr)' (pid 605) exited with status 0 waiting took 0.022997 se
conds
[ 7.418513] init: starting service 'exec 4 (/sbin/ffu)'...
[ 7.418846] init: SVC_EXEC pid 609 (uid 0 gid 0+0 context u:r:recovery:s0) started; waiting...
[ 7.419833] init: Service 'exec 4 (/sbin/ffu)' (pid 609) exited with status 255 waiting took 0.001316
seconds
------
One more update, I did a sanity check that that dd command is actually overwriting FOTAkernel. It doesn't look like it's working:
Code:
G8441:/data/local/tmp # dd if=/dev/block/bootdevice/by-name/FOTAKernel of=FOTAKernel-extracted.img
131072+0 records in
131072+0 records out
67108864 bytes transferred in 0.812 secs (82646384 bytes/sec)
G8441:/data/local/tmp # chown shell:shell FOTAKernel-extracted.img
G8441:/data/local/tmp # dd if=twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img of=/dev/block/bootdevice/by-name/FOTAKernel
60128+0 records in
60128+0 records out
30785536 bytes transferred in 2.037 secs (15113174 bytes/sec)
G8441:/data/local/tmp # sync
G8441:/data/local/tmp # sync
=/dev/block/bootdevice/by-name/FOTAKernel of=FOTAKernel-extracted-2.img <
131072+0 records in
131072+0 records out
67108864 bytes transferred in 0.846 secs (79324898 bytes/sec)
And there's no `diff` on the device, so I pulled the files back to a laptop then:
Code:
$ diff FOTAKernel-extracted-2.img FOTAKernel-extracted.img
$ diff FOTAKernel-extracted.img twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img
Binary files FOTAKernel-extracted.img and twrp-3.2.1-0-lilac-10-patchlevel-2018-05-05.img differ
@j4nn @pbarrette doing some more reading, I found some interesting details about booting to recovery stored on FOTAKernel here:
https://twrp.me/sony/sonyxperiaxz.html
https://twrp.me/sony/sonyxperiaz3compact.html
Looks like you really need a kernel that has the ramdisk extraction setup. So I'm guessing that once I figure out why dd isn''t working as I expected (see above) that I need to overwrite the main stock kernel with an alternative.
Yes, a dd extraction of the partition will be different than the TWRP image.
That's because the TWRP image is only ~35MB, while "dd" is extracting the entire 64MB partition.
So, if you do a visual diff on the files, you should see that what's actually different is the fact that the partition extraction is filled with zeros after the end of the TWRP image.
You're doing a "reboot recovery", but have you tried:
1 - Turn the phone off
2 - Press and hold [Vol-Down].
3 - Press and hold [Power].
4 - Release [Power] at power on.
5 - Release [Vol-Down] when you see an actual boot screen (after the bootloader unlocked screen).
I don't remember the "reboot recovery" command ever working right for me.
Edit to add: That's also a really old version of TWRP that you seem to be using.
pbarrette said:
Yes, a dd extraction of the partition will be different than the TWRP image.
That's because the TWRP image is only ~35MB, while "dd" is extracting the entire 64MB partition.
So, if you do a visual diff on the files, you should see that what's actually different is the fact that the partition extraction is filled with zeros after the end of the TWRP image.
You're doing a "reboot recovery", but have you tried:
1 - Turn the phone off
2 - Press and hold [Vol-Down].
3 - Press and hold [Power].
4 - Release [Power] at power on.
5 - Release [Vol-Down] when you see an actual boot screen (after the bootloader unlocked screen).
I don't remember the "reboot recovery" command ever working right for me.
Edit to add: That's also a really old version of TWRP that you seem to be using.
Click to expand...
Click to collapse
Hot damn. Thanks, I'm booted to twrp!
Note: i was using the older version for android 8 since I'm currently on the android 8 exploitable rom!
apexofservice said:
@j4nn @pbarrette doing some more reading, I found some interesting details about booting to recovery stored on FOTAKernel here:
https://twrp.me/sony/sonyxperiaxz.html
https://twrp.me/sony/sonyxperiaz3compact.html
Looks like you really need a kernel that has the ramdisk extraction setup. So I'm guessing that once I figure out why dd isn''t working as I expected (see above) that I need to overwrite the main stock kernel with an alternative.
Click to expand...
Click to collapse
XZ1 compact never needed the recovery with this extraction stuff. But according to
https://twrp.me/sony/sonyxperiaxzpremium.html
XZ Premium (which is also yoshino platform, the same as xz1c is) seems to need that - but I am not sure if it is still valid.
It might got fixed even in xzp case with some bootloader update to have it working the same as with other yoshino phones.
Sorry for my late answer, it's good you already have it working.
But I still wonder about that usb problem with fastboot - have you tried a different pc with different usb controller, preferably usb 2.0 type (not 3.0 one)?
j4nn said:
XZ1 compact never needed the recovery with this extraction stuff. But according to
https://twrp.me/sony/sonyxperiaxzpremium.html
XZ Premium (which is also yoshino platform, the same as xz1c is) seems to need that - but I am not sure if it is still valid.
It might got fixed even in xzp case with some bootloader update to have it working the same as with other yoshino phones.
Sorry for my late answer, it's good you already have it working.
But I still wonder about that usb problem with fastboot - have you tried a different pc with different usb controller, preferably usb 2.0 type (not 3.0 one)?
Click to expand...
Click to collapse
I haven't yet. Well, I have sorta. When I first ran into issues, I tried it with a different laptop, got the same result. Now that laptop was also a thinkpad (although a newer model) and was also running debian linux. I don't have any computers with Windows. I was going to reboot this laptop with usb3.0 kernel mod blacklisted and only using hci but I didn't get around to it yet (especially once I got twrp flashed and working, then I mainly wanted to get started actually using the phone i bought ). However, if it were a usb thing, wouldn't we expect that newflasher would fail too? Still, it is very curious about the fastboot thing, however, so I'm willing to keep playing with it.
@apexofservice, I am not sure if blacklisting usb3 drivers would help. Sometime there may be present multiple usb ports, some connected to usb 3.0 host controller, others just usb 2.0 controller.
Even if newflasher works, it is not that simple, that fastboot should work too.
Fastboot (including it's usb support) is implemented in UEFI bootloader, the ABL component of it (Android Boot Loader).
So usb stack is implemented by UEFI fw.
While newflasher uses flash mode, which is running XFL - a linux (bare bone android) kernel, running the lilo/loader userspace application. So there is in my opinion quite good usb stack implemented by linux kernel.
So it can easily be some incompatibility within UEFI usb stack implementation used with fastboot.
Related
Hi Folks, Not to be left out of all the 4.1.2 Fun, Here's a little teaser of what's to come!
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
ROM STATUS: BUILD0 PREALPHA - OFFLINE - AWAITING UPDATE
Click to expand...
Click to collapse
NOTE: SEE THIS POST FOR THE LATEST DETAILED ROM INFORMATION
Click to expand...
Click to collapse
NOTE: SEE THIS POST FOR THE LATEST DEVELOPMENT INFORMATION
Click to expand...
Click to collapse
Now Go! We Make Rom Now!
NOTES: ETA? DON'T EVEN ASK! :laugh:
Great Work !
[BUILD0]Touchscreen, OpenGLES and CWM Test!
Hi Folks.
Feeling Adventurous? Then You Might want to have a quick go this OmapZoom AOSP 4.1.2 JZO54K That I've prepared It's in it very early stages but It would be help if some folks could give it blast and let me know if the TouchScreen functionality is working as my touchscreen hasn't worked for a long time and as such it is some I can't test. If the lastest version of Android wasn't enough of a draw, This rom also includes the work I've done with CWM Recovery.
BUILD INFORMATION AND DETAILS
What's BUILD0?
Good Question, Build0 ( Build Zero ) is pre-alpha release aimed at testing specific hardware functionality and software features.
Hardware - Working
Touchscreen (?!?) - The Drivers are installed so it "should" just work
Archos 3G / Huawei + Others 3G Dongles - The Hardware will be recognized but there is nothing implemented in Android user land as yet.
Hardware - Not Working
Everything else! - To be implemented in future builds[/QUOTE]
Software Information
The main software/driver focus of this build was getting the PowerVR Drivers to function to enable HW Acceleration. This has been achieved not only using the stock kernel modules ( as one would expect ) but also on test custom kernel builds. This is an area along with the Camera that has proved problematic when attempting previous ports and is something I wanted to solve early on.
Hacking On It!
Source Code Info : See Separate Post on building and source code info [ COMING SOON ]
Kernel Version : Archos Stock 3.0.21 - This will change in the next build to use a kernel with JellyBean Specific features plus some extra treats , For anyone interested in hacking on this current build I have included all the stock kernel modules, they can be found /system/lib/modules. Of course the kernel modules for most hardware is only half the story as many devices also require a binary firmware blob which is not included but can be grabbed from the Archos 3.0.25 Firmware.
StabilityThe build seems pretty stable overall but although the incorrect battery percentage do make a it wobble a little
Clockwork Mod Recovery - I will update the CWM thread with details regarding bugs and testing etc but just to say, It's seems fully functional with very few minor issues.
Installation - Please See The Installation Instructions For Details
Installation Guide
Installation Guide
STOP! HAVE YOU TAKEN A BACKUP OF YOUR IMPORTANT DATA
Although your existing data is not touched, It is advised you backup your data directory before proceeding.
Click to expand...
Click to collapse
ALL THE USUAL DISCLAIMERS APPLY, FILES ARE PROVIDED AS-IS AND WITHOUT WARRANTY ,
ITS YOUR DEVICE, YOUR RESPONSIBILITY, I'M NOT YOUR DAD!
Click to expand...
Click to collapse
Build0 - Requirements
Archos G9 SD Version
android sdk / android debug bridge ( adb )
SDE Enabled Firmware ( unofficial or official )
common sense.
NOTE: I've only tested this using Linux , The procedure should be the same on Windows but we don't know until we try.
Assumptions
1.You know how to flash a SDE initramfs and zImage either through the Developer Menu or using kd_flasher from the adb command line,
2.You know how to boot your device into the Special Developer Edition Firmware ( SDE )
3.You have setup adb correctly a your device is listed in the adb devices list.
Build0 - Installation Steps
1. Download and unpack the cwm boot image [ Hotfile :/archosg9-jzo54k-cwmboot.7z ]
2. Download and unpack the system image [ CURRENTLY OFFLINE - AWAITING UPDATE ]
3. Flash the unpacked zImage and initramfs.cpio.lzo using the [Recovery]/[Developer Edition Menu]/[Flash Kernel and initramfs] option in Archos recovery mode.
4. Reboot Into Developer Edition ; You should now see the Familiar CWM User Interface, You should see a couple of error messages regarding mounting /cache/recovery/command and /cache/recovery/log. This is expected.
5. use adb to push the unpacked system.img to the /._ directory on the device with the following command
Code:
[B]adb push system.img /._/system.img [/B]
NOTE: The system.img is 500MB in size and it may take some time for the transfer to be completed
6. When the file transfer is complete, reboot the device either using the CWM UI or adb reboot, The device should reboot back into CWM, The previous error messages will still present, Again this is the expected behaviour.
At this point, if everything is ok you should be able the use adb shell commands. Lets check the mount points using
Code:
[B]adb shell mount[/B]
The output should be as follows
Code:
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk0p1 on /mnt/rawfs type rawfs (rw,relatime)
/dev/block/mmcblk0p4 on /._ type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop0 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime)
If you see the message
Code:
- exec '/system/bin/sh' failed: No such file or directory (2) -
Then either you have not followed the instructions correctly or I've not typed them up correctly! Either way something's not right. See the troubleshooting section below for tips on how to check what's what.
7. Next we need to create a ext4 image for the cache and data partitions. This involves create an empty file with dd, loop mount the file as a block device using losetup then making the filesystem using mk2fs.ext2. Sounds like a lot of work. I thought so too, so all you need to do is run the following adb shell command
Code:
adb shell createfs
This will create a 500MB cache image and a 2GB data image. Again because of the file sizes involved this does take a couple of minutes to complete. Please be patient, when the command is completed the full output should look as follows
Code:
File System Image Creation Script - For Test Purpose Only
/dev/block/mmcblk0p4 /._
FileSystem Container /dev/block/mmcblk0p4 Mounted at /._.....
Checking Available Space.
Available Space : 5129
Creating cache image at /._/CAC With Block 500000
500000+0 records in
500000+0 records out
512000000 bytes (488.3MB) copied, 39.070434 seconds, 12.5MB/s
DD Returned 0 : Loop Mounting the raw image /._/CAC to /dev/block/loop1
Creating Ext FileSystem on /dev/block/loop1
warning: 287 blocks unused
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
125416 inodes, 499713 blocks
25000 blocks (5%) reserved for the super user
First data block=1
Maximum filesystem blocks=524288
61 block groups
8192 blocks per group, 8192 fragments per group
2056 inodes per group
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409
Creating data image at /._/DATA With Block 2000000
2000000+0 records in
2000000+0 records out
2048000000 bytes (1.9GB) copied, 175.243408 seconds, 11.1MB/s
DD Returned 0 : Loop Mounting the raw image /._/DATA to /dev/block/loop2
Creating Ext FileSystem on /dev/block/loop2
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
125184 inodes, 500000 blocks
25000 blocks (5%) reserved for the super user
First data block=0
Maximum filesystem blocks=4194304
16 block groups
32768 blocks per group, 32768 fragments per group
7824 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
8. Reboot the device. The device will once a gain reboot into CWM Recovery. This time there should be no error messages. check everyhting is mounted and created correctly using
Code:
adb shell mount
The output should look as follows
Code:
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /acct type cgroup (rw,relatime,cpuacct)
tmpfs on /mnt/asec type tmpfs (rw,relatime,mode=755,gid=1000)
tmpfs on /mnt/obb type tmpfs (rw,relatime,mode=755,gid=1000)
none on /dev/cpuctl type cgroup (rw,relatime,cpu)
/dev/block/mmcblk0p1 on /mnt/rawfs type rawfs (rw,relatime)
/dev/block/mmcblk0p4 on /._ type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/block/loop0 on /data type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1)
/dev/block/loop1 on /cache type ext4 (rw,nosuid,nodev,relatime,user_xattr,barrier=1)
/dev/block/loop2 on /system type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/sys/kernel/debug on /sys/kernel/debug type debugfs (rw,relatime)
9. Congratulations You now have Jellyean and CWM Recovery running on you device
One Last time choose "reboot system now" from the cwm menu to taste those JellyBeans!
TROUBLESHOOTING
Ok you've got problems, nothing that cannot be worked around.
Investigating
Code:
- exec '/system/bin/sh' failed: No such file or directory (2) -
If you run into this error then I means that your system.img is not present on the device or has not been mounted correctly for some reason. because of the way the device recovery is setup at the minute adb still looks for it's shell binary in /system/bin this only exists if the system is mounted. Fortunately we still have a couple of adb commands at our disposal, namely pull and push, the work around this issue you do the following [ Example uses Bash Terminal on Linux ]
Code:
adb pull /sbin/busybox
chmod +x busybox # Linux Only - Make sure busybox is still executable
adb push /system/bin/sh
You should now be able to drop into an interactive shellk using
Code:
adb shell
A further trick to make sure you have access to all the commands is to symlink the contents of /sbin to /system/bin. like so
Code:
a s "ln -s /sbin/* /system/bin"
More Troubleshooting Soon! If folks get stuck.
Development Information
It turns out, perhaps unsurprisingly that the omapzoom.org aosp repo is the one for us!
I did some light changes to the blaze_tablet device tree, which mainly involved changing the word blaze to archos .
Once again I've got the powervr drivers loading successful, because archos are using the latest version we don't have to rip them off the device as the userland binaries in the device/ti/proprietary-open.git work fine.
As this is the very first build I've scaled everything back, so what you've basically got is a booting rom to hack on. Apart from the powervr drivers everything else is untested and presumed not working. Also the kernel needs rebuilding to include tracing.
If anyone fancies hacking on this, get the source from http://omapzoom.org and the archos device tree can be found on my github. place the device files in a device/ti/archos_tablet directory.
Use the jb-mr0-release branch, I had some trouble building the development branch (jb-mr0-dev), clearly someone has committed some breaking changes.....
One more for luck
Don't you just hate it when the op does this
zImage and initramfs.cpio.lzo
I flashed the zImage and initramfs.cpio.lzo, rebooted. No CWM menu, still SDE. What should I do next, try pushing system.img anyway?
stevemp
stevemp said:
I flashed the zImage and initramfs.cpio.lzo, rebooted. No CWM menu, still SDE. What should I do next, try pushing system.img anyway?
stevemp
Click to expand...
Click to collapse
Hi There,
That's very strange. This should have replaced the existing SDE Booting Procedure, I wouldn't push the system.img quite yet
I have a couple of questions?
What Model Tablet Do You Have?
Are you running An SDE Rom Already, If so which one?
Is your SDE Official or Unofficial?
Have You Removed The Android Kernel Using the Recovery Menu Option?
Did you flash using the Recovery/Developer Edition menu option?
Are you using Windows or Linux?
Can you elaborate on "Still SDE", Do You Mean It Booted into your existing Rom?
That should be good for starters,
Thanks
trevd said:
Hi There,
That's very strange. This should have replaced the existing SDE Booting Procedure, I wouldn't push the system.img quite yet
I have a couple of questions?
What Model Tablet Do You Have?
Are you running An SDE Rom Already, If so which one?
Is your SDE Official or Unofficial?
Have You Removed The Android Kernel Using the Recovery Menu Option?
Did you flash using the Recovery/Developer Edition menu option?
Are you using Windows or Linux?
Can you elaborate on "Still SDE", Do You Mean It Booted into your existing Rom?
That should be good for starters,
Thanks
Click to expand...
Click to collapse
Archos 80 G9 OMAP 4460 1.2 Ghz 512 Mb ram [email protected]_V04
Never mind, let tablet reboot CWM menu showed up. I thought supposed to reboot into SDE.
Jelly Bean boots but touch screen not working
stevemp
stevemp said:
Archos 80 G9 OMAP 4460 1.2 Ghz 512 Mb ram [email protected]_V04
I think SDE is official, not sure how to find out.
Windows 7 64 bit.
SDE -> Developer Edition Menu -> Flash Kernel & Initramfs -> copied zImage and initramfs.cpio.lzo rebooted -> held power button and volume down -> went back to SDE -> Developer Edition Menu -> still looks the same.
stevemp
Click to expand...
Click to collapse
Ok Thanks Again for the Feedback.
I think the official SDE is watermarked! I also think we might have our wires crossed and you've misunderstood ( more likely I've not explained clearly ) Just what this is. This does NOT replace the existing Archos Recovery Menus. On technical level it is an SDE Rom which can be booted between android and recovery effectively adding an extra boot mode to SDE, This sits apart from the Archos BootMenu Stuff.
I suppose a good way to think about it is in the following structure.
Code:
Archos Boot Menu
Android
Recovery
Developer Edition -----> Android
Recovery
So You actually load the developer edition to use this recovery. Flashing and Booting these Files won't affect any other Rom/Data on the Tablet as the Partitions are self contained in there own image files. So you can easily return to [email protected] by flashing a "Classic" initramfs and kernel.
If You still can't boot into CWM You might want to have a go with the alternative flashing method using adb. It's a lot easier than all that Vol+Down Stuff.
When Booted in android, run the following commands
Code:
adb push zImage /data/local/zImage
adb push initramfs.cpio.lzo /data/local/initramfs.cpio.lzo
adb shell "kd_flasher -i /data/local/initramfs.cpio.lzo -k/data/local/zImage"
adb shell "reboot_into sde"
Thanks Again
stevemp said:
Archos 80 G9 OMAP 4460 1.2 Ghz 512 Mb ram [email protected]_V04
Never mind, let tablet reboot CWM menu showed up. I thought supposed to reboot into SDE.
stevemp
Click to expand...
Click to collapse
Beat Me Too It, See my above post.... :victory:
Oh well stands as a good explanation
Jelly Bean
Boots into Jelly Bean, touch screen not working.
Awaiting further instructions.
stevemp
stevemp said:
Boots into Jelly Bean, touch screen not working.
Awaiting further instructions.
stevemp
Click to expand...
Click to collapse
OK Thanks for the test.... To use the classic phrase, It's not you It's me , I think I'm missing some layout files, Nice to hear you got it Booted.
One piece of probably useful information I've omitted! You can boot back into CWM using adb, while booted into JellyBean use
Code:
adb reboot recovery
Recovery should be fully working, You can flash zip i.e gapps CWM-SU etc, The sdcard mount point tries to mount the external sdcard as fat32 ( for now ).
once the external sdcard is mounted you should be able to run a backup
No more instructions at the minute I'm afraid but I'll get right on it.
Once again Thanks for the Testing and Feedback, It's been very useful.
Just for Archos Gen9 SD ?
why and what kind of gen9 ?
i have 3 gen 9
8" 1ghz 16 go
10" 1.5ghz 16go
10" 1.5ghz 250go
cajl said:
Just for Archos Gen9 SD ?
why and what kind of gen9 ?
i have 3 gen 9
8" 1ghz 16 go
10" 1.5ghz 16go
10" 1.5ghz 250go
Click to expand...
Click to collapse
Should be good for all Gen9 SD's and in time HD versions as well, Can't test with HD Versions because I don't have one! :laugh:
If you want i will be testing this afternoon on the HD
and if the dl is ok
stevemp said:
Boots into Jelly Bean, touch screen not working.
Awaiting further instructions.
stevemp
Click to expand...
Click to collapse
Hi!
Touch screen driver will be ok!
I think should be ok with the curent driver from 4.0.25 !
....just let time to trevd for add this stuff! :good:
surdu_petru said:
Hi!
Touch screen driver will be ok!
I think should be ok with the curent driver from 4.0.25 !
....just let time to trevd for add this stuff! :good:
Click to expand...
Click to collapse
All ready on it. missing /system/usr/idc ( input device configurations ) , they can be pull from an existing archos rom
For those who are interested.
http://source.android.com/tech/input/input-device-configuration-files.html
http://source.android.com/tech/input/touch-devices.html
I seem to recall the wireless xbox 360 pad being added using ( i think ) this method. I'll have a quick look, I might throw that in if its not too difficult
trevd said:
All ready on it. missing /system/usr/idc ( input device configurations ) , they can be pull from an existing archos rom
For those who are interested.
http://source.android.com/tech/input/input-device-configuration-files.html
http://source.android.com/tech/input/touch-devices.html
I seem to recall the wireless xbox 360 pad being added using ( i think ) this method. I'll have a quick look, I might throw that in if its not too difficult
Click to expand...
Click to collapse
Hi!
Thanks TREVD!
A very very very good job!!! :good:
My device is it now on Service Centre for reparation ( touchscreen issue! ) for 3 , 4 week!
I can't wait to test all your stuff!
Thank's again and good luck! :good:
New universal method of rooted for the Optimus 2x
After much programming and experimenting with another great part, already I can deliver my latest work.
So far have only made for Linux and Mac. (there are methods to not be as done in CMD)
Apparently it seems very simple, but it cheats, it is quite complex, since I've programmed detection of errors and possible solutions to the problems of communication.
The program is smart, detects the operating system that we are using, Linux or iOS, and detects the version of ROM installed to determine installation done.
Also installs the CWM Recovery, and also knows which install depending on the GB ROM or ICS, all automatic, without having to think that option used.
Before you root it will ask you if the CWM Recovery is installed and if it is not you can do it at that time.
The method used is not new, I already used it in earlier versions of GB, the difference with the other methods is that you don't have to copy anything to the SD and things of these, simple and clean installation.
Well I hope that you have Linux or a Mac can root without having to boot the "tedious" Windows.
CHANGELOG
V-0.5
-Implemented detecting permissions
-Implemented detection system 32/64b
-Fixed bug, was not working in Ubuntu 11.04 and higher
V-0.4
-Detection of new possible connection failures.
-Detection of errors in routines Android
-Optimized routines
V-0.3
-Fixed bug of execution, did not work on some current versions of Ubuntu and derivatives
-New start menu.
-New header
V-0.2
-Re-raise with correction error in English language, it only pulled in Spanish
-Includes English language
-Changing the graphic appearance
V-0.1
-Only in Spanish
Click to expand...
Click to collapse
DOWNLOAD
Toolkit_ICS-Root_Stock-v-0.5_LINUX-MAC_by_Homero.rar - 13.40 MB
Thank's Man...and have a nice year 2013!!!...
Nice, it should became sticked.
Also... your program must be also noob-proof
Great work, homero! Thank you.
Sent from my LG-P990 using xda app-developers app
Homero again back with a bang...you're hulk of lg optimus forum..you rock bro
Finally some Linux love.... :thumbup:
Sent from my LG-P990 using xda app-developers app
Thanks homero
Enviado desde mi O2X
I have committed an error, and the English version, and does not run.
You can download the new corrected version or edit and modify.
Edit the root file and look for this line:
Code:
if [ "$ANSWER" = 1 ]; then
tools/es.sh
elif [ "$ANSWER" = 2 ]; then
tools/es.sh
elif [ "$ANSWER" = "x" ] || [ "$ANSWER" = "X" ]; then
Changing this:
Code:
elif [ "$ANSWER" = 2 ]; then
tools/es.sh
why another:
Code:
elif [ "$ANSWER" = 2 ]; then
tools/en.sh
Save and ready, already operates the English version
Homero2 said:
I have committed an error, and the English version, and does not run.
You can download the new corrected version or edit and modify.
Edit the root file and look for this line:
Code:
if [ "$ANSWER" = 1 ]; then
tools/es.sh
elif [ "$ANSWER" = 2 ]; then
tools/es.sh
elif [ "$ANSWER" = "x" ] || [ "$ANSWER" = "X" ]; then
Changing this:
Code:
elif [ "$ANSWER" = 2 ]; then
tools/es.sh
why another:
Code:
elif [ "$ANSWER" = 2 ]; then
tools/en.sh
Save and ready, already operates the English version
Click to expand...
Click to collapse
Beware of #!/bin/sh ... read -n command is bash command, and it does not work well in /bin/sh ...
Confirmed on NetRunner (kubuntu 12.10 ).
You should use #!/bin/bash. That applies to all *.sh scripts.
asmerito said:
Beware of #!/bin/sh ... read -n command is bash command, and it does not work well in /bin/sh ...
Confirmed on NetRunner (kubuntu 12.10 ).
You should use #!/bin/bash. That applies to all *.sh scripts.
Click to expand...
Click to collapse
OK, that is the answer that was waiting, since neither worked in Ubuntu 12.04
EDIT:
Re-raise corrected v-0.3
Though your tool says that flashing the recovery worked successful, I can't boot into recovery. When pushing vol- and power I'm just stuck at the pink LG logo (it's in a boot loop while holding vol- and power). Since the system is not rooted, yet, I also cannot boot into recovery with the CWM app.
thorstenhirsch said:
Though your tool says that flashing the recovery worked successful, I can't boot into recovery. When pushing vol- and power I'm just stuck at the pink LG logo (it's in a boot loop while holding vol- and power). Since the system is not rooted, yet, I also cannot boot into recovery with the CWM app.
Click to expand...
Click to collapse
Don't worry in excess, can be retrieved very easily, but before answer to these questions.
Android version?
did CWM previously installed?.
Terminal type? (P990, P990, etc.)
on slackware 14.0, expanded in /opt:
two patches applied;
files are executables with right permissions;
dir 'tools' is accessible;
lg2x is connected via USB (on, off, MTP, PC Suite, without battery and vol -, ...?)
but same result
Terminal: P990 (EU)
ROM: ICS stock
Previous ver: CM 7.2 stable
Previous CWM: 5.0.2
Homero2 said:
Android version?
did CWM previously installed?.
Terminal type? (P990, P990, etc.)
Click to expand...
Click to collapse
Android 4.0.4 (official V30A)
CWM - well, under GB layout I could install it (I was on CWM5 first and later switched to CWM6), but this was my first try on ICS layout
Terminal type - you mean the shell? I'm using Ubuntu 12.10, so /bin/sh did not work and I replaced all /bin/sh with /bin/bash, that means I was running bash when I "bricked" my phone.
kanzy said:
on slackware 14.0, expanded in /opt:
two patches applied;
files are executables with right permissions;
dir 'tools' is accessible;
lg2x is connected via USB (on, off, MTP, PC Suite, without battery and vol -, ...?)
but same result
Terminal: P990 (EU)
ROM: ICS stock
Previous ver: CM 7.2 stable
Previous CWM: 5.0.2
Click to expand...
Click to collapse
Is about understands that this method of single rooted is for Stock ROM versions.
Clarified the issue, I see errors jump to run ADB.
Try with the latest version that I uploaded, the V-0.4
thorstenhirsch said:
Android 4.0.4 (official V30A)
CWM - well, under GB layout I could install it (I was on CWM5 first and later switched to CWM6), but this was my first try on ICS layout
Terminal type - you mean the shell? I'm using Ubuntu 12.10, so /bin/sh did not work and I replaced all /bin/sh with /bin/bash, that means I was running bash when I "bricked" my phone.
Click to expand...
Click to collapse
Not be what could happen...
Doing tests I found that if you are in Recovery, and the SYSTEM partition is not mounted, the program cannot determine partition type should be used.
That error is already fixed in the V-0.4.
It can reflash the Recovery with one of the many versions that we have in the Forum, one in Flash only recovery or All in one.
I say this because it is the only thing that could have happened, since the rooted is not harmful, only copy two files in the system.
Using V-0.4, and it does not work...
Homero2 said:
Is about understands that this method of single rooted is for Stock ROM versions.
Clarified the issue, I see errors jump to run ADB.
Try with the latest version that I uploaded, the V-0.4
Not be what could happen...
Doing tests I found that if you are in Recovery, and the SYSTEM partition is not mounted, the program cannot determine partition type should be used.
That error is already fixed in the V-0.4.
It can reflash the Recovery with one of the many versions that we have in the Forum, one in Flash only recovery or All in one.
I say this because it is the only thing that could have happened, since the rooted is not harmful, only copy two files in the system.
Click to expand...
Click to collapse
Same problem as on slackware, got booloop after flashing recovery. Cannot enter recovery
After this step:
INSTRUCTIONS
CWM will be installed for version ICS V-4.0.4 of Android
Nvflash started
rcm version 0X20001_____________________________________________________________
System Information:
chip name: unknownh Recovery CWM
chip id: 0x20 major: 1 minor: 4
chip sku: 0xf
chip uid: 0x045070c04120b4d7
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: emmc
operating mode: 3
device config strap: 0
device config fuse: 17
sdram config strap: 0
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: tools/fastboot.bin
/ 1027184/1027184 bytes sent
tools/fastboot.bin sent successfully
waiting for bootloader to initialize
bootloader downloaded successfully
sending file: tools/recovery_cwm-6_ics_opti.img
\ 7145472/7145472 bytes sent
tools/recovery_cwm-6_ics_opti.img sent successfully
everything went wrong, and my stock ICS got bootloop.
Using Kubuntu 12.10, stock ICS and V-0.4 of your tool.
Thank you mate! Gonna share it like a bee
asmerito said:
Same problem as on slackware, got booloop after flashing recovery. Cannot enter recovery
...
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=921169
Fixed bug, now works in Ubuntu 11.04, 11.10, 12.04 and 12.10
An error has been detected by Jonki, Thank you!!
Homero2 said:
Fixed bug, now works in Ubuntu 11.04, 11.10, 12.04 and 12.10
An error has been detected by Jonki, Thank you!!
Click to expand...
Click to collapse
What was the problem?
This is the place for various bits and pieces of information/facts/wtf collected whilst digging around in our TF701.
Use at your own peril.
UPDATE: I know the staging partition is where to blob (bootloader) goes, but as I found out, that's only half of the story.
It seems like the bootloader takes the contents of staging at boot time and puts them where they belong.
Now if anybody has more details about this, that would be great.
Partitions
Code:
name device mountpoint fs description
/dev/block/platform/sdhci-tegra.3/ADF /dev/block/mmcblk0p7 /ADF ext4 ?
/dev/block/platform/sdhci-tegra.3/APD /dev/block/mmcblk0p6 /APD ext4 ASUS Product Demo
/dev/block/platform/sdhci-tegra.3/APP /dev/block/mmcblk0p4 /system ext4 Android OS
/dev/block/platform/sdhci-tegra.3/CAC /dev/block/mmcblk0p5 /cache ext4 recovery logs
/dev/block/platform/sdhci-tegra.3/CRA /dev/block/mmcblk0p11 ?
/dev/block/platform/sdhci-tegra.3/DTB /dev/block/mmcblk0p2 ?
/dev/block/platform/sdhci-tegra.3/EKS /dev/block/mmcblk0p13 NVEKSP
/dev/block/platform/sdhci-tegra.3/LNX /dev/block/mmcblk0p3 Linux kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/MDA /dev/block/mmcblk0p12 ?
/dev/block/platform/sdhci-tegra.3/MSC /dev/block/mmcblk0p8 empty (misc, bootloader etc.)
/dev/block/platform/sdhci-tegra.3/PER /dev/block/mmcblk0p10 /persist ext4 config/calibration data
/dev/block/platform/sdhci-tegra.3/SOS /dev/block/mmcblk0p1 Recovery kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/UDA /dev/block/mmcblk0p14 /data ext4 Android user data
/dev/block/platform/sdhci-tegra.3/USP /dev/block/mmcblk0p9 Staging (blob)
recovery.fstab
Code:
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
/dev/block/platform/sdhci-tegra.3/by-name/MSC /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/USP /staging emmc defaults defaults
/devices/platform/sdhci-tegra.2/mmc_host/mmc1 /storage/sdcard1 vfat default voldmanaged=sdcard:auto
/devices/platform/tegra-ehci.0 /mnt/usbdrive vfat default voldmanaged=usbdrive:auto
Blob
Code:
name size description status
[U]10.14.1.47:[/U] [ATTACH]2435244._xfImport[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (original) [ATTACH]2435246._xfImport[/ATTACH]
blob.BC1 8,192 Bytes ? (original) [ATTACH]2435245._xfImport[/ATTACH]
blob.EBT 1,396,736 Bytes Bootloader (original) [ATTACH]2435247._xfImport[/ATTACH]
blob.PT 2,202 Bytes Partition Table (original) [ATTACH]2435248._xfImport[/ATTACH]
[U]10.26.1.7:[/U] [ATTACH]2435238._xfImport[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (unchanged) [ATTACH]2435241._xfImport[/ATTACH]
blob.BC1 8,192 Bytes ? (changed) [ATTACH]2435240._xfImport[/ATTACH]
blob.EBT 1,421,312 Bytes Bootloader (changed) [ATTACH]2435242._xfImport[/ATTACH]
Unbrick
How to unbrick a TF701 that still has fastboot running (possibly partially redundant):
WARNING: Any damage caused by following these instructions...
Yeah, right... Nevermind that... If your fastboot works, this will save your tablet
Required tools: I assume you have them already
Required files:
UL-K00C-xx-10.14.1.47-user.zip (on micro SD card in TF701)
10.14.1.47 blob and boot.img (unpacked from UL-K00C-xx-10.14.1.47-user.zip)
drgravy's recovery.img
Code:
fastboot erase boot
fastboot erase staging
fastboot format system
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery.img
fastboot reboot-bootloader
check the version displayed. Is it 10.14.1.47? if not, hard reset to bootloader ([vol-] + [power])
boot recovery kernel (RCK)
install zip
choose zip from sdcard
UL-K00C-xx-10.14.1.47-user.zip
Yes
wait and pray to odin
+++ go back +++
reboot system now
Yes - Disable recovery flash (doesn't actually matter)
Yes - Root device (/system/xbin/su) (just kidding, this doesn't work)
Please consider clicking thanks
Sources:
Lots of own work
http://forum.xda-developers.com/showpost.php?p=47767352&postcount=71
https://github.com/AndroidRoot/BlobTools
im trying to find pretty much the same info
mmcblk0p? for boot and external_sd
This helped alot thanks!
nevermind find both
LNX = boot
/dev/block/mmcblk1p1 is external_sd
schmeggy929 said:
im trying to find pretty much the same info
mmcblk0p? for boot and external_sd
This helped alot thanks!
nevermind find both
LNX = boot
/dev/block/mmcblk1p1 is external_sd
Click to expand...
Click to collapse
things that will appear here tomorrow:
by name symlinks
recovery fstab info
unpacked blob contents
more detailed bootloader related stuff
anything fun I'll find on the way
for the next 12 hours that's it...
lpdunwell said:
This is the place for various bits and pieces of information/facts/wtf collected whilst digging around in our TF701.
Use at your own peril.
UPDATE: I know the staging partition is where to blob (bootloader) goes, but as I found out, that's only half of the story.
It seems like the bootloader takes the contents of staging at boot time and puts them where they belong.
Now if anybody has more details about this, that would be great.
Partitions
Code:
name device mountpoint fs description
/dev/block/platform/sdhci-tegra.3/ADF /dev/block/mmcblk0p7 /ADF ext4 ?
/dev/block/platform/sdhci-tegra.3/APD /dev/block/mmcblk0p6 /APD ext4 ASUS Product Demo
/dev/block/platform/sdhci-tegra.3/APP /dev/block/mmcblk0p4 /system ext4 Android OS
/dev/block/platform/sdhci-tegra.3/CAC /dev/block/mmcblk0p5 /cache ext4 recovery logs
/dev/block/platform/sdhci-tegra.3/CRA /dev/block/mmcblk0p11 ?
/dev/block/platform/sdhci-tegra.3/DTB /dev/block/mmcblk0p2 ?
/dev/block/platform/sdhci-tegra.3/EKS /dev/block/mmcblk0p13 NVEKSP
/dev/block/platform/sdhci-tegra.3/LNX /dev/block/mmcblk0p3 Linux kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/MDA /dev/block/mmcblk0p12 ?
/dev/block/platform/sdhci-tegra.3/MSC /dev/block/mmcblk0p8 empty (misc, bootloader etc.)
/dev/block/platform/sdhci-tegra.3/PER /dev/block/mmcblk0p10 /persist ext4 config/calibration data
/dev/block/platform/sdhci-tegra.3/SOS /dev/block/mmcblk0p1 Recovery kernel (8388608 b)
/dev/block/platform/sdhci-tegra.3/UDA /dev/block/mmcblk0p14 /data ext4 Android user data
/dev/block/platform/sdhci-tegra.3/USP /dev/block/mmcblk0p9 Staging (blob)
recovery.fstab
Code:
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
/dev/block/platform/sdhci-tegra.3/by-name/MSC /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/USP /staging emmc defaults defaults
/devices/platform/sdhci-tegra.2/mmc_host/mmc1 /storage/sdcard1 vfat default voldmanaged=sdcard:auto
/devices/platform/tegra-ehci.0 /mnt/usbdrive vfat default voldmanaged=usbdrive:auto
Blob
Code:
name size description status
[U]10.14.1.47:[/U] [ATTACH]2435244[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (original) [ATTACH]2435246[/ATTACH]
blob.BC1 8,192 Bytes ? (original) [ATTACH]2435245[/ATTACH]
blob.EBT 1,396,736 Bytes Bootloader (original) [ATTACH]2435247[/ATTACH]
blob.PT 2,202 Bytes Partition Table (original) [ATTACH]2435248[/ATTACH]
[U]10.26.1.7:[/U] [ATTACH]2435238[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (unchanged) [ATTACH]2435241[/ATTACH]
blob.BC1 8,192 Bytes ? (changed) [ATTACH]2435240[/ATTACH]
blob.EBT 1,421,312 Bytes Bootloader (changed) [ATTACH]2435242[/ATTACH]
Unbrick
How to unbrick a TF701 that still has fastboot running (possibly partially redundant):
WARNING: Any damage caused by following these instructions...
Yeah, right... Nevermind that... If your fastboot works, this will save your tablet
Required tools: I assume you have them already
Required files:
UL-K00C-xx-10.14.1.47-user.zip (on micro SD card in TF701)
10.14.1.47 blob and boot.img (unpacked from UL-K00C-xx-10.14.1.47-user.zip)
drgravy's recovery.img
Code:
fastboot erase boot
fastboot erase staging
fastboot format system
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery.img
fastboot reboot-bootloader
check the version displayed. Is it 10.14.1.47? if not, hard reset to bootloader ([vol-] + [power])
boot recovery kernel (RCK)
install zip
choose zip from sdcard
UL-K00C-xx-10.14.1.47-user.zip
Yes
wait and pray to odin
+++ go back +++
reboot system now
Yes - Disable recovery flash (doesn't actually matter)
Yes - Root device (/system/xbin/su) (just kidding, this doesn't work)
Please consider clicking thanks
Sources:
Lots of own work
http://forum.xda-developers.com/showpost.php?p=47767352&postcount=71
https://github.com/AndroidRoot/BlobTools
Click to expand...
Click to collapse
Sorry, how should I extract the recovery.img from the OTA zip file?
I can only find several files: install-recovery.sh recovery-from-boot.p recovery-resource. dat
Or if I can extract it anywhere else?
lpdunwell said:
Code:
[U]10.26.1.7:[/U] [ATTACH]2435238[/ATTACH]
blob.BCT 8,192 Bytes Boot Config Table (unchanged) [ATTACH]2435241[/ATTACH]
blob.BC1 8,192 Bytes ? (changed) [ATTACH]2435240[/ATTACH]
blob.EBT 1,421,312 Bytes Bootloader (changed) [ATTACH]2435242[/ATTACH]
Click to expand...
Click to collapse
@lpdunwell
Any ideas what BC1 is for? Also there is no SOS file inside the BLOB. I have repacked the BLOB as I wanted to make a bootloader and recovery flash package but not sure how to flash a recovery.
On the TF700 you could just pack it back into the BLOB using the below and it would flash to staging fine. Any ideas?
Code:
blobpack -s blob EBT blob.EBT SOS blob.SOS
I wonder if the same can be done like this?
Code:
blobpack -s blob BCT blob.BCT BC1 blob.BC1 EBT blob.EBT SOS blob.SOS
sbdags said:
@lpdunwell
Any ideas what BC1 is for? Also there is no SOS file inside the BLOB. I have repacked the BLOB as I wanted to make a bootloader and recovery flash package but not sure how to flash a recovery.
On the TF700 you could just pack it back into the BLOB using the below and it would flash to staging fine. Any ideas?
Code:
blobpack -s blob EBT blob.EBT SOS blob.SOS
I wonder if the same can be done like this?
Code:
blobpack -s blob BCT blob.BCT BC1 blob.BC1 EBT blob.EBT SOS blob.SOS
Click to expand...
Click to collapse
TBCH, I'm not sure about the BC1.
The recovery is not part of the blob (anymore?). And the exact way an official update flashes it is probably not the best way to go when flashing manually. My advice for the moment probably is: Keep flashing the bootloader to a minimum, and flash recoveries via fastboot.
lpdunwell said:
TBCH, I'm not sure about the BC1.
The recovery is not part of the blob (anymore?). And the exact way an official update flashes it is probably not the best way to go when flashing manually. My advice for the moment probably is: Keep flashing the bootloader to a minimum, and flash recoveries via fastboot.
Click to expand...
Click to collapse
Yeah I tried a number of ways to get it to flash but it looks like the nvcopy tool that Asus use doesn't work outside the stock recovery.
Search the UL-K00C-WW-10.14.1.47-user.zip file
Hi,
And thank you. But Do you know where I can download the UL-K00C-WW-10.14.1.47-user.zip ?
On ASUS and can find only WW_epaduser_10_14_1_47_UpdateLauncher.zip.
Oups UL-K00C-WW-10.14.1.47-user.zip is in WW_epaduser_10_14_1_47_UpdateLauncher.zip.
Question
Hi
A question : Is it possible to use the same procedure with UL-K00C-WW-10.26.1.7-user.zip or UL-K00C-WW-10.26.1.18-user.zip ?
Best regards
Bumping this as it should be stickied
Xstof said:
Hi,
And thank you. But Do you know where I can download the UL-K00C-WW-10.14.1.47-user.zip ?
On ASUS and can find only WW_epaduser_10_14_1_47_UpdateLauncher.zip.
Oups UL-K00C-WW-10.14.1.47-user.zip is in WW_epaduser_10_14_1_47_UpdateLauncher.zip.
Click to expand...
Click to collapse
Did you ever find out where to get this file? I've been looking everywhere and I fear my device is hosed without it. HELP!
SgtMac02 said:
Did you ever find out where to get this file? I've been looking everywhere and I fear my device is hosed without it. HELP!
Click to expand...
Click to collapse
Google "Asus support downloads", click on the first link....
lpdunwell said:
Code:
fastboot erase boot
fastboot erase staging
fastboot format system
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery.img
fastboot reboot-bootloader
Click to expand...
Click to collapse
Ok, so I'm trying to get through this and having some trouble...
I've been having to go back and forth on a few things and I fear I've managed to hose thing up pretty good. But at this point, I have the files you state, and in following these instructions, was able to successfully erase the partitions mentioned, then when I tried to flash the first time, I actually screwed up and didn't have the blob file I needed, so now I go back, and obviously I can't re-erase the other files, but formatting system still works, so I know I'm getting good communication with the device. Then trying to flash the blob to staging, I get:
sending 'staging' (1379 KB)...
FAILED (command write failed (No such device or address))
Any thoughts or suggestions would be greatly appreciated.
Am I completely bricked?
I'm stuck in a boot loop with Asus / Unlocked appearing and unable to get to recovery. I've tried connecting with win 8.1 via usb but adb does not see devices. i assume running fastboot is the same situation. I can see the device listed APX and understand that Nvflash can help with that but there is no nvflash for Tegra 4.
I'm not sure how it got to this state - could be me or device. it is new and i considered returning save for the Device is Unlocked message
Ironically, this is my second Tf701t as the first cracked the screen. Considering taking motherboard out of old and putting in new (or visa vera) but I'm really bad with hardware.
Do I really have 2 broken devices I'll try anything.
Thanks for any (emotional) support ...
sonicthoughts said:
I'm stuck in a boot loop with Asus / Unlocked appearing and unable to get to recovery. I've tried connecting with win 8.1 via usb but adb does not see devices. i assume running fastboot is the same situation. I can see the device listed APX and understand that Nvflash can help with that but there is no nvflash for Tegra 4.
I'm not sure how it got to this state - could be me or device. it is new and i considered returning save for the Device is Unlocked message
Ironically, this is my second Tf701t as the first cracked the screen. Considering taking motherboard out of old and putting in new (or visa vera) but I'm really bad with hardware.
Do I really have 2 broken devices I'll try anything.
Thanks for any (emotional) support ...
Click to expand...
Click to collapse
This happened in my TF300T, yes is a hard brick.
Nvflash only works if you did work before.
Here is a guide to ifixit a TF700 perhaps help you. :good:
Would it not make more sense to swap the screens over?
Sent from my HTC Desire 610 using XDA Free mobile app
lpdunwell said:
This is the place for various bits and pieces of information/facts/wtf collected whilst digging around in our TF701.
Use at your own peril.
UPDATE: I know the staging partition is where to blob (bootloader) goes, but as I found out, that's only half of the story.
It seems like the bootloader takes the contents of staging at boot time and puts them where they belong.
Now if anybody has more details about this, that would be great.
Sources:
Lots of own work
http://forum.xda-developers.com/showpost.php?p=47767352&postcount=71
https://github.com/AndroidRoot/BlobTools
Click to expand...
Click to collapse
Thank you for your analysis! I wonder does the "staging" partition contain temporary updates, and the blob flashed to it will automatically decompress to the correct partitions in the next boot?
In other words, in order to update the bootloader and the recovery system, I could do either:
1.
Code:
fastboot flash staging bootloader
fastboot flash recovery TWRP.img
Or:
Code:
blobpack -s bootloader-TWRP.blob EBT bootloader.EBT SOS TWRP.img
fastboot flash staging bootloader-TWRP.blob
Are they equivalent?
Stuck with the old bootloader
[CODE said:
fastboot erase boot
fastboot erase staging
fastboot format system
fastboot flash staging blob
fastboot flash boot boot.img
fastboot flash recovery.img
fastboot reboot-bootloader[/CODE]
check the version displayed. Is it 10.14.1.47? if not, hard reset to bootloader ([vol-] + [power])
boot recovery kernel (RCK)
install zip
choose zip from sdcard
UL-K00C-xx-10.14.1.47-user.zip
Yes
wait and pray to odin
+++ go back +++
reboot system now
Yes - Disable recovery flash (doesn't actually matter)
Yes - Root device (/system/xbin/su) (just kidding, this doesn't work)
Please consider clicking thanks
Sources:
Lots of own work
http://forum.xda-developers.com/showpost.php?p=47767352&postcount=71
https://github.com/AndroidRoot/BlobTools
Click to expand...
Click to collapse
I am stuck, for some reason after following these steps when the device reboots it is still with the old recovery and bootloader. Can anybody help please?
xabier87 said:
I am stuck, for some reason after following these steps when the device reboots it is still with the old recovery and bootloader. Can anybody help please?
Click to expand...
Click to collapse
What are you trying to do? Which BL and recovery do you currently have?
Flashable zips for the last bootloaders are here: http://forum.xda-developers.com/showpost.php?p=61045480&postcount=2
berndblb said:
What are you trying to do? Which BL and recovery do you currently have?
Flashable zips for the last bootloaders are here: http://forum.xda-developers.com/showpost.php?p=61045480&postcount=2
Click to expand...
Click to collapse
Thanks for the info! I might try with these zips and bootloaders. I am trying to reset my tablet or make it work. Had cm-12.1-20160711-NIGHTLY-tf701t.zip on it with TWRP recovery and US_epad-10.26.1.18-20131217 bootloader but it recently stoppped working. I do have access to the bootloader and recovery but after following the fastboot instructions and rebooting nothing is changed on the tablet.
Hello,
I've been trying to encrypt my device for a while now. It always just goes to the encrypting icon, then waits a second and boots into CM12.1 again. Now I've tried to use adb logcat, where I was able to find this when starting encryption, just after all the SIGKILLs:
E/Cryptfs ( 229): Cannot open real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
E/Cryptfs ( 229): Unable to get crypt_ftr_info
E/Cryptfs ( 229): Cannot get size of block device /dev/block/platform/msm_sdcc.1/by-name/userdata
Click to expand...
Click to collapse
I'm using CM12.1 titan linked here. However, I'm fairly certain that this is not a ROM issue, I've had it on all ROMs. Any help would be greatly appriciated.
~ Robin
maybe it really is the encryption footer?
Robin.S said:
I've been trying to encrypt my device for a while now. It always just goes to the encrypting icon, then waits a second and boots into CM12.1 again. Now I've tried to use adb logcat
Click to expand...
Click to collapse
(I'm sorry but it won't let me post links yet, you'll have to fix them below to use, I stripped the schemes, put them between LINK uppercase, and italicized the link text)
I'm getting the same thing, I just tried with 20150505 nightly cm12.1, this seems to a be a known issue, but with very little real information as to the problem. I found LINK forum.cyanogenmod.org/topic/88973-moto-g-cm11-encryption-failed/ LINK this forum post going back to mid 2014, and LINK jira.cyanogenmod.org/browse/CYAN-4532 LINK the linked JIRA bug which seems to indicate that all the Moto G devices (falcon, peregrine, titan), possibly Moto X as well are affected, but nobody seems to know what causes this bug, only vague hints that it may be a "timing related issue" but no other clarifying information in the now more than a year since this bug was posted.
The obvious conclusion is that nobody is encrypting their devices, which I find bizarre. Once Motorola releases a 5.1 factory ROM for this device (which is supposedly imminent -- they've already released for G-2013 and X-2014 I believe), I'll flash it and test that one.
I used logcat -v long and saw the times, the process kills definitely come after the attempts to open the block device fails. I did a logcat -c in one shell and then a vdc cryptfs enablecrypto inplace <password> in another (this is what the encrypt UI initiates), and the after the resulting softboot (it keeps the adb shell alive, and system uptime continues, so this isn't a hard boot), a logcat shows the same sequence:
Code:
[ 05-06 20:06:03.897 230: 287 E/Cryptfs ]
Cannot open real block device /dev/block/platform/msm_sdcc.1/by-name/userdata
[ 05-06 20:06:03.897 230: 287 E/Cryptfs ]
Unable to get crypt_ftr_info
[ 05-06 20:06:03.898 230: 287 E/Cryptfs ]
Cannot get size of block device /dev/block/platform/msm_sdcc.1/by-name/userdata
and then the kills start.
At first, because of the apparent inability to get crypt footer (in the error message), I thought this was lack of the 16k footer mentioned in the aforementioned bug, but LINK review.cyanogenmod.org/#/c/86684/ LINK the patch to include it appears to be long incorporated in LINK github.com/CyanogenMod/android_device_motorola_titan/blob/cm-12.1/BoardConfig.mk LINK our board's version of this file.
However, as I write this, I notice that the size in BoardConfig.mk does not correspond to the one on the device:
Code:
$ readlink /dev/block/platform/*/*/userdata
/dev/block/mmcblk0p38
$ grep mmcblk0p38 /proc/partitions
259 6 5774208 mmcblk0p38
$ bc
((5930598400 / 1024) - 5774208) / 1024
16.9843750000
they appear to differ by slightly more than 16k (the size of the encryption footer). But yet /system corresponds exactly with the line from BoardConfig.mk:
Code:
$ readlink /dev/block/platform/*/*/system
/dev/block/mmcblk0p36
$ grep mmcblk0p36 /proc/partitions
259 4 1130496 mmcblk0p36
$ bc
1157627904 / 1024
1130496.0000000000
so now I'm thinking that really is the problem (the userdata partition needs to have its size extended by 16k). But then there is LINK forum.cyanogenmod.org/topic/104204-xt1039-cm12-nightly-20150123-encryption-of-data-partition-not-working-simply-warm-reboots/ LINK this forum post which claims that the same partition encrypts fine with the stock image.
I didn't factory reset when flashing cm12.1 (from a stock 5.x ROM), which I think recreates the partition (?) So, maybe the partition didn't get resized to the correct value. However if the stock ROM handles this case, I should think CM would too.
What about you? Did you factory reset (including /data) when you installed CM on your Titan? I saw no need to get rid of /data (although I did have to delete some things in /data/misc to get rotation working) when coming from stock ROM and wanted to avoid having to redo everything. Which worked fine... except for this
Hi All,
Device Detail:
- Samsung S10 5G
- Qualcomm Device
- Model: SM-G977U
- ROM: VZW-G977UVRU2ASH7-20190827135903
- Kernel-Version - Linux version 4.14.83-16633035 ([email protected]) (clang version 6.0.10 for Android NDK) #2 SMP PREEMPT Wed Aug 14 16:23:48 KST 2019
Background: I have
- rooted the device with instructions given by Magisk.
- I can successfully reboot to the recovery rootfs.
Problem: I am trying to modify the `system.img.ext4.lz4` file to root the device with normal boot. I am aware that it will not let the device install OTA Updates.
Unpack-Pack System and make new AP.tar, flash:
- Without any modification to the `system.img`, I have just unpacked `system.img.ext4.lz4`->`system.img.ext4`->`system.img`->mounted to system directory and packed it back to `system.img`->`system.img.ext4`->`system.img.ext4.lz4`.
- Replaced unpack-packed `system.img.ext4.lz4` with the AP `system.img.ext4.lz4` and make a tar of it.
- Then I have flashed it using Odin v3.13 along with BL, CP, and HOME_CSC.
- Odin has show PASS and I have rebooted the device into recovery mode.
- Done the Wipe data/factory reset and reboot to recovery again but released the recovery key combination on splash screen as mentioned in the root instructions .
- The device stuck in a boot loop.
Tries:
1. Disable Dm-verity
- Removed `avb` flag from `boot.img` with
Code:
magiskboot dtb boot.img patch
- Removed `avb` and `verify` flags from `dtbo.img` with
Code:
magiskboot dtb dtbo.img patch
- Patched `ramdisk.cpio` with
Code:
magiskboot cpio ./initrd 'patch false true'
Patched `boot.img` and `dtbo.img` is working fine with magisk patched AP file but the `ramdisk.cpio` creating the issue: Stuck at splash screen when trying to go to recovery after successfully flash with Odin. Download mode is appearing on splash screen.
So, I have used `boot.img` and `dtbo.img` along with unpack-packed `system.img.ext4.lz4` but the result is still a boot loop. I have also tried a combination of `boot.img` and `dtbo.img` along with unpack-packed `vendor.img.ext4.lz4` and flashed the AP.tar with other files but still the result is a boot loop.
So, I want to debug the problem and got to know about `pstore` which preserve the logs when kernel panic.
2. pstore
- Checked that `/sys/fs/pstore` is mounted by the system with following in init file: Grep the pstore using `find . | grep '\.rc' | xargs cat | grep pstore -n -i` and get following result:
Code:
314: # pstore/ramoops previous console log
315: mount pstore pstore /sys/fs/pstore nodev noexec nosuid
316: chown system log /sys/fs/pstore/console-ramoops
317: chmod 0440 /sys/fs/pstore/console-ramoops
318: chown system log /sys/fs/pstore/console-ramoops-0
319: chmod 0440 /sys/fs/pstore/console-ramoops-0
320: chown system log /sys/fs/pstore/pmsg-ramoops-0
321: chmod 0440 /sys/fs/pstore/pmsg-ramoops-0
- Checked the kernel config by pulling the file from /proc/config.gz.
Code:
$ cat config | grep PSTORE
CONFIG_PSTORE=y
CONFIG_PSTORE_ZLIB_COMPRESS=y
# CONFIG_PSTORE_LZO_COMPRESS is not set
# CONFIG_PSTORE_LZ4_COMPRESS is not set
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_PMSG=y
CONFIG_PSTORE_PMSG_SSPLOG=y
CONFIG_PSTORE_RAM=y
- Check the `ramoops` configuration:
Code:
./sys/module/ramoops/parameters/console_size 262144
./sys/module/ramoops/parameters/dump_oops 1
./sys/module/ramoops/parameters/ecc 0
./sys/module/ramoops/parameters/ftrace_size 262144
./sys/module/ramoops/parameters/mem_address 3241148416
./sys/module/ramoops/parameters/mem_size 1048576
./sys/module/ramoops/parameters/mem_type 0
./sys/module/ramoops/parameters/pmsg_size 262144
./sys/module/ramoops/parameters/record_size 262144
`pstore` setup looks fine but when I am trying the get logs from `sys/fs/pstore` then I found nothing.
I have tried it by two ways:
1. Crash manually with panic kernel using:
Code:
echo 1 > /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger
Followed Reading Kernel Logs
2. Flashing non-working rom that cause a boot loop and then flashed a working ROM with rooting steps and checked the file at `sys/fs/pstore`.
I need a favor in:
- Any steps to fix/debug the `pstore` problem?
- Any other way to find the kernel logs?
Update 1: I get the logs from recovery but I am not able to identify the problem.
Logs link: https://drive.google.com/file/d/1b-XNmjpYvH-L8lY0xA0SYr7XcITVCrVS/view?usp=sharing
Description: In this video, I have done the following:
1. Displayed recovery logs before: The last recovery logs are ends with 8.
2. Rebooted the device with a recovery key combination. I have already wipe data partition before making this video.
3. The boot loop happens and in the next reboot, I have pressed the recovery key combination to open the recovery mode where logs that end with 9 displayed.
4. Then I have recorded `last_history`, `last_avc_message_recovery`, `last_log.9` and `last_kmsg.9`
5. `last_history` and `last_avc_message_recovery` looks unchanged(same as before boot loop).
6. Then, I just have tried to mount the system but that didn't work.
7. At last, I have just rebooted the system normally without any recovery key combination.
Some Highlighted logs of last_log.9
exec -f /system/bin/e2fsck -v -y /dev/block/bootdevice/by-name/cache
error: _do_exec: can't run '/system/bin/e2fsck'
(errno 13 : Permission denied)
/system/bin/e2fsck terminated by exit(255)
...
E:Can't read /cache/recovery/last_locale: No such file or directory
...
W:Failed to unmount /efs: Device or resource busy
can't unmount /efs - Device or resource busy
...
W:Failed to set brightness: Invalid argument
I:Screensaver disabled
Atomic Commit failed in DisableNonMainCrtcs
Atomic Commit failed, rc = 0
...
Reboot Recovery Cause is [[BootChecker]RebootRecoveryWithKey]
...
print_recovery_cause() : reboot_reason=[[BootChecker]RebootRecoveryWithKey]
...
[property list]
persist.audio.fluence.speaker=true
...
ro.vendor.build.security_patch=2018-08-05
Supported API: 3
I:/efs is already mounted
W:Failed to unmount /efs: Device or resource busy
check_selective_file:Can't unmount /efs - Device or resource busy
just_reboot_after_update = 1
should_wipe_cahcewipe_cache
-- Wiping cache...
erase_volume(/cache)
...
MDF_I: Completed reset MDF flag!
MDF_I: Completed initialized MDF for Recovery!
mke2fs 1.43.3 (04-Sep-2016)
Discarding device blocksL 4096/153600??????????????????????????????done
Discard takes 0.00051s
Creating filesystem with 153600 4k blocks and 38400 inodes
...
Creating journal (2048 blocks): done
...
copy_logs
...
Cache wipe complete
[Checking pre-multi-csc2]
[start failed section]
sales_code=VZW
Carrier ID=[XAA]
[system partition space check]
The device has /product partition.
[out-recovery]
I:system root image is true, so need to change the unmount point from /system to /system_root
running out-recovery time : 0.000s
running recovery time: 1.738s
copy_avc_msg_to_data(1, )
I:fs_type "ext4" for /cache
copy_file 'proc/avc_msg' 'cache/recovery/last_avc_msg_recovery'
!__RECOVERY_FOR_ASSAMBLY
b_del_recovery_command = true
Rebooting...
## finish_recovery_terminate(del=1, reboot_cmd=reboot, clear_BCB=1)
## finish_recovery(delcmd=1,...
I:Saving locale "en-US"
I:fs_type "ext4" for /cache
I:[libfs_mgr]dt_fstab: Skip disabled entry for partition vm-linux
I:## unlink /cache/recovery/command
copy_logs
I:fs_type "ext4" for /cache
copy_log_file :: create recovery log file '/cache/recovery/log'
copy_log_file :: create recovery log file '/cache/recovery/last_log'
Click to expand...
Click to collapse
Is anyone have experience in detecting problems from the kernel logs?
i can not help you, but we can collect ideas. what about re-sign the system.img? there is a key somewhere, i guess just deleting won't work but maybe it is possible to calculate checksum
or maybe you can switch to SuperSU 2.79 SR3 (latest release from chainfire) or at least look inside the update-binary shell script how to root system.
regarding dm-verity i would start with searching for "verify" flag in your fstabs and remove it. magisk is also doing some hex patches and re-signing, it's the best source to look inside magisk installer zip update-binary/ updater-script, if you have the knowledge to read code
another option is try to port a twrp recovery from another snapdragon (i wonder if somebody did this already) if you can find a porting guide
so the vzw s10 5g is unlockable?
elliwigy said:
so the vzw s10 5g is unlockable?
Click to expand...
Click to collapse
yes
aIecxs said:
yes
Click to expand...
Click to collapse
Figures lol.. I have a g975u from big red n don't plan on buying another lol
aIecxs said:
yes
Click to expand...
Click to collapse
Message me on telegram and I can help you if you help me.. I'm curious in some logs and what not.. I also might have something you can use..
Did you get it working? I have the same phone and I want to use the 600mgz tmobile 5g in a few days, so I need the right rom.
elliwigy said:
so the vzw s10 5g is unlockable?
Click to expand...
Click to collapse
aIecxs said:
yes
Click to expand...
Click to collapse
Snapdragon bootloader unlockable? How?
I'm a VZW customer and can get the phone on an upgrade, but want to root it...
i got a g977p and twrp n magisk working great
do you think it is possible to flash other branding on verizon devices with modded odin?
aIecxs said:
do you think it is possible to flash other branding on verizon devices with modded odin?
Click to expand...
Click to collapse
dunno.. its not possible on n976v..
Was there any luck on rooting the Verizon G977U?
@Vats12 has already successful rooted with magisk in recovery. this thread is for rooting system (kind of rooting where su binary is placed in /system/xbin like for older devices, which breaks OTA)
aIecxs said:
@Vats12 has already successful rooted with magisk in recovery. this thread is for rooting system (kind of rooting where su binary is placed in /system/xbin like for older devices, which breaks OTA)
Click to expand...
Click to collapse
So you want like the supersu method?
ExtremeGrief said:
So you want like the supersu method?
Click to expand...
Click to collapse
Yes, do you know how to do this?
Magisk (guide) does a lot of other things too..
Maybe we can use Magisk to disable the securities and then SuperSu can help in the rooting system?
Vats12 said:
Yes, do you know how to do this?
Magisk (guide) does a lot of other things too..
Maybe we can use Magisk to disable the securities and then SuperSu can help in the rooting system?
Click to expand...
Click to collapse
But why? Safetynet will be gone
What model is the device?
ExtremeGrief said:
But why? Safetynet will be gone
What model is the device?
Click to expand...
Click to collapse
model see OP! i guess because of the buttons needed for booting in magiskrecovery, but the reason is not important only HOW (for Vats12, not for me i don't own this device)
Sorry but this thread needs to be closed
aIecxs said:
model see OP! i guess because of the buttons needed for booting in magiskrecovery, but the reason is not important only HOW (for Vats12, not for me i don't own this device)
Click to expand...
Click to collapse
I don't want to be the one who shouts fake, but the instructions you gave a link to says you have to be able to flash a bootloader first, which means an unlocked blootloader, if you have Verizon rom this is not possible, as the blootloader is locked.
If you did find a way to flash a modified bootloader, or a modified recovery those are the instructions we need, because in fastboot you are unable to do this with a locked bootloader and you are unable to unlock the bootloader on Verizon. If you have a modified bootloader or recovery flashed on your device what did you use to flash it with Odin? Because only way to flash a boot.img is either get into download mode and flash with Odin, or with Edl, if you got into edl mode then can you provide instructions on that, because we would like to know how to get the device into EDL mode as well
Sorry boys this is a hoax.
@DroidisLINUX there is video proof in OP, and again for you:
This is not a tutorial about unlocking and rooting, it is a question how he can modify /system to permanently integrate su