Contact the device maintainer on Matrix
this post was submitted on 17 Dec 2024
14 points (100.0% liked)
Lineage OS
1053 readers
22 users here now
Lineage OS
lineageos.org | Wiki
IRC | Unofficial Matrix room | Discord
Other LineageOS communities on Lemmy
founded 4 years ago
MODERATORS
If you boot into bootloader mode with the hardware buttons like volume up and power or whatever, you might be able to dirty flash the phone again and get it to boot. But that would probably at least if nothing else wipe out Google Play Services unless you tried all the flashing instructions again. I want to say you might be able to put in the pin somewhere and possibly even access the data from the hard drive, but I won't swear to that.
I attempted already installing by hand, meaning doing an adb sideload. That's what I meant when I said I attempted to downgrade, of course I also tried sideloading the same version that lead to the boot loop just in case. I haven't tried doing a factory reset, but I really would like to avoid it.
I don't use google play, I use lineageos for microg, and even so, I avoid google services, since most my apps come from f-droid. Regardless, losing the data is really a bad thing, and all apps configurations and such.
In the future it may be worth taking a backup
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.
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.
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?
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
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.
% adb logcat |& tee logcat.txt
- waiting for device -
And now the boot hangs forever it seems...
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.
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.
% 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...
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.
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, :(
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.
Ohh, well, I followed your instructions...
So what part doesn't work now? Is ADB running at boot or not? If it is running, are you authorised or not?
ADB running at boot never worked, though running whether on normal operation or on recovery works flawlessly.
As the phones were needed, I had to do factory reset them, which worked out. But, that doesn't prevent me to keep trying to get ADB working at boot, which to be honest I never tried before. It seems important to get it work, so I can get and share the logs that matter. As you mentioned, linux info and logs from recovery are useless, :( But now there's no rush, since I unfortunately did a factory reset.
I think I got another moto same model, not in use, which has broken mobility data (it doesn't get internet while on mobile), and I think I can keep trying from it, but without upgrading with this dangerous version, since I want to detect with it if the coming upgrade is as dangerous (lesson learned for me is to try with that broken phone before attempting on the ones in use). This way I don't take the phones that are already in use. So again, I'll keep trying the , but now not that pressured.
It's weird to me that I could use ADB on recovery, with no issue, even to transfer files, which to me it means there were no authorization issues then, and it never worked on boot. As mentioned, I'll modify the pseudo-broken phone and keep trying the ADB on boot with it...
ADB running at boot never worked
Please ensure the props are set as I wrote them.
Also note that the props get reset on every system flash.
It’s weird to me that I could use ADB on recovery, with no issue, even to transfer files, which to me it means there were no authorization issues then, and it never worked on boot.
That's not weird at all; those are two entirely different operating modes. The recovery isn't even Android for the most part.
The recovery typically accepts any ADB connection while Android only accepts explicitly trusted ones. ADB also doesn't typically run by default in regular Android execution.
Most likely no way to not lose data. Unless you use some custom recovery and manage to use adb pull. That's why you usually do a backup before doing any OTA