Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Question / ask for help: hard bricked? #84

Open
bugsyb opened this issue Mar 23, 2023 · 36 comments
Open

Question / ask for help: hard bricked? #84

bugsyb opened this issue Mar 23, 2023 · 36 comments
Assignees

Comments

@bugsyb
Copy link

bugsyb commented Mar 23, 2023

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

No valid operating system could be found.
The device will not boot.

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!

@pascallj
Copy link
Contributor

pascallj commented Mar 23, 2023

Hi, I'm sorry to hear this. Maybe I can help.

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.

I think you are referring to the three options which are given when you try to install Magisk through the app:

* Select and Patch a file
* Direct Install (Recommended)
* Install to Inactive Slot (After OTA)

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 vbmeta and therefore when your bootloader is locked, AVB won't let your device boot. Normally this is not an issue as this is not checked when you have your bootloader unlocked. This is what the Readme refers to:

  • The Direct install method for updating Magisk. Magisk updates must be done by repatching as well.

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.

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.

Why does it fail? Is there a particular error message?

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.

This is correct. On every update the slots are switched, also on sideload.

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?

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?

@bugsyb
Copy link
Author

bugsyb commented Mar 24, 2023

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!).
It fails with:

fastboot flashing get_unlock_ability
...
(bootloader) get_unlock_ability: 0
OKAY [  0.042s]
finished. total time: 0.042s

And then

fastboot flashing unlock
...
FAILED (remote: flashing unlock is not allowed)
finished. total time: 0.044s

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".
In case of Magisk (Stable/normal) it just prompted immediately for reboot and then all worked fine.
In case of Magisk Delta, message was similar and then gave the three options you've mentioned, whilst it was already installed and showing from the app level. Because it was (at least looked like) direct outcome of the message that it needs to make some more steps to finish installation and it was advised on XDA Magisk Delta thread, I used the Direct Install option. Straight after this as it did reboot, there's no OS.

For the moment:

  • recover - doesn't load
  • rescue - same - doesn't show anything after being selected
  • bootloader unlock - fails (exact dump above)
  • OEM Unlock switch is unaccessible as it OS doesn't load.

Is there any chance to do anything from bootloader level?
Something like: fastboot update OTA.zip ?

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.

@chenxiaolong
Copy link
Owner

Everything @pascallj mentioned is correct. Based on this:

It fails with:

fastboot flashing get_unlock_ability
...
(bootloader) get_unlock_ability: 0
OKAY [  0.042s]
finished. total time: 0.042s

And then

fastboot flashing unlock
...
FAILED (remote: flashing unlock is not allowed)
finished. total time: 0.044s

Nothing happens when "Recovery" or "Rescue" is selected from Bootloader level.

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 fastboot flash or fastboot boot while locked (even with a stock Google-signed image).

I used the Direct Install option. Straight after this as it did reboot, there's no OS.

This is likely what caused it not to boot. If it's anything like regular Magisk's Direct Install, Magisk Delta would've flashed an unsigned boot image as part of that.


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.

@pascallj
Copy link
Contributor

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/

@bugsyb
Copy link
Author

bugsyb commented Mar 24, 2023

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!

@pascallj
Copy link
Contributor

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 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.

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).

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?!

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.

@chenxiaolong
Copy link
Owner

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.

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

@pascallj
Copy link
Contributor

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.

@chenxiaolong
Copy link
Owner

I agree, it seems very dangerous. The only reason I can possibly think of is if they don't trust fastboot flashing unlock to properly wipe the encryption keys for the data partition.

@bugsyb
Copy link
Author

bugsyb commented Mar 25, 2023

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'll search for Google authorized repair center - thanks for all ideas. If you'd be aware of any guys providing $$$ service remotely - I might consider it... as it looks like it can't get worse from now ;)

@pascallj
Copy link
Contributor

pascallj commented Mar 30, 2023

I don't think it can be fixed remotely. Please let us know how this works out!

@derzahla
Copy link

derzahla commented Apr 13, 2023

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

@chenxiaolong
Copy link
Owner

@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.

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 OEM unlocking toggle, so it should be in the same state you left it.

@bugsyb
Copy link
Author

bugsyb commented Apr 13, 2023

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.
Can you get it to boot to recovery? I can't, literally nothing works and it is real hard brick for me.
Hope is yours OEM Unlocking is enabled and your loss will be data/config loss and not $$$ due to hard bricked device.

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.

@pascallj
Copy link
Contributor

@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.

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.

@bugsyb
Copy link
Author

bugsyb commented Apr 13, 2023

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.

@pascallj, would you mind to share steps how to boot it/recover?
I'm asking about it as below drove me to state the hard brick and I've tried all commands I could find.
All of them come down to: OEM Unlocking seems to be disabled and as such I can't do anything.
I do have keys used with avbroot and potentially could sign any other image boot.img to try to boot - I just hopefully missed the magic formula to get it running.

This is based on (#84 (comment))

[chenxiaolong]
Everything @pascallj mentioned is correct. Based on this:

It fails with:

fastboot flashing get_unlock_ability
...
(bootloader) get_unlock_ability: 0
OKAY [  0.042s]
finished. total time: 0.042s

And then

fastboot flashing unlock
...
FAILED (remote: flashing unlock is not allowed)
finished. total time: 0.044s

Nothing happens when "Recovery" or "Rescue" is selected from Bootloader level.

I think you unfortunately have a hard brick

@pascallj
Copy link
Contributor

@pascallj, would you mind to share steps how to boot it/recover? I'm asking about it as below drove me to state the hard brick and I've tried all commands I could find. All of them come down to: OEM Unlocking seems to be disabled and as such I can't do anything. I do have keys used with avbroot and potentially could sign any other image boot.img to try to boot - I just hopefully missed the magic formula to get it running.

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.

chenxiaolong added a commit that referenced this issue May 23, 2023
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 <[email protected]>
chenxiaolong added a commit that referenced this issue May 23, 2023
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 <[email protected]>
chenxiaolong added a commit that referenced this issue May 23, 2023
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 <[email protected]>
@ccoager
Copy link

ccoager commented Sep 8, 2023

With Magisk version 26.3 I see this:

Requires Additional Setup
Your device needs reflash Magisk to work properly. Please reinstall Magisk within app, recovery mode cannot get correct device info.

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?

@chenxiaolong
Copy link
Owner

@ccoager Can you open a new avbroot issue for that? That specific issue is unlikely to be an upstream bug.

@ccoager
Copy link

ccoager commented Sep 8, 2023

@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:

  1. Magisk thinks it needs to reflash itself when it really doesn't
  2. Patching from Magisk ends up bricking your phone

These are the reasons I was asking if an upstream bug has been filed.

@chenxiaolong
Copy link
Owner

Ah, understood.

  1. Magisk thinks it needs to reflash itself when it really doesn't

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 Your device needs reflash Magisk to work properly. error only occurs if the preinit device doesn't match what Magisk expects. Usually, this happens because the wrong partition was chosen for --magisk-preinit-device, but it can also happen if the Magisk app version doesn't match the version of Magisk used when patching the OTA with avbroot. Magisk app 26.3 + avbroot OTA patched with 26.1 is one scenario where I've personally encountered this.

  1. Patching from Magisk ends up bricking your phone

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.

@chenxiaolong chenxiaolong self-assigned this May 31, 2024
@jordanss1
Copy link

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?

@pascallj
Copy link
Contributor

@jordanss1 What OS were you using with avbroot while this happened?

In fastboot mode there is no option to unlock or lock the bootloader.

What do you mean there is no option? Do the commands fail?

@jordanss1
Copy link

I was using GrapheneOS on a Pixel 7. When I use

adb devices

My terminal says

no permissions (missing udev rules? user is in the plugdev group); see [http://developer.android.com/tools/device.html] fastboot

And then

fastboot flashing unlock

Results in

< waiting for any device >

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 : /

@pascallj
Copy link
Contributor

I was using GrapheneOS on a Pixel 7.

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.

When I use

adb devices

My terminal says

no permissions (missing udev rules? user is in the plugdev group); see [http://developer.android.com/tools/device.html] fastboot

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).

And then

fastboot flashing unlock

Results in

< waiting for any device >

This is expected behaviour with the issue above.

I've accepted my fate tbh : /

I have not, yet 😉

@jordanss1
Copy link

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

sudo: adb: command not found
sudo: fastboot: command not found

I don't think you can run those commands with sudo.

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.

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.

@pascallj
Copy link
Contributor

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

sudo: adb: command not found
sudo: fastboot: command not found

I don't think you can run those commands with sudo.

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.

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.

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.

@jordanss1
Copy link

jordanss1 commented Aug 18, 2024

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.

@pascallj
Copy link
Contributor

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?

@jordanss1
Copy link

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

$ sudo vim /etc/udev/rules.d/51-android.rules SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}=="2e81", MODE="0666", GROUP="plugdev"

Because after reconnecting the device it seems to have worked. Thanks for not giving up on me bro!

@jordanss1
Copy link

jordanss1 commented Aug 18, 2024

One last question: if I remove the custom key using

fastboot erase avb_custom_key

Can I go ahead and sideload the stock Graphene OTA update or does it have to be the full install?

Edit: nevermind all sorted

@pascallj
Copy link
Contributor

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

$ sudo vim /etc/udev/rules.d/51-android.rules SUBSYSTEM=="usb", ATTR{idVendor}=="22b8", ATTR{idProduct}=="2e81", MODE="0666", GROUP="plugdev"

Because after reconnecting the device it seems to have worked. Thanks for not giving up on me bro!

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.

One last question: if I remove the custom key using

fastboot erase avb_custom_key

Can I go ahead and sideload the stock Graphene OTA update or does it have to be the full install?

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).

@adek23
Copy link

adek23 commented Sep 25, 2024

@bugsyb what happened to your phone? Did you manage to repair it?

@bugsyb
Copy link
Author

bugsyb commented Sep 26, 2024

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.

@pascallj
Copy link
Contributor

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?

@bugsyb
Copy link
Author

bugsyb commented Sep 30, 2024

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!
Then courier company used to send it back to EU, UPS, did submit to Tax Office, ignoring all status/request raised and said can release it only if duties would be paid and then they will fix it... And then turned around and claimed the ain't going to do anything as they did all good.
Will never use UPS either...
I'd need to take them to court and I simply don't have enough time for it - costs of the lawyer would be +/- at least the cost of duties...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants