Hi I just wanted some confirmation that unlocking bootloader doesn't block me from getting OTA updates from Google, since I haven't gotten an OTA for the latest build yet (The May update). I'm hoping this is only cause I'm in India and it hasn't pushed to us yet. I've enrolled in the Android Beta Program to test if OTA is really broken (since it sends an OTA with the Android N image.)
I haven't modified anything, I tried flashing TWRP but it didn't stick cause I didn't know I had to go into the recovery and modify the system/boot, so I still have the stock android recovery.
Any confirmation will give me a lot of peace of mind, cause I value getting OTAs and not having to manually flash it. If it has indeed been broken, I want to know if relocking would fix it and if relocking would wipe data again. Thanks for your help
EDIT: Just got the OTA for the N preview, so I guess it's just a roll out thing then. Just want to leave this here for anyone else who's new to nexus devices and was wondering the same.
AnrgKrshn said:
Hi I just wanted some confirmation that unlocking bootloader doesn't block me from getting OTA updates from Google, since I haven't gotten an OTA for the latest build yet (The May update). I'm hoping this is only cause I'm in India and it hasn't pushed to us yet. I've enrolled in the Android Beta Program to test if OTA is really broken (since it sends an OTA with the Android N image.
I haven't modified anything, I tried flashing TWRP but it didn't stick cause I didn't know I had to go into the recovery and modify the system/boot, so I still have the stock android recovery.
Any confirmation will give me a lot of peace of mind, cause I value getting OTAs and not having to manually flash it. If it has indeed been broken, I want to know if relocking would fix it and if relocking would wipe data again. Thanks for your help
Click to expand...
Click to collapse
Simply having an unlocked bootloader won't stop you from receiving OTAs. I don't believe they've even began pushing the OTA for the May update.
brholt6 said:
Simply having an unlocked bootloader won't stop you from receiving OTAs. I don't believe they've even began pushing the OTA for the May update.
Click to expand...
Click to collapse
Just saw this after I posted my edit lol. Thanks for the confirmation
Will the ota work with systemless root?
94SupraTT said:
Will the ota work with systemless root?
Click to expand...
Click to collapse
You need to flash stock boot and recovery images to receive it or alternatively use chainfires flashfire app.
This is really a big topic that no one asks, everyone just asks how to fix it but I want to know what exactly happens to Android system in deep that cause hard brick and unable to start the device. Previously when I had a Chinese phone, it was so simple to downgrade and upgrade stuff without bricking because there was no bootloader at all. Everytime I check it said "Unkonwn Bootloader". I'd be happy if someone explain or just drop links about the bootloader and why hard brick happens due to downgrade. I am thinking a way to fix the hard brick device in a way that will fix it all the time with just a simple procedure, doesn't matter if you had downgraded or rekt system stuff or you're on any Android version, it will be fixed. It sounds stupid but I think there must be a way, if we go more deeper into Android system, we can make it working.
I'll have a go at answering this...
It's generally not the downgrading of stock Motorola firmware that bricks a device, often times it's the usage of OTA updates following a downgrade that causes the hard brick.
From what I've seen of many hard bricks (on Moto G4/Plus, G5 Plus, Z Play, though probably a similar scenario on other devices from other manufacturers):
1)You have your system firmware and your bootloader. E.g. The C1:14 version bootloader comes with the Feb 2018 7.1.1 stock Nougat firmware/OTA update. Normally, they would be matching (so you'd have the 7.1.1 Feb 2018 firmware with the C1:14 bootloader). Using OTA updates would be no problem.
2)If you downgrade your stock firmware (custom ROMs usually are not applicable in this case, regardless of the custom ROM security patch/version), you may be able to flash older stock firmware but your bootloader cannot be downgraded. E.g. you flashed the August 2017 7.1.1 stock firmware on a device previously updated to Feb 2018 stock firmware. You'd have the August 2017 system firmware but a Feb 2018 bootloader. Your device may run okay and the flash may have gone okay besides some 'security version downgrade' errors with the bootloader and GPT.
3)So your downgraded device runs okay and you get an OTA prompt to the Sept 2017 security patch OTA. This is where the problems start. OTA updates appear to only be verified by your system version, and looking through the updater scripts for various OTA updates, they check if your system partition, OEM, boot (kernel) etc are fully stock and are of the correct build to flash to. Tellingly, the OTA script does not seem to check for your bootloader version , I think the OTA assumes your bootloader and the system are of the same matching versions/patch levels. As you've downgraded your device, this assumption does not hold. Should there be a check for the bootloader version if it was possible? Perhaps.
4)Your device reboots and begins flashing the Sept 2017 OTA. So far, the OTA is checking and verifies your device is running the August 2017 firmware, and begins patching. However, the OTA can patch your bootloader with older images without verification, which means it applies Sept 2017 images to a Feb 2018 bootloader, corrupting the bootloader and thus hard bricking your device.
(EDIT - reading this page, it suggests that there are multiple bootloaders in your device, each one verifying each other to ensure integrity. https://forum.xda-developers.com/android/general/info-android-device-partitions-basic-t3586565 My guess is that applying the old OTA images to a newer bootloader changes the signature of the bootloader we see - e.g. changing the signature of the secondary bootloader/SBL or having an old aboot image in the newer bootloader - and so fails the upstream verification, hence a hard brick.)
I'm not sure how your old device's bootloader is different, maybe it's a lot less stringent. Was it running a Qualcomm bootloader or a Mediatek bootloader?
However, with Qualcomm bootloaders, if the bootloader image is corrupted they appear to fall back to a emergency download mode (you can read more here: https://alephsecurity.com/vulns/aleph-2017028 ). To recover, you often need crytographically signed images from the appropriate OEM (Motorola in this case) to rescue a device in such a state. As I understand it, these images - including the often requested blankflashes - include methods to communicate with your device (via the sahara protocol) https://github.com/openpst/sahara and a programmer to verify your device and bootloader are suitable for repairing, before flashing a new bootloader: https://forum.xda-developers.com/showpost.php?p=62191317&postcount=2112 https://forum.xda-developers.com/showpost.php?p=63490742&postcount=17 We cannot make these, and any attempts to modify them would likely break the cryptographic signatures on the files, so would be rejected (else you could inject your own compromised bootloader, or downgraded bootloader as per the paper, which would be dangerous for security). This security issue is likely why OEMs do not release blankflashes or other such repair files.
If the blankflash is too old or older than the corrupted bootloader, the programmer appears to fail to rescue the device. Short of having the actual, signed files in a blankflash or similar, that are as new or newer than your current corrupted bootloader, it becomes very hard to rescue a device. That's likely why we've seen quite a few Z Play devices on 7.1.1 or 8.0 that downgraded and got corrupted by an OTA that are not rescuable at the moment - we simply do not have updated tools. Motorola (and likely other OEMs) seems to regard these blankflashes as internal development tools and as such won't give them out - all we have are leaks. I imagine Motorola's point of view also includes that since your bootloader was unlocked, you assume responsiblity for anything that happens.
If you do hard brick then I recall there are a few options:
a)Hope that a blankflash or updated MSM8953 programmer/signed images for Motorola devices is leaked. Must be as new or newer than your corrupted bootloader (recall you cannot downgrade bootloaders). No guarantee of being released if at all.
b)Hope that someone finds a JTAG or other board level repair.
c)Pay for a motherboard replacement (expensive, 60-80% of the device cost sometimes) - perhaps you may be covered by local consumer laws.
d)Buy a new device, forget about repairing this one.
As I mentioned above, hard bricks are very difficult to recover from without the correct tools. However, they are avoidable if users do not flash older stock firmware, only flashing the same stock firmware as they had on their device (matching their bootloader) or newer stock firmware. If they do downgrade, then not using OTA updates whatsoever may also save them from a hard brick (though in that case you must use the latest stock firmware to update with). Alternatively, if you unlocked your device bootloader, you could just use TWRP flashable stock ROMs and forget about using stock firmware at all - TWRP flashables in general should not affect the bootloader.
Any further comments or corrections welcome.
echo92 said:
I'm not sure how your old device's bootloader is different, maybe it's a lot less stringent. Was it running a Qualcomm bootloader or a Mediatek bootloader?
.
Click to expand...
Click to collapse
Yes indeed it was a mediatek device and thank you so much for your answer, I really appreciate it.
So a patched bootloader will able to bypass the verification step and the update will be flashed easily but the problem is with the security. BTW, what kind of security concerns? Will my device become vulnerable to hackers and viruses?
And if the patching bootloader is a pain then is there any way to patch the OTA itself? A patched OTA which doesn't requires verification and won't cause hard bricking. So if a person who has downgraded to predecessor version and have a bootloader of successor version can get the successor version of Android through side loading the patched OTA.
I was thinking about the JTAG stuff but it's overall not economically feasible.
I think patched Ota update is a good way to get around but is it possible?
Manish355 said:
Yes indeed it was a mediatek device and thank you so much for your answer, I really appreciate it.
So a patched bootloader will able to bypass the verification step and the update will be flashed easily but the problem is with the security. BTW, what kind of security concerns? Will my device become vulnerable to hackers and viruses?
And if the patching bootloader is a pain then is there any way to patch the OTA itself? A patched OTA which doesn't requires verification and won't cause hard bricking. So if a person who has downgraded to predecessor version and have a bootloader of successor version can get the successor version of Android through side loading the patched OTA.
I was thinking about the JTAG stuff but it's overall not economically feasible.
I think patched Ota update is a good way to get around but is it possible?
Click to expand...
Click to collapse
Good questions.
1)In theory, a patched bootloader may let you bypass the verification step, though the upstream bootloaders (including those burned into your device's memory) may still stop that bootloader from running, as it fails the 'chain of trust' as Google puts it. https://source.android.com/security/verifiedboot/verified-boot
As for security concerns, well, who knows? If you could put a compromised bootloader onto your device with the correct authorisations, it could do anything. That's likely why blankflashes are not around, plus the fact they have to be signed by the issuing OEM to be valid. Else, that could be a potential vector to breaking security. If you can't trust the guardian of your device (which the bootloader can act as), what can you then trust about that device?
2)In theory, again, you could patch the OTA, but the OTA is signed, and thus any modification may break the signing. This would then cause rejection by the stock recovery https://source.android.com/devices/tech/ota/sign_builds
I have seen OTA updates modified to work with TWRP, though I think they may not update your bootloader (e.g. have a look here: https://forum.xda-developers.com/g5-plus/how-to/npn25-137-33-stock-firmware-t3577081/page12 ) However, in that case, you may be better off staying with TWRP flashables of the stock ROM and forget about using stock ROM firmware if you are worried about the bootloader.
So in summary, if you want to avoid a hard brick, some ways are:
1)Ensure you only flash the latest firmware onto your device that is as new or newer than your bootloader. If your bootloader is locked, that should apply automatically (as the bootloader will block downgrades).
2)If you do choose to flash older stock firmware that is older than your bootloader version, please do not use OTA updates. Only use newer stock firmware to update (and ensure it's the correct build for your region/software channel).
3)If you so wish and you have an unlocked bootloader, forget about using stock firmware, use the TWRP flashables of the stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/development/rom-nov-patch-npns26-118-22-2-8-t3717037) Of course, OTA updates are not usable.
echo92 said:
Good questions.
1)In theory, a patched bootloader may let you bypass the verification step, though the upstream bootloaders (including those burned into your device's memory) may still stop that bootloader from running, as it fails the 'chain of trust' as Google puts it. https://source.android.com/security/verifiedboot/verified-boot
As for security concerns, well, who knows? If you could put a compromised bootloader onto your device with the correct authorisations, it could do anything. That's likely why blankflashes are not around, plus the fact they have to be signed by the issuing OEM to be valid. Else, that could be a potential vector to breaking security. If you can't trust the guardian of your device (which the bootloader can act as), what can you then trust about that device?
2)In theory, again, you could patch the OTA, but the OTA is signed, and thus any modification may break the signing. This would then cause rejection by the stock recovery https://source.android.com/devices/tech/ota/sign_builds
I have seen OTA updates modified to work with TWRP, though I think they may not update your bootloader (e.g. have a look here: https://forum.xda-developers.com/g5-plus/how-to/npn25-137-33-stock-firmware-t3577081/page12 ) However, in that case, you may be better off staying with TWRP flashables of the stock ROM and forget about using stock ROM firmware if you are worried about the bootloader.
So in summary, if you want to avoid a hard brick, some ways are:
1)Ensure you only flash the latest firmware onto your device that is as new or newer than your bootloader. If your bootloader is locked, that should apply automatically (as the bootloader will block downgrades).
2)If you do choose to flash older stock firmware that is older than your bootloader version, please do not use OTA updates. Only use newer stock firmware to update (and ensure it's the correct build for your region/software channel).
3)If you so wish and you have an unlocked bootloader, forget about using stock firmware, use the TWRP flashables of the stock firmware (e.g. https://forum.xda-developers.com/moto-z-play/development/rom-nov-patch-npns26-118-22-2-8-t3717037) Of course, OTA updates are not usable.
Click to expand...
Click to collapse
Wow, you're the man. I was expecting that because when I looked into the OTAs, I found it's hard to modify the OTA to work on signed bootloader. It's like a lock and key system that makes the OTA possible. Thanks for your help, it has saved me not of time.
BTW, the stock ROM (Oreo) replaces the build prop everytime I reboot? I am trying to modify the build prop but no results till now. Is it because of magisk? Because magisk is a systemless root so it prevents system modifications?
Manish355 said:
Wow, you're the man. I was expecting that because when I looked into the OTAs, I found it's hard to modify the OTA to work on signed bootloader. It's like a lock and key system that makes the OTA possible. Thanks for your help, it has saved me not of time.
BTW, the stock ROM (Oreo) replaces the build prop everytime I reboot? I am trying to modify the build prop but no results till now. Is it because of magisk? Because magisk is a systemless root so it prevents system modifications?
Click to expand...
Click to collapse
Hmm, if you're following this rooting guide, https://forum.xda-developers.com/moto-z-play/how-to/guide-how-to-magisk-root-xposed-oreo-8-t3743273 it could well be dm-verity which is still enabled on your device. As I understand it, dm-verity is there to prevent modifications to your system partition (which build.prop is part of) and other key partitions, or if it detects modifications, to stop your device from booting. Others have reported the same issue on other devices https://forum.xda-developers.com/mate-9/help/mount-writable-twrp-t3685867 https://source.android.com/security/verifiedboot/ I think dm-verity is strictly enforced on Nougat and I imagine the same applies to Oreo, if not more so.
However, looking at the magisk help documentation, attempting to disable dm-verity with the stock kernel (stock = the Motorola hudsoncm kernel in this case) can cause odd instabilities on devices https://www.didgeridoohan.com/magisk/MagiskIssues so you may have to look into flashing an Oreo based custom kernel, if one is available (which hopefully has the F2FS fix integrated, and has dm-verity disabled or not present) if you wish to modify your system. However, that custom kernel probably will have to wait for the Oreo stock kernel source to be released by Motorola, as you'll need the Motorola Oreo kernel source to build a compatible kernel for stock Oreo ROMs from what I understand.
echo92 said:
Hmm, if you're following this rooting guide, https://forum.xda-developers.com/moto-z-play/how-to/guide-how-to-magisk-root-xposed-oreo-8-t3743273 it could well be dm-verity which is still enabled on your device. As I understand it, dm-verity is there to prevent modifications to your system partition (which build.prop is part of) and other key partitions, or if it detects modifications, to stop your device from booting. Others have reported the same issue on other devices https://forum.xda-developers.com/mate-9/help/mount-writable-twrp-t3685867 https://source.android.com/security/verifiedboot/ I think dm-verity is strictly enforced on Nougat and I imagine the same applies to Oreo, if not more so.
However, looking at the magisk help documentation, attempting to disable dm-verity can cause odd instabilities on devices https://www.didgeridoohan.com/magisk/MagiskIssues so you may have to look into flashing an Oreo based custom kernel, if one is available (which hopefully has the F2FS fix integrated, and has dm-verity disabled or not present) if you wish to modify your system. However, that custom kernel probably will have to wait for the Oreo stock kernel source to be released by Motorola, as you'll need the Motorola Oreo kernel source to build a compatible kernel for stock Oreo ROMs from what I understand.
Click to expand...
Click to collapse
There's an option in magisk that says "Preserve AVB 2.0/dm-verity", should unchecking it will work?
Or rooting with SuperSU would work? I tried SuperSU 2.82, it all flashed but stuck on boot at the last. Do you know how can I root my device using SuperSU, safety net is not an issue.
Manish355 said:
There's an option in magisk that says "Preserve AVB 2.0/dm-verity", should unchecking it will work?
Click to expand...
Click to collapse
I honestly do not know, though it's possible unchecking that may cause a bootloop if magisk tries to disable dm-verity on the stock kernel. I'm hoping you could boot into recovery and enable dm-verity then re-flash magisk to get your device running if you do bootloop.
echo92 said:
I honestly do not know, though it's possible unchecking that may cause a bootloop if magisk tries to disable dm-verity on the stock kernel. I'm hoping you could boot into recovery and enable dm-verity then re-flash magisk to get your device running if you do bootloop.
Click to expand...
Click to collapse
Rooting with SuperSU would work? I tried SU 2.82 but my device got stuck at boot after long time and several bootloops. Do you know how to root using superSU? I don't mind safety net fail or pass, I don't use apps that requires safety net either.
Manish355 said:
Rooting with SuperSU would work? I tried SU 2.82 but my device got stuck at boot after long time and several bootloops. Do you know how to root using superSU? I don't mind safety net fail or pass, I don't use apps that requires safety net either.
Click to expand...
Click to collapse
I'm not familiar with rooting with SuperSU on the Z Play - for my G4 Plus, the easiest way was to flash a custom kernel (ElementalX courtesy of flar2 or vegito) which had dm-verity removed from the kernel. That way, when you flashed magisk or SuperSU, there was less risk of boot issues. There were dm-verity disablers but I recall they had to be modified for each new stock firmware and sometimes had boot issues if the patch didn't work properly.
I have absolutely no idea if this will work on the Oreo stock kernel, in theory you could unpack the kernel, disable dm-verity and re-pack the kernel: https://forum.xda-developers.com/showpost.php?p=69558535&postcount=7912
However, I think the most compatible and reliable path would be to compile a custom kernel, without dm-verity, from the Z Play Oreo kernel source, then flash that to your device then flash magisk/SuperSU.
echo92 said:
I'm not familiar with rooting with SuperSU on the Z Play - for my G4 Plus, the easiest way was to flash a custom kernel (ElementalX courtesy of flar2 or vegito) which had dm-verity removed from the kernel. That way, when you flashed magisk or SuperSU, there was less risk of boot issues. There were dm-verity disablers but I recall they had to be modified for each new stock firmware and sometimes had boot issues if the patch didn't work properly.
I have absolutely no idea if this will work on the Oreo stock kernel, in theory you could unpack the kernel, disable dm-verity and re-pack the kernel: https://forum.xda-developers.com/showpost.php?p=69558535&postcount=7912
However, I think the most compatible and reliable path would be to compile a custom kernel, without dm-verity, from the Z Play Oreo kernel source, then flash that to your device then flash magisk/SuperSU.
Click to expand...
Click to collapse
I haven't tried compiling a kernel, I am not a developer (I had ported ROMs for my old MTK device but none for this device, I am not very much familiar with snapdragon devices) so i think I should just flash a custom ROM, that would work, right?
Manish355 said:
I haven't tried compiling a kernel, I am not a developer (I had ported ROMs for my old MTK device but none for this device, I am not very much familiar with snapdragon devices) so i think I should just flash a custom ROM, that would work, right?
Click to expand...
Click to collapse
If you really want access to your /system partition and build.prop, custom ROMs are an option, yes, as their kernels shouldn't have dm-verity on and so are easier to root. Ensure you have the stock firmware to revert back to if you so wish and back up your data, as a custom ROM flash will usually mandate a data wipe/factory reset.
Alternatively, wait for the Z Play Oreo kernel source and for a developer to release a custom kernel built on that source.
echo92 said:
Alternatively, wait for the Z Play Oreo kernel source and for a developer to release a custom kernel built on that source.
Click to expand...
Click to collapse
Ya, this seems like a good option. BTW, unchecking the dm-verity in magisk won't do anything, after reboot it checks again. Thanks for the help.
Driver Installation
Does anyone know how to update the drivers to reflect that the device is a Moto phone? I bricked my device (exactly as described here; downgraded then OTA bricked). When I plug in to my computer it recognizes it as a USB driver Qualcomm HS-USB QDLoader 9008. Would it help any to download a driver to have it identify as a phone?
Tweedledope said:
Does anyone know how to update the drivers to reflect that the device is a Moto phone? I bricked my device (exactly as described here; downgraded then OTA bricked). When I plug in to my computer it recognizes it as a USB driver Qualcomm HS-USB QDLoader 9008. Would it help any to download a driver to have it identify as a phone?
Click to expand...
Click to collapse
Unfortunately, the only way is to somehow repair your bootloader as the bootloader is (part of ) what identifies your device to your computer as a phone. That Qualcomm HS-USB 9008 is your device in emergency mode - usually when your bootloader is corrupted (by a bad OTA update) or non-existent and now it's in a fail-safe boot state.
The only ways to get your device recognised again are to find a working blankflash to repair your device bootloader, try to boot from a cloned image of a working device (and then perform a firmware flash to repair the damage) or pay for a motherboard replacement.
First of all this phone belongs to my dad. This means I haven't used it and I'm not familiar with many things about it.
The phone is running a stock ROM. It is not rooted, but it does have TWRP.
A software update prompt popped up trying to install "v20p-apr-03-2018" (why is an update for the G4 called v20 lol).
Telling it NOT to download it and NOT check for updates ever doesn't work. The update prompt comes back in 2 days tops. So **** you LG.
Since it's not rooted the easiest option seems to be to flash the update, however it just launches TWRP and does nothing. I found no way to actually download the update and keep it on the device so that I can manually tell TWRP to flash it.
So: Is there a way to download said update and flash it through TWRP? Or should I root it and delete the stupid update tool? I really don't want to flash a stock recovery.
ast00 said:
First of all this phone belongs to my dad. This means I haven't used it and I'm not familiar with many things about it.
The phone is running a stock ROM. It is not rooted, but it does have TWRP.
A software update prompt popped up trying to install "v20p-apr-03-2018" (why is an update for the G4 called v20 lol).
Telling it NOT to download it and NOT check for updates ever doesn't work. The update prompt comes back in 2 days tops. So **** you LG.
Since it's not rooted the easiest option seems to be to flash the update, however it just launches TWRP and does nothing. I found no way to actually download the update and keep it on the device so that I can manually tell TWRP to flash it.
So: Is there a way to download said update and flash it through TWRP? Or should I root it and delete the stupid update tool? I really don't want to flash a stock recovery.
Click to expand...
Click to collapse
Freeze or uninstall Software Update (LG proprietary, i.e., closed source, app) - may require root. That should stop the annoying requests. If you are able to upgrade you will lose TWRP and will have to re-flash TWRP again. You may want to consider that you do not have the latest Google security patches by not doing the update, putting your Dad's phone more at risk.
sdembiske said:
Freeze or uninstall Software Update (LG proprietary, i.e., closed source, app) - may require root. That should stop the annoying requests. If you are able to upgrade you will lose TWRP and will have to re-flash TWRP again. You may want to consider that you do not have the latest Google security patches by not doing the update, putting your Dad's phone more at risk.
Click to expand...
Click to collapse
It's not like LG updates security patches that often so it's not that big of a deal if I can't update it.
It's also fine if I lose TWRP during the process, I just want to avoid flashing stock recovery just for the sake of updating it.
And I still can't download the update and keep it. I don't know where it puts the update after downloading it. I couldn't find it in TWRP.
ast00 said:
It's not like LG updates security patches that often so it's not that big of a deal if I can't update it.
It's also fine if I lose TWRP during the process, I just want to avoid flashing stock recovery just for the sake of updating it.
And I still can't download the update and keep it. I don't know where it puts the update after downloading it. I couldn't find it in TWRP.
Click to expand...
Click to collapse
It helps if you include your phone model when looking for specific firmware updates.
If you're Dad's phone is an H815, there are some v20p downloads available here: https://lg-firmwares.com/lg-h815-firmwares/firmwares/
In order to flash in TWRP without losing TWRP, you would have to remove the stock recovery and create a flashable zip ...
Easiest is to simply freeze or remove the lg Software Update app as I indicated - the annoying update notification should then disappear ...
Note: XDA courtesy is to hit the Thanks button (bottom right of post), when members are trying to help and solve your issues. As a Senior Member you know this.
This update does not contain any security fixes it's just for the new European data protection law..
First thing you should try is:
Upgrade TWRP.
Do a full TWRP backup!
Test android update again.
Second thing:
Have you tried the LG bridge windows software to update?
If so and it fails there too you can find the update when you try to Flash it within the LG folder of your Windows PC afterwards use this KDZ file and lgup to flash it.
There is a chance that when using the internal updater that you can find the update file when in TWRP in /cache in a folder fota but it will likely be in a LG specific format so may don't help you much.
Third thing :
Disable the LG updater within TWRP (search for a howto)
Sent from my LG-H815 using XDA Labs
in brief
I have unlocked the botloder with commands in cmd, I have uploaded magisk, I expanded internal memory by sd card (my error). Unfortunately, after the upgrade to Android 9, the phone fail at receive any new updates (installation error of 30%). Subsequently, dumped magisk, did not help, , I uninstall sd card, now I did restore the factory data and the updates still do not work. November version of Andorida is badly bugged and there are problems even with the camera. So it looks like I'll have to send a phone for guarantees, a question now how to block a botloader or you have an idea how to fix ota update.
same here, but now you can download the full 10.0.3.0 rom to install with miflash. https://en.miui.com/download-354.html
fine but how to reblock a botloader ?
karenz88 said:
fine but how to reblock a botloader ?
Click to expand...
Click to collapse
use this on fastboot:
Code:
fastboot oem lock
Warning: this will wipe your data and if you have tampered with phone's partitions phone will hard brick. Make sure to have a backup. Other people have also experienced issues with January update. Locking the bootloader and booting the phone successfully doesn't mean that you will have January update for sure.
There's no point in locking the bootloader or returning the phone just because you failed to apply OTA update. Your phone is perfectly fine. Most of us had problems and bootloop while trying to apply Magisk OTA. This has been a frequent issue since the initial Pie update and the phone has nothing to do with it. It's either Google implemented stricter security policies or current version of Magisk are having Pie compatibility issues. If OTA is to important to you, just flash an official fastboot image and don't root your phone.
Ota does not have much meaning for me, but I have a problem with the camera and it annoys me already. I reblock a botloader and still cant update phone...
karenz88 said:
Ota does not have much meaning for me, but I have a problem with the camera and it annoys me already. I reblock a botloader and still cant update phone...
Click to expand...
Click to collapse
Fastboot image of 10.0.3 is already out. You could consider flashing your phone with "flash all" option to fix the errors. And i would recommend keeping the bootloader unlocked because many mi a2 owners got their phone bricked as a result of ota update with a locked bootloader in which case the only workaround is to disassemble the phone.
Greetings.
Let's say I accidentally DL'd the OTA from the OEM update screen. Where in my file system might I find the file? I read that it may expire and vanish. It's that true? Kind of afraid to reboot right now. Thanks in advance.
Pixel 2xl, rooted, Magisk, OEM 10, Aug. rev.
Even if the OTA did expire and vanish, and I have never heard that happening, Google makes full OTA images available at https://developers.google.com/android/ota in the Taimen section. As to where they are located, likely in the /data partition, but I have absolutely no clue where exactly they are.
I would simply reboot, as the system has most likely already applied the OTA and simply needs to finish completing the update.
So I had to reboot, now I lost root. Is there an easy way to get it back or do I have to wipe?? Thanks.
Boot - NOT install - TWRP using fastboot on the bootloader screen and flash a copy of Magisk you should have stored on your unit.
If you need detailed instructions we have a rooting guide on the forum that should help. Just make sure not to install TWRP or the unit will end up bootlooping, requiring you to flash the full firmware to fix it.