[10.0][OFFICIAL][EOL] LineageOS 17.1 for Oneplus 5 & 5T

[debby_]

Hello,

I did the OTA update for lineage-17.1-20210202 and my phone would not boot up after doing so. I ended up having to wipe the cache and transfer lineage-17.1-20210126 to my phone via USB in order to get it to boot. Thank god I didn't lose my photos, but I am going to have to redo all my apps and customizations. Has anyone else had this issue with the latest update?

Reflash gapps?

 

[Marsbar]

Changing "Vibration and haptic strength" setting between "Low", "Medium" and "High" appears to make no difference on my OP5.

Is there a setting I'm missing? Does it work for everyone else?

 

[DaniRainbow]

Reflash gapps?

I did reflash Gapps when I was able to boot successfully, but did not flash Gapps as part of the OTA update. Is that something that needs to be done each time? I lost all apps, not just Google apps.

 

[Thimoteo]

Hi,

After such crash, there should be log files in /sys/fs/pstore/. Please send contents of this directory once it occurs along with small details on what you were doing at the time.
The logs exist there only right after a reboot (either in twrp or Android), and you need root access to get them.

How to:
Enable adb root in developer options.
Open shell, "adb root", "adb pull /sys/fs/pstore".
You can PM me the files.

Thanks for the reply, T1mb3. I'll send the files after the next crash.

 

[js-xda]

I did reflash Gapps when I was able to boot successfully, but did not flash Gapps as part of the OTA update. Is that something that needs to be done each time? I lost all apps, not just Google apps.

No, not needed for OTA updates. But there have been lately several cases where reflashing GAPPS resolved being stuck during the boot process. If you boot to recovery and flash both the ROM update and a matching recent GAPPS package without booting to system, you shouldn't have issues with the app lose (doing so on monthly basis on a Necus 7). Deviating from this is nevertheless never a good idea. Also flashing GAPPS on a system having run without them before is not a good idea.

 

[DaniRainbow]

No, not needed for OTA updates. But there have been lately several cases where reflashing GAPPS resolved being stuck during the boot process. If you boot to recovery and flash both the ROM update and a matching recent GAPPS package without booting to system, you shouldn't have issues with the app lose (doing so on monthly basis on a Necus 7). Deviating from this is nevertheless never a good idea. Also flashing GAPPS on a system having run without them before is not a good idea.

Thanks! I'll be sure to do this from now on.

 

[zumi001]

Hi,

After such crash, there should be log files in /sys/fs/pstore/. Please send contents of this directory once it occurs along with small details on what you were doing at the time.
The logs exist there only right after a reboot (either in twrp or Android), and you need root access to get them.

How to:
Enable adb root in developer options.
Open shell, "adb root", "adb pull /sys/fs/pstore".
You can PM me the files.

I experienced the same issue today on the lineage-17.1-20210201-nightly-cheeseburger version, locked up phone with the notification led being cyan, and the phone not waking up with the power button. the /sys/fs/pstore was empty a few hours after the incident (but without rebooting). I had to power cycle it with the power button. Is it cleaned on a timer or what do you mean by "right after a reboot"?

I did nothing specific before the lockup, the phone was just idle for ~1h, during which I went away from my home wifi network and probably switched to 4G, and it didn't wake up when I tried to use it.

 

[denisovich]

I've managed somehow to use dumpling lineageOS 17.1 for a while now, without any bootloops or any other issues for some time now, including OTA updates. This ROM is very nice, and very stable.

Am I doing something wrong?

Because I feel a bit left out judging by some of the posts here.

 

[Scream275]

@denisovich I'm on this ROM for the last three builds and it's working great so far. I'm having gapps, magisk, dotfix for the camera & gcam installed. No OTA-update problems so far (only flashing the ROM, nothing else).

There are only three issues I found, detailed here:

OnePlus 5T HD-Audio switch not availabe for HD-Audio headphones (aptx) (#3036) · Issues · LineageOS / issues / android · GitLab

I got Teufel Airy (2015) headphones which support the aptx codec. On OxygenOS 10.0.1 my 5T used the aptx codec (a aptx toast appeared), but on the latest...

gitlab.com

e-mail spinning infinitely on refresh of combined account view (#3040) · Issues · LineageOS / issues / android · GitLab

I'm having two e-mail accounts set up (both IMAP, both correctly configured). On each account separately the e-mail app works fine. The issue is only available for the...

gitlab.com

The third one was a frozen system where I had to force power off the device, but that did happen only once. So I haven't reported it. EDIT: happened now three times in about 1 month

I had one more issue with the last build, detailed here:

OnePlus 5T VoWifi stopped working with build from 20210202 (#3035) · Issues · LineageOS / issues / android · GitLab

Expected Behavior VoWifi is working like in build lineage-17.1-20210126-nightly-dumpling-signed.zip. If being in airplane mode & activating wifi, the mentioned build showed...

gitlab.com

I guess that was related to the sim-card stuff, other people wrote about. VoWifi is working again since the latest build.

 

[rphair]

Device MAC = random 1 of 2 choices every phone boot (?!)

My phone has two different possible MAC addresses that it can start with: sometimes one, sometimes the other (not hardware related because I never had this issue on LineageOS 16.0).

The device always connects to a WiFi network which I control, with WiFi settings always set to use "Device MAC" rather than a randomly generated MAC (default). WiFi connections always show the same MAC as in About Phone > WiFi MAC address... i.e., the same random one of the two addresses. Therefore I assume it's the device "WiFi MAC Address" itself that is inconsistent.

I've also looked in the developer settings and can't see what would cause this. We need a consistent IP address on this device but can't work around the problem on our OpenWRT router because reserving a single address for more than one MAC address hangs DHCP on the router.

If there is a bug report for this, or if I should file one, please let me know where or how. If there's no fix I'd be happy with a workaround for now.

Nightly LOS 17.1 dated 8 February 2021 + Magisk 21.4
Reimaged recently from a full wipe with no substantial settings changes from the default.

 

[zumi001]

Device MAC = random 1 of 2 choices every phone boot (?!)

My phone has two different possible MAC addresses that it can start with: sometimes one, sometimes the other (not hardware related because I never had this issue on LineageOS 16.0).

The device always connects to a WiFi network which I control, with WiFi settings always set to use "Device MAC" rather than a randomly generated MAC (default). WiFi connections always show the same MAC as in About Phone > WiFi MAC address... i.e., the same random one of the two addresses. Therefore I assume it's the device "WiFi MAC Address" itself that is inconsistent.

I've also looked in the developer settings and can't see what would cause this. We need a consistent IP address on this device but can't work around the problem on our OpenWRT router because reserving a single address for more than one MAC address hangs DHCP on the router.

If there is a bug report for this, or if I should file one, please let me know where or how. If there's no fix I'd be happy with a workaround for now.

Nightly LOS 17.1 dated 8 February 2021 + Magisk 21.4
Reimaged recently from a full wipe with no substantial settings changes from the default.

Try going into the settings of your specific wifi network (not the generic wifi settings). There's a new (compared to LOS16) "Privacy" option there where you have to select "Use device MAC" instead of the default that randomizes your MAC address.

 

[rphair]

Try going into the settings of your specific wifi network (not the generic wifi settings). There's a new (compared to LOS16) "Privacy" option there where you have to select "Use device MAC" instead of the default that randomizes your MAC address.

Correct. When my particular WiFi setting is set to "Use device MAC" that's what it always uses. However, as I said above, the Device MAC itself is potentially different with each Android reboot (being one of two possible values).

 

[zumi001]

Correct. When my particular WiFi setting is set to "Use device MAC" that's what it always uses. However, as I said above, the Device MAC itself is potentially different with each Android reboot (being one of two possible values).

Sorry, I missed the part that your actual device address is changing. This has not happened to me yet. As a workaround you can set a static ip for that specific network. Maybe check the dmesg for the kernel and look for the different MACs and see what's the difference in those lines when the kernel discovers the device. Is it done by the same driver in both cases? Might be some race condition.

 

[rphair]

As a workaround you can set a static ip for that specific network.

You missed that part too ... I already tried that: as it says above OpenWRT doesn't accept duplicate MAC reservations of the same IP address (or maybe the same hostname; can't tell). Hangs the DHCP server & haven't been able to figure out why or how to avoid that (tips would be welcome).

Maybe check the dmesg for the kernel and look for the different MACs and see what's the difference in those lines when the kernel discovers the device. Is it done by the same driver in both cases? Might be some race condition.

Good idea & will try that next time I see the address flipping. If anything useful can be learned I'll post it here.

 

[zumi001]

You missed that part too ... I already tried that: as it says above OpenWRT doesn't accept duplicate MAC reservations of the same IP address (or maybe the same hostname; can't tell). Hangs the DHCP server & haven't been able to figure out why or how to avoid that (tips would be welcome).

Nah-ah, I did not miss it, not this time at least! I don't mean to set a static DHCP lease in your router, but to add the Wifi network on your phone with a static IP, instead of DHCP. When you try to add the network, click "Advanced options" and then change "IP settings" to "static". You have to forget your network and add it again, this doesn't show up when you edit an already added wifi network.

Then judging from you using OpenWRT I think you will be able to set the address/gateway/etc. according to your network. This way your router is not responsible to assign you an address, your phone does. Not ideal but should help you until you figure out the MAC address weirdness.

Good luck with the debugging.

 

[rphair]

Nah-ah, I did not miss it, not this time at least! I don't mean to set a static DHCP lease in your router

OOPS that's my mistake, you used the words "static IP" unambiguously for sure... I was just hoping to keep to our small office standard of one-IP-per-MAC kept in the router all in one place & backed up. Yes thanks you're right it would save some headache until that can be restored ... I just ruled it out earlier since it masks the problem completely so we don't know if it's fixed in a future release.

If anyone knows what to look for in the logs please post an idea. The first time the Device MAC address itself appears in `dmesg` is when it's used as a MAC address to connect to a WiFi network. If assigned earlier than that in the boot process, it doesn't appear in `dmesg`.

From this initial log message of the wireless binding, I'm guessing `vdev-0` is the driver for this particular boot-up? (It doesn't show the android device MAC until a few lines later.)

[ 43.502209] [20210220_15:21:32.966692]@3 [wpa_su][1101258803][15:21:32.966687] wlan: [2767:I:SME] vdev-0: Connecting to MS5.0GHz d8:07:**:**:**:** rssi: -33 channel: 116 akm 9 cipher: uc 6 mc 6, CC: IN

Anyway I'll save our `dmesg` output & see if it looks any different when it's using the other MAC address. If we find evidence of a bug from all this, please let me know if/how I should report it (I haven't done that before).

 

[rphair]

... can't work around the problem on our OpenWRT router because reserving a single address for more than one MAC address hangs DHCP on the router. ...

p.s. I've found out that, while this is true if setting a duplicate MAC-to-IP assignment in the UI (which writes /etc/config/dhcp), you can instead put the phone hostname & IP address in /etc/hosts and then that hostname with as many MAC addresses as you want in /etc/ethers, which works & doesn't hang DNS & DHCP servers.

End of that off-topic workaround & I'll post anything here that sheds some light on the original issue (the inconsistent Device MAC).

 

[zumi001]

Anyway I'll save our `dmesg` output & see if it looks any different when it's using the other MAC address. If we find evidence of a bug from all this, please let me know if/how I should report it (I haven't done that before).

I'm out of my depth here, I know Linux but not Android too well. On a normal Linux system the network card would appear in the dmesg, but I can't find it in my own dmesg output either on my OP5. However I also don't have this issue, and I see "wlan0" with the proper MAC in the output of ip link command. My other (probably not useful) suggestion is to make sure there's no root app or any VPN apps that could screw with your MAC address.

Also if you can reproduce the problem you can check the "ip link" output and look around in that. There's also theoretically a way to change the address of your interface with ip link set dev wlan0 address XX:XX:XX:XX:XX:XX but I'm also not sure if this works under Android. If it does, you can correct it when you see that it's incorrect.

As for reporting the issue: https://wiki.lineageos.org/how-to/bugreport -- but I see T1mb3, the (awesome) maintainer for this version of LOS is here in, so if you find anything definitive he might be able to see and fix it.

 

[js-xda]

I am reporting two, appearing initially probably independent bugs where I suspect suspected initially a connection nevertheless. As I am running German GUI, translation of some menu entries or such might be not exact.

Running LOS 17.1 210208 (and later upgrade to 210222) on OnePlus 5 with TWRP 3.4.0, firmware 10.0.1 (01.09.2020), no Magisk, no microG but OpenGAPPS Pico.

---

1. Locking display directly vs. setting stating 5 second delay
I noticed since migrating from LOS 16.0 that the device locks right away upon screen off and not with the indicated delay of 5 seconds. I hadn't looked into it further until 1-2 weeks ago. Then I realized it is possible to regain the delay behavior when deactivating the function that power button locks straight away (default setting as far as I know). I decided to give it a try - noticing already the risk that I might re-activate the phone e. g. in my pockets within the 5 seconds period.

---

2. Phone rebooting (somewhat) at random pattern
Somewhat later, I noticed that the phone started rebooting at random pattern a few times per day. I noticed as the screen was empty at first upon entering the unlock PIN like after a full reboot when the device is decrypted. Odd thing was that (other for a normal reboot) the SIM PIN wasn't required! So, it wasn't about a power loss or something like that. I suspected/tried:

• Flashing newer build 210222 - no change
• Wiping Dalvik/ART cache - at first it appeared less but then returned to the usual frequency of two to three times per day
• One more thing that I can't recall right now ... will add later if recalling ...

At some moment, I realized that the initial occurrence might coincide with the change done as described in the first part (deactivating power button locking straight away). So, I suspected at first that it was about me doing something by accident (e. g. in the pocket) but I could recall also definitely an occurrence where the phone had been laying on my desk and no touch for sure. I gave it a try and reactivated the power button locking straight away ... and the issue appears to be gone (more than 24 h without a single occurrence). Update 2.3.: Never mind - multiple reboots this morning not stopping until forced shutdown.

---

Has anyone observed same or similar behavior? I checked on this thread but couldn't find any matching reports.

 

[js-xda]

2. Phone rebooting (somewhat) at random pattern
Somewhat later, I noticed that the phone started rebooting at random pattern a few times per day. I noticed as the screen was empty at first upon entering the unlock PIN like after a full reboot when the device is decrypted. Odd thing was that (other for a normal reboot) the SIM PIN wasn't required! So, it wasn't about a power loss or something like that. I suspected/tried:

• Flashing newer build 210222 - no change
• Wiping Dalvik/ART cache - at first it appeared less but then returned to the usual frequency of two to three times per day
• One more thing that I can't recall right now ... will add later if recalling ...

At some moment, I realized that the initial occurrence might coincide with the change done as described in the first part (deactivating power button locking straight away). So, I suspected at first that it was about me doing something by accident (e. g. in the pocket) but I could recall also definitely an occurrence where the phone had been laying on my desk and no touch for sure. I gave it a try and reactivated the power button locking straight away ... and the issue appears to be gone (more than 24 h without a single occurrence). Update 2.3.: Never mind - multiple reboots this morning not stopping until forced shutdown.

Last night, I flashed manually the latest LOS 17.1 build 210301 together with OpenGAPPS ARM64 Pico for Android 10 210303 - reboots occuring still. Updated also to TWRP 3.5.0.

Anyone an idea besides wiping everything and starting with a clean system to verify that it is (not) about the system or the hardware? Problem is that I have no guarenteed way how to reproduce.