Anycubic Slicer Next only ships as a Ubuntu 24.04 .deb. After switching from Windows to CachyOS I wanted to keep using it for my Kobra S1, but the official installer Anycubic Slicer Next Linux installation guide (wiki.anycubic.com) hard-checks for lsb_release -sc == noble and refuses to run on anything else. Distrobox (distrobox.it) solves exactly this: run a Ubuntu container that integrates with the host. App menu entry, home-directory passthrough, GPU acceleration, the works.

The setup below is adapted from u/jpagesb's comment on r/anycubic (www.reddit.com), which is what got me started. The locale section further down is the one place I had to deviate.

The setup

sudo pacman -S distrobox podman
distrobox create --name anycubic-slicer --image ubuntu:24.04 --nvidia
distrobox enter anycubic-slicer

--nvidia matters if you have an NVIDIA GPU (mine is an RTX 3080). Without it, the 3D canvas falls back to software rendering and slicing previews crawl. Inside the container, run the official installer:

sudo apt update && sudo apt install -y curl ca-certificates lsb-release locales
/bin/bash -c "$(curl -fsSL https://cdn-universe-slicer.anycubic.com/install/AnycubicSlicerNextInstaller.sh)"

The installer adds Anycubic’s apt repo and pulls anycubicslicernext. Then export the desktop entry to the host:

distrobox-export --app AnycubicSlicerNext
exit

The exported .desktop file in ~/.local/share/applications/ references the icon under /run/host/..., which the host can’t resolve. Strip the prefix:

sed -i 's|/run/host||' ~/.local/share/applications/*nycubic*.desktop

Now the icon shows up in the app menu. Click it, and… nothing happens.

Symptom: the icon does nothing

No window. No splash. No error dialog. The .desktop file uses Terminal=false, so any stderr from the launcher is swallowed.

To see what’s actually happening, run the binary directly:

distrobox enter anycubic-slicer -- AnycubicSlicerNext

The crash:

[2026-05-08 15:45:32.717578] [trace]   Initializing StaticPrintConfigs
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid

C++ couldn’t open a locale that the binary thought was set, threw an unhandled runtime_error, and the process died before the GUI could draw a single pixel.

Why the recipe’s locale step isn’t quite enough

The Reddit recipe runs sudo locale-gen en_US.UTF-8 inside the container, with the comment # add your locale if different. Fair note from the author, but on a mixed-locale setup it’s easy to misread which one “your locale” actually is.

Mine looks like this:

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8

KDE’s regional settings happily mix locales: English UI, German numbers and dates. Distrobox passes the host environment straight into the container by default, so LC_NUMERIC=de_DE.UTF-8 arrives at the slicer, and the C++ locale machinery tries to open a de_DE.UTF-8 that the container hasn’t generated.

In the container, locale -a shows English locales (the locales package and distrobox’s own setup take care of those out of the box) but nothing else:

$ distrobox enter anycubic-slicer -- locale -a | head
C
C.utf8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8

No de_DE.utf8. One of the inherited de_DE.UTF-8 values reaches the slicer, libc has no such locale, C++ throws.

Fix

Generate the locale that your host actually uses, inside the container:

distrobox enter anycubic-slicer -- sudo locale-gen de_DE.UTF-8

Output:

Generating locales (this might take a while)...
  de_DE.UTF-8... done
Generation complete.

That’s it. Click the icon, and the slicer opens.

If your host uses a different mixed locale (fr_FR.UTF-8, es_ES.UTF-8, whatever), substitute that. The general rule: every locale that appears in your host locale output must exist in the container. If you’re not sure which one is being requested, just look at the locale command output on the host and locale-gen each non-C/non-POSIX value into the container.

Verifying it works end-to-end

After the fix, the things I cared about all work:

  • 3D canvas with GPU acceleration. With --nvidia set on container creation and the locale fix in place, the slicer renders the print bed and model previews smoothly. Rotating a complex model stays interactive instead of dropping to a slideshow.
  • File access. Distrobox bind-mounts the host home directory, so STL/3MF files live wherever they normally do: ~/Downloads, ~/3D, anywhere under ~/. The slicer sees them at the same path.
  • Anycubic Cloud / remote print. Sign in to the Anycubic account inside the slicer, the Kobra S1 shows up, “send to printer” works without leaving the desk. Same workflow I had on Windows.

Updating from the host

If you’d rather not click through the in-app updater, the manual command is:

distrobox enter anycubic-slicer -- bash -c 'sudo apt update && sudo apt install --only-upgrade -y anycubicslicernext'

The bash -c '...' matters. Without it, the && is interpreted by your host shell and only the first half runs in the container.

Tearing it down

If you want to undo the whole thing, the cleanup is clean:

rm ~/.local/share/applications/*nycubic*.desktop
distrobox rm -f anycubic-slicer
podman rmi docker.io/library/ubuntu:24.04   # optional, frees the base image

No host packages were touched beyond distrobox and podman themselves. Nothing in /etc, no systemd units, and the Anycubic apt repo lives entirely inside the container.

Conclusion

The whole exercise is one missing locale-gen away from working, but the failure mode hides itself: the icon does nothing, the binary segfaults silently, and a quick look at locale shows LANG=en_US.UTF-8 so you assume the recipe’s default covers you. If your host has any non-English LC_* variable (KDE makes that the default for anyone outside the US setting their region), you’ll trip on it anyway.

The bigger takeaway: any GUI app launched through distrobox-export with Terminal=false will eat its own stderr on crash. When that happens, the diagnostic move is always distrobox enter <name> -- <binary> directly. The error is usually right there.