Bug 1179629 - Fresh install: flatpak application won't run without static hostname
Fresh install: flatpak application won't run without static hostname
Status: CONFIRMED
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: GNOME
Leap 15.3
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: E-mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-12-05 15:59 UTC by Maurizio Galli
Modified: 2021-09-13 20:32 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Error log (343 bytes, text/plain)
2020-12-05 15:59 UTC, Maurizio Galli
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maurizio Galli 2020-12-05 15:59:49 UTC
Created attachment 844145 [details]
Error log

How to reproduce:

1. Fresh install of openSUSE Leap 15.2
2. Install flatpak + any flatpak application
3. run application e.g flatpak run com.github.tchx84.Flatseal
4. Application crashes see error logs attached

The issue seems to be related to name@localhost assigned by default

Workaround:

Setup a static hostname via Yast > Network > Hostname/DNS

I received several reports of people with a fresh install and confirming fixing it with a static hostname.
Comment 1 Fabian Vogt 2020-12-07 09:06:59 UTC
What's the output of "xauth list"? It should contain an entry with "#ffff#".
Comment 2 Maurizio Galli 2020-12-08 14:14:50 UTC
(In reply to Fabian Vogt from comment #1)
> What's the output of "xauth list"? It should contain an entry with "#ffff#".

Right after fresh install:

mau@localhost:~> xauth list
localhost/unix:0  MIT-MAGIC-COOKIE-1  d56f411b012a955974a66232540e958e
mau@localhost:~>
Comment 3 Fabian Vogt 2020-12-08 14:26:09 UTC
(In reply to Maurizio Galli from comment #2)
> (In reply to Fabian Vogt from comment #1)
> > What's the output of "xauth list"? It should contain an entry with "#ffff#".
> 
> Right after fresh install:
> 
> mau@localhost:~> xauth list
> localhost/unix:0  MIT-MAGIC-COOKIE-1  d56f411b012a955974a66232540e958e
> mau@localhost:~>

The FamilyWild entry is missing, so most likely a bug in GDM.
Comment 4 Maurizio Galli 2020-12-08 14:28:35 UTC
(In reply to Fabian Vogt from comment #3)
> (In reply to Maurizio Galli from comment #2)
> > (In reply to Fabian Vogt from comment #1)
> > > What's the output of "xauth list"? It should contain an entry with "#ffff#".
> > 
> > Right after fresh install:
> > 
> > mau@localhost:~> xauth list
> > localhost/unix:0  MIT-MAGIC-COOKIE-1  d56f411b012a955974a66232540e958e
> > mau@localhost:~>
> 
> The FamilyWild entry is missing, so most likely a bug in GDM.

In my case it's LightDM and Xfce but other users reported it with other DE's as well.
Comment 5 Fabian Vogt 2020-12-08 14:37:24 UTC
(In reply to Maurizio Galli from comment #4)
> (In reply to Fabian Vogt from comment #3)
> > (In reply to Maurizio Galli from comment #2)
> > > (In reply to Fabian Vogt from comment #1)
> > > > What's the output of "xauth list"? It should contain an entry with "#ffff#".
> > > 
> > > Right after fresh install:
> > > 
> > > mau@localhost:~> xauth list
> > > localhost/unix:0  MIT-MAGIC-COOKIE-1  d56f411b012a955974a66232540e958e
> > > mau@localhost:~>
> > 
> > The FamilyWild entry is missing, so most likely a bug in GDM.
> 
> In my case it's LightDM and Xfce but other users reported it with other DE's
> as well.

Ok, so just the usual story of:
- netconfig trying extra hard to set the right hostname (other distros don't, so they're not affected)
- We have a patched libxcb to honour $XAUTHLOCALHOSTNAME (other distros don't, most flatpaks neither)

The most compatible upstream way is to use FamilyWild, which GDM and SDDM do, but apparently not lightdm. Implementing that is unfortunately not trivial as it requires using a temporary file for Xauthority.

Reassigning.
Comment 6 Luquet 2021-05-25 13:09:00 UTC
Hello.

I confirm the bug with SDDM too. (kde install)

If you choose X11, with flatpak i got the same problem too.
Comment 7 Sebastian Wagner 2021-06-18 15:27:55 UTC
This is the upstream bug report: https://github.com/flatpak/flatpak/issues/4043

It runs down to the issue that, by default "localhost.localdomain" is the hostname and openSUSE-specific behaviour in some xauth-related stuff causes troubles with the dot. Hostnames with dots cause that flatpaks based on KDE won't run (sounds crazy, yes)

According to https://github.com/flatpak/flatpak/pull/4130/commits/fd6a3b79f4e022e3f41f0c71ab7c6f21393c0db1 there's a fix in flatpak's versions 1.11.2 1.11.1 , but openSUSE Leaps' version is 1.10 AFAIK (both in 15.2 and 15.3).

Hope this helps.
Comment 8 Fabian Vogt 2021-06-18 15:43:01 UTC
(In reply to Sebastian Wagner from comment #7)
> This is the upstream bug report:
> https://github.com/flatpak/flatpak/issues/4043
> 
> It runs down to the issue that, by default "localhost.localdomain" is the
> hostname and openSUSE-specific behaviour in some xauth-related stuff causes
> troubles with the dot.

Really? AFAIK the issue is that:
1. openSUSE adjusts the hostname based on DHCP and reverse DNS (other distros by default don't)
2. To mitigate xauth related issues, libxcb is patched to handle $XAUTHLOCALHOSTNAME

The issue is that flatpak applications don't use the system libxcb, and are thus affected by 1. I don't think there's any issue with the hostname format by itself.

Without patching libxcb or mitigating the issue in another way (SDDM and GDM in TW use FamilyWild, which doesn't depend on hostnames), this can't be fixed completely because the hostname can still change dynamically.

> Hostnames with dots cause that flatpaks based on KDE
> won't run (sounds crazy, yes)
>
> According to
> https://github.com/flatpak/flatpak/pull/4130/commits/
> fd6a3b79f4e022e3f41f0c71ab7c6f21393c0db1 there's a fix in flatpak's versions
> 1.11.2 1.11.1 , but openSUSE Leaps' version is 1.10 AFAIK (both in 15.2 and
> 15.3).
> 
> Hope this helps.
Comment 9 Sebastian Wagner 2021-06-18 16:14:35 UTC
> Really? AFAIK the issue is that:

I just re-phrased what was in the upstream issue and have no deeper knowledge. Sorry for mis-interpreting that, I'm sure you have a better understanding of the issue and how and where it can be resolved.

The workaround to set a hostname works for me and I'm satisfied for now.