Random reboots due to (probably) the new 7.8 update

Issues
, ,
1
  • Device: motog32 devon
  • iodéOS Version: 7.8
  • Affected App(s): whole device

Short Description:

My phone is randomly rebooting since yesterday only when I use it not when idling. I also factory reset my phone but its still happening. Maybe it’s the latest update iode 7.8 idk.

New Issue, Regression, or Feature Request?

New issue

Additional Information:

I have moto g32 devon 8bg ram. I have been daily driving iode os for a few months now. And it ran perfectly and none of this happened. But now its rebooing randomly

webp

1 Like
Issues with release 7.8 August 31
2

Happening on my motog32 also, so no isolated issue

3

I’m facing the same issue with my Pixel 5

4

I have downgraded to 7.7 and none of this reboot is happening. so its definitely the new update 7.8

2 Likes
5

Is there an easy way to downgrade (without data cleaning) ?

6

sry idk on that. probably not, but again idk

1 Like
7

Same problem here with my G32 Devon. It’s randomly rebooted 4 times today since updating to 7.8 yesterday.

8

Same issue on Pixel 5 since upgrading to 7.8 version.

Seems related to [IodéOS Beta 7.8] - Redémarrage aléatoire

9

Pixel 5 - same issue - random reboots

10

Same here, (pixel 5).
Yesterday it rebooted a few times, this was pretty random.

Today it reliably reboots after I log in. No problem after entering sim pin, then about 15 seconds after entering device pin – phone is still unresponsive - it reboots.

Good to know I’m not alone.
I’m effectively locked out now, any suggestions would be welcome.

11

Same here with Pixel 5. I have no issues on my Pixel 4.

12

I’m not a developer myself, and I don’t understand most of the following informations. I used an AI assistant (Claude) to help pull apart the bugreports/logs from my device and characterize this crash. Sharing the raw findings here in case they’re useful; happy to share the full bugreports/dropbox dumps if needed, and please double-check anything below rather than take it at face value.

Device: Google Pixel 5 (redfin), iodéOS 7.8 stable
Kernel panics starting from the very first reboot after the OTA install (2026-09-03 00:30), fully reproducible, 13 identical occurrences captured so far via dumpsys dropbox --print (SYSTEM_LAST_KMSG entries).

Faulting process (100% of occurrences):

  • Comm: iode-snort, native daemon, PPID 1 (started by init), SELinux domain u:r:iodesnort:s0
  • Crashing function: nf_queue_entry_get_refs+0xb0/0x224
  • Call path: nfqnl_recv_verdict → nf_reinject → full TCP receive path → tcp_ack → tcp_xmit_retransmit_queue → __tcp_retransmit_skb → __tcp_transmit_skb → (inet_csk_xmit/inet6_csk_xmit) → (ip_xmit/ip6_xmit) → nf_hook_slow → nf_queue → crash

Trigger condition (consistent across all 13 occurrences): iode-snort delivers an NFQUEUE verdict for a packet, the reinject causes a TCP RETRANSMISSION (__tcp_retransmit_skb), and that retransmitted packet gets re-queued through the same NFQUEUE hook — crash happens at that point, looks like a refcount/use-after-free issue on the queue entry.
Confirmed on both IPv4 and IPv6 (roughly even split across the 13 traces), so not protocol-specific. This looks like it could be in the same general area as the upstream kernel fix “netfilter: nf_queue: fix socket refcount bugs” (socket refcounting during nf_queue reinject), though I can’t confirm it’s the exact same bug.

NFQUEUE rules involved (from iptables/ip6tables dump):

  • iode-snort_INPUT / iode-snort_OUTPUT chains
  • NFQUEUE balance 0:3 / 4:7 (IPv4), 8:11 / 12:15 (IPv6), flag “bypass”

Aggravating factor observed: 2 of 3 crashes captured live were mid SeedVault backup (via Nextcloud as SAF backend) — sustained TCP traffic seems to increase the odds of hitting the race, but a plain retransmission seems to be the only real requirement.

Tested: disabling / force-stopping the com.iode.app package from Android Settings — no effect on the crashes.

Kernel: 4.19.325-cip135-st19-gf7b06dbf9ff3, build google/redfin/redfin:14/UP1A.231105.001.B2/11260668:user/release-keys

I can share the full bugreports, dropbox dumps and logcat captures if that helps track it down further.

1 Like
13

I also experienced reboots with 7.8 on FP5. Interestingly it only started a couple if hours after the update and not immediately. I removed and reinserted Sim, SD card and battery and luckily the reboots are gone since then. Maybe just a big coincidence, but I wanted to share that.

14

Here the same. Also Pixel 5. Looks that it mainly reboots, after connecting with wifi. Offline I have not observed a crash so far.

15

Exactly the same issues for me with Motorola G42. Since the update to iodé 7.8 two days ago, randomly while using, the device freezes and reboots. Effect started about 1 day after the update, not immediately. Also interesting: These reboots do not request the SIM pin, which is the expected behavior and that’s what happens when I manually reboot.

16

Hello,

I also experienced tge random reboot on my moto g32 devon.

When the phone restart, or when I switch it off and then switch it on, it doesn’t require any Pin code…

Same behaviour as explained by @aroshi

Thanks for your help !

17

If this helps:

I suspect the reboot is caused by excessive RAM/memory usage.

I’ve managed to prevent the reboot by conserving memory: I disabled resource-intensive apps.

In my case: when I allow Syncthing-Fork to sync >> reboot after a few seconds. When I stop Syncthing-Fork from syncing: no reboot.

If you’ve noticed a reboot after turning on Wi-Fi or plugging in to charge, it’s probably because certain apps are launching (in the background). So just find the app > disable background execution, and everything should be back to - almost - normal.

Edit : stop all consuming processes (ex: Switch off 90Hz display)

18

Same issue Motorola G32. Started right after update. Memory related freeze/reboot happens to me as well - even some heavy site in Chrome/Brave can trigger it.

Plus no media sound - none, even alerts after update. After reboot (after update reboot) sound fixed, at least for now.

19

Same here with Moto G42

20

Although I could not reproduce yet, I have an idea of the origin of the issue : a recent kernel upgrade made in lineage. New builds will be uploaded today in a couple of hours, attempting to fix that issue. Sorry for the inconvenience !

5 Likes