Lemdro.id

1 point

11 days ago

Downgrading doesn’t help, no matter if a major upgrade is attempted.

What do you mean by this?

A downgrade to the previous version should by all means fix this.

report

[ - ]

1 point

11 days ago

well, I tried installing through adb both recovery and lineageos image version 21.0-20241115, and also version 20.0-20240719, and I got the same boot loop after each install. I suspect the 21.0-20241216 installed something new which doesn’t get replaced or removed when downgrading. I guess a major downgrade (notice I went back to 20) doesn’t help a bit, so I guess downgrading any further wouldn’t help.

report

[ - ]

1 point

11 days ago

You cannot downgrade to 20. Doing so might actually have broken something but that’s not given.

Downgrading to the previous nightly should have worked though. In which order did you try this?

To get to the bottom of this, you need to read out the ADB logcat. Do you have TWRP?

report

[ - ]

1 point

11 days ago

I tried first same version, then prior version, then the one before which on lineage for microg is the latest 20. So it didn’t work for immediate prior version.

I use the lineage recovery image that comes bundled with lineageos. I looked to see if twrp has support for this phone, and it doesn’t, not officially at least.

I wasn’t aware of adb logcat, but:

% adb logcat
/system/bin/sh: logcat: inaccessible or not found

report

[ - ]

1 point

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

report

[ - ]

1 point

11 days ago

% adb logcat |& tee logcat.txt
- waiting for device -

And now the boot hangs forever it seems…

report

[ - ]

1 point

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

report

[ - ]

1 point

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

report