Unity3D on Arch Linux
Getting a games engine to behave on a rolling-release distro
Contents
<p>The first time I tried to install Unity on Arch Linux, the build failed at ninety per cent because <code>/tmp</code> filled up. Not because the machine was short of disk — it had plenty — but because <code>/tmp</code> was mounted as <code>tmpfs</code>, which lives in RAM, and Unity’s installer is a multi-gigabyte download that wanted to unpack there. That single gotcha is the whole reason this post exists. Unity runs perfectly well on Arch, but the failure modes are unusual enough that the official instructions never quite cover the case you actually hit, and the AUR package changes shape every couple of years. Here is how it works today, why each step matters, and what to do when it breaks.</p>
<h2 id="why-arch-for-a-games-engine-at-all">Why Arch for a games engine at all</h2><div class="ad-unit ad-in-article" aria-label="Advertisement">
<span class="ad-label">Advertisement</span>
<ins class="adsbygoogle" style="display:block;text-align:center"
data-ad-client="ca-pub-3726833845844946"
data-ad-slot="3291553914"
data-ad-format="auto"
data-full-width-responsive="true"></ins>
<script>(adsbygoogle = window.adsbygoogle || []).push({});</script>
</div>
<p>Arch is not the obvious choice. Unity officially supports Ubuntu and CentOS, and if you just want the path of least resistance, one of those on a spare box will give you fewer surprises. So why bother?</p>
<p>Because Arch gives you a current toolchain without asking permission. Unity leans on a lot of native libraries — graphics drivers, <code>glibc</code>, GTK, the whole X11 or Wayland stack — and on a distro that freezes those for two years, you eventually hit a wall where a new Unity release wants something newer than your system ships. Arch’s rolling model means you already have the newer thing. The trade is that <em>you</em> are now responsible for the version churn, and a games engine is exactly the kind of large, driver-sensitive binary that notices when a library moves under it. If you like that trade, read on. If you don’t, this genuinely might not be the distro for this job, and I’ll say so again at the end.</p>
<p>I run a small pile of Linux boxes for exactly this reason — I’d rather own the maintenance than be told when I’m allowed to upgrade. It’s the same instinct behind hosting my own services, which I’ve written about in <a href="/story/the-real-cost-of-self-hosting-electricity-time-and-what-you-actually-save/">the real cost of self-hosting</a>. The freedom is real; so is the homework.</p>
<h2 id="the-modern-install-unityhub-from-the-aur">The modern install: unityhub from the AUR</h2>
<p>Forget the old advice you’ll find in blog posts from the last decade. The <code>unity-editor</code> AUR package and the <code>yaourt</code> helper it referenced are both dead — <code>yaourt</code> was abandoned years ago, and you should not be running it. The current, maintained route is the <strong><code>unityhub</code></strong> package, driven by a modern AUR helper such as <code>yay</code> or <code>paru</code>.</p>
<p>Unity Hub is a launcher. It manages editor versions, licences and projects, and it downloads the actual editor binaries itself once it’s running. So the AUR package is small; the heavy lifting happens on first launch.</p>
<p>Install an AUR helper first if you don’t have one, then the hub:</p>
<div class="highlight"><div class="chroma">
<table class="lntable"><tr><td class="lntd">
<pre tabindex="0" class="chroma"><code><span class="lnt">1
</span><span class="lnt">2
</span><span class="lnt">3
</span><span class="lnt">4
</span><span class="lnt">5
</span><span class="lnt">6
</span><span class="lnt">7
</span></code></pre></td>
<td class="lntd">
<pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl"><span class="c1"># paru, built from the AUR the manual way once</span>
</span></span><span class="line"><span class="cl">sudo pacman -S --needed base-devel git
</span></span><span class="line"><span class="cl">git clone https://aur.archlinux.org/paru.git
</span></span><span class="line"><span class="cl"><span class="nb">cd</span> paru <span class="o">&&</span> makepkg -si
</span></span><span class="line"><span class="cl">
</span></span><span class="line"><span class="cl"><span class="c1"># then Unity Hub is a one-liner</span>
</span></span><span class="line"><span class="cl">paru -S unityhub
</span></span></code></pre></td></tr></table>
</div>
</div><p>If you prefer <code>yay</code>, <code>yay -S unityhub</code> is the exact equivalent. Either helper fetches the <code>PKGBUILD</code>, pulls in dependencies, and builds a proper package that <code>pacman</code> then tracks — which matters, because it means <code>pacman -R unityhub</code> cleanly removes it later instead of leaving droppings around your filesystem.</p>
<p>Once it’s installed, launch it:</p>
<div class="highlight"><div class="chroma">
<table class="lntable"><tr><td class="lntd">
<pre tabindex="0" class="chroma"><code><span class="lnt">1
</span></code></pre></td>
<td class="lntd">
<pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">unityhub
</span></span></code></pre></td></tr></table>
</div>
</div><p>There’s one non-obvious step the hub won’t do for you. Create its preferences directory by hand, or the editor may fail to save settings:</p>
<div class="highlight"><div class="chroma">
<table class="lntable"><tr><td class="lntd">
<pre tabindex="0" class="chroma"><code><span class="lnt">1
</span></code></pre></td>
<td class="lntd">
<pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">mkdir -p ~/.local/share/unity3d
</span></span></code></pre></td></tr></table>
</div>
</div><h2 id="licensing-and-getting-an-editor">Licensing and getting an editor</h2><div class="ad-unit ad-in-article" aria-label="Advertisement">
<span class="ad-label">Advertisement</span>
<ins class="adsbygoogle" style="display:block;text-align:center"
data-ad-client="ca-pub-3726833845844946"
data-ad-slot="3291553914"
data-ad-format="auto"
data-full-width-responsive="true"></ins>
<script>(adsbygoogle = window.adsbygoogle || []).push({});</script>
</div>
<p>On first launch the hub asks you to sign in and pick a licence. If you don’t have a Unity account, create one at <a href="https://id.unity.com/">id.unity.com</a> — the free <strong>Personal</strong> tier is fine for hobby projects and small revenue, and it’s what most people on Arch are here for. Activate the licence from inside the hub under the account menu; command-line licence activation exists for CI but is overkill for a workstation.</p>
<p>Then install an editor version. In the hub, go to <strong>Installs → Install Editor</strong>, and pick an <strong>LTS</strong> release rather than the newest tech-stream build. LTS versions get patched for years and are far less likely to trip over a driver or library quirk. Add the build support modules you actually need — Linux, WebGL, Android — and skip the rest, because each one is a large download you’ll otherwise never use.</p>
<h2 id="actually-building-and-running-something">Actually building and running something</h2>
<p>Installing the editor is only half the job; the other half is producing a build that runs. On Linux you have two obvious targets. A native Linux player is a standalone binary Unity produces under <strong>File → Build Settings → Linux</strong>, and it runs directly — no browser, no runtime to install, just an executable and its <code>_Data</code> folder. WebGL is the other common target, and it’s the one that most often surprises people, because a WebGL build won’t run from a <code>file://</code> URL; browsers block the required requests. You have to serve it over HTTP. A throwaway static server is enough to test locally:</p>
<div class="highlight"><div class="chroma">
<table class="lntable"><tr><td class="lntd">
<pre tabindex="0" class="chroma"><code><span class="lnt">1
</span><span class="lnt">2
</span><span class="lnt">3
</span></code></pre></td>
<td class="lntd">
<pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl"><span class="nb">cd</span> path/to/webgl-build
</span></span><span class="line"><span class="cl">python3 -m http.server <span class="m">8000</span>
</span></span><span class="line"><span class="cl"><span class="c1"># then open http://localhost:8000 in a browser</span>
</span></span></code></pre></td></tr></table>
</div>
</div><p>For anything you’ll host properly, put it behind a real web server with the correct MIME types and compression headers — Unity’s WebGL builds ship large, and serving the <code>.wasm</code> and data files with Brotli or gzip makes an enormous difference to load time. This is exactly the kind of small self-hosted static site I’d tuck behind the same reverse proxy that fronts everything else on the box.</p>
<p>There’s also a headless mode worth knowing about even if you never touch CI. <code>unity-editor -batchmode -quit -projectPath <path> -executeMethod <Class.Method></code> runs the editor with no GUI, which is how automated builds work — and, usefully on a workstation, how you script a build without clicking through menus. It needs the licence already activated, which is why the licensing step earlier matters.</p>
<h2 id="watch-the-disk-and-especially-tmp">Watch the disk, and especially /tmp</h2>
<p>This is the part that bit me, and it bites nearly everyone, so it gets its own section.</p>
<p>The editor download and unpack is genuinely large — several gigabytes per editor version, more once you add platform modules. Two things go wrong:</p>
<p>First, the obvious one: your home partition runs out of space. Editors land under <code>~/Unity/Hub/Editor/</code>, and each version is its own multi-gigabyte tree. Keep an eye on it:</p>
<div class="highlight"><div class="chroma">
<table class="lntable"><tr><td class="lntd">
<pre tabindex="0" class="chroma"><code><span class="lnt">1
</span><span class="lnt">2
</span></code></pre></td>
<td class="lntd">
<pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">du -sh ~/Unity/Hub/Editor/*
</span></span><span class="line"><span class="cl">df -h ~
</span></span></code></pre></td></tr></table>
</div>
</div><p>Second, the sneaky one: <code>/tmp</code>. On many Arch setups <code>/tmp</code> is <code>tmpfs</code>, meaning it lives in RAM and is capped at half your memory by default. Installers and the editor’s own asset importer scratch to a temp directory, and if that directory is a too-small <code>tmpfs</code>, the operation dies with a confusing “no space left on device” even though <code>df -h /home</code> looks healthy. Check whether you’re affected:</p>
<div class="highlight"><div class="chroma">
<table class="lntable"><tr><td class="lntd">
<pre tabindex="0" class="chroma"><code><span class="lnt">1
</span></code></pre></td>
<td class="lntd">
<pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">findmnt /tmp
</span></span></code></pre></td></tr></table>
</div>
</div><p>If it reports <code>tmpfs</code>, point the temp directory somewhere with real disk before a big install:</p>
<div class="highlight"><div class="chroma">
<table class="lntable"><tr><td class="lntd">
<pre tabindex="0" class="chroma"><code><span class="lnt">1
</span><span class="lnt">2
</span><span class="lnt">3
</span></code></pre></td>
<td class="lntd">
<pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl"><span class="nb">export</span> <span class="nv">TMPDIR</span><span class="o">=</span><span class="s2">"</span><span class="nv">$HOME</span><span class="s2">/.cache/unity-tmp"</span>
</span></span><span class="line"><span class="cl">mkdir -p <span class="s2">"</span><span class="nv">$TMPDIR</span><span class="s2">"</span>
</span></span><span class="line"><span class="cl">unityhub
</span></span></code></pre></td></tr></table>
</div>
</div><p>Set that in the shell you launch the hub from, do your install, and you can drop it afterwards. It’s a two-line fix once you know it’s the cause — the trick is knowing.</p>
<h2 id="troubleshooting-the-things-that-actually-break">Troubleshooting the things that actually break</h2>
<p><strong>“Unity Hub won’t launch / blank window.”</strong> The hub is an Electron app, and on Wayland it sometimes renders a blank or black window. Force it under XWayland or disable GPU compositing:</p>
<div class="highlight"><div class="chroma">
<table class="lntable"><tr><td class="lntd">
<pre tabindex="0" class="chroma"><code><span class="lnt">1
</span><span class="lnt">2
</span><span class="lnt">3
</span></code></pre></td>
<td class="lntd">
<pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="line"><span class="cl">unityhub --no-sandbox
</span></span><span class="line"><span class="cl"><span class="c1"># or, for the blank-window case</span>
</span></span><span class="line"><span class="cl"><span class="nv">ELECTRON_OZONE_PLATFORM_HINT</span><span class="o">=</span>x11 unityhub
</span></span></code></pre></td></tr></table>
</div>
</div><p><strong>“Licence activation fails silently.”</strong> Almost always a clock or network issue. Make sure the system clock is correct (<code>timedatectl status</code>), because TLS to Unity’s licensing servers fails on a skewed clock, and confirm nothing is blocking outbound HTTPS.</p>
<p><strong>“Editor crashes on project open after a system update.”</strong> This is the rolling-release tax. A <code>pacman -Syu</code> bumped a graphics or <code>glibc</code> library and the older editor doesn’t like it. The pragmatic fixes, in order: install a newer LTS editor from the hub (it’ll be built against current libraries), or check <code>~/.config/unity3d/Editor.log</code> for the exact missing symbol. This is precisely the risk you took on by choosing Arch — most of the time an update is fine, occasionally it isn’t, and the log tells you which library moved.</p>
<p><strong>“Missing dependency at build time.”</strong> The AUR helper usually resolves these, but if <code>makepkg</code> complains, read the <code>PKGBUILD</code>’s <code>depends</code> array and install what’s named. Don’t blindly force-install; the dependency is listed for a reason.</p>
<p>Keep an editor log habit. When something misbehaves, <code>Editor.log</code> and <code>~/.local/share/unity3d/</code> hold the answer far more often than a forum thread does.</p>
<h2 id="keeping-it-maintainable">Keeping it maintainable</h2>
<p>A rolling distro rewards a little discipline. Update the hub and your AUR packages deliberately, not reflexively, and read what <code>paru</code> or <code>yay</code> is about to change before you confirm. Keep a note — even a plain text file in the project repo — of which editor version a given project was built against, because Unity projects are sensitive to editor version and “it worked last month” is not a version number. If you rely on this box, back up the whole home directory somewhere off the machine; I fold mine into the same routine I use for everything else, along the lines of the approach in <a href="/story/build-your-own-google-drive-nextcloud-on-linux/">build your own Google Drive with Nextcloud</a>.</p>
<p>One more habit that pays off: keep the number of installed editor versions small. It’s tempting to hoard every LTS you’ve ever used, but each one is several gigabytes and Unity offers no built-in cleanup — you remove old versions from the hub’s Installs pane by hand. I keep the current LTS a project needs and the one immediately before it, and delete the rest. On a rolling distro where disk pressure already causes the <code>/tmp</code> and home-partition problems above, that restraint is genuinely worth it.</p>
<p>Pin editors to LTS, install platform modules only when you need them, and treat a post-update crash as a diagnosis exercise rather than a disaster. That’s the whole maintenance loop.</p>
<h2 id="is-it-worth-it">Is it worth it?</h2>
<p>If you already live on Arch and want your games engine on the same machine as everything else, yes — <code>unityhub</code> from the AUR is a clean, well-maintained path, and the <code>/tmp</code> and disk traps are one-time lessons. You get a current toolchain, tight control, and an editor that stays out of your way.</p>
<p>If you’re choosing a distro <em>specifically</em> to run Unity and you don’t otherwise care about rolling releases, be honest with yourself: a supported Ubuntu LTS will crash less often after routine updates, because it isn’t moving libraries under the editor every week. Arch is the right answer when you want the control and accept the upkeep. It’s the wrong answer when you just want Unity to open and never think about the OS again. Pick accordingly — and if you pick Arch, keep that editor log open.</p>
Advertisement
Related Content
Advertisement
