Unity cannot create a project,- and cannot find the default path ( Linux mint)

Hi, for some reason Unity does not create any projects in /home/haaken/unity-projects even if this folder exists. Im on Linux Mint 22

Logfile:
info-log.txt (151.2 KB)

How do I solve this issue?

Not enough information to help. What do you mean “does not create any project”? What are you doing EXACTLY? What are you getting EXACTLY? An error message?

Give us more details and maybe, just maybe, we can help.

I press " New Project" ,- then “Create project”

If everything was ok, it should create files in /home/haaken/unity-projects/ , but that does not happen.
I only get the gray spinning/loading circle.

That eventually disappears,- I get this:

If I click on " my project" ,this error message pops up.

How did you install the Unity Hub?

somehow i see the editor and hub version 2019 in the log. could you try to update those to at least the LTS we support?

I followed the method for Linux found here:
https://docs.unity3d.com/hub/manual/InstallHub.html

It’s because the sdk found here needs that version:

well the key error seems to be {“timestamp”:“2024-08-01T12:26:38.161Z”,“level”:“error”,“moduleName”:“Installation Manager”,“pid”:7459,“message”:"Parent editor location not found in the available editors list. Install path to be determined when pending editor install is complete. Error: No editor installed. Could not be retrieved for criteria: {"version":"2019.4.31f1","architecture":"x86_64"}\n

so it didnt find the editor…

The logs contains a lot of errors when trying to read files from /home/haaken/.local or /home/haaken/.config. I would start by checking the permissions on /home/haaken and also which filesystem it is using and how it it mounted.

1 Like

drwxrwxr-x 2 haaken haaken 4096 aug. 10 11:30 unity-projects

I did a complete new install of unity + editor and that seems to have fixed the issue, If I use the newest editor. 2019.4.31 simply refuses to work.
It is installed, so I have no idea what the issue is…

It used to work if installed by flatpack,- but now also the same issue there too.

Flatpack log:
info-log-flatpack.txt (34.9 KB)

Looks like the problem is on the editor side. Have you checked the editor logs? What happen if you start the editor in a terminal?

Yeah, something is going on with the 2019.4.
I have no idea what, but I don’t think it’s a permission issue since the latest editor works.
I have posted the logs.
How do I start it in the terminal?

You posted the Hub logs, not the editor logs. These are in .config/unity3d/Editor.log. Try starting 2019.4 and check the logs for errors.

You can start the editor from the terminal with ./Unity/Hub/Editor//Editor/Unity. You can check the doc for the command line arguments. For example you could try -createProject to create a new project at a given path.

It may not be a permission issue but I wouldn’t be so quick to rule it out. Even if the permissions of the directories are correct filesystem and mount options can cause a tone of problems. Also, does Linux Mint uses AppArmor now?

/Unity
./Unity: error while loading shared libraries: libgconf-2.so.4: cannot open shared object file: No such file or directory

Huh… The libgconf-2-4 package does not exist in the Noble ( Ubuntu 24.04 ) repositories or https://hub-dist.unity3d.com/artifactory/hub-debian-prod-local stable InRelease …

I have asked here:
https://forums.linuxmint.com/viewtopic.php?t=426975

Ho cool! Yet another dependency problem! Who could have predicted that those would keep happening now that Unity is distributed with packages?

You might be able to get it from the repository of the previous version of Ubuntu. Or the unofficial Flatpak might work for you.

That libgconf package also might be missing from the flatpack environment.

I have no idea why the vseeface sdk and the spesific univrm are using a editor that isn’t supported. It’s likely that I’m not the only one on Linux mint that is affected by the missing libgconf package. Of course I could shudders use a virtual windows machine, but I’m absolutely no fan of windows.

You said it worked with the flatpak before so I assume it has the correct environment. Unfortunately this flatpak is not maintained by Unity. They should be doing it to put en end to all these stupid dependency problems but it seems they don’t want to.

The SDK you want to use appear not to have been updated for years, that’s probably why it requires a crusty old version of Unity. You will probably be able to use it with more recent versions, Unity is pretty good with retro compatibility.

Yeah, flatpack used to work. It doesn’t do that anymore.

@tylerinthezoo please take a look at this, it might interest you.

I managed to get Unity 2019 to work on Ubuntu 24.04 by putting it into a flatpak. It doesn’t run natively on this version of Ubuntu because, as Supermagnum pointed, some dependencies are missing. But inside a flatpak you can put whatever dependencies you like regardless of which distribution you are using.

I did a little digging on the unofficial UnityHub flatpak that is on flathub and I think their approach is wrong. They flatpacked the Hub, not the editor. This is nice for ease of installation but it doesn’t solve the dependencies problem. Different versions of the editor require different dependencies so flatpacking the Hub isn’t going to solve that. We need to flatpak the editor instead.

Here is the manifest I came up with.

# The name of the flatpak we are going to create.
id: com.unity.Unity2019_4_40

# We use Gnome runtime as a base because it has almost everything we need.
runtime: org.gnome.Platform
runtime-version: '46'
sdk: org.gnome.Sdk

# When this flatpak is run then use our start-unity script
command: start-unity

# No need for that.
separate-locales: false

# Because we need it.
tags:
  - proprietary

# Poke holes into the sandboxing so Unity can access what it needs.
finish-args:
  - --device=all
  - --device=dri
  - --filesystem=home
  - --share=ipc
  - --share=network
  - --socket=pulseaudio
  - --socket=x11

modules:
  # We need gconf for unity. We need debug-glib and intltool for gconf.
  - modules/intltool/intltool-0.51.json
  - modules/dbus-glib/dbus-glib.json
  - modules/gconf/gconf.json
  
  # The module to copy and install the Unity editor.
  - name: unity
    buildsystem: simple
    build-commands:
      - install -Dm755 start-unity.py /app/bin/start-unity # Install our start-unity script.
      - cp -r Editor /app/bin/Editor                       # Copy all the editor from Unity's normal install.
    sources:
      - type: file
        path: start-unity.py
      - type: dir
        path: /home/chiw/Unity/Hub/Editor/2019.4.40f1 # This is where the Unity editor is installed on my computer.
        dest: Editor

# We can get our dependencies in deb form. Is it better than building from sources? Not sure...
#  - name: gconf
#    buildsystem: simple
#    build-commands:
#      - ar -x libgconf-2-4.deb
#      - tar -xf data.tar.xz
#      - install -Dm755 usr/lib/x86_64-linux-gnu/libgconf-2.so.4.1.5 /app/lib/libgconf-2.so.4
#    sources:
#       - type:          file
#         url:           http://de.archive.ubuntu.com/ubuntu/pool/universe/g/gconf/libgconf-2-4_3.2.6-7ubuntu2_amd64.deb
#         sha256:        ad86a4ee82b2631dab97d16736580f03108524a8040a790a6ef8b20cbd358be4
#         dest-filename: libgconf-2-4.deb

#  - name: dbus-glib
#    buildsystem: simple
#    build-commands:
#      - ar -x libdbus-glib-1-2.deb
#      - tar -xf data.tar.zst
#      - install -Dm755 usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2.3.5 /app/lib/libdbus-glib-1.so.2
#    sources:
#       - type:          file
#         url:           http://de.archive.ubuntu.com/ubuntu/pool/main/d/dbus-glib/libdbus-glib-1-2_0.112-2build1_amd64.deb
#         sha256:        eac07c361f81d846d877c606a98736137ecd04a36c33fdf53baa45693cea3f95
#         dest-filename: libdbus-glib-1-2.deb

What I do is copy the editor from its normal installation location and add the missing dependencies (we can either build them from source or retrieve them from older Ubuntu repo, both approach work).

Then all we need is a little trick to start Unity so that it can find the license file. This is the start-unity.py file:

#!/usr/bin/env python3
import os
import subprocess
import sys


def main():
  env = os.environ.copy()

  # Use user's real local directory instead of the one inside the flatpak container.
  # We need this so that Unity can access the license ULF file create by the Hub.
  env['XDG_DATA_HOME'] = os.path.join(os.path.expanduser('~'), ".local/share")

  # Use the tmp directory inside the flatpak container.
  env['TMPDIR'] = f'{env["XDG_CACHE_HOME"]}/tmp'

  # Start Unity.
  os.execvpe('/app/bin/Editor/Editor/Unity',
             ['/app/bin/Editor/Editor/Unity',
             '-useHub',
             '-hubIPC',
             '-cloudEnvironment', 'production',
             *sys.argv[1:]],
             env)


if __name__ == '__main__':
  main()

Then, after building the flatpak, it can be started from the command line. It doesn’t appear in the Hub (but there are probably ways around that) but by using command line arguments I can create and open projects. I didn’t do extensive testing, there are probably some problems, but this is a proof of concept.

I also tried it with Unity 2022.3 and it works too. It is even easier because no extra dependencies are needed, the Gnome runtime already contain everything we need.

I believe this is how Unity should be distributed in the future. First users have been complaining about dependencies problems with LibSSL and now with GConf. It will happen again. Ubuntu is not going to freeze its libraries to keep compatibility with Unity. This solution fix this problem once and for all.

All you need to do is to create a flatpak for each version of the editor, each of witch would have a slightly different manifest to include the dependencies it need. The Hub could download, install and start those flatpaks and the whole process would be transparent for the User. This isn’t too different than what the Hub is doing today. Currently the Hub download and install archives. With my proposed solution it would download and install flatpaks instead.

That doesn’t mean Unity has to officially support every distribution under the sun. Nor does it mean Unity has to keep supporting old versions of the editor. But it would allow users to install whatever version of Unity they want on whatever distribution they want.

Well, my two cents.

1 Like