Question / ask for help: hard bricked? #84
Comments
|
Hi, I'm sorry to hear this. Maybe I can help.
I think you are referring to the three options which are given when you try to install Magisk through the app:
The in-place option you mentioned being the second one. If that's the case, it makes sense that your system will not boot anymore. If you install Magisk (the method, not the app) via any other way than by using avbroot, your device will likely not boot anymore as it overwrites some parts which make avbroot work. Even if it only makes a tiny change, the boot signature is now changed and not reflected in
I have no experience with Magisk Delta, but as far as I know Magisk never automatically prompts you to install it this way. Maybe it does this if it's not installed correctly. If all of the above is correct, then if your boot image has been replaced by the install method, you probably also can't sideload anymore as your custom OTA certificate is may not be present anymore in the boot image. The new sideload OTA is verified against this certificate when sideloading. And even if the certificate is present, I am not sure if it would let it check as the boot image is now invalid according to AVB. So I think this leaves you with starting over by unlocking the bootloader and trying again. Which should work as long as you didn't disable 'OEM unlocking', which you mention you didn't. I am not sure about the grayed out part though. I don't know why that would be the case. I've read reports in the past that this happened to new devices which were not registered or something.
Why does it fail? Is there a particular error message?
This is correct. On every update the slots are switched, also on sideload.
I think you can't sideload anymore, but you can give it a shot. Normally you can only successfully sideload an image you signed with your personal OTA key. It doesn't really matter which one it is, as long as it is a full OTA. I'd recommend an avbroot patched full Google OTA patched with normal Magisk to be sure. For any other way of getting a new (factory) image onto your device, you should have to unlock your bootloader first. So we can cross that bridge when we get there. @chenxiaolong, feel free to correct me if I'm wrong. EDIT: And to be complete, is this the Google Pixel 6 Pro you mentioned in a previous post? |
|
Thank you for detailed answer. Yes, it is Google Pixel 6 Pro. I'm 100% sure I didn't touch the "OEM unlocking" switch in settings, though all the fastboot responses suggest that it is locked (sic!). And then Nothing happens when "Recovery" or "Rescue" is selected from Bootloader level. Small clarification - Magisk was patched into OTA with avbroot and in both cases on the first run of Magisk app (after it was installed), it did state something between the lines "Magisk has to perform additional steps". For the moment:
Is there any chance to do anything from bootloader level? Prior any steps now, I'm asking as don't want to get into even worse situation though already have some bad feeling that it is hard brick (and phone has been unboxed literally less than 6 days ago) ;) On the OEM Unlock - I'm wondering if it couldn't be the case that somehow the slot which is supposed to load has swiched to empty one - though this is already denied here. The reason I thought about it was a message on one of the Google official docs about slots and Android 13 and Android 12 that second slot stays empty. |
|
Everything @pascallj mentioned is correct. Based on this:
I think you unfortunately have a hard brick. For Qualcomm-based devices, there are lower level tools to help recover, but there's nothing publicly available for Google Tensor-based devices. Pixel bootloaders don't allow you attempt
This is likely what caused it not to boot. If it's anything like regular Magisk's I'm very confused as to what might've potentially turned off the OEM unlock switch. As far as I'm aware, that is the one and only way that the bootloader can end up in this state. Hopefully it's not something that this specific OS did on its own. I know some carrier versions of Pixels have additional checks to enable unlocking (eg. the T-Mobile USA variant of Pixel devices only allow bootloader unlocks if the device is paid off and also SIM unlocked). I hope auto-disabling isn't something that Google introduced. |
|
Well, I just found this: https://www.reddit.com/r/CalyxOS/comments/v8qtwk/why_is_it_so_important_to_disable_oem_unlocking/ Although I can't find any official documentation by CalyxOS, is seems they disable OEM unlocking by default after installation. I think this is a terrible thing to do by default without giving the user a huge warning. So that might explain it. Although I don't think this will work, maybe you can try the Android Flash Tool. I don't think this tool can do much more than we can with fastboot, but I never tried it so I am not sure how it works. I was also hoping rescue mode would still work when bricked but then you should see the "Waiting for rescue command" prompt. But you can still give it a shot using https://pixelrepair.withgoogle.com/ |
|
Thanks for confirmation of the bad news. Neither Android Flash Tool nor Pixelrepair, even if discover device, do not move on, claiming that can't communicate with device. I'm pretty sure one of the commands issued just fails due to Bootloader locked or recovery/rescue mode being absent. The design doesn't make sense as it literally makes the phone a brick and bootloader should provide an ability to at least wipe device out and push new binaries. There are SSD commands (and am sure eMMC exist similarly) to wipe storage with one command. This is certainly about willingness how Google wants to handle it. With my situation - hard brick outside of trying to replace it under warranty (it is 7 days old phone now), could this be potentially fixed by one of local phone specialists, i.e. they might have some magic boxes or in worst case open up the phone and overwrite eMMC or something? Just to bring it to life. I can't imagine I've fully working (from HW side) piece of electronics which all I could is bin or sell for parts?! Thanks again! |
|
If I was in your place I'd definitely feel the same way. I think your device should be yours and you should be able to do with it what you want. So from a right to repair standpoint, I agree. However, and I'm playing devil's advocate here, we are doing something that Google did not exactly designed for. It works because they wrote the specification and they mostly obey to their own specification. As long as the image is okay and the device is not rooted, this is not a problem because with system-as-root, the system is immutable and therefore always works. If some data ruins the operation of the device, just wipe the data and the system is in the exact same state as it was prior to the data being there. This two-stage unlock, as I call it, wasn't always present. Previously just sending 'fastboot unlock' was enough to wipe the device and unlock it (and therefore make the device basically unbrickable). I can see why they implemented it though. They want to verify that the one who unlocks the bootloader, also is the one who has complete access to the device. This second step can only be done after a user has successfully logged in. However what I don't know is what attack vector they had in mind when designing this which wasn't covered previously. As long as flipping between lock and unlock wipes the device, your data should be safe. It also isn't a anti-theft thing, because you can still wipe the device just fine in the recovery menu and use a stolen device that way. You can even now unlock it afterwards and you are basically in the exact same state as you would be if you unlocked it immediately.
There are some partitions which you should not wipe because these contain IMEI data, firmware, calibration data and all that stuff which is device specific. This could however be implemented on a different flash chip (maybe it is, I don't know).
I don't want get your hopes up, but this should be repairable (in theory). Probably not under warranty though, so you might have to pay a fee. I've read reports of people getting their bricked Pixels reflashed for tens of dollars. However this is the internet and your mileage may vary, especially as it depends on where you are from and what your options are. Maybe their phones weren't even as bricked as they thought they were. However you should definitely go to or send it to a certified Google repair center (or whatever they call it). I would discourage you from going to your local screen repair phone kiosk. They probably can't do much more than we can. |
Darn, looks like that is indeed the case: If the bootloader is locked, the CalyxOS setup wizard will unconditionally turn off the OEM unlock switch: https://github.com/CalyxOS/platform_packages_apps_SetupWizard/blob/7d2df25cedcbff83ddb608e628f9d97b38259c26/src/org/lineageos/setupwizard/SetupWizardApp.java#L135-L140 |
…locking Issue: #84 Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
|
If you can think of any valid reason why they would do that, please enlighten me. They would only have to supply one faulty update to brick all of their users' devices. |
|
I agree, it seems very dangerous. The only reason I can possibly think of is if they don't trust |
|
Thanks guys - what the CalyxOS done is insane and me being silly that didn't quadruple check it - though thought I did it. Potentially I did it prior one other OTA update and after boot it just does it - every time. This is almost worse than what Google does ;) |
|
I don't think it can be fixed remotely. Please let us know how this works out! |
|
Did you have any luck @bugsyb ? It seems the same thing just happened to me only I am on a pixel 5, magisk stable and grapheneOS. Ive been using avbroot and patching the OTA updates for sideloading. Everything was great. Then a got a notification that there was an update for the magisk app so I updated. Then to install I received the option for "Direct Install (Recommended)" which I didnt recall having before(must have just been pushed to stable). I didn't give much thought like I should have, so I selected it. Same exact results as you - cannot boot Invalid OS and cannot get into recovery. So I was excited after finding your thread and hoping there was a fix because I really didnt want to have all my data wiped and start from scratch. Then I read that you werent even able to unlock the boot loader anymore... After reading further with @pascallj's findings that calyxOS disabled OEM unlocking my stomach dropped. I too recall seeing the OEM unlocking option greyed out but showing as enabled. I have no idea why they would do that besides to purposely brick the phone of people who root their roms. I have always taken special care to make sure I never switched off OEM unlocking because of this risk. The grapheneOS lead dev is vehemently against people rooting his rom and I have seen exchanged where he gets upset and ridicules anyone who asks about rooting . I'm almost afraid to try unlocking the bootloader now. @chenxiaolong & @pascallj , one thing I'm not understanding though - wouldn't this new magisk "direct install" option cause the even a stock pixel to brick , since it changes the boot signature? If that is the case then it mustve caused a bunch of people to have to unlock and wipe all their data. ugh, I am going to so some more research and then I will try to unlock my boot loader and see if it's even possible anymore. Will report back |
Yep, assuming the same conditions (locked bootloader + Magisk Direct Install), then it'll render the device unbootable regardless if it's stock or a custom OS. Magisk would flash its newly created unsigned boot image, which would not be trusted by the bootloader. (I'd imagine most folks are using unlocked bootloaders and anyone using stock + locked bootloader + Magisk are probably avbroot users though.) Hopefully unlocking the bootloader (along with its unfortunate data wipe) will do the trick for you. I did a quick search over GrapheneOS's code and it doesn't look like there's anything that would automatically change the |
|
Sadly, I didn't manage to recover this phone till now. I too didn't touch the OEM Unlocking switch and I too remember seeing it enabled/greyed though after confirmation from the code perspective that it disables it... it doesn't make sense. What I don't get is why CalyxOS/GrapheneOS, for which OEM unlocking needs to be enabled first then are against it. It's privacy but also it is our device. This is separate conversation. What is on CalyxOS is the worst... auto-disable. |
Maybe it was already clear from @chenxiaolong's answer, but I'd like to explicitly point out that it would make it unbootable, but not bricked. Of course this only applies to 'stock' pixels with avbroot. I can't remember if it's there, but maybe @chenxiaolong can add a note to the Readme which points out that you should also never update Magisk via the app. Technically you can update the app only and not the 'Magisk rooting method', but there is not really a valid reason to do that. |
@pascallj, would you mind to share steps how to boot it/recover? This is based on (#84 (comment))
|
I was responding to @derzahla's case where OEM unlocking hasn't been changed. In that case a Magisk update will only make the device unbootable but not bricked. In your case CalyxOS has flipped your OEM unlock switch and you've installed another boot.img though Magisk. Therefore we're pretty sure your device is bricked. |
The module helps reduce the chance of OEM unlocking being disabled, whether by the user or by some OS's initial setup wizard. It works by running some Java code at boot, which connects to the `OemLockService` binder service and calls `setOemUnlockAllowedByUser(true)`, the same as what the Settings app does. Fixes: #8 Issue: #84 Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
The module helps reduce the chance of OEM unlocking being disabled, whether by the user or by some OS's initial setup wizard. It works by running some Java code at boot, which connects to the `OemLockService` binder service and calls `setOemUnlockAllowedByUser(true)`, the same as what the Settings app does. Fixes: #8 Issue: #84 Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
The module helps reduce the chance of OEM unlocking being disabled, whether by the user or by some OS's initial setup wizard. It works by running some Java code at boot, which connects to the `OemLockService` binder service and calls `setOemUnlockAllowedByUser(true)`, the same as what the Settings app does. Fixes: #8 Issue: #84 Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
|
With Magisk version 26.3 I see this:
Every time you open the app, it complains. The message seems pretty compelling but the end result is bricking your phone. Has anyone filed a bug upstream to address this? |
|
@ccoager Can you open a new avbroot issue for that? That specific issue is unlikely to be an upstream bug. |
|
@chenxiaolong I'm talking about the same issue in this thread. I was uninformed before reading this thread. I let Magisk do a direct patch and ended up with, "No valid operating system could be found." Fortunately, I was able to reinstall. There seems to be two issues here:
These are the reasons I was asking if an upstream bug has been filed. |
|
Ah, understood.
There are various states where Magisk can run well enough where most root apps and Magisk modules behave, but other components break (most notably, Magisk modules' custom SELinux policies). This is likely why they added the checks. For Magisk 26.0 and newer, the
Yeah, this is annoying and it's unfortunate we don't have a way of blocking Magisk's direct install feature entirely. I think it's pretty unlikely upstream would add protections to help prevent this. They only support unlocked bootloader setups where it's fine to flash an unsigned boot image. |
|
Pretty sure this just happened to me. I wasn't thinking and directly installed it from the magisk app. My phone says no vaild operating system and the device state says locked. In fastboot mode there is no option to unlock or lock the bootloader. Boot slot says b. Recovery mode just says no vaild operating system. I guess I'm screwed? Is there anything I can even do with a bricked phone... at all? |
|
@jordanss1 What OS were you using with avbroot while this happened?
What do you mean there is no option? Do the commands fail? |
|
I was using GrapheneOS on a Pixel 7. When I use
My terminal says
And then
Results in
Even though I had the OEM Unlock module installed by @chenxiaolong I think somehow when I did the direct install of Magisk it over-rode that and now there is no option to unlock the bootloader in fastboot mode and, as above, using fastboot flashing unlock is ineffective. I've accepted my fate tbh : / |
As far as I know, GrapheneOS does not disable the OEM unlocking switch which was the issue in this thread. This is what bricked the device in question.
This has to be solved first. Your terminal does not have the permissions to access devices. Please try again running as root (via sudo or whatever).
This is expected behaviour with the issue above.
I have not, yet 😉 |
Haha thanks bro but I really think I'm screwed this time. It isn't to do with sudo because I've always been able to adb and fastboot without it. But trying it with sudo results in
I don't think you can run those commands with sudo.
You're right, it has never disabled OEM Unlocking but in this situation where I've installed Magisk directly from the app itself I believe is what has screwed me. I've done some searching around and I can see other people with this issue have hard bricked. I had a similar issue before but when it happened unlocking the bootloader was an option in fastboot mode. Now there's not even that option. |
What OS are you using? I am not sure exactly what permissions you need, but I think you either have to add your user to a group and restart you session, or run as root for the kind of access adb and fastboot need to function properly. I don't have much time to investigate this right now and direct you, but as long as you can't run adb devices without that error, it is still a problem on your system and not with the phone. So you can look into that.
That will indeed make you unable to boot the phone if the bootloader is locked, but it should not disallow you to unlock your bootloader. I am reasonably sure that there is no sign that your device is bricked from everything you mentioned. It is all expected behaviour so far. |
|
I am using Linux Mint. I'm not sure you're right about this because I have played around with adb and fastboot on my phone plenty of times without having to escalate privilege. Just the fact that the unlock/lock bootloader option is not showing up in fastboot tells me all I need to know. That option has always been there when I've screwed something up. ADB works but the it can't recognize the device. |
|
Do you have another android phone you can enable ADB on to actually verify that adb works? Because I have had that error before and it always was a permission issue. Or did you have that permission error before while actually using AVB and despite the error it worked? |
|
Wow I have no idea what did it but I just installed the new platform tools and disconnected my device and it worked when I used fastboot flashing unlock. It might have something to do with when I added this earlier in response to that permission error I had
Because after reconnecting the device it seems to have worked. Thanks for not giving up on me bro! |
|
One last question: if I remove the custom key using
Can I go ahead and sideload the stock Graphene OTA update or does it have to be the full install? Edit: nevermind all sorted |
No worries, glad you got it working! Please note that that rule does give every user access to devices who identify them as such. So this also goes for 'system users' or others users on the system. It is not that big of a deal, but in my opinion it is better to make your user part of the plugdev group, so only you have those permissions. But that aside.
You can only sideload an update OTA if your current version is exactly the image it expects as the one before that I think. So if your current OS is avbroot or touched by Magisk or anything other than a completely untouched GrapheneOS, you have to do a full install. You also cannot boot any avbroot'ed OS signed with your keys anymore if you do that (if the bootloader is locked). |
|
@bugsyb what happened to your phone? Did you manage to repair it? |
|
Google accepted it for repair, though accepted it EU and tried to send it from US, claiming it's a US version (which it wasn't). All in all, had to pay custom duties and VAT of the SRP price, which in effect was more than sourcing locally another phone... Google Support is sh#@$, really. Had to work with like 30 reps over weeks and none of them reading past exchange. Will never go with Google phone again. |
|
I don't know where you live, but you usually shouldn't have to pay customs tax for a product which is already imported once. This must be a declaration error. Have you tried to get the money back from your local customs? |
|
That's what I knew... Funny is that failed was returned to Google EMEA repair center, in fact it all is sent to Poland/EU. The replacement, Google said, can only issue out of US, hang tight, and send only to US address! |
Asking here as hopes are given your knowldge, you'll be able to advise as it touches images signing elements.
I've had CalyxOS with Magisk Delta and patched OTA - all worked fine.
Since last bootloader lock as part of inistial install, nothing has been touched in the settings around (OEM unlock - and I'd bet I've seen it enabled and grayed out maybe even?).
Initially I had Magisk Stable and (this will become later important) upon first run, it asks to proceed with additional tasks and reboots - all went fine.
Afterwards (many reboots after as was trying to get all SafetyNet passed), decided to go ahead with Magisk Delta.
Original OTA has been re-patched this time with Magisk Delta. OS did boot and reboot, all fine. Did run Magisk Delta app and it did ask to perform additional steps, same as Magisk (Stable). This time though it gave three options - following recommendation elsewhere (Magisk Delta thread on XDA), in-place option has been used and feeling was it was the closes to normal Magisk (as is more basic). Similar patching is done when Magisk Modules are installed.
After this OS was reboot (same as in case of normal Magisk), this time though - OS didn't boot up anymore.
The most I can get is bootloader (no recover/rescue) and system claims
Looking at bootloader it shows that it is slot b. Trying to unlock bootloader fails! (I have no idea why, as didn't touch this).
Therefore as I can't get to OS, recovery or unlock bootloader, I'm kind of stuck, not sure if not even with a hard-brick.
Feeling is that somehow it switched to slot b (though reading elsewhere it switches slots on every OTA update/does it on OTA sideload too?). Maybe slot b is empty and that's the problem. With that said, I can't change slots with bootloader locked either.
Can I try to fastboot image signed image? Which one should I try? From Google or try to patch/avbroot sign factory one from CalyxOS?
For the moment I just need to restore system to live and then can try further.
Thanks in advance!
The text was updated successfully, but these errors were encountered: