Element is offline after the first log on #850

Ithvr · 2022-12-18T16:11:41Z

Steps to reproduce

Log on the client for the first time
Verify the client
Restart the client

Outcome

What did you expect?

I expect that when I start Element that I get log on as normal

What happened instead?

Everything works fine when I log on Element Desktop the first time, but after I restart the client is stuck being offline telling that "Connectivity to the server has been lost."
I know the server is working well since it works on other clients, and the browser version of element

Operating system

OpenSUSE Tumbleweed

Application version

Element-Desktop 1.11.15

How did you install the app?

OpenSUSE repository

Homeserver

element.ithvr.no

Will you send logs?

Yes

N0Manches · 2023-01-11T11:00:28Z

I have the same error on opensuse tumbleweed for weeks.
Tried to delete all configs, reinstall... nothing works.

Clicking on "Help & About" just closes the window.

Information for package element-desktop:
----------------------------------------
Repository     : openSUSE-Tumbleweed-Oss
Name           : element-desktop
Version        : 1.11.17-1.1
Arch           : noarch
Vendor         : openSUSE
Installed Size : 4.0 MiB
Installed      : Yes
Status         : up-to-date
Source package : element-desktop-1.11.17-1.1.src
Upstream URL   : https://github.com/vector-im/element-desktop
Summary        : A glossy Matrix collaboration client - desktop
Description    : 
    A glossy Matrix collaboration client - desktop

openSUSE Tumbleweed 20230110

When I try to use flatpak or the PWA with ungoogled-chromium I am logged out as soon the process is terminated.
So it also does not work on Fedora.

Really annoying... atm I can only use the web version in the browser on all my operating system I use. (Of course the other version are also web versions... but I think one can understand the point...)

t3chguy · 2023-01-11T11:02:09Z

I suggest reporting this upstream to the OpenSUSE package (community) maintainer. It isn't one we package & support

N0Manches · 2023-01-11T11:13:35Z

It is a pity that only debian based distros are officially supported :(.

So on debian based distros everything works fine? There is no spam on your server requests?

M_MISSING_TOKEN: MatrixError: [401] Invalid Authorization header.

In another thread someone explained that sometimes (sometimes is not the case for me here) a key... is incorrectly saved in the Browser IndexedDB.

t3chguy · 2023-01-11T11:14:26Z

@N0Manches that can happen if your keyring isn't available when the app launches, so the key to unlock idb is missing

N0Manches · 2023-01-11T11:26:02Z

found the others
#1079
element-hq/element-web#18584

But of course I verified it with my Android phone then everything works fine until I restart the application, everytime. No idea what I could do differently.
But what is a bit strange to me that I need to verify it twice first it asked for the keys desktop -> android. Afterwards my phone says there is a new device android -> desktop. Is that normal? The verification process with the qr code are both the same.

AUSBird · 2023-01-15T22:06:37Z

I'm also having the same issue. I login and it works until the application restarts when the whole app just wont connect.

My console output after restarting gives me this

Keytar isn't installed; secure key storage is disabled.
Seshat isn't installed, event indexing is disabled.
/home/ausbird/.config/Element exists: yes
/home/ausbird/.config/Riot exists: no
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change
Resetting the UI components after locale change
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[19320:0116/080329.443447:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
[19383:0116/080329.500425:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change

I noticed it mentions Keytar isn't installed; secure key storage is disabled., is this potentially part of a cause for the issue?

subscribernamegoeshere · 2023-01-21T12:07:37Z

where would i find this keytar message? my ctrl shift i from inside element-desktop client on this opensuse 15.4 machine doesnt show keytar error. those look like very early-on messages from a log, but i can only just as fast press ctrl+shift+i and eventually only kind of see later bootstrapping messages of this element-desktop client?

I see stuff like the following:

....
rageshake.ts:73 Restoring session for @subscribernamegoeshereyougettheidea:matrix.org
rageshake.ts:73 setLoggedIn: mxid: @subscribernamegoeshereyougettheidea:matrix.org deviceId: DEVICEIDHERE000000 guest: false hs: https://matrix-client.matrix.org/ softLogout: false freshLogin: false
....
rageshake.ts:73 StorageManager: Checking storage consistency
rageshake.ts:73 StorageManager: Local storage supported? true
rageshake.ts:73 StorageManager: IndexedDB supported? true
rageshake.ts:73 StorageManager: Local storage contains data? true
rageshake.ts:73 StorageManager: Crypto initialised? true
rageshake.ts:73 StorageManager: Sync store using IndexedDB contains data? true
rageshake.ts:73 StorageManager: Crypto store using IndexedDB contains data? true
rageshake.ts:73 StorageManager: Storage consistency checks passed
rageshake.ts:73 Expected a pickle key, but none provided. Encryption may not work.
.....
rageshake.ts:73 Session persisted for @subscribernamegoeshereyougettheidea:matrix.org
rageshake.ts:73 Lifecycle: Starting MatrixClient
rageshake.ts:73 EventIndex: Event indexing isn't installed for the platform, not initializing.
rageshake.ts:73 IndexedDBStore.startup: connecting to backend
rageshake.ts:73 MatrixClientPeg: waiting for MatrixClient store to initialise
rageshake.ts:73 StorageManager: Persistent? true
rageshake.ts:73 Switching to room id ROOMID1GOESHERE:matrix.org at event undefined
rageshake.ts:73 IndexedDB worker is ready
logger.ts:46 LocalIndexedDBStoreBackend.connect: connecting...
logger.ts:46 LocalIndexedDBStoreBackend.connect: awaiting connection...
logger.ts:46 LocalIndexedDBStoreBackend.connect: connected
logger.ts:46 LocalIndexedDBStoreBackend: loading account data...
logger.ts:46 LocalIndexedDBStoreBackend: loading sync data...
logger.ts:46 LocalIndexedDBStoreBackend: loaded sync data
logger.ts:46 LocalIndexedDBStoreBackend: loaded account data
logger.ts:46 LocalIndexedDBStoreBackend: loaded initial data
rageshake.ts:73 IndexedDBStore.startup: loading presence events
rageshake.ts:73 IndexedDBStore.startup: processing presence events
rageshake.ts:73 Crypto: Starting up crypto store...
rageshake.ts:73 connecting to indexeddb matrix-js-sdk:crypto
rageshake.ts:73 connected to indexeddb matrix-js-sdk:crypto
rageshake.ts:73 Crypto: initialising roomlist...
rageshake.ts:73 Crypto: initialising crypto object...
rageshake.ts:73 Crypto: initialising Olm...
rageshake.ts:73 Crypto: initialising Olm device...
rageshake.ts:73 Unable to initialise e2e Error: OLM.BAD_ACCOUNT_KEY
.......

AUSBird · 2023-01-21T20:34:54Z

I ran the element app from a terminal and it gave me that output

…

On Sat, Jan 21, 2023 at 10:07 PM subscribername goes here < ***@***.***> wrote: where would i find this keytar message? my ctrl shift i from inside element-desktop client on this opensuse 15.4 machine doesnt show keytar error. those look like very early-on messages from a log, but i can only just as fast press ctrl+shift+i and eventually only kind of see later bootstrapping messages of this element-desktop client? I see stuff like the following: .... rageshake.ts:73 Restoring session for @subscribernamegoeshereyougettheidea: matrix.org rageshake.ts:73 setLoggedIn: mxid: @subscribernamegoeshereyougettheidea: matrix.org deviceId: DEVICEIDHERE000000 guest: false hs: https://matrix-client.matrix.org/ softLogout: false freshLogin: false .... rageshake.ts:73 StorageManager: Checking storage consistency rageshake.ts:73 StorageManager: Local storage supported? true rageshake.ts:73 StorageManager: IndexedDB supported? true rageshake.ts:73 StorageManager: Local storage contains data? true rageshake.ts:73 StorageManager: Crypto initialised? true rageshake.ts:73 StorageManager: Sync store using IndexedDB contains data? true rageshake.ts:73 StorageManager: Crypto store using IndexedDB contains data? true rageshake.ts:73 StorageManager: Storage consistency checks passed rageshake.ts:73 Expected a pickle key, but none provided. Encryption may not work. ..... rageshake.ts:73 Session persisted for @subscribernamegoeshereyougettheidea: matrix.org rageshake.ts:73 Lifecycle: Starting MatrixClient rageshake.ts:73 EventIndex: Event indexing isn't installed for the platform, not initializing. rageshake.ts:73 IndexedDBStore.startup: connecting to backend rageshake.ts:73 MatrixClientPeg: waiting for MatrixClient store to initialise rageshake.ts:73 StorageManager: Persistent? true rageshake.ts:73 Switching to room id ROOMID1GOESHERE:matrix.org at event undefined rageshake.ts:73 IndexedDB worker is ready logger.ts:46 LocalIndexedDBStoreBackend.connect: connecting... logger.ts:46 LocalIndexedDBStoreBackend.connect: awaiting connection... logger.ts:46 LocalIndexedDBStoreBackend.connect: connected logger.ts:46 LocalIndexedDBStoreBackend: loading account data... logger.ts:46 LocalIndexedDBStoreBackend: loading sync data... logger.ts:46 LocalIndexedDBStoreBackend: loaded sync data logger.ts:46 LocalIndexedDBStoreBackend: loaded account data logger.ts:46 LocalIndexedDBStoreBackend: loaded initial data rageshake.ts:73 IndexedDBStore.startup: loading presence events rageshake.ts:73 IndexedDBStore.startup: processing presence events rageshake.ts:73 Crypto: Starting up crypto store... rageshake.ts:73 connecting to indexeddb matrix-js-sdk:crypto rageshake.ts:73 connected to indexeddb matrix-js-sdk:crypto rageshake.ts:73 Crypto: initialising roomlist... rageshake.ts:73 Crypto: initialising crypto object... rageshake.ts:73 Crypto: initialising Olm... rageshake.ts:73 Crypto: initialising Olm device... rageshake.ts:73 Unable to initialise e2e Error: OLM.BAD_ACCOUNT_KEY ....... — Reply to this email directly, view it on GitHub <#850>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWKI2NJ7GQR6KXIIKEWZJTWTPGRJANCNFSM6AAAAAATCTAQXI> . You are receiving this because you commented.Message ID: ***@***.***>

subscribernamegoeshere · 2023-01-22T02:16:34Z

I ran the element app from a terminal and it gave me that output

thanks for this information. by the way did you already file a bugreport with opensuse folks for this situation or anyone in here to really get this stuff solved on the opensuse platforms? thanks.

asdil12 · 2023-01-27T12:25:03Z

The keytar and Seshat messages are unrelated. They are, because on openSUSE element-desktop is build without native bindings that would allow searching for messages. This is because of the abysmal node/cargo build process not being easy to run in the secure build environment that doesn't have internet access.

I have to say that I don't run into this issues on tumbleweed.
This is my startup log:

Keytar isn't installed; secure key storage is disabled.
Seshat isn't installed, event indexing is disabled.
/home/MYUSER/.config/Element exists: yes
/home/MYUSER/.config/Riot exists: no
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to de
Fetching translation json for locale: de
Resetting the UI components after locale change
Resetting the UI components after locale change
Changing application language to de
Fetching translation json for locale: de
Resetting the UI components after locale change

subscribernamegoeshere · 2023-01-28T14:18:33Z

i am far from being technically knowledgeable about all of this, i dont build my software on my own. coming back to this logged out state after every restart of the element application, what is the actual root cause that opensuse vendor and their compilation does have this bug? is this already known? will opensuse ever again have a working and lasting element application? what was different in december or november of last year that their compiled and built application worked normally and now does not any more? any real answers to this?

asdil12 · 2023-01-28T14:31:40Z

The problem is that I cannot reproduce this issue on my tumbleweed installation.

You could try to delete your .config/Element directory and start with a fresh config. (Make sure you have a different client still logged in to keep your encrypted chats).
Also you could create a test account on a different server and see if the issue only appears on that particular server.

subscribernamegoeshere · 2023-01-29T23:11:11Z

doesnt help at all removing the .config/Element/ folder. the client re-logs in and re-verfiies with other existing devices.

upon first shutdown of the new opensuse logged-in instance newly creasted device id and all, it is immediately offline for good upon the next re-start of this client. once again. all the same.

how are we gonna figure out whats happening? please solve this. :(
p,s, but this is open suse 15.4 x64 over here not tumbleweed. also this uses matrix.org simple username password account. what i remember maybe changed around the very end of last year is that for the first time i have had a second fellow participant chat with a second person via matrix and this user created a very new user account on matrix.org and this chat was immediately kind of end to end encrypted or was forced to this setting by this other party. my other chats to one other person is not yet end to end encrypted. thats the only thing i remember.

also the newly created linux client shows this one settings complaint in the security area that components would be missing to be able to search through end to end encrypted messages or so it complains in that one area with explanatory text or something on how to build the client or what components would be missing. maybe this is another hint.

asdil12 · 2023-01-29T23:16:57Z

I'm sorry but I only package that software for openSUSE and have no idea about the inner workings of element. This sounds like a bug in element that only appears under very specific circumstances that I can't even reproduce.

I can only recommend you to try a different matrix client. Nheko is in the openSUSE repos and works pretty well.

subscribernamegoeshere · 2023-01-29T23:29:50Z

wow this is no good answer at all, we are all bugreporting a bug about the element client here, the solution should not be to disregard a bug and abandon ship :(

how do we work to solve this stuff? what can be next steps in the proper direction?

subscribernamegoeshere · 2023-01-30T08:32:38Z

can you please create yourself a test account on matrix.org to use the same server and backend situation? and on leap 15.4 . i have added this single repository

https://download.opensuse.org/repositories/devel:/languages:/nodejs/15.4/

and I guess these three packages are being used from that rpm-md repo

element-desktop-1.11.20-lp154.1.1.noarch
element-web-1.11.20-lp154.2.1.noarch
nodejs-electron-22.1.0-lp154.1.1.x86_64

thanks for looking into this matter. it was working happily for a long time on 15.4 but now it does not :(

subscribernamegoeshere · 2023-01-31T11:14:37Z

one other thing that strikes me odd is that a simple not logged in element desktop client only showing the basic matrix.org landscape scene fotography with the login signup etc buttons would not load of this element desktop application is pinned to the taskmanager area and thus being automatic started when the kde desktop of the opensuse 15.4 starts for the normal user session. when there having a basic simple wifi connection that is slow to establish or taking a while to acquire ip addresses and all this element desktop application shows in its fullscreen window that something is wrong and it could not resolve element.io and it should be restarted and what not. so even the basic starting up of an non logged in element desktop application (client) is not robust enough to handle non networking and non online states of the machine when the networking connection the internet connection is not yet established, cut, broken or dns servers are not responding yet etc.

is it maybe possible as my opensuse 15.4 element-desktop was always in the automagic startup when it tries to reestablish the user account it maybe first quickly fails to get hold of ip addresses dns results and what not then somehow yanks all this information or parts of the authentication headers cookies or session states or whichever exact technical details and then lands in this failed state of profile or user account and user session of the matrix.org account, and when shortly thereafter the networking layers of the machine are there and fully established the session is already hosed and borked and of no use any more?

just an idea. please look into this bug. why would opensuse 15.4 users be left out in the dark and have no real working element-desktop client any more? this cant be state of the art for the opensuse 15.4 platform and this cant be a serious thing going on that a user needs to endure these days. can it? thanks

btw, a native firefox (rpm) on opensuse 15.4 can happily run a matrix-web (surfing element.io) way to connect to the matrix.org backend and this session happily works, survives firefox shutdowns, machine shutdowns, machine reboots and all that. as it ought to be.

what now? thanks.

subscribernamegoeshere · 2023-02-14T10:08:25Z

still all the same tried over again everything with currently:

element-desktop-1.11.22-lp154.1.1.noarch
element-web-1.11.22-lp154.1.1.noarch
nodejs-common-5.0-150400.1.4.x86_64
nodejs16-16.18.1-150400.3.12.1.x86_64
nodejs-electron-22.2.1-lp154.3.1.x86_64

opensuse 15.4 is only able to have a matrix element client running from within a webbrowser. so sad :(

subscribernamegoeshere · 2023-02-14T17:03:25Z

still defunct after todays rpm

element-web-1.11.23-lp154.1.1.noarch
element-desktop-1.11.23-lp154.1.1.noarch
nodejs-common-5.0-150400.1.4.x86_64
nodejs16-16.18.1-150400.3.12.1.x86_64
nodejs-electron-22.2.1-lp154.3.1.x86_64

barathrm · 2023-03-08T09:48:29Z

Same issue, also opensuse tumbleweed, KDE. kwallet is open. Same logs as others.

Tried removing ~/.config/Element
Tried removing ~/.pki

Related?

Connectivity to the Server Has Been Lost element-web#18584 (comment)
element suddenly not connecting any more (matrix.org account) immediately offline, finding no way to make it work #849

element.log

subscribernamegoeshere · 2023-03-14T08:03:01Z

thanks for further participants in this bug. is it maybe possible that a security store (kde wallet?) is involved in this issue? although my kde wallet (same here) does not show any access or prompt when element desktop on opensuse leap 15.4 is running or starting. my kde wallet is also not automatically unlocked and needs a password.

at present this kde wallet only seems to store wifi credentials.
thanks.

subscribernamegoeshere · 2023-03-29T15:58:32Z

okay this is still the same, with:

element-desktop-1.11.26-lp154.1.1.noarch
element-web-1.11.26-lp154.2.1.noarch

nodejs16-16.19.1-150400.3.15.1.x86_64
nodejs-common-5.0-150400.1.4.x86_64
nodejs-electron-22.3.4-lp154.1.1.x86_64

invalid authorization header after returing to this client / instance. no connection possible.
okay seriously, will this ever be investigated any further? what can we as users do more?

it seems as if opensuse platform is kind of becoming abandonware and steering itself in very differnt directions from where it has once been, what I read at various places but thats another story I guess.

t3chguy · 2023-03-29T15:59:35Z

@subscribernamegoeshere have you reported it to the community maintainer of your package?

AUSBird · 2023-03-29T18:26:35Z

Update from me, I’m not sure if this will help others but I updated my homeserver to the latest version available (Cant remember what version I was on but can get that info later, this was a few weeks ago) and it works for me now. I don’t know why the client wasn’t saving keys, but to my surprise the server update fixed the client *shrugs*

…

On Thu, 30 Mar 2023 at 1:59 am, Michael Telatynski ***@***.***> wrote: @subscribernamegoeshere <https://github.com/subscribernamegoeshere> have you reported it to the community maintainer of your package? — Reply to this email directly, view it on GitHub <#850>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABWKI2MB3OOFZZSEFTVBRZTW6RL7FANCNFSM6AAAAAATCTAQXI> . You are receiving this because you commented.Message ID: ***@***.***>

subscribernamegoeshere · 2023-03-30T13:42:55Z

updated what exactly on your homeserver? the element packages? anyhow, this machine with KDE desktop auto-starts element desktop application ( element-desktop-1.11.26-lp154.1.1.noarch ) automatically after a full shutdown and reboot thereafter. Upon login of the normal user into the KDE, the desktop gets restored, some simple "konsole" application starts at my machine and the element desktop app appears immediately complaining about:

Failed to start
Your Element is misconfigured
Unexpected error resolving homeserver configuration
Go to element.io

as this machine has wireless access and the wifi connection doesnt come up and get connected as quickly and it does not have ip stack and its own address and route to public internet immediately.

is this maybe a hint as well to shortcoming of this opensuse element-desktop built binaries and package and so? maybe this situation gives additional hints into some causes why authentication headers or basic connection does not succeed or why some stages of the handshake with the element/matrix backend servers are failing or missing or something in this regard?

thanks.

subscribernamegoeshere · 2023-03-30T13:46:30Z

@subscribernamegoeshere have you reported it to the community maintainer of your package?

If I understand this thread and its participants posting right, https://github.com/asdil12 @asdil12 is actually the? or some package maintainer of the element stuff for open/suse and he is aware of the situation or something?

i am only participating in this issue here on github in this bug and my other one I already referenced in this thread
thanks.

asdil12 · 2023-03-30T16:29:14Z

is this maybe a hint as well to shortcoming of this opensuse element-desktop built binaries and package and so? maybe this situation gives additional hints into some causes why authentication headers or basic connection does not succeed or why some stages of the handshake with the element/matrix backend servers are failing or missing or something in this regard?

This is something I can actually help with:

You could use this script to wait for internet access and only afterwards start element-desktop:

for i in {1..300} ; do ping -c1 opensuse.org && break ; sleep 1 ; done
element-desktop

subscribernamegoeshere · 2023-04-27T12:59:43Z

i wonder utmostly how can the internationally? famous? distribution named suse be in such disarray that a simple? open source project like this matrix element client does not run on it and is in such elementary shattered state after every shutdown of the application.
i guess its time to abandon ship. opensuse is just not the distro to run.

still authentication header errors for months now currently at:

element-web-1.11.30-lp154.2.1.noarch
element-desktop-1.11.30-lp154.1.1.noarch
nodejs-common-5.0-150400.1.4.x86_64
nodejs-electron-22.3.6-lp154.3.1.x86_64
nodejs16-16.20.0-150400.3.18.2.x86_64

UkeHa · 2023-05-07T12:06:57Z

I'm also affected by this issue on latest suse tumbleweed. Using the flatpak version shuts down after a couple of seconds, using the distro version works flawlessly but forgets the login every time the application is restarted.

t3chguy · 2023-05-07T12:30:02Z

Sounds like an issue with the keyring access, I suggest opening a ticket with that package's maintainer

subscribernamegoeshere · 2023-05-08T22:06:00Z

t3chguy, what keyring stuff is this about exactly? the element desktop local native app (.rpm) on opensuse 15.4 never asked me for any kde wallet (?) or whatever if thats what you mean? i am not an expert about this. how can we progress? maybe we are lucky now that also the grand tumbleweed would be affected by this bug, maybe some opensuse fellas will become busy at last? wondering :(

t3chguy · 2023-05-09T07:44:58Z

@subscribernamegoeshere Element Desktop uses Keytar to store secrets in your keyring, those secrets are used to encrypt/pickle things in IndexedDB such as your Access Token, if accessing your keyring fails your token may end up wrongly unpickled and thus you cannot authenticate to your server. The opensuse and flatpak apps are community maintained, you'd need to ask them for help with this.

LeoniePhiline · 2023-06-14T15:35:03Z

Hi! Also openSUSE Tumbleweed here, and same problem.
The console output says keytar is in fact not used (not installed) (notably, keytar is not even maintained any more):

$ element-desktop
Keytar isn't installed; secure key storage is disabled.
Seshat isn't installed, event indexing is disabled.
/home/leonie/.config/Element exists: yes
/home/leonie/.config/Riot exists: no
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change
Resetting the UI components after locale change
Changing application language to en-us
Fetching translation json for locale: en-us
Resetting the UI components after locale change

Relevant lines:

Is this in indication that...:

the error lies in keytar not being installed?
or does this indicate the error must in fact lie somewhere else, since keytar isn't even in use?

By the way, --devtools do not work:

$ element-desktop --devtools
Keytar isn't installed; secure key storage is disabled.
Seshat isn't installed, event indexing is disabled.
/home/leonie/.config/Element exists: yes
/home/leonie/.config/Riot exists: no
Error: Cannot find module 'electron-devtools-installer'
Require stack:
- /usr/share/element/app.asar/lib/electron-main.js
- /usr/lib64/electron/resources/default_app.asar/main.js
- 
    at Module._resolveFilename (node:internal/modules/cjs/loader:963:15)
    at n._resolveFilename (node:electron/js2c/browser_init:2:109751)
    at Module._load (node:internal/modules/cjs/loader:811:27)
    at f._load (node:electron/js2c/asar_bundle:2:13330)
    at Module.require (node:internal/modules/cjs/loader:1035:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at /usr/share/element/app.asar/lib/electron-main.js:380:80
    at Generator.next (<anonymous>)
    at fulfilled (/usr/share/element/app.asar/lib/electron-main.js:46:58) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/usr/share/element/app.asar/lib/electron-main.js',
    '/usr/lib64/electron/resources/default_app.asar/main.js',
    undefined
  ]
}
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change
Resetting the UI components after locale change
Changing application language to en-us,en,en,en
Fetching translation json for locale: en-us
Fetching translation json for locale: en
Fetching translation json for locale: en
Fetching translation json for locale: en
Resetting the UI components after locale change

OpenSUSE factory package is here: https://build.opensuse.org/package/show/openSUSE%3AFactory/element-desktop

@t3chguy Is the build script correct?

https://build.opensuse.org/package/view_file/openSUSE:Factory/element-desktop/element-desktop.spec?expand=1

E.g. is ELECTRON_SKIP_BINARY_DOWNLOAD=1 ok since changes like #631? Are any modules supposedly downloaded rather than built, which causes them to end up missing with this build script?

I added a comment for the maintainers here: https://build.opensuse.org/package/show/openSUSE:Factory/element-desktop#comment-1787999

Notably, the "further upstream" package at https://build.opensuse.org/package/show/devel%3Alanguages%3Anodejs/element-desktop has the same problem.

keytar (which is no longer maintained) requires libsecret, which I have installed (i+):

S  | Name                               | Type    | Version    | Arch   | Repository
---+------------------------------------+---------+------------+--------+--------------------------
   | git-credential-libsecret           | package | 2.41.0-1.1 | x86_64 | Main Repository (OSS)
   | git-credential-libsecret           | package | 2.41.0-1.1 | x86_64 | openSUSE:Tumbleweed
   | git-credential-libsecret           | package | 2.41.0-1.1 | x86_64 | openSUSE:Tumbleweed
   | git-credential-libsecret           | package | 2.41.0-1.1 | x86_64 | openSUSE-20230612-0
   | git-credential-libsecret-debuginfo | package | 2.41.0-1.1 | x86_64 | openSUSE-Tumbleweed-Debug
i+ | libsecret-1-0                      | package | 0.20.5-1.5 | x86_64 | Main Repository (OSS)
i+ | libsecret-1-0                      | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
i+ | libsecret-1-0                      | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
i+ | libsecret-1-0                      | package | 0.20.5-1.5 | x86_64 | openSUSE-20230612-0
   | libsecret-1-0-32bit                | package | 0.20.5-1.5 | x86_64 | Main Repository (OSS)
   | libsecret-1-0-32bit                | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
   | libsecret-1-0-32bit                | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
   | libsecret-1-0-32bit                | package | 0.20.5-1.5 | x86_64 | openSUSE-20230612-0
   | libsecret-1-0-32bit-debuginfo      | package | 0.20.5-1.5 | x86_64 | openSUSE-Tumbleweed-Debug
   | libsecret-1-0-debuginfo            | package | 0.20.5-1.5 | x86_64 | openSUSE-Tumbleweed-Debug
   | libsecret-debugsource              | package | 0.20.5-1.5 | x86_64 | openSUSE-Tumbleweed-Debug
   | libsecret-devel                    | package | 0.20.5-1.5 | x86_64 | Main Repository (OSS)
   | libsecret-devel                    | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
   | libsecret-devel                    | package | 0.20.5-1.5 | x86_64 | openSUSE:Tumbleweed
   | libsecret-devel                    | package | 0.20.5-1.5 | x86_64 | openSUSE-20230612-0
   | libsecret-lang                     | package | 0.20.5-1.5 | noarch | Main Repository (OSS)
   | libsecret-lang                     | package | 0.20.5-1.5 | noarch | openSUSE:Tumbleweed
   | libsecret-lang                     | package | 0.20.5-1.5 | noarch | openSUSE:Tumbleweed
   | libsecret-lang                     | package | 0.20.5-1.5 | noarch | openSUSE-20230612-0

t3chguy · 2023-06-15T07:37:29Z

@LeoniePhiline the build script isn't correct, it omits native dependencies

#yarn run build:native

is commented out.

This is why there is no keytar & seshat, as for whether that is the issue I would need your element logs (Settings > Help & About) to know

asdil12 · 2023-06-15T13:42:58Z

openSUSE element package maintainer here.

I was finally able to reproduce the issue by deleting my ~/.config/Element/ and logging in again.
I was getting this "couldn't connect to server" issue after a restart of element.

I tried with the official static builds, which contain native binaries (see https://packages.element.io/desktop/install/linux/glibc-x86-64/index.html) which worked fine.

So with the help of some outdated comments in some closed issue (#594 (comment)) and the semi-helpful documentation on native modules (https://github.com/vector-im/element-desktop/blob/develop/docs/native-node-modules.md) as well as some patch that was needed to convince this gyp thing to build keytar…

--- .hak/keytar/x86_64-unknown-linux-gnu/build/node_modules/node-gyp/gyp/pylib/gyp/input.py 2023-06-15 12:09:05.127000000 +0200
+++ .hak/keytar/x86_64-unknown-linux-gnu/build/node_modules/node-gyp/gyp/pylib/gyp/input.py 2023-06-15 13:34:18.969088855 +0200
@@ -1190,7 +1190,7 @@
         else:
             ast_code = compile(cond_expr_expanded, "<string>", "eval")
             cached_conditions_asts[cond_expr_expanded] = ast_code
-        env = {"__builtins__": {}, "v": StrictVersion}
+        env = {"__builtins__": {"openssl_fips": ""}, "v": StrictVersion}

… as well as finding out, how to bundle cargo dependencies, which was surprisingly easy after finding out, where cargo was actually called, I was able to build with native modules within our offline build environment.

I already submitted my changes to the devel project (https://build.opensuse.org/package/rdiff/devel:languages:nodejs/element-desktop?linkrev=base&rev=36), but as the nodejs-electron package was updated today and is currently building, I don't expect anything being built before tomorrow.

In the meantime here is my locally built element-desktop:

element-desktop-1.11.32-0.x86_64.rpm.gz

LeoniePhiline · 2023-06-15T17:34:31Z

@asdil12 You are THE hero! Thank you so much!

subscribernamegoeshere · 2023-06-19T18:55:21Z

opensuse leap 15.5 with

element-desktop-1.11.32-lp155.3.1.x86_64
element-web-1.11.32-lp155.1.1.noarch

seems to work stable now.

subscribernamegoeshere · 2023-07-18T17:35:23Z

this bug / issue probably can be closed (resolved?) now. keeps working with opensuse leap 15.5, current version from today due to CVE

element-desktop-1.11.36-lp155.1.1.x86_64
element-web-1.11.36-lp155.1.1.noarch
nodejs-electron-22.3.14-lp155.1.1.x86_64

sebix · 2023-07-18T17:58:49Z

I can confirm 1.11.34-1.1 on Tumbleweed works too

Ithvr added the T-Defect label Dec 18, 2022

subscribernamegoeshere mentioned this issue Jan 21, 2023

element suddenly not connecting any more (matrix.org account) immediately offline, finding no way to make it work #849

Closed

t3chguy transferred this issue from element-hq/element-web Apr 18, 2023

t3chguy added X-Community-Supported-Platform This issue occurs in a platform not directly supported by us, but by a community project elsewhere Z-Linux Z-Suse labels Apr 27, 2023

t3chguy closed this as completed Jul 18, 2023

LeoniePhiline mentioned this issue Jul 27, 2023

Connectivity to the server has been lost. Sent messages will be stored until your connection has returned. #1030

Open

stikonas mentioned this issue Nov 7, 2023

"Connectivity to the server has been lost." #942

Open

Element is offline after the first log on #850

Element is offline after the first log on #850

Comments

Ithvr commented Dec 18, 2022

Steps to reproduce

Outcome

What did you expect?

What happened instead?

Operating system

Application version

How did you install the app?

Homeserver

Will you send logs?

N0Manches commented Jan 11, 2023 • edited Loading

t3chguy commented Jan 11, 2023

N0Manches commented Jan 11, 2023

t3chguy commented Jan 11, 2023 • edited Loading

N0Manches commented Jan 11, 2023

AUSBird commented Jan 15, 2023

subscribernamegoeshere commented Jan 21, 2023

AUSBird commented Jan 21, 2023 via email

subscribernamegoeshere commented Jan 22, 2023

asdil12 commented Jan 27, 2023

subscribernamegoeshere commented Jan 28, 2023

asdil12 commented Jan 28, 2023

subscribernamegoeshere commented Jan 29, 2023 • edited Loading

asdil12 commented Jan 29, 2023

subscribernamegoeshere commented Jan 29, 2023 • edited Loading

subscribernamegoeshere commented Jan 30, 2023 • edited Loading

subscribernamegoeshere commented Jan 31, 2023

subscribernamegoeshere commented Feb 14, 2023

subscribernamegoeshere commented Feb 14, 2023

barathrm commented Mar 8, 2023 • edited Loading

subscribernamegoeshere commented Mar 14, 2023

subscribernamegoeshere commented Mar 29, 2023

t3chguy commented Mar 29, 2023

AUSBird commented Mar 29, 2023 via email

subscribernamegoeshere commented Mar 30, 2023

subscribernamegoeshere commented Mar 30, 2023

asdil12 commented Mar 30, 2023 • edited Loading

subscribernamegoeshere commented Apr 27, 2023

UkeHa commented May 7, 2023

t3chguy commented May 7, 2023

subscribernamegoeshere commented May 8, 2023

t3chguy commented May 9, 2023

LeoniePhiline commented Jun 14, 2023 • edited Loading

t3chguy commented Jun 15, 2023 • edited Loading

asdil12 commented Jun 15, 2023

LeoniePhiline commented Jun 15, 2023

subscribernamegoeshere commented Jun 19, 2023

subscribernamegoeshere commented Jul 18, 2023 • edited Loading

sebix commented Jul 18, 2023

N0Manches commented Jan 11, 2023 •

edited

Loading

t3chguy commented Jan 11, 2023 •

edited

Loading

subscribernamegoeshere commented Jan 29, 2023 •

edited

Loading

subscribernamegoeshere commented Jan 29, 2023 •

edited

Loading

subscribernamegoeshere commented Jan 30, 2023 •

edited

Loading

barathrm commented Mar 8, 2023 •

edited

Loading

asdil12 commented Mar 30, 2023 •

edited

Loading

LeoniePhiline commented Jun 14, 2023 •

edited

Loading

t3chguy commented Jun 15, 2023 •

edited

Loading

subscribernamegoeshere commented Jul 18, 2023 •

edited

Loading