Anyone with a moto one 5g ace (kiev) that performed OTA update recently and got a boot loop out of it?

I use lineageos for microG, which is based on lineageos, and Today got an OTA update which I can’t matches the same version as the one on lineage, but after attempting the reboot required by the update, the phone gets into a boot loop.

I haven’t found a way to get out of the loop without losing data. Downgrading doesn’t help, no matter if a major upgrade is attempted.

It looks to me this could be rather lineageos issue, since I got a past experience with a pixel 4a (5g), and at that time I lost all data attempting a factory reset that didn’t even help at all. Later there came an update from lineageos, which I manually installed, and got the phone back, though with all data lost. This time I’d like to avoid losing data.

Any help or hint is appreciated.

  • Atemu
    1·
    5 days ago

    You won’t get a log early in the boot process without a prop being set. Although, if your ADB key is already trusted, this might also be possible using the LOS recovery.

    Flash the previously working version, get adb shell access in the recovery and mount the system partition read-write somewhere.

    Then append this to /system/build.prop:

    persist.service.adb.enable=1
persist.service.debuggable=1
persist.sys.usb.config=mtp,adb

    If your key is trusted, you should now be able to access the device via ADB during boot and can do adb logcat before starting the device.

    If your key is not trusted, you’ll see the device as unauthorised and will have to get your public key (~/.android/adbkey.pub) into /data/misc/adb/adb_keys somehow. I’ve never been able to mount the userdata partition in LOS recovery do be able to do that though but I haven’t bothered to debug why that is. It might just work for your device though.

    I’d recommend you to redirect the log to a file and let it reach the boot loop point. When it reboots, terminate adb logcat (or perhaps it does that on its own).

    Now you’ll have to scour the log for the actual exception thrown. It will be quite a ways up in the log and IIRC you should see zygote freaking out around the point where the actually interesting error is.

    • kixikOP
      1·
      5 days ago
      % adb logcat |& tee logcat.txt
- waiting for device -

      And now the boot hangs forever it seems…

      • Atemu
        1·
        5 days ago

        That means you didn’t actually get an ADB connection yet. Either the install is fscked to the point where even ADB doesn’t work (I doubt that), ADB doesn’t actually run (did you follow the steps I provided?) or you’re not actually authenticated. Please confirm with adb devices and also check whether the USB device is even visible to your kernel via dmesg.

        • kixikOP
          1·
          5 days ago
          % adb devices
List of devices attached
ZY22FKS3NB      recovery

          When you say authenticated, do you mean authenticated with google specific keys? I think LOS and LOS4microG both have their own keys, so if in need of google keys I doubt LOS and LOS based ROMs can authenticate.

          This is the dmesg grabbed on 20241216 recovery, and this is a /proc/kmsg I attempted to grab…

          • Atemu
            1·
            5 days ago

            When you captured that, the device was in the recovery. That’s not particularly interesting; recovery works fine.

            We need adb access during boot. You need it to say “device” here while it’s attempting to boot.

            If no device shows up, you haven’t enabled the prop to enable ADB properly.

            • kixikOP
              1·
              5 days ago

              Yeap, I suspect as you mentioned, with LOS and LOS4uG there are no trusted keys. And you’re right, linux messages on recovery are really not interesting, :(

              • Atemu
                1·
                4 days ago

                This has nothing to do with the ROM. While you can embed trusted keys into a ROM which is useful for debugging, what I mean is the regular trusted ADB keys that get added when you allow ADB access from your computer via the pop-up.

                If you’ve allowed your PC ADB access recently (this expires after some time), your key should be trusted. If it isn’t, there is the method to make it trusted I described.

                You do need to modify the system partitioni to enable ADB at boot though. Just do what I described.

                • kixikOP
                  1·
                  2 days ago

                  Ohh, well, I followed your instructions…

      • kixikOP
        1·
        5 days ago

        got back to the same by sideloading latest, and then went back to previous working version. Previous working version, is boot looping faster though, and after a couple of trials it goes the recovery (this doesn’t happen on latest), this was like that before, so there’s a difference between latest and prior working version, on latest the loop never ends, and each iteration is somehow long compared to the prior working version.

        I’ll go get some rest.