Closed JassMan23 closed 5 years ago
MORE
I am not convinced that the installer is actually checking adb status because the mode that is masquerading as "recovery" does not respond to any adb requests. I know the log says that there are several adb shell: echo 1
commands along with others such as adb shell: cat /etc/recovery.fstab
, however adb devices
does not report any device when you open a terminal.
Also I thought that the recovery mode should show a menu similar to following: Ubuntu Touch (CWM-based) Recovery v6.0.4.6
but booting into recovery mode (manually or within installer) brings up the "chipex" screen.
Don't run adb devices while the installer is running, that'll break the connection to the device.
@NeoTheThird I am not running adb during the install process. But, once the installer says Success, I have tried running adb devices and no devices are shown. The same happens if you manually reboot the N7 and select recovery mode.
My hypothesis is that once you have had an ADB Push Error, one or more parts of the install is in an indeterminate state. On the next install attempt, it gets as far as booting into recovery but the recovery rom notes the discrepancy, puts up the chipex image and refuses to launch its end of adb so it is then impossible to correct the situation. Because the installer is not correctly determining that adb is running, it goes through the motions but the fault is never corrected.
I think the same is probably true in most of the failed installs. People say they have to flash TWRP or some other recovery and change to an alternate OS before returning to Touch. I believe this is simply because the Touch Recovery is not allowing anyone to use adb to hack and look for the problem.
I know a little knowledge is a dangerous thing and I am an almost total noob, but it seems to me it should be simple for Recovery to start the adb bridge BEFORE it checks filesystem consistency and halts.
OK, a bit more research: I have managed to install TWRP as the recovery system; Looking at the logs in /cache/recovery
, there is a recurring theme that the boot process can't open /data
I:Setting up '/data' as data/media emulated storage.
I:Created '/sdcard' folder.
I:Can't probe device /dev/block/mmcblk0p30
I:Unable to mount '/data'
I:Actual block device: '/dev/block/mmcblk0p30', current file system: 'ext4'
I:Can't probe device /dev/block/mmcblk0p30
I:Unable to mount '/data'
I:Actual block device: '/dev/block/mmcblk0p30', current file system: 'ext4'
E:Bad magic for real block device /dev/block/platform/msm_sdcc.1/by-name/metadata
Could not mount /data and unable to find crypto footer.
I:Setting up '/data' as data/media emulated storage.
I:Can't probe device /dev/block/mmcblk0p30
I:Unable to mount '/data'
I:Actual block device: '/dev/block/mmcblk0p30', current file system: 'ext4'
I:Can't probe device /dev/block/mmcblk0p30
Failed to mount '/data' (Invalid argument)
I:Actual block device: '/dev/block/mmcblk0p30', current file system: 'ext4'
Unable to recreate /data/media folder.
this is reiterated by df showing:
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 926920 24 926896 0% /dev
tmpfs 926920 24 926896 0% /tmp
/dev/block/mmcblk0p23 564988 454148 110840 80% /cache
/dev/block/mmcblk0p22 847656 843792 3864 100% /system
Based on this, I thought I would try a manual fastboot format userdata with the following FAIL:
Couldn't parse erase-block-size '0x'.
Couldn't parse logical-block-size '0x'.
mke2fs 1.44.1 (24-Mar-2018)
/tmp/TemporaryFile-kxQt9x: Unimplemented ext2 library function while setting up superblock
/usr/lib/android-sdk/platform-tools/mke2fs failed with status 1
mke2fs failed: 1
error: Cannot generate image for userdata
My installed version of fastboot is 1:8.1.0+r23-5~18.04 from ubuntu. Even TWRP seems unable to format data. It reports Could not mount /data and unable to find crypto footer. Failed to mount /data (Invalid argument)
Just had another thought. Is it because the recovery.fstab says that he partition is encryptable? What should I set instead? recovery.fstab
/boot emmc /dev/block/platform/msm_sdcc.1/by-name/boot /recovery emmc /dev/block/platform/msm_sdcc.1/by-name/recovery /misc emmc /dev/block/platform/msm_sdcc.1/by-name/misc /system ext4 /dev/block/platform/msm_sdcc.1/by-name/system /data ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata flags=encryptable=/dev/block/platform/msm_sdcc.1/by-name/metadata /cache ext4 /dev/block/platform/msm_sdcc.1/by-name/cache /sbl1 emmc /dev/block/platform/msm_sdcc.1/by-name/sbl1 /sbl2 emmc /dev/block/platform/msm_sdcc.1/by-name/sbl2 /sbl3 emmc /dev/block/platform/msm_sdcc.1/by-name/sbl3 /tz emmc /dev/block/platform/msm_sdcc.1/by-name/tz /rpm emmc /dev/block/platform/msm_sdcc.1/by-name/rpm /aboot emmc /dev/block/platform/msm_sdcc.1/by-name/aboot /sbl2b emmc /dev/block/platform/msm_sdcc.1/by-name/sbl2b /sbl3b emmc /dev/block/platform/msm_sdcc.1/by-name/sbl3b /tzb emmc /dev/block/platform/msm_sdcc.1/by-name/tzb /rpmb emmc /dev/block/platform/msm_sdcc.1/by-name/rpmb /abootb emmc /dev/block/platform/msm_sdcc.1/by-name/abootb /usb-otg vfat /dev/block/sda1 /dev/block/sda flags=removable;storage;display=USB-OTG
@UBPorts Finally got a working system by using the manual install with a couple of mods. The main problem seems to be that some devices with a more modern Android (mine was 6.0.1 - Marshmallow) sets encryption on the /Data partition whether you want it or not.
The modified install: Before you start, goto TWRP and dowload the latest version for your hardware. First, you need to reboot your device to bootloader mode. Press and hold the volume down and power buttons until the phone reboots. Now, connect your phone to your computer and run the following commands to wipe the internal memory.
fastboot oem unlock fastboot format cache fastboot reboot-bootloader
If you want to erase the data on the device, run these commands:
fastboot format userdatafastboot format system
Installation
fastboot flash recovery recovery.imgfastboot flash recovery twrp-3.3.1-0-flo.img fastboot flash boot boot.img
When you reboot into Recovery, Do NOT Install TWRP Now reboot the device to recovery mode. Press and hold the volume up and power buttons until the phone reboots. Create a new text file with LF line-feeds called "commandfile" with the following content:
format system load_keyring image-master.tar.xz image-master.tar.xz.asc load_keyring image-signing.tar.xz image-signing.tar.xz.asc mount system update ubports-8832267993eb0215232c953d6c5fa7f22ab2fe348b4e68946b098b6bdc19830c.tar.xz ubports-8832267993eb0215232c953d6c5fa7f22ab2fe348b4e68946b098b6bdc19830c.tar.xz.asc update device-1481ee5bb7d4443bbc1506c297bc19aecc0520a305dca7a3ef800c57969ac9f4.tar.xz device-1481ee5bb7d4443bbc1506c297bc19aecc0520a305dca7a3ef800c57969ac9f4.tar.xz.asc update keyring-4c4e7ef380ebcfa2c31084efa199138e93bfed8fc58aa3eb06bdf75a78af9b57.tar.xz keyring-4c4e7ef380ebcfa2c31084efa199138e93bfed8fc58aa3eb06bdf75a78af9b57.tar.xz.asc update version-8.tar.xz version-8.tar.xz.asc
unmount systemumount system
We will now send all the installation files to the device.
adb shell "mount -a" # You might see some errors from this command, that's ok. adb shell "mkdir -p /cache/recovery" adb push pool/ubports-8832267993eb0215232c953d6c5fa7f22ab2fe348b4e68946b098b6bdc19830c.tar.xz /cache/recovery/ adb push pool/ubports-8832267993eb0215232c953d6c5fa7f22ab2fe348b4e68946b098b6bdc19830c.tar.xz.asc /cache/recovery/ adb push pool/device-1481ee5bb7d4443bbc1506c297bc19aecc0520a305dca7a3ef800c57969ac9f4.tar.xz /cache/recovery/ adb push pool/device-1481ee5bb7d4443bbc1506c297bc19aecc0520a305dca7a3ef800c57969ac9f4.tar.xz.asc /cache/recovery/ adb push pool/keyring-4c4e7ef380ebcfa2c31084efa199138e93bfed8fc58aa3eb06bdf75a78af9b57.tar.xz /cache/recovery/ adb push pool/keyring-4c4e7ef380ebcfa2c31084efa199138e93bfed8fc58aa3eb06bdf75a78af9b57.tar.xz.asc /cache/recovery/ adb push pool/version-8.tar.xz /cache/recovery/ adb push pool/version-8.tar.xz.asc /cache/recovery/ adb push gpg/image-signing.tar.xz /cache/recovery/ adb push gpg/image-signing.tar.xz.asc /cache/recovery/ adb push gpg/image-master.tar.xz /cache/recovery/ adb push gpg/image-master.tar.xz.asc /cache/recovery/ adb push commandfile /cache/recovery/ubuntu_command
Before the device will reboot, you need to remove encryption from the /Data partition. To do this is not intuitive. In TWRP, select [Wipe](). At the bottom of the screen above the slider is a button labelled [Format Data](). Touch this button and a console screen will pop up showing progress. Check that you have been totally successful:
adb shell df
You should see:
/dev
/tmp
/cache
/system
/data
as a minimum of partitions.
You can now replace TWRP with the standard UBPorts Recovery. Return to the Bootloader, and flash in the UBPorts version
fastboot flash recovery recovery.img
Moment of truth! Reboot to Recovery With a bit of luck, instead of seeing Chipex, you should see [Ubuntu]() and a progress bar. The bar will progress quite slowly after the first half so be patient.
If you've arrived here because of similar symptoms but find the solution too complicated or it doesn't work for you, you might try the simpler sequence in https://github.com/ubports/ubports-installer/issues/2174.
Automatically generated error report UBports Installer Version: 0.2.7-beta Device: flo Channel: ubports-touch/16.04/stable Package: snap Operating System: Ubuntu Linux 18.04 bionic x64 NodeJS version: v8.2.1
Error log: https://paste.ubuntu.com//p/NyZz7KQSr9/ ___ Finally got past first stages of install process; Installer downloaded 13 files and pushed them to tablet; Copied files from storage to "rom": Rebooted; Claimed "Success" but device now say "This phone needs restoring from a PC or service center." Display is a chip overlaid on a red X inside an octagon.
In fact this may be caused by a previous bug which is that once you have had a failure, ADB won't run and the device cannot automatically detected. I believe it is specifically looking for the bridge to return a serial number followed by "device" but in the event of a failure, you can only get to fastboot mode which returns serial number followed by "fastboot".
EDIT just discovered this is an old bug covered in issue 300. Getting out of this all looks very scary to a noob like me. Perhaps the installer needs to check that it really has had success by doing an adb pull of something to verify it is all in the right places and if it fails point the user to a help page which is explained in simple terms, along with up to date locations of individual files needed.
Also the install documentation which I assume is pretty much the latest, makes no mention of this in the troubleshooting section even though the problem appears to have been around since 2017.