Related
OK so I recently switched this neat, cheap and decent entry phone, and of course wanted to root and unlock the bootloader.
Using the technique outlined in http://forum.xda-developers.com/showthread.php?t=2066887 "[ROOT][CWM] Huawei Ascend Y201 Pro U8666" I managed to happily root the device. Meaning I could install droidwall and adfree, and uninstall one or two of the annoying Huawei apps. (Surprisingly there are less Vendor apps on this than the previous Ideos U8150 I had.)
So happy that that worked, I thought I would go to the next stage and unlock the boot loader, in preparation for maybe installing clockworkmod recovery. And eventually a ROM if I could find one that looked "safe" and sound.
Cranking up the "UnlockBootloader.exe" as before and clicking the unlock BOOTLOADER initiated something on my phone... However when I switched off my phone preparatory to rebooting, I found what I guess to be a bricked/borked device.
There's no vibrate, no flash on screen, no logo, no pink screen that other people talk about in the few reports I have found around the web. Just that the lower backlit soft buttons flash ten times and then nothing else happens. I can't even find information about what this obviously low level failure message means...
As you can guess, I have tried all sorts of things to get it going: battery removal; powering from USB while botting; any and all of the key press holds for boot; all to the same effect. Have tried several times to find anything similar on the net and can't seem to find anything similar. Especially the ten flash indicator
So my question is "Is this an absolute sign that the device is bricked?" I guess I could try to play the innocent and send it back under warranty, but I guess someone will realise it was my fault. Unless a memory failure happened at the exact time I was flashing/unlocking...
And a warning that same device owners should be careful when following the guide. I'm pretty sure I had everything as outlined. I'm running XP, didn't have it mounted, had fastboot off, etc... Although now its hard to check on the device to see if that was the case
and also
I should also perhaps add that before using UnblockBootLoader with root success, I tried the ICS "adb restore" directory traversal vulnerability, which is part of Root_with_restore, and was unsuccessful.
And that there's no life reported at a low, USB device level to my linux kernel, when plugged in now. So I can't even try a firmware patch using adb etc.
Of course I can't post a relevant cautionary note into the above mentioned thread, as I have yet to reach the 10 post milestone mark, enabling me to post in that section...
Hi,
Sorry for opening an old thread, have the same issue and just wanted to know if you manged to resolve this or it you just took it back to the shop?
Regard
No solution
No - I never managed to work out or find a solution. I just got a new one, and only went as far as the root'ing stage.
I have never seen an applicable ROM for this device anyway, so I guess it wasn't too much of an issue. And root'ing to get those crucial management apps installed, and also being able to remove some Huawei "cruft" is the real thing you need.
Hi, first time poster hoping for some help with my first encounter with Red Eye at bootup. I have a stock phone. I don't really care about the phone but my wife really wants the pictures off it. It doesn't have an SD card or cloud backup and the pictures are on internal memory. I am able to get into the boot options (like AP fastboot) but I do not know what the options will do for me exactly. Can I choose an option that may fix the phone but will not wipe the memory? Is there any possiblity a PC can see the phone at the Red Eye screen if I connect with USB(would a certified Verizon data cable help?) Would actually opening the phone and doing some sort of mod get me any closer to retrieving pictures? I am a complete novice at this kind of thing and only have experience with PC hardware and software and the like.
GLE3 said:
Hi, first time poster hoping for some help with my first encounter with Red Eye at bootup. I have a stock phone. I don't really care about the phone but my wife really wants the pictures off it. It doesn't have an SD card or cloud backup and the pictures are on internal memory. I am able to get into the boot options (like AP fastboot) but I do not know what the options will do for me exactly. Can I choose an option that may fix the phone but will not wipe the memory? Is there any possiblity a PC can see the phone at the Red Eye screen if I connect with USB(would a certified Verizon data cable help?) Would actually opening the phone and doing some sort of mod get me any closer to retrieving pictures? I am a complete novice at this kind of thing and only have experience with PC hardware and software and the like.
Click to expand...
Click to collapse
none of those options will be of any direct help, however fastboot may be used to try and fix it later.
first,
- do you know what caused it to become like this?
- is it bootloader unlocked? if you dont know what that is, there will be some dialogue on the fastboot screen. status code=0 locked or similar.
- do you know what version it was on? if you dont know, did you always update when available? would likely mean latest version.
- do you have a windows pc available, with a usb 2 port, and a cable to connect the phone to it?
edit,
ultimately, this is where we are headed, if you want to take a look at it. specifically the "rsd flasher". i was going to go another route, but this is probably a more direct option.
the rsd flasher will take you to another site, and is made by samuri. im not real familiar with his tool, but know its good. just will save me time in having you tear the fxz apart and flash certain things.
**note, im not sure if this phone was made for multiple carriers, this will only be relevant when getting the correct fxz file. samuri will know more about this than i would.
bweN diorD said:
none of those options will be of any direct help, however fastboot may be used to try and fix it later.
first,
- do you know what caused it to become like this?
- is it bootloader unlocked? if you dont know what that is, there will be some dialogue on the fastboot screen. status code=0 locked or similar.
- do you know what version it was on? if you dont know, did you always update when available? would likely mean latest version.
- do you have a windows pc available, with a usb 2 port, and a cable to connect the phone to it?
edit,
ultimately, this is where we are headed, if you want to take a look at it. specifically the "rsd flasher". i was going to go another route, but this is probably a more direct option.
the rsd flasher will take you to another site, and is made by samuri. im not real familiar with his tool, but know its good. just will save me time in having you tear the fxz apart and flash certain things.
**note, im not sure if this phone was made for multiple carriers, this will only be relevant when getting the correct fxz file. samuri will know more about this than i would.
Click to expand...
Click to collapse
First off, thanks your reply! I've been to other sites that were not helpful even to this point! To answer your questions:
bweN diorD said:
- do you know what caused it to become like this?
- is it bootloader unlocked? if you dont know what that is, there will be some dialogue on the fastboot screen. status code=0 locked or similar.
- do you know what version it was on? if you dont know, did you always update when available? would likely mean latest version.
- do you have a windows pc available, with a usb 2 port, and a cable to connect the phone to it?
Click to expand...
Click to collapse
Not exactly sure what happen to the phone. My wife tells me one minute it was charged at 26% and working fine, the next moment it was 'dead'.
It is locked with a status of 0
My Wife says if the phone had automated updates(if stock phone is configured that way) then yes she has all the updates. If updates require manual intervention then it's probably not updated.
Yes, I have a Windows PC with 2 USB ports and a generic data cable that fits the phone.
I'm looking at the post you linked too now... Thanks again for your help!
GLE3 said:
First off, thanks your reply! I've been to other sites that were not helpful even to this point! To answer your questions:
Not exactly sure what happen to the phone. My wife tells me one minute it was charged at 26% and working fine, the next moment it was 'dead'.
It is locked with a status of 0
My Wife says if the phone had automated updates(if stock phone is configured that way) then yes she has all the updates. If updates require manual intervention then it's probably not updated.
Yes, I have a Windows PC with 2 USB ports and a generic data cable that fits the phone.
I'm looking at the post you linked too now... Thanks again for your help!
Click to expand...
Click to collapse
no problem
its likely your phone is fully updated, but since we arent 100% sure, its going to be best to go with the most current file. reason being, because you are locked, you can only flash = or forward. if you try to flash back, it will either not work, or bootloop. usually not work.
it would probably be best if you continued this in @SamuriHL's thread for the rsd flasher. he is very helpful, will likely be able to quickly point you to the most current file, and will be able to answer any questions about the tool where i wouldnt.
Joying "N2" firmware.
Looking into the process for booting to recovery, I started looking into the Joying firmware, specifically, the file fwu_image.bin. This is an interesting file, it appears to be a bootloader and/or some kind of hypervisor.
Some strings in it led me to find a tool called the "Intel Phone Flash Tool"
There is a LOT of potentially useful information in this thread; http://forum.xda-developers.com/gen...70-3g-sofia-atom-x3-c3130-quad-t3103085/page2
Other interesting strings;
USB Driver Bootcore module --- something about booting via USB?
There is a bunch of stuff about **fastboot**.
"rockchip,power-key-pressed-time" -- interesting. Does it respond differently to holding the power key for different lengths of time?
"%s BCB is boot-normal, set NVM to normal mode." -- this seems to be related to selecting boot modes based on data on NVM, i.e., what happens when you issue "reboot recovery".
Wonder what would happen if you ran "reboot bootloader"?
Some stuff about "special" key...
This stuff.... some kernel parameters, and, of course, the SERIAL NUMBER that freaks tomtom out;
Code:
phyBlk = 0x%x die = %d block_in_die = 0x%x 0x%x
0123456789abcdef
(null)
0123456789ABCDEF
bug in vfprintf: bad base
SF_3GR_ver 1639.400
1639.400_M1S1
,dDK
,DDK
androidboot.bootloader
androidboot.serialno
loader_charged
normal
androidboot.mode
ptest
charger
0123456789012345678901234567890
0123456789012345
update-radio/hboot
boot-fb-pt-updated
boot-fastboot
boot-recovery
update-psi
fb_update_bl
At least partial kernel commandline as; "console=ttyFIQ0,115200n8 idle=halt earlyprintk=xgold notsc apic=sofia androidboot.hardware=sofiaboard nolapic_pm firmware_class.path=/system/vendor/firmware androidboot.selinux=permissive x86_intel_xgold_timer=soctimer_only vmalloc=512m slub_max_order=2 uvcvideo.en_autosuspend=0 selinux=0 limit_cpu=disable mvpipe.at_dbg_port=1"
Note: serial console on ttyFIQ0, I wonder where that could be found.
Also note: selinux is in a pointless state. Major copout.
There are a *LOT* of strings in there that tie it to the FYT SoM. The bootloader is, no doubt, incompatible with MTCD boards.
There seem to be a LOT of references to hardware that these units do not have. Even found the string "huawei" in it. Makes me thing that this is a lot more than just a simple bootloader. This looks like it actually contains a *complete Linux kernel*. No wait, actually TWO.
This is really weird. Perhaps a bootloader followed by 2 kernels?
"/local/zengguan/RK-release-for-eoi/1511-official-release/mobilevisor/core"
"Mobilevisor/bootloader boot shared info structure version mismatch!"
Ok, so here is what I'm thinking;
1) It might have fastboot.
2) The USB keyboard - boot to recovery process may well avoid starting the boot partition, I think that it may be starting one of the kernels in the hypervisor partition, and using that to adjust the NVM to cause a recovery boot.
3) NEITHER of those are guaranteed, further study would be required.
Found THIS immediately before what appears to be fastboot:
"-----BOOT_REASON_LONG_ON_KEY-----"
So what does that mean? Boots to fastboot if you hold down the ON key for a long time? What is an ON key?
This comes AFTER fastboot:
"------display screen start------"
Could be that fastboot mode has no display output.
Hmm...
%s line=%d DOWN bit is set
%s line=%d DOWN and Power bit is set
Another edit... they aren't calling it a hypervisor, they're calling it a MICROVISOR. Essentially, a combined hypervisor + microkernel. The main kernel accesses security sensitive resources via the microkernel. Think of it as TRUSTZONE.
I *think* that the watchdog is implemented in the microvisor. With any luck, they didn't completely bonehead it -- a complete mess up should (if implemented in a sane manner) result in a reboot into some mode where recovery is possible, such as fastboot or recovery.
Found this; https://translate.google.ca/transla...96%87%E4%BB%B6%E6%8F%90%E5%8F%96/&prev=search
First thing I notice is that the partition table of THAT device, aligns with Joying N2 devices. This is very good news, because it means that we can learn about our device from it.
So that big file "fwu_image.bin" that I was looking into, is being written to ImcPartID122. This is important, because that website I linked above indicates that 122 is something of a "special" partition. Ok, by special, I really mean SCREWBALL.
Normally, your storage devices are laid out as following;
/dev/typeN --- for the "base" device, representing the entire storage area as a single file. Counts from 0 up.
and
/dev/typeNpM which splits out the different partitions of the device.
So if you just wanted to write a block of binary data to the beginning of the storage device, you normally would dd if=source of=/dev/typeN and be done with it.
But these devices are a bit screwball. ImcPartID122, for instance, seems to link to /dev/block/nand0p12 <-- 12th partition? Ok, its labeled as "ALL", so I think we can assume that this is somewhat similar in concept to /dev/block/nand0. Or maybe with some special offset? Probably would make a bit of sense for me to actually look at the real partition table to figure out what is going on.
NOTE: Yes, it is certainly possible for device partitions to overlap. Nothing to worry about in that regard.
So "ALL", explains why I was able to find two copies of the linux kernel in there. It actually *INCLUDES* both the boot and the recovery partitions! Or maybe boot and boot-backup, don't quite know just yet. So next you're going to say that this can't be so, since the file isn't sparse, and the boot partition comes after the system partition.... while it *looks* like the boot partition comes after the system partition (boot: ImcPartID071, system: ImcPartID068), this is not actually the case. Those "ImcPartID"'s are actually just names. 068 -> /dev/block/nand0p14, 071 -> /dev/block/nand0p9... Plus, the partition number really doesn't have to correspond to its physical ordering on the device, and as the "All" partition indicates, on these, it doesn't. So no conflicts -- that is good.
Great stuff @doitright!
Finding the location of that long serial number in the fwu_image.bin is promising for a TomTom fix. Many consider it the best offline navigation app for when there might not be an internet connection for proper function of Waze/GoogleMaps. Do you think its possible to overwrite the serial number in place on the /dev/block partition or would editing the bin and reflashing be the best bet?
The only ON key I can imagine on the capacitive button units is the recessed POW button. I tried holding it beyond 30 seconds but there is no boot into recovery. Issuing "reboot bootloader" or "reboot recovery" from root terminal on the unit unfortunately seems to just reboot the unit normally.
The latest firmware Joying emailed has the MCU dated 10/31 and ROM dated 11/15 if that is different from the one you're looking at: http://forum.xda-developers.com/showpost.php?p=69755292&postcount=426 Though I assume any changes would be minimal from the previous versions. Running everything on top of this microvisor sounds different from the MTCB/C D units. We are lucky to have you looking at it!
rcll said:
Great stuff @doitright!
Finding the location of that long serial number in the fwu_image.bin is promising for a TomTom fix. Many consider it the best offline navigation app for when there might not be an internet connection for proper function of Waze/GoogleMaps. Do you think its possible to overwrite the serial number in place on the /dev/block partition or would editing the bin and reflashing be the best bet?
The only ON key I can imagine on the capacitive button units is the recessed POW button. I tried holding it beyond 30 seconds but there is no boot into recovery. Issuing "reboot bootloader" or "reboot recovery" from root terminal on the unit unfortunately seems to just reboot the unit normally.
The latest firmware Joying emailed has the MCU dated 10/31 and ROM dated 11/15 if that is different from the one you're looking at: http://forum.xda-developers.com/showpost.php?p=69755292&postcount=426 Though I assume any changes would be minimal from the previous versions. Running everything on top of this microvisor sounds different from the MTCB/C D units. We are lucky to have you looking at it!
Click to expand...
Click to collapse
I used to use tomtom... back in around 2005-2008. They had a version that ran on PalmOS 5.whatever, so it was good for the old Treo 650. I'm not at all fond of the subscription model that they've taken on -- to hell with that!
For offline nav, I use Alk Copilot: https://play.google.com/store/search?q=copilot&c=apps&hl=en
As far as changing the serial number, I'm going to have to track it to what partition it is actually in, and figure out its layout.... determine if there are any other implications to altering it besides just changing the serial number. Would hate to see it cause BRICKING.
My device just got bricked. It was part of the recall and I had removed TegraOTA long ago. Today, after a few weeks of testing out CM13, I decided to go back to stock, remembered to flash the NoMoreOTA zip file but for some reason, it didn't stick. My device started downloading an update which I failed to get suspicious at, then shut down and hasn't come back online since.
This is far more than the frustration of losing a device and its data. It's a scary thought that NVidia has the ability to so utterly control our devices from a distance, with very little that can be done to prevent it if you're an average user. Remember that fuss when Amazon used DRM in their EBooks to remotely delete them from the computers of customers that legally purchased and should've had full rights to the content? This is inexcusable, and we must work to find a fix and pressure NVidia into giving up this disturbing practice.
Here are a basic list of resources I'm researching that have potential, I'll be posting as stream-of-consciousness and these links will also be here for reference when I reboot into Linux for some of the more advanced stuff. I can't make any promises, but stay tuned, this might just work!
Resources
Main XDA discussion RE kill switch
An old method that worked on the first variation of the kill switch (doesn't help anymore, since now the kill switch directly attacks the bootloader)
More discussion on the topic:
https://forum.xda-developers.com/shield-tablet/help/shield-tablet-stuck-apx-mode-black-t3074446
So far:
Bootloader is corrupted. Device is showing as APX.
Step one, therefore: Download APX drivers.
I found these for the Note 7, weren't easy to come across.
Slight issue with signature verification. You need to reboot into advanced settings and disable device driver signature verification.
http://www.howtogeek.com/167723/how...8.1-so-that-you-can-install-unsigned-drivers/
To use NVFlash, we need the device's SKB. Most forum members seem to agree that's virtually impossible without a leak from NVidia themselves, but those same people also claim the same issue with getting an APX driver for the Shield, so maybe it can be done. A hopeful post on the matter:
[GUIDE] Recovering Recovery/Obtaining SKB
Below link looks promising, need to obtain blob from stock rom. Guy claims he has the blob file, but we still need the SBK:
https://www.reddit.com/r/theNvidiaS...shield_tablet_bricked_at_1114_pm_est/cu2kudk/
This might help:
SBCalc - Generate your SBK (v1.1)
https://forum.xda-developers.com/showthread.php?t=1927818
What is NVFlash and what are SBKs?
http://www.androidroot.mobi/pages/the-inner-workings-of-secure-boot-key-and-nvflash/
More unresolved threads on this topic:
https://forum.xda-developers.com/shield-tablet/help/shield-tablet-stuck-apx-mode-black-t3074446
https://forum.xda-developers.com/shield-tablet/general/recover-y01-battery-shield-tablet-t3199153/
Lives Updates To Come
You cant repair kill switched NST, because tegraOta attack bootloader at low level and btld is pernamently corrupted.
Also Since Nvidia Tegra Note 7 SBK key is not used its an ODM key system. So they are heading into the wrong bush. only Nvidia knows the ODM key. But good luck.
Hey ReckoningForce,
Really hope you find a way, been searching for hours myself.
Driving me mad as i was bloody stupid enough to turn my should have been recalled device one without turning off the WiFi first, so unfortunately in the same boat as yourself.
Please update this thread if you get anything working!
Thanks again mate
hI, I HAVE A SHIELD 2017 with boot unlocked , but after downgrade from 9.1 to 8 (7.2.3) are in permanent loop:
1 message about risk unlock
2 logo nvidia
3 coloured cirlcle of anroid running
After get print on display "android" it loop into nvidia logo and repeat again infinitely those steps: HDMI recognize them as "Shield"
if i put a keyboard on usb port and i try to boot into fastboot/recovery ( A+B+PWRON) dont
do anymore loop but are stucked into run coloured cirvcles on screen : HDMI recognize them as "PB1"
Also un usb service port it recognize it as MTP USB device
does exist any possibility to get recovery or fastboot mode or i need to throw it out?
So I was trying to just do a clean install. This phone had no mods installed.
I have done this many times and all went well. I am hoping that someone can help me understand what went wrong.
So working on linux, latest fastboot/adb (29.0.6-6198805) and the March image for blueline.
flashing radio and bootloader went fine. When I got to flashing the kernel it stopped after writing slot_a and rebooting into fastboot. I got the message "waiting for any device"
The phone displayed a warming (see pics) that the bootloader is unlocked and phone vulnerable and gave me an option to pause. after a few seconds it went into a "fastbootd" screen that I never saw before (see pic attached) which gave me options to restart or go back to bootloader. Either option breaks the flashing sequence which ends with error.
Re-flashing produces the same result.
Any suggestions what causes this?
Of course the phone does not boot anymore. But I can get to bootloader again using key sequence. Bootloader is unlocked.
Thank you!
Fastbootd happens part way through a flash-all beginning with Android 10. I assume you are using the flash-all script and now doing each command individually. If not, edit the flash-all to get rid of the -w to dirty flash and keep apps and user data. My guess though is that your path is referring to an older version of fastboot. If you have ever installed the apt version of fastboot, it becomes the first to load in your path. Instead, drop the March files into your updated platform-tools folder and ./ the flash-all command in terminal directly from that folder. In a pinch, you can also sideload the ota zip (which you will need to download separately of course) from fastbootd by entering recovery from there and sideloading. Fastbootd gets you into user space, so you should have adb sideload ability.
there are no older fastboot/adb installed i checked. I did each command individually. Reason is long but the person with long nails in the pic is my daughter who is in Europe and I was trying to troubleshoot her pixel through WhatsApp .
I tried to do this flashing using her Chromebook and the stock linux emulation. This may be the problem i will come back to it.
So all files (images + fastboot/adb) were placed in one directory and I ran ./fastboot....
I can try and move fastboot/adb to a bin directory. i doubt this is the problem though. I ran them from home directory before.
I can try a sideload. never done it though.
Here's what i think happens and maybe you can tell me if sideload may avoid this situation:
ChromeOS has to give permission to Linux to use USB for a specified device. It does not remember that device after being disconnected though. Therefore I suspect that during the reboot into fastboot the phone looses USB permission for a second and hence breaks the process.
With all the covid thing all she has available is her Chromebook. I have a linux machine but it's here across the pond.
So does a sideload involve any intermittent re-boots where I may loose USB permissions?
sliding_billy said:
Fastbootd happens part way through a flash-all beginning with Android 10.
Click to expand...
Click to collapse
I did not know that.
What is the "normal" sequence of events? In our case it got to fastbootd and the laptop seemed stuck into "waiting for any device" Am i supposed to press anything or it resumes on its own?
We tried choosing bootloader once and reboot another time but in both cases the process broke down. Are we supposed to wait longer or what?
metricusa said:
there are no older fastboot/adb installed i checked. I did each command individually. Reason is long but the person with long nails in the pic is my daughter who is in Europe and I was trying to troubleshoot her pixel through WhatsApp .
I tried to do this flashing using her Chromebook and the stock linux emulation. This may be the problem i will come back to it.
So all files (images + fastboot/adb) were placed in one directory and I ran ./fastboot....
I can try and move fastboot/adb to a bin directory. i doubt this is the problem though. I ran them from home directory before.
I can try a sideload. never done it though.
Here's what i think happens and maybe you can tell me if sideload may avoid this situation:
ChromeOS has to give permission to Linux to use USB for a specified device. It does not remember that device after being disconnected though. Therefore I suspect that during the reboot into fastboot the phone looses USB permission for a second and hence breaks the process.
With all the covid thing all she has available is her Chromebook. I have a linux machine but it's here across the pond.
So does a sideload involve any intermittent re-boots where I may loose USB permissions?
Click to expand...
Click to collapse
metricusa said:
I did not know that.
What is the "normal" sequence of events? In our case it got to fastbootd and the laptop seemed stuck into "waiting for any device" Am i supposed to press anything or it resumes on its own?
We tried choosing bootloader once and reboot another time but in both cases the process broke down. Are we supposed to wait longer or what?
Click to expand...
Click to collapse
I've never ran ChromeOS, but the reboot into fastbootd not retaining the connection would definitely be a problem. The sideload does no reboots until install is complete, so that would be a better way for sure. In reality the phone did at least one reboot into fastbootd. You'd need to try a flash-all with -w in place to see if it could pull off a clean install with the factory image and not lose track of the connection. No doubt it will lose track with individual commands . The normal sequence for factory flash now is just that... run the flash-all .sh it will go into fastbootd during install while terminal will continue to work. There are definitely some spots where nothing appears to be happening on the phone or terminal until reboot. Given the remote nature of your install, I do think a sideload (follow the directions on the pixel ota developers page where you DL the file) is the best option for you.
metricusa said:
there are no older fastboot/adb installed i checked. I did each command individually. Reason is long but the person with long nails in the pic is my daughter who is in Europe and I was trying to troubleshoot her pixel through WhatsApp .
I tried to do this flashing using her Chromebook and the stock linux emulation. This may be the problem i will come back to it.
So all files (images + fastboot/adb) were placed in one directory and I ran ./fastboot....
I can try and move fastboot/adb to a bin directory. i doubt this is the problem though. I ran them from home directory before.
I can try a sideload. never done it though.
Here's what i think happens and maybe you can tell me if sideload may avoid this situation:
ChromeOS has to give permission to Linux to use USB for a specified device. It does not remember that device after being disconnected though. Therefore I suspect that during the reboot into fastboot the phone looses USB permission for a second and hence breaks the process.
With all the covid thing all she has available is her Chromebook. I have a linux machine but it's here across the pond.
So does a sideload involve any intermittent re-boots where I may loose USB permissions?
Click to expand...
Click to collapse
I had the same problem with my PixelBook. My conclusion was ChromeOS does not forward the USB connection to the Linux container before the phone times out, but your theory about loosing USB permission may be correct. If you have developer mode enabled on the ChromeBook, try booting into Linux from a USB stick instead of running the Linux container. Unfortunately, I have no other solution.
dcarvil said:
If you have developer mode enabled on the ChromeBook, try booting into Linux from a USB stick instead of running the Linux container. Unfortunately, I have no other solution.
Click to expand...
Click to collapse
I agree but with my daughter abroad she can't do the USB stick thingy.
I'll explore the sideload. I'll have to test everything on my Pixel 3. I was trying to avoid that. I have both a Linux machine and a Chromebook here.
And yes, the permission is lost quite fast during a phone reboot. I tested it. I do however find it amazing that a Chromebook is capable of doing such advanced tasks.
I'll try again tomorrow and report back.
metricusa said:
I agree but with my daughter abroad she can't do the USB stick thingy.
I'll explore the sideload. I'll have to test everything on my Pixel 3. I was trying to avoid that. I have both a Linux machine and a Chromebook here.
And yes, the permission is lost quite fast during a phone reboot. I tested it. I do however find it amazing that a Chromebook is capable of doing such advanced tasks.
I'll try again tomorrow and report back.
Click to expand...
Click to collapse
What if you get phone into fastbootd, then plug in so the phone is recognized, then "fastboot update image-blueline-qq2a.200305.002.zip"
Or just unplug it once it gets to fastbootd and plug it back in...if it becomes unrecognized, unplug and plug it back in again when needed?
wangdaning said:
What if you get phone into fastbootd, then plug in so the phone is recognized, then "fastboot update image-blueline-qq2a.200305.002.zip"
Or just unplug it once it gets to fastbootd and plug it back in...if it becomes unrecognized, unplug and plug it back in again when needed?
Click to expand...
Click to collapse
I'll try that.
Unplugging opens another can of worms:
The reason we are doing this is bc the phone suddenly has a problem charging. Opening the battery setting shows a red battery with the message "can't charge now". Also if plugged in while turned off the little battery shows a question mark.
Google offered to exchange it but shipping it back and forth from Europe is 140$ each way and I got a new phone for less. On top of this I risk having to pay import taxes on it.
So in short, if unplugged the phone dies.
The intent of doing this burn was to see if this issue is software related. As I said it happened suddenly after a simple restart. Battey was fine and after restart was not.
I have a feeling it's not the software though.
Wow, that is really high for shipping. I mean, I ship from China to the US for like 20 USD, beside the point though really. She knows no one with an ordinary PC to test? Or a local cell phone service center in her area that could evaluate it? I mean the battery could be dead, or it could have, ehehe, been dropped and a connection loose or something. Not trying to imply anything there, just saying there are many variables at play. I would say if getting to fastbootd and trying the update does not work, then she should really look for a repair shop. Depending on where she is it should be fairly cheap or even free for them to look at it.
wangdaning said:
Wow, that is really high for shipping. I mean, I ship from China to the US for like 20 USD, beside the point though really. She knows no one with an ordinary PC to test? Or a local cell phone service center in her area that could evaluate it? I mean the battery could be dead, or it could have, ehehe, been dropped and a connection loose or something. Not trying to imply anything there, just saying there are many variables at play. I would say if getting to fastbootd and trying the update does not work, then she should really look for a repair shop. Depending on where she is it should be fairly cheap or even free for them to look at it.
Click to expand...
Click to collapse
Well the option is through fedex/ups. Shipping USPS has resulted many times in the package being stuck in customs for weeks. And the price is not necessarily much lower.
Yes we looked into having it seen by a repair shop but normally we should have been able to do flash it ourselves. Plus it's a good experience for her to be exposed to some linux and the basics of hacking a phone.
Another reason is that this has a high chance of being hardware related so whatever we spend on repair shop is wasted money.
I got her a Samsung A51 and she is out of trouble for now. I have had several bad experiences with pixels so this time I am officially done with spending a fortune on them.
Update as of this morning: It is clear that the USB permission is lost while fastboot performs a reboot during flashing. We tried to quickly re-allow the permission but while the terminal waits for a device patiently it looks that the loss of link is long enough for the phone to decide that something went wrong and goes into fastbootd.
We also tried to flash just the boot.img in both slots . that went well apparently but did not change anything and the phone is still unbootable. Tried recovery but it went back into bootloader with the error that it cannot boot boot.img.
So next step is sideload. i have to figure how that works
fastboot reboot fastboot, select recovery, apply update from ADB, adb sideload whatever.zip
Seems if there is no way to keep the phone on without it plugged in that is a problem. What about a cheap wifi charger, will that keep it on? I mean the phone will technically reboot going from bootloader to fastboot (fastbootd) and the permission will be lost. At least a repair shop could use a proper computer to test it.
wangdaning said:
Seems if there is no way to keep the phone on without it plugged in that is a problem. What about a cheap wifi charger, will that keep it on?
Click to expand...
Click to collapse
The phone stays on while it is connected to usb. Never died in this process. The connection loss is because of permissions not power.
Latest update: adb sideload worked just perfectly phone is back in running condition.
The bad news, which was expected, is that we did not solve the battery problem so it's hardware related. See attached pic.
In any case: A million thanks for the help. You guys rock!
At least we found out that a Chromebook can do some of these tasks but cannot do the flashing.
I placed a question on Chromebook community about a possible way to give Linux permanent permission to USB. If I find out any good news I'll report back.
Thank you and stay safe!
metricusa said:
Latest update: adb sideload worked just perfectly phone is back in running condition.
The bad news, which was expected, is that we did not solve the battery problem so it's hardware related. See attached pic.
In any case: A million thanks for the help. You guys rock!
At least we found out that a Chromebook can do some of these tasks but cannot do the flashing.
I placed a question on Chromebook community about a possible way to give Linux permanent permission to USB. If I find out any good news I'll report back.
Thank you and stay safe!
Click to expand...
Click to collapse
Glad you got the device up. As for the charging issue, have you tried a different wired charger or a wireless charger? I assume you are converting power somehow in Europe.
sliding_billy said:
have you tried a different wired charger or a wireless charger?
Click to expand...
Click to collapse
Yes. Tried different charger and a battery pack and also charging through USB from laptop. Did not try wireless. Before I bought the new phone she was using the phone connected to a battery pack.
As you can see in the pic the battery is red and it says "can't charge" while confirming that it does receive power.
I Googled the issue and there are several reports about same behavior. I also did talk to a repair shop over the phone and they said that the power module goes bad and it is a known problem with pixel 2 and 3. He also mentioned that there is a class action lawsuit but I cannot confirm the info.
It doesn't really matter at this point.
My aim was to eliminate the remote possibility this problem was due to some software issue. We solved this and from now on it's a google issue. As I mentioned Google offered to exchange the phone. But with COVID we had to postpone some flights when we could have made the exchange.
I will contact Google and ask for some workaround the COVID crisis. I hope they will be cooperative. I don't see why not.
Thank you all for your help!