Fedora freezes and then reboots when using ADB

Exactly. I will later try if the same happens on my laptop (also rocking Fedora) or if this is particular just for my computer.

The flippant answer is “well stop running adb server” but honestly, that’s somewhat bizarre.

I’d have thought that given the number of adb/android developers out there, if it was an issue with the adb server then there would be hell on about it. It MUST be this specific machine… right? :frowning:

Actually I can stop running it now, I’ve done what I needed. Although I was flashing new ROM and I was lucky it happened for the first time only shortly after that, so I didn’t brick my device. If I want to do that in the future, I will probably forget and might not be that lucky.

I found actually issue that resembled this one from 11 years ago, but back then it was something in kernel and downgrade helped. But 11 years ago…
We’ll see, maybe its something new and everyone will start getting this issue :grinning_face:

Please do report back if it is fine on your laptop, as I’m interested from a technical perspective. In the meantime I’ll start digging around into how one can debug semi-random resets without logs.

For sure, I will let you know :blush: Thanks!

Don’t forget to set that systemd flush value back to 5 minutes

oh, good you reminded me thanks! :grinning_face:

So I finally got to try it on the laptop and it is not freezing. I started the adb more than an hour ago and it is still running. That laptop was freshly installed about an year ago, while my computer has been installed several years ago. So maybe some “legacy” software that still lingers on my PC may be causing this? I see that on the laptop there is e.g. different terminal so I am pretty sure, there is more things like that… Kinda don’t want to reinstall the computer though :grinning_face:

Some time back gnome switched from using the older gnome terminal to using ptyxis for the standard terminal app. Many other software bits have modernized/migrated/altered as well so there may be many lingering configs in user space that could affect performance of different apps.

One way to find out if this issue is a user config would be to create a new user and test when logged in as that new user. If the new user does not experience the same issue then it would seem a user config and comparing the configs in user space (~/.config, ~/.local, and the other dot files under the home directory) between the new user and the original user may provide a clue.

That is a good idea, I will try later again.

How can lingering config affect this though? Does it mean that they are still used by the system even though they shouldn’t (if there are any)?
Thank you

When doing upgrades, any config in userland (the users home directory tree) does not get upgraded since that is not directly system related. Those config files are created by the app when it is used. Outdated configs there occasionally cause issues for some apps.

Aha, that is interesting. Would be nice to have some tools for migrating/upgrading these things.

Impossible to automate since there are thousands of users of each app, on thousands of different hardware types, and thousands of different software configs. Nothing that is system installed should ever modify files in a users home directory tree.

The only potential source of managing those updates would be for each individual app that places config files in $HOME to update them on a case by case basis. Theoretically if the app were to save version info in the users config files then the next time it was launched it may be able to check and possibly update the configs. Again, though, that would be on an app by app basis when used and not based on a system update.

Users must be aware when an app undergoes a major update and be prepared to adjust their individual configs accordingly.

In many cases the only way to know the changed config is the issue is to start a new user and open the same app to compare function. If the error/issue is resolved then the fix would be to wipe out the existing config in the original users $HOME and restart the app as if newly installed.

Hi!

Any update to this? I switched from Windows a few months ago, I use Nobara but I have the exact same issue on my desktop PC.

I would really like to know how to solve this issue without having to reinstall everything, please.

Thanks!

Did you try the troubleshooting steps indicated in my post just above?
This topic seems likely a configuration issue for the specific app related to lingering config files in the users home directory and has nothing to do with a reinstall.

Test by creating a new user then see if that new user has the same problem. If the new user can use the app properly then it would be a config issue for your old user. If the new user sees the same results then you need to dig deeper.

Also note that we do not support nobara here (we support fedora only) and you should take your issues up with their customer support at their web site.

Nothing new, I was looking into the configs, but that is way too over my head. So I probably won’t solve it for now and I will do clean re-install at some point.

My issue seems to be fixed after updating ADB. Perhaps you could try that.

That was the first thing I tried to check if I am up to date :grinning_face: I think its the configs in my case, I was reading about it a bit and I find a lots of new configs that “awaits” what I want to do (use, merge,..) but I don’t know enough to be able to decide, so I will leave it as is and maybe re-install my system soon, didn’t do that in more than 3 years or so…