Indeed, this seems to be what's going on based on OP's description.

Electrum does not use the operating system's CA store anymore. The python certifi package is used, which bundles Mozilla's CA root store. certifi is a required dependency, and Electrum uses it as the CA store everywhere internally.

This has been the case since around version 3.3. Before that, for some network requests the certifi (/requests) store was used, for other Electrum implicitly used the OS store. Using the OS store used to cause weird issues on some systems.

https://github.com/spesmilo/electrum/blob/8eb3c43603ed1915fa3e0b8d17c9dbeb183270c5/electrum/util.py#L88
https://github.com/spesmilo/electrum/blob/8eb3c43603ed1915fa3e0b8d17c9dbeb183270c5/contrib/deterministic-build/requirements.txt#L15-L16

Every version of Electrum ships with some specific version of certifi, so over time that CA store might get out of date, for an older release.
(At least when running the binaries. However if you e.g. install from a Linux distro, they might update the version of python3-certifi that they package independently of Electrum.)

Note that the checksum in BIP39 seeds is weak. A 12 word BIP39 seed only has a 4 bit checksum. There is a 1/16 chance that a random selection of 12 words from the wordlist is a valid seed.

What error do you get? Check the debug log of the client.

Yes, coin selection is supported.
In the desktop Qt GUI, go to menubar>View>Addresses, and also menubar>View>Coins.
The Coins tab is better suited for this, where you can right-click an individual coin (utxo) and select "Add to coin control" (or "Remove from coin control").
There is similar functionality in the Addresses tab too.

Also, from the same right-click context menus, you can "Freeze"/"Unfreeze" addresses/coins, which is sort of the inverse operation (except freezing is persisted in the wallet file, so it will be remembered even if you close the application and reopen it later).

You don't need to close your channels when you update, especially in minor patch releases.
Even in major releases that was never the case. Well okay, IIRC 4.3 dropped support for old pre-static_remotekey channels, but that type was never in a released version (only on git master).

You can be sure that if you had to close channels as part of an upgrade, that would be in the release notes.

Maybe related:

https://github.com/spesmilo/electrum/issues/9218
>  Android app currently not available in Google Play in UK

Yes, indeed fuse2 is needed atm.
What do you mean by electron-sandboxing (4)? Electrum does not use electron. Do we really need that sysctl? I have never seen a problem with that before.

In theory yes, but in practice there are some assumptions for what the host OS has and libc is one of those.
In general with AppImages, the idea is that the developer is supposed to build them on a very old Linux distribution, and users are then able to run them on newer (but not older) distros.

The AppImages for 4.3.2-4.5.2 are built using debian 10, which ships glibc 2.28.
Debian 10 is already "oldoldstable" at this point, so OP should really upgrade their system.

zbar is used for webcams to scan a QR code and to decode it.
E.g. you have an invoice with a QR code shown on your phone screen and you hold it up to your laptop camera. The laptop would then need to have the zbar library.
If you don't need this feature, it is safe to ignore.

You can see in the network overview that the client managed to connect to 9 servers ("connected nodes"). The red orb means that it could not connect to the main server selected.
I can also see that "select server automatically" is unchecked, meaning the client won't try any other server as main server. I guess that server is offline though.
So you should either enable automatic selection, or manually select another server.

What is your use case for trying to RBF txs that do not signal RBF?

~All txs created by Electrum signal RBF. Is it to bump the fee of txs created by other wallets?

It's a plugin to run your own swap server, it is an alternative implementation to Boltz.

- You can point the client to any remote swap server by setting the "swapserver_url" config key (unrelated to plugin),
- and it is possible to run a swap server yourself locally using this new plugin (which itself is a server implementation in python).

We wrote the plugin for our own use, to replace Boltz, as they changed their license from AGPL to a non-free license around 2023-04.
Since around 2023-08 we are no longer using Boltz. That is, the official swap server is now an electrum daemon with this plugin enabled.

That sounds like base64 encoding, which suggests the seed is encrypted. Are you by any chance comparing a wallet file that has a password set with one that does not?

Do you mean in the Android app? TBH that functionality in kivy might have been accidental... What exactly is your use case?

note: OP also opened an https://github.com/spesmilo/electrum/issues/8419, where I replied in detail.
In short,
- when you open a channel, you cannot receive before sending some first
- and it is the channel-opener who pays for the on-chain fees of having the channel closed in the future, for which part of the opener's balance is set aside. When the on-chain fees are as high as recently (~500 sat/vb), the fee set aside can easily be approx 2 mBTC.
As OP opened a channel with a capacity of 2 mBTC (the minimum hardcoded value allowed by Electrum), he basically had no usable balance left.

Can't you just use the -P flag? That's how the portable windows exe works internally.

I was able to reproduce thanks to the details given in OP. Indeed it is the same as above linked issue (which I could not reproduce before).
This is a regression introduced in 4.4.0. The fix will be released in 4.4.3 (perhaps later this week but no guarantees).
In the meantime, you can go back to Electrum 4.3.4, which not have this issue.

Hi! That sounds similar to https://github.com/spesmilo/electrum/issues/8365

Which version of Electrum are you using? Please make sure you are using the latest.

If so, could you please provide debug logs for when the error occurs. In particular I would like the exception "traceback". That would probably greatly help in reproducing and fixing.

(Feel free to comment on the github issue too. In fact I would notice any replies faster there, and probably reply faster myself.)

Well, what kind of wallet do you have? The more details you can give, the better. (no secret keys, etc. though)
If you go into "Wallet details", what icons/badges do you see at the top? (e.g. for one wallet of mine I see "standard", "p2wpkh", "HD", "Encrypted", "Lightning", "Seed")
Going back to an old version is just a temporary workaround. If you would like your problem to get fixed, please help in reproducing it. (and ideally open bug reports on github, it is difficult to keep track of reports across multiple places...)

Do you mean it segfaults (SIGILL/SIGSEGV), i.e. the whole process dies?