Here’s how to run LM Studio from the AppImage you downloaded:

🧭 1. Navigate to the download location

Open a terminal in the folder where the file is located, for example:

cd ~/Downloads

⚙️ 2. Make it executable

You need to give the AppImage permission to run:

chmod +x LM-Studio-0.3.30-1-x64.AppImage

🚀 3. Run LM Studio

Now you can start it directly:

./LM-Studio-0.3.30-1-x64.AppImage

If you prefer, you can also double-click it in your file manager after step 2.

🧩 (Optional) 4. Create a launcher / menu entry

If you want it to appear in your applications menu:

./LM-Studio-0.3.30-1-x64.AppImage --install

or manually move it to a system-wide location:

sudo mv LM-Studio-0.3.30-1-x64.AppImage /usr/local/bin/lmstudio

Then you can run it with:

lmstudio

🧠 Notes

• AppImages are self-contained — no installation required.
• If it doesn’t start, make sure fuse is installed:
  bash
sudo apt install fuse
• For Ubuntu 22+ or Debian Bookworm+, you may need:
  bash
sudo apt install libfuse2

Would you like me to show how to create a desktop icon for it (so it appears in your launcher menu like normal apps)?

Exactly — that’s it. 😄

Because you moved the file before making it executable, it now sits in /usr/local/bin without the proper permissions.
Here’s how to fix it:

🔧 Fix permissions

sudo chmod +x /usr/local/bin/lmstudio

🚀 Then launch it

lmstudio

If it still complains, check the file’s ownership and permissions:

ls -l /usr/local/bin/lmstudio

You should see something like:

-rwxr-xr-x 1 root root 300M Oct 14 17:12 /usr/local/bin/lmstudio

The key part is the x (executable) flag for users.

Once that’s set, LM Studio should launch normally.

Yep—that error is from Chromium/Electron’s sandbox inside the AppImage. Two ways to fix it:

Quick (less secure)

Run without the setuid sandbox:

lmstudio --no-sandbox
# or
lmstudio --disable-setuid-sandbox

If that works, you’re good—but this lowers security.

Better (recommended): enable user namespaces

This lets Chromium use the userns sandbox (no setuid helper needed).

1) Check current setting:

sysctl kernel.unprivileged_userns_clone

2) If it prints = 0, enable it now and persist it:

echo 'kernel.unprivileged_userns_clone=1' | sudo tee /etc/sysctl.d/00-local-userns.conf
sudo sysctl --system

3) Launch normally:

lmstudio

Why this happens

The AppImage mounts itself under /tmp/.mount_* and expects a chrome-sandbox binary with setuid root perms inside the image—something you can’t fix at runtime. Enabling user namespaces lets Chromium sandbox without that setuid helper.

Yep—user namespaces are on, but Electron is still trying to use the setuid sandbox packaged inside the AppImage (which can’t be set 4755 on a FUSE mount). Easiest fixes:

Option A — Run without the setuid sandbox (quickest)

lmstudio --disable-setuid-sandbox
# or
lmstudio --no-sandbox

If that works, you can make it stick by wrapping it:

echo '#!/usr/bin/env bash
exec /usr/local/bin/lmstudio --disable-setuid-sandbox "$@"' | sudo tee /usr/local/bin/lmstudio-safe >/dev/null
sudo chmod +x /usr/local/bin/lmstudio-safe
lmstudio-safe

Option B — Extract the AppImage and run from there (avoids the suid path)

cd ~/Downloads
./LM-Studio-0.3.30-1-x64.AppImage --appimage-extract
cd squashfs-root
./AppRun --disable-setuid-sandbox

(You can create a launcher pointing to ~/Downloads/squashfs-root/AppRun --disable-setuid-sandbox.)

Option C — Install the .deb instead of AppImage (cleanest long-term)

The Debian/Ubuntu package installs Chromium/Electron pieces with proper sandboxing:

# example; adjust filename if different
sudo apt install ./lm-studio_*_amd64.deb

Then launch from your menu or:

lm-studio

Why this happens: AppImages mount via FUSE under /tmp/.mount_*. The chrome-sandbox binary inside can’t have real setuid 4755 on a FUSE mount, so Electron aborts unless you force the non-suid sandbox (--disable-setuid-sandbox) or use a package format that can set it correctly (the .deb).

Got it — let’s get your system booting again.
If it’s halting at “Gnome Display Manager (gdm)”, it usually means your graphical environment (GNOME or GPU drivers) failed to start, not that the system is totally broken.

🧭 Step 1. Switch to a text console

Press Ctrl + Alt + F3 (or F2/F4 — any F-key between F2–F6).
You should get a black screen with a login prompt.

Log in with your username and password.

🧩 Step 2. Check GPU driver status

Run:

sudo systemctl status gdm

and:

nvidia-smi

If nvidia-smi fails, your NVIDIA driver probably crashed or got mismatched during the sandbox run.

⚙️ Step 3. Try restarting the display manager cleanly

sudo systemctl restart gdm

If it returns errors, note them — they’ll tell us whether it’s GNOME, Xorg, or Wayland failing.

🩺 Step 4. Reconfigure or reinstall graphics drivers (if needed)

If you see messages like “failed to start display server” or “no screens found,” do this:

sudo apt reinstall nvidia-driver-* -y
sudo reboot

Or, if you use open-source drivers:

sudo apt reinstall xserver-xorg-video-nouveau -y
sudo reboot

🧰 Step 5. If still stuck, temporarily boot into text mode

You can disable the GUI startup to get back in:

sudo systemctl set-default multi-user.target
sudo reboot

This boots you to a command-line login so you can repair things safely.
Later, re-enable the GUI with:

sudo systemctl set-default graphical.target

Once you’re back at a terminal, I can help you check logs:

journalctl -xe | tail -50

and

cat ~/.local/share/xorg/Xorg.0.log | tail -50

Send me those outputs — they’ll pinpoint exactly what froze GNOME.

Would you like me to walk you through a safe driver reset sequence from text mode?

Short answer: it’s almost certainly not the AppImage sandbox.
A SIGTRAP/core dump at gdm usually points to GNOME Shell ↔ GPU/driver/Wayland trouble (NVIDIA most commonly), not LM Studio. Your sysctl change (userns) also wouldn’t nuke GNOME.

Let’s get you back in quickly.

Quick recovery path (from a text console)

1) Switch to TTY
Press Ctrl+Alt+F3, log in.

2) Grab quick signals

sudo coredumpctl info gdm | sed -n '1,80p'
journalctl -b -u gdm --no-pager | tail -200
journalctl -b | egrep -i "nvrm|nvidia|mutter|gnome-shell|wayland" | tail -200
nvidia-smi || true

(If nvidia-smi fails, drivers are your prime suspect.)

3) Force Xorg (bypass Wayland for now)

sudo sed -i 's/^#\?WaylandEnable=.*/WaylandEnable=false/' /etc/gdm3/custom.conf
# ensure the line exists; if not, add it:
grep -q '^WaylandEnable=' /etc/gdm3/custom.conf || echo 'WaylandEnable=false' | sudo tee -a /etc/gdm3/custom.conf
sudo systemctl restart gdm

Now try Ctrl+Alt+F1 (or F7) to see if the login screen appears.
If it does, log in; we can fine-tune later.

4) If GNOME still crashes, disable user extensions/caches (per-user)

mv ~/.local/share/gnome-shell/extensions ~/.local/share/gnome-shell/extensions.bak 2>/dev/null || true
rm -rf ~/.cache/gnome-shell/* 2>/dev/null || true
sudo systemctl restart gdm

5) If still stuck, (re)install core GNOME bits

sudo apt-get update
sudo apt-get --reinstall install gdm3 gnome-shell
sudo systemctl restart gdm

6) If the problem is NVIDIA (very common)
– Reinstall your driver (replace 550 with your series; check what you had installed):

apt-cache policy | grep -i nvidia-driver | head
sudo apt-get --reinstall install nvidia-driver-550 libnvidia-egl-wayland1
sudo systemctl restart gdm

• If DKMS/module issues appear:

sudo dkms status
lsmod | grep -i nvidia
sudo update-initramfs -u
sudo reboot

7) Last resort to get a desktop up: temporarily try LightDM

sudo apt-get install lightdm
sudo dpkg-reconfigure lightdm   # choose lightdm
sudo systemctl restart lightdm

If LightDM works, we know it’s specifically a gdm/Wayland path (often NVIDIA + Wayland).

Why this isn’t the AppImage

• The AppImage runs as your user, mounted via FUSE under /tmp/.mount_*.
• It can’t alter system libraries or display manager configs.
• SIGTRAP at gdm is typically GNOME Shell asserting/crashing due to driver/Wayland glitches (NVIDIA is the usual culprit), or a bad extension.

What to send me

Paste the outputs of:

journalctl -b -u gdm --no-pager | tail -200
journalctl -b | egrep -i "nvrm|nvidia|mutter|gnome-shell|wayland" | tail -200
nvidia-smi

and whether step 3 (WaylandEnable=false) brought the login screen back.
From there, I’ll zero in on a precise fix (Wayland vs Xorg, exact NVIDIA package, or extension cleanup).

That symptom—Files (Nautilus) disappearing from the menu and drive icons opening Disks (gnome-disks) instead of mounting normally—fits with a partial GNOME crash or missing extension, not the LM Studio sandbox itself.
Here’s what it likely means and how to fix it cleanly:

🔍 What was happening before the reboot

1. Nautilus crashed or failed to load
   – The “Files” icon vanishing means the nautilus process stopped, possibly due to a GNOME Shell extension error or GPU hiccup.
2. Gnome-disks became default for volumes
   – When the “Files” (Nautilus) handler deregisters, GNOME falls back to gnome-disks to open devices.
3. Underlying trigger
   – If NVIDIA/Wayland crashed, many GNOME extensions restart in fallback mode, producing exactly this behavior.

🧩 Recovery plan (from TTY as before)

Once you log into a console (Ctrl+Alt+F3):

1. Reinstall core GNOME components
   bash
sudo apt-get update
sudo apt-get --reinstall install nautilus gnome-shell gdm3 gnome-session gnome-control-center
   This repairs any missing handlers or corrupted MIME settings.

2. Reset Nautilus defaults
   bash
nautilus --quit 2>/dev/null || true
gio mime inode/directory org.gnome.Nautilus.desktop
xdg-mime default org.gnome.Nautilus.desktop inode/directory

3. Rebuild the desktop schema cache
   bash
sudo glib-compile-schemas /usr/share/glib-2.0/schemas/

4. Restart GNOME Display Manager
   bash
sudo systemctl restart gdm

🧠 After you regain the desktop

If you get back in and things look off:

gnome-extensions disable $(gnome-extensions list)

Then log out/in; if stable, re-enable one by one:

gnome-extensions enable <name>

💡 Summary

• LM-Studio’s sandbox didn’t cause the issue; it just happened to crash around the same time your GNOME session was already unstable.
• The real culprits are GNOME Shell + NVIDIA (Wayland) or a corrupted MIME/extension state.
• Reinstalling and resetting Nautilus and GNOME shell almost always fixes the missing “Files” icon and drive behavior.

If you’re back at a console now, I can give you the exact 4-line command sequence to get GNOME back up without rebooting.
Would you like that next?

Okay — let’s slow down and get you back to a working desktop systematically.
If none of that worked, we’re likely dealing with a GNOME-Shell crash loop or a broken NVIDIA ↔ Wayland/Xorg hand-off.
We’ll bypass GNOME entirely first to verify that your base system still runs fine.

🧭 1. Boot to text mode

At the TTY (press Ctrl + Alt + F3 and log in):

sudo systemctl set-default multi-user.target
sudo reboot

That ensures you come up in command-line mode only.
After reboot, log in again (no graphical login this time).

🧩 2. Confirm system and drivers

Run:

lspci -nnk | grep -A3 -E "VGA|3D"
nvidia-smi

• If nvidia-smi fails or hangs, the driver is the root of the crash.
  Reinstall it cleanly:
  bash
sudo apt purge 'nvidia-*'
sudo apt install nvidia-driver-550 libnvidia-egl-wayland1
sudo reboot
  (replace 550 with whatever version you were using if different)

If nvidia-smi works fine, GNOME itself is broken — go to step 3.

🧰 3. Test an alternate desktop (quick sanity check)

Install a lightweight desktop to confirm Xorg/Wayland still works:

sudo apt install lightdm xfce4
sudo systemctl enable lightdm
sudo reboot

• If XFCE loads, your GPU stack is good and only GNOME is damaged.
• If even XFCE won’t load, the NVIDIA driver is still at fault.

🧱 4. If XFCE works → rebuild GNOME cleanly

From XFCE or the TTY:

sudo apt purge gdm3 gnome-shell gnome-session nautilus --autoremove -y
sudo apt install gdm3 gnome-shell gnome-session nautilus -y
sudo systemctl enable gdm
sudo systemctl set-default graphical.target
sudo reboot

That forces GNOME to reinstall from scratch with fresh configs.

🧠 5. Optional: wipe GNOME’s user config

If it still loops:

mv ~/.config/dconf/user ~/.config/dconf/user.bak
mv ~/.local/share/gnome-shell ~/.local/share/gnome-shell.bak

and restart gdm:

sudo systemctl restart gdm

Why this helps

• Moving to multi-user.target guarantees you can boot safely.
• Installing XFCE + LightDM isolates whether it’s the GPU stack or GNOME.
• Purging/reinstalling GNOME resets every schema, MIME handler, and extension that may have been corrupted when the display session crashed.

Once you’re back at a terminal after step 1, tell me:
– Does nvidia-smi succeed or fail?
– Would you prefer to try XFCE next, or go straight into a GNOME reinstall?

I’ll give you the exact next 3-line command sequence for whichever path you choose.

Perfect — that’s actually good news.
That means:

✅ The system boots cleanly.
✅ Nothing’s catastrophically broken.
❌ The graphical target just isn’t active yet.
📏 Tiny text = high-DPI console font (easy fix).

Let’s bring the desktop up step-by-step.

🧭 1. Make sure the graphical target is enabled

sudo systemctl set-default graphical.target
sudo systemctl enable lightdm
sudo systemctl start lightdm

That should launch XFCE right away (LightDM login screen → choose Xfce Session).

If you see a login box — log in and you’re in business.
If it still drops back to console, run:

sudo systemctl status lightdm

and tell me the last few lines — that’ll show if Xorg or the driver crashed.

🔍 2. Fix the “tiny text” console font (for comfort while testing)

sudo dpkg-reconfigure console-setup

• Choose UTF-8,
• then a larger font (e.g. TerminusBold 16×32).
  When done:

sudo setupcon

Your TTY text should now be readable.

🧩 3. Once XFCE starts successfully

We’ll know your GPU stack and Xorg are fine — then we can safely rebuild GNOME.

Would you like me to give you the quick commands to completely reset GNOME and switch LightDM → GDM once XFCE is confirmed working?

Alright — that “password not valid” message in LightDM (or any login manager) can be misleading.
It doesn’t necessarily mean your password is wrong — it usually means PAM, home directory permissions, or Xauthority failed.
Let’s diagnose and fix it cleanly.

🧭 Step 1 – Verify your actual password works

You’re already in a text console (TTY).
At the prompt, type:

whoami

Confirm it shows darren.
Then test:

su - darren

If it lets you in, your password is correct — the issue is graphical authentication.

🧩 Step 2 – Check ownership and permissions of your home

ls -ld /home/darren

Expected:

drwx------  ... darren darren /home/darren

If it shows root root or anything else:

sudo chown -R darren:darren /home/darren

⚙️ Step 3 – Reset LightDM session files

sudo rm -f /var/lib/lightdm/.Xauthority
sudo rm -f /home/darren/.Xauthority
sudo rm -rf /home/darren/.cache/sessions/*
sudo systemctl restart lightdm

Try logging in again.

🧰 Step 4 – If still failing, check PAM / auth logs

sudo tail -50 /var/log/auth.log

Look for lines like:

pam_unix(lightdm:auth): authentication failure

or

unable to open /home/darren/.Xauthority

If you see .Xauthority or “Permission denied,” the chown fix above solves it.

🧼 Step 5 – Reset password if unsure (won’t hurt anything)

sudo passwd darren

Enter a new password twice, then:

sudo systemctl restart lightdm

Once you get in, XFCE should load and stay stable.
After that we can safely reinstall GNOME.

Would you check step 2 (ls -ld /home/darren) and tell me what the ownership line shows?
That one line will tell me exactly why LightDM is rejecting the login.

Okay — that gives us a very specific symptom:
LightDM is starting, but the greeter (login box) is either frozen, missing its input field, or can’t connect to the display backend.

That almost always means the greeter theme crashed or GPU driver/X authority isn’t allowing input.

Let’s fix it step by step from a TTY again:

🧭 1. Switch to console (Ctrl + Alt + F3)

Log in as darren.

🧹 2. Reset LightDM to a simple greeter

sudo apt install lightdm-gtk-greeter lightdm-gtk-greeter-settings -y
sudo dpkg-reconfigure lightdm

When asked, choose lightdm as the default display manager.

Then force the GTK greeter:

sudo sed -i 's|^#greeter-session=.*|greeter-session=lightdm-gtk-greeter|' /etc/lightdm/lightdm.conf
sudo sed -i 's|^#user-session=.*|user-session=xfce|' /etc/lightdm/lightdm.conf

Restart LightDM:

sudo systemctl restart lightdm

You should now get a plain gray login window with clear text boxes.

🧩 3. If you still can’t type, verify keyboard input devices

Back in the TTY:

grep -i "input" /var/log/Xorg.0.log | tail -20

If you see lines like “no input devices found” or “could not load libinput”:

sudo apt install xserver-xorg-input-all -y
sudo systemctl restart lightdm

🧠 4. If LightDM is still glitchy

We can temporarily use startx to bring XFCE up manually:

startx

If that launches your desktop, it confirms that LightDM is the only broken layer.

Once we get you back into XFCE this way, we’ll cleanly reinstall GNOME (optional) and disable the broken greeter theme permanently.

Can you tell me what greeter you see right now — plain gray with a clock, or some themed background? That will tell me whether it’s the GTK one or the old WebKit greeter causing the blank box.

Excellent — you’re in and stable. 🥳
That means: ✅ drivers and Xorg stack are working, ✅ LightDM/XFCE proved the hardware’s fine.
So now we can cleanly reinstall GNOME and make it the default again.

🧩 1 – Remove XFCE / LightDM extras (optional)

You can keep them as a backup if you like, but if you want GNOME only:

sudo apt purge xfce4 lightdm lightdm-gtk-greeter --autoremove -y

⚙️ 2 – Reinstall core GNOME packages

sudo apt update
sudo apt install --reinstall gdm3 gnome-shell gnome-session gnome-control-center nautilus -y

When prompted for the display manager, choose gdm3.

🔁 3 – Set GDM & graphical target as defaults

sudo systemctl enable gdm
sudo systemctl set-default graphical.target

🚀 4 – Reboot into GNOME

sudo reboot

After reboot you should see the GNOME GDM login screen again.
Log in normally and confirm that “Files” (Nautilus) and your top bar are back.

💡 If the login screen appears but loops/crashes again

Just switch back to TTY (Ctrl + Alt + F3) and run:

sudo apt install gnome-session gnome-shell gdm3 nautilus --reinstall -y
mv ~/.config/dconf/user ~/.config/dconf/user.bak 2>/dev/null || true
sudo systemctl restart gdm

That wipes only user-level GNOME settings.

Once you’re back inside GNOME, we’ll clean up any leftover XFCE configs and re-enable your normal startup services.
Would you like me to include that cleanup step after you confirm GNOME starts successfully?

That message is because the service is gdm3, not gdm on Ubuntu/Debian. Let’s flip you back to GNOME cleanly.

1) Install/repair GNOME + GDM3

sudo apt update
sudo apt install --reinstall gdm3 gnome-shell gnome-session gnome-control-center nautilus -y

2) Make GDM3 the display manager

sudo dpkg-reconfigure gdm3    # pick "gdm3" when prompted

3) Disable LightDM and enable/start GDM3

sudo systemctl disable lightdm || true
sudo systemctl stop lightdm || true
sudo systemctl enable gdm3
sudo systemctl start gdm3

4) Ensure the GUI target is default, then reboot

sudo systemctl set-default graphical.target
sudo reboot

If after reboot the GDM login appears but crashes/loops, force Xorg (helps with NVIDIA):

sudo sed -i 's/^#\?WaylandEnable=.*/WaylandEnable=false/' /etc/gdm3/custom.conf
sudo systemctl restart gdm3

You can check status anytime with:

systemctl status gdm3

Perfect — those messages are just saying GDM3 isn’t running yet, so it couldn’t “reload.” That’s normal at this point; it’s not an error.
Let’s finalize GNOME and start it manually:

✅ 1. Stop LightDM if still active

sudo systemctl stop lightdm
sudo systemctl disable lightdm

⚙️ 2. Start GDM3 manually

sudo systemctl start gdm3

If the GDM login screen appears — great.
If not, check what it says:

systemctl status gdm3 --no-pager

🔁 3. Ensure it autostarts on boot

sudo systemctl enable gdm3
sudo systemctl set-default graphical.target

🧩 4. Force Xorg if NVIDIA + Wayland is the culprit

If it still fails or loops:

sudo sed -i 's/^#\?WaylandEnable=.*/WaylandEnable=false/' /etc/gdm3/custom.conf
sudo systemctl restart gdm3

🧠 Why you’re seeing “service not active”

The GDM daemon wasn’t started yet (LightDM was still the one running). Once LightDM is stopped and GDM3 started manually, those reload messages disappear.

After running the start gdm3 command, tell me whether:
– You get a GNOME login screen,
– It stays on console with an error,
– Or it crashes back to text mode.

That single detail will show if GNOME is fixed or if the NVIDIA stack still needs a nudge.

That’s actually a really good sign — it means GNOME is running again, just in its factory-default fallback theme.
Right now you’re seeing:

• the Adwaita (plain gray/blue) look,
• missing Ubuntu theming (no orange/purple accents, Yaru icons, etc.),
• possibly the default GNOME session, not the “Ubuntu” session that ships with Ubuntu’s extensions.

So the core desktop is healthy — it just needs the Ubuntu skin and extensions re-enabled.

🧩 Step-by-step: Restore the full Ubuntu GNOME look

1️⃣ Install Ubuntu theming & session packages

sudo apt install --reinstall ubuntu-desktop yaru-theme-gnome-shell yaru-theme-gtk yaru-theme-icon yaru-theme-sound -y

2️⃣ Re-enable Ubuntu’s GNOME session

sudo apt install gnome-shell-extension-ubuntu-dock gnome-shell-extension-appindicator -y

3️⃣ Log out → On the login screen

At the bottom-right gear icon (⚙️), choose “Ubuntu” (not “GNOME”) before entering your password.
That loads Ubuntu’s pre-tuned shell layout and extensions.

4️⃣ (Optional) Re-enable Wayland (if you want)

If you disabled it earlier:

sudo sed -i 's/^WaylandEnable=false/#WaylandEnable=false/' /etc/gdm3/custom.conf

Then restart GDM:

sudo systemctl restart gdm3

💡 Optional cleanup

You can also remove XFCE bits if they’re lingering:

sudo apt purge xfce4 lightdm* --autoremove -y

Once you log back in under “Ubuntu (Default)”, you should have:
– the orange/purple GNOME login screen,
– top bar with Activities + Clock + System Menu,
– Dock on the left side,
– “Files” (Nautilus) and “Software” apps themed correctly.

Would you like me to include the quick command to restore your original GNOME extensions list (like Desktop Icons, Weather, etc.) too?

Excellent — that’s exactly what I wanted to hear. 😄
You’re back in GNOME, stable, and the system survived the sandbox chaos.

Good call on taking a break — you’ve just done a full-on desktop resurrection, driver verification, and session rebuild in one evening.

When you’re ready later, we can:
– snapshot or clone your working setup (so you never have to go through this again),
– clean up leftover XFCE or lightdm configs,
– and safely sandbox or containerize things like LM-Studio so they can’t touch the display stack next time.

Rest easy, Darren — system integrity restored. 🌀
Want me to jot down a short “post-recovery maintenance checklist” for when you come back tomorrow?

Good question — and honestly, LM Studio itself probably didn’t “break” the system, but it did light the fuse on a chain of weak links that were already there.

Here’s what almost certainly happened, in plain terms:

🧩 1. LM Studio uses Electron (Chromium)

AppImages run in a self-mounted FUSE container under /tmp/.mount_*.
Electron tries to launch a sandboxed Chromium process using:
– the setuid chrome-sandbox binary (which fails in FUSE), and
– OpenGL acceleration (through your NVIDIA driver).

That combination—FUSE mount + GPU sandbox—crashes a lot on Ubuntu with NVIDIA.

⚙️ 2. When it failed, it likely spiked or crashed the compositor (Mutter)

GNOME’s shell renderer (mutter) uses the same GPU context as Electron apps.
So when LM Studio’s Electron core crashed with a sandbox fault, Mutter’s OpenGL context also went unstable.

That’s what caused:
– the “Files” icon disappearing,
– disks opening stats windows instead of Nautilus, and
– GNOME losing its theme (partial crash recovery).

🔄 3. Then, when you rebooted

The corrupted session files + half-dead GDM/Wayland cache tried to re-initialize NVIDIA’s driver.
Since GDM runs before you log in, a bad state there can trigger:

gdm3[PID]: core dumped signal = trap

…and stop the entire graphical boot sequence cold.

🔥 So LM Studio didn’t directly wreck GNOME

It just hit a brittle edge case:
– NVIDIA + Wayland + AppImage sandbox = 🧨

Ubuntu’s GNOME theme & session got trashed in the fallout.

✅ Now that you’re stable again

Later, when you feel like it, I’d suggest:
1. Run LM Studio with --disable-gpu-sandbox --disable-setuid-sandbox
bash
lmstudio --disable-gpu-sandbox --disable-setuid-sandbox
That tells Electron to skip all those fragile sandbox calls.
2. (Optional) Extract the AppImage instead of executing it directly:
bash
./LM-Studio-0.3.30-1-x64.AppImage --appimage-extract
cd squashfs-root
./AppRun --disable-gpu-sandbox
This avoids FUSE altogether.
3. Or use the .deb version from LM Studio’s site, which integrates safely with the system’s Chromium sandbox and NVIDIA stack.

You actually handled this recovery like a pro.
When you’re ready to clone the drive, we’ll make a clean image so you can always revert to this exact working state.

Want me to prep the clone guide tomorrow using rsync + grub (simple manual method) or timeshift + borg (snapshot-based)?

Totally understandable — that “tiny-text console” situation makes recovery feel ten times harder.
It happens because, without GNOME or the NVIDIA driver loaded, you’re stuck at the kernel’s default framebuffer resolution (often the monitor’s native 4K or 2K). The TTY font is only a few pixels high in that mode.

Here’s how you can make sure next time the console is actually readable before doing any surgery:

🧩 1. Permanent larger TTY font

sudo dpkg-reconfigure console-setup

• Choose UTF-8 → Guess optimal character set
• Then pick a bigger font, e.g. TerminusBold 16×32
• Finish, then apply it immediately:

sudo setupcon

🧩 2. Force smaller console resolution (optional)

If you’d rather keep the same font but reduce framebuffer resolution:

sudo nano /etc/default/grub

Find the line:

GRUB_GFXMODE=auto

Change it to something like:

GRUB_GFXMODE=1280x720
GRUB_GFXPAYLOAD_LINUX=keep

Then run:

sudo update-grub
sudo reboot

That locks the TTY to 720p, giving nice chunky text regardless of your monitor’s native DPI.

🧩 3. Quick on-the-fly test (no reboot)

When you’re at a console, you can instantly load a bigger font:

sudo setfont /usr/share/consolefonts/Lat2-Terminus16.psf.gz

So next time you’re rescuing the system, you’ll actually be able to see what you’re typing instead of squinting. 😅
When you’re ready tomorrow, we’ll do that clone guide so you have a safety net before experimenting again.

Gotcha—that makes sense now. And yay for being back in GNOME. 🙂

Here’s a straight, no-nonsense plan to try that “Enoch (Mistral-65B) 4-bit” safely on your box without detonating the desktop again:

1) Reality check on 65B @ “~7 GB VRAM”

• 7 GB VRAM ≠ 7 GB total. It just means you can offload some layers to GPU; you’ll still need ~32–64 GB system RAM for a 65B Q4 model (more if context is large).
• Expect slow tokens/s on CPU-heavy paths (often ~0.5–2 tok/s) unless you’ve got a beefy CPU and fast RAM.
• If stability > speed, run mostly on CPU first; add GPU offload later.

2) Run it in a safety bubble (so it can’t trash GNOME)

Pick one (I recommend A or B):

A) Firejail (quick sandbox)

sudo apt install firejail
firejail --private --net=none /usr/local/bin/lmstudio --disable-gpu-sandbox --disable-setuid-sandbox

• --private = ephemeral home; --net=none = no network (good for testing).
• Mount a read-only folder for models if needed: --private=~/LMtest and place a copy there.

B) New unprivileged user + no Wayland

sudo adduser lmuser
sudo usermod -aG video lmuser
# Switch TTY, log in as lmuser, and start on Xorg only:
sudo sed -i 's/^#\?WaylandEnable=.*/WaylandEnable=false/' /etc/gdm3/custom.conf
sudo systemctl restart gdm3

Run LM Studio from lmuser. If it crashes, your main profile stays clean.

C) Podman/Rootless container (cleanest)

sudo apt install podman
podman run --rm -it --security-opt=no-new-privileges \
  --device /dev/dri \
  -v /home/darren/Models:/models:ro \
  -v /home/darren/LMcache:/cache \
  docker.io/ghcr.io/ggerganov/llama.cpp:full

Then run the model inside. (Containerized = minimal host risk.)

3) If you still want LM Studio UI, use the safer flags

Electron + AppImage + NVIDIA is the fragile combo. Launch like this:

lmstudio --disable-gpu-sandbox --disable-setuid-sandbox

If it complains, try the extracted AppImage (avoids FUSE):

./LM-Studio-0.3.30-1-x64.AppImage --appimage-extract
cd squashfs-root
./AppRun --disable-gpu-sandbox --disable-setuid-sandbox

4) Importing a 65B GGUF into LM Studio

• Put the .gguf under something like ~/Models/Enoch65B/.
• In LM Studio: Models → Local Models → Add local GGUF and point to it.
• Start with small context (2048) and no GPU offload to verify it runs.
• Then gradually increase:
• Context: 4096 if RAM allows.
• GPU offload (n-gpu-layers): start ~10–20 for 7 GB VRAM and watch nvidia-smi.
• Disable “Flash-Attention/quant-attn” if it crashes.

5) CLI fallback (llama.cpp)

If LM Studio is flaky, llama.cpp is rock solid:

# Example
./main -m /models/enoch65b.Q4_K_M.gguf -n 256 -c 2048 -ngl 20 -t 12 --temp 0.7 --repeat_penalty 1.1 --color

Tune:
– -c context; -ngl GPU layers (watch VRAM); -t CPU threads.

6) Health checks before trusting it

• Verify integrity: check SHA256 of the download; avoid random mirrors.
• No network run: first passes offline (--net=none in firejail or disable Wi-Fi) to ensure it isn’t phoning home.
• Prompt tests: run a few of your known-truth Q&A from your Quen corpus to see if the “infused knowledge” is real vs. hallucinated.
• Bias/data provenance: anything “infused” will reflect that source’s lens. Keep it sandboxed from your main RAG until you’re confident.

7) If performance is painful

• Try a MoE or smaller dense model tuned for CPU (e.g., 8×7B MoE, or a strong 7–14B instruct) while you evaluate the content quality.
• Or run the 65B server-style on CPU and offload a handful of layers to the GPU (steady if slower, but stable).

If you want, tomorrow we can:
– set up a clean test user + firejail profile for LM Studio,
– write a one-liner wrapper that always launches with safe flags, and
– do a Timeshift/Borg snapshot before you experiment so rollback is trivial.

Nice catch on testing this, btw. Let’s poke it—but with gloves on.