🧑 You
Check the system logs and find out what happened: I came to sit down at this PC and it looks like it was logged out entirely, which is weird because it has auto login. So it didn't reboot or maybe it did reboot but logged me out. Or possible wayland crash?
▶ Tool: read_file [path='~/Personal/skills/skill_index.md']
▶ Tool: run_bash [command='uptime; echo '---'; who; echo '---'; last -x reboo]…
▶ Tool: run_bash [command='journalctl --list-boots | tail -10']
▶ Tool: run_bash [command='loginctl list-sessions; echo '---'; loginctl list-]…
The skill index doesn't have a specific skill for checking system logs. The user wants me to investigate system logs to …
🤖 Assistant
I checked the skill index — no dedicated log-analysis skill there, so I'll dig into the system logs directly. Let me gather the basics first.
▶ Tool: run_bash [command='loginctl show-session 65 -p Id -p User -p Type -p ]…
▶ Tool: run_bash [command='journalctl -b 0 --no-pager -t systemd-logind | tai]…
▶ Tool: run_bash [command='journalctl -b 0 --no-pager | grep -iE 'gdm|gnome-s]…
Interesting. The system has been up for 3 days, 17 hours. So it has NOT rebooted since August 6. The current boot (boot …
🤖 Assistant
The machine has been up 3 days 17 hours — so it did not reboot. But there's an active session for beholder at tty2 right now. Let me look closer at session history and recent events.
▶ Tool: run_bash [command='journalctl -b 0 --no-pager --since "2026-08-10 11:]…
▶ Tool: run_bash [command='journalctl -b 0 --no-pager -t gnome-shell | tail -]…
Now I have a much clearer picture:
🤖 Assistant
Now I can see the key events. Let me dig into exactly what happened right around the session logout at 11:46:24 today — the machine resumed from suspend at 11:43:57, and the session died ~2.5 minutes later.
▶ Tool: run_bash [command='journalctl -b 0 --no-pager --since "2026-08-10 11:]…
Now I need to find what happened between 11:43:57 (resume from suspend) and 11:46:24 (session logged out). The gnome-she…
🤖 Assistant
The system resumed from an overnight suspend at 11:43:57, then the session logged out at 11:46:24. Let me zoom into the two-minute window before the logout to find what killed it.
▶ Tool: run_bash [command='journalctl -b 0 --no-pager --since "2026-08-10 11:]…
▶ Tool: run_bash [command='journalctl -b 0 --no-pager | grep -iE 'segfault|co]…
There's a LOT of drmModeAtomicCommit errors after resume. gnome-shell[2358] is the user session's shell (PID 2358, from …
🤖 Assistant
The NVIDIA/KMS errors are flooding after resume. Now let me see exactly what happened in the seconds right before the logout, and check for any crash signals.
▶ Tool: run_bash [command='ls -la /var/crash/ 2>/dev/null; echo '---'; file /]…
▶ Tool: run_bash [command='journalctl -b 0 --no-pager --since "2026-08-10 11:]…
Found it! There's a core dump:
🤖 Assistant
Found it! org.gnome.Shell@ubuntu.service: Failed with result 'core-dump' at 11:46:22, and there's a crash report at /var/crash/_usr_bin_gnome-shell.1000.crash. Let me examine it.
▶ Tool: run_bash [command='grep -m1 -E '^(ProblemType|Signal|ExecutablePath|I]…
▶ Tool: run_bash [command='grep -A6 '^StacktraceTop' /var/crash/_usr_bin_gnom]…
▶ Tool: run_bash [command='journalctl --no-pager | grep -E 'core-dump|org.gno]…
▶ Tool: run_bash [command='nvidia-smi --query-gpu=driver_version,name --forma]…
Now I have the full picture:
🤖 Assistant
Confirmed the smoking gun. Let me pull details from the crash report and check whether this has happened before on earlier resumes.
▶ Tool: run_bash [command='journalctl -b 0 --no-pager | grep -c 'drmModeAtomi]…
▶ Tool: run_bash [command='journalctl -b 0 --no-pager --since "2026-08-07 15:]…
Now I have a complete picture:
🤖 Assistant
I have the full picture now. Let me verify one more detail — whether the KMS errors also happened on earlier resumes in this boot, which would confirm the NVIDIA resume issue.
Interesting! The drmModeAtomicCommit errors happened on EVERY resume in this boot:
🤖 Assistant
Found it. Here's the full story:
GNOME Shell (the Wayland compositor) segfaulted at 11:46:22 AM today, about 2.5 minutes after the machine woke from an overnight suspend. That killed your whole session and dumped you at the GDM login screen. Auto-login doesn't kick in after a session crash (only at boot), so you were left staring at a login prompt.
|
Time |
Event |
|
Aug 9, 22:03:16 |
System suspended (overnight) |
|
Aug 10, 11:43:57 |
Resumed from suspend |
|
11:44:00–11:46:20 |
NVIDIA KMS errors flood: hundreds of Page flip failed: drmModeAtomicCommit: Invalid argument from gnome-shell; kernel warned nv_drm_handle_hotplug_event [nvidia_drm] hogged CPU |
|
11:46:21 |
Apps report "Lost connection to Wayland compositor" / "The Wayland connection broke. Did the Wayland compositor die?" |
|
11:46:22 |
systemd[2115]: org.gnome.Shell@ubuntu.service: Main process exited, code=dumped, status=11/SEGV → gnome-shell segfault |
|
11:46:24 |
GDM spawns greeter (login screen). No reboot |
|
12:10:38 |
You logged back in — that's your current session (65) |
Want me to check what NVIDIA/mutter versions are available to update, or look at whether this has a matching upstream bug report?
🧑 You
Yeah check if this is a reported issue and anyone has a fix for it yet. I think the drivers are fully up to date though.
▶ Tool: run_bash [command='. /etc/os-release && echo "$PRETTY_NAME"; echo '--]…
The user wants me to check if this is a reported issue (GNOME Shell segfault after NVIDIA suspend/resume with drmModeAto…
🤖 Assistant
The drivers being up to date is useful — that points more at a compositor/driver interaction bug. Let me grab the exact package versions first, then search for matching reports.
▶ Tool: web_search [query='gnome-shell segfault after suspend resume nvidia drm]…
▶ Tool: web_search [query='mutter crash g_hash_table_remove suspend resume wayl]…
▶ Tool: web_search [query='GNOME Shell crash login screen after resume nvidia d]…
Ubuntu 26.04 LTS, GNOME Shell 50.1, mutter 50.1, NVIDIA driver 595.84 (open variant — nvidia-driver-595-open). The candi…
🤖 Assistant
Up to date confirmed — Ubuntu 26.04 LTS, GNOME Shell/mutter 50.1, NVIDIA 595.84 (open driver). Now let me search for matching reports.
▶ Tool: fetch_url [url='https://www.mail-archive.com/desktop-bugs@lists.ubuntu]…
▶ Tool: fetch_url [url='https://www.mail-archive.com/desktop-bugs@lists.ubuntu]…
▶ Tool: web_search [query='launchpad bug 2148655 GNOME Shell crash resume']
Very interesting results! Notably:
🤖 Assistant
Excellent — the second result is a smoking gun: Ubuntu bug 2156471 (June 2026) describes exactly your scenario — "GNOME Shell crashes immediately after resume... returned to a fresh login/session and all open desktop state is gone" — and the reply points to bug 2148655 which had a fix released recently. Let me pull those up.
▶ Tool: fetch_url [url='https://bugs.launchpad.net/bugs/2148655']
▶ Tool: run_bash [command='apt-get update -qq 2>&1 | tail -2; echo '=== avail]…
This is a perfect match! The Ubuntu bug 2156471 is essentially identical to the user's situation:
🤖 Assistant
This is a perfect match — same OS (Ubuntu 26.04), same GNOME Shell/mutter 50.1, same nvidia-driver-595-open, same crash-after-resume-to-login-screen symptom, same crash dump path. And crucially: it's a known bug (2148655) with a fix already released — but the crash reports show the fix isn't installed yet. Let me check the main bug page and see if the fix package is available on your machine.
▶ Tool: run_bash [command='grep -E 'mutter|gnome-shell|libmutter' /var/log/dp]…
▶ Tool: web_search [query='mail-archive 2156471 "GNOME Shell crashes after S3 r]…
Now I have the complete picture. Let me put it together:
🤖 Assistant
Found it — and there's a wrinkle to investigate. The fix is mutter 50.1-0ubuntu2.1 (released to -updates May 27, 2026), and you already have 50.1-0ubuntu2.2 — which is newer than the fixed version. So either the fix is already installed and your crash is a variant it didn't cover, or your mutter was updated after the crash. Let me check install dates and the package changelogs, plus the rest of that bug thread.
▶ Tool: run_bash [command='ls -la /var/log/dpkg.log* /var/log/apt/history.log]…
▶ Tool: run_bash [command='grep -aiE 'Package|version|mutter|gnome-shell' /va]…
Interesting — the dpkg.log grep returned nothing! That means /var/log/dpkg.log may have rotated, or grep failed. Let me …
🤖 Assistant
Key finding: your installed mutter 50.1-0ubuntu2.2 includes the 2.1 fix (the 2.2 SRU only adds a touchscreen fix on top). So the fix for bug 2148655 should already be on your machine — yet you crashed anyway with a different backtrace (g_hash_table_remove, not meta_logical_monitor_get_layout). Let me confirm when mutter was installed relative to the crash, and check the crash report's recorded package version.
▶ Tool: run_bash [command='zgrep -hE ' upgrade | install ' /var/log/dpkg.log*]…
▶ Tool: fetch_url [url='https://bugs.launchpad.net/ubuntu/+source/gnome-shell/]…
Important finding! The dpkg log shows that mutter/gnome-shell were on **Ubuntu 24.04 (mutter 46.x)** until... wait, that…
🤖 Assistant
Critical confirmation: the crash report's own Dpkg section shows the crash happened with mutter 50.1-0ubuntu2.2 and gnome-shell 50.1-0ubuntu1.1 — i.e. the 2148655 fix WAS installed when you crashed. So the published fix didn't prevent your particular crash. Let me confirm the install date, check the current status of bug 2156471, and see what's in the pending gnome-shell 1.2 update.
▶ Tool: run_bash [command='grep -a -A30 '^ThreadStacktrace' /var/crash/_usr_b]…
▶ Tool: web_search [query='mutter issue 4736 gnome-shell crash resume wayland o]…
Now I have a very complete picture. Let me summarize the facts:
🤖 Assistant
So the timeline is now clear and surprising: you've had the published fix (mutter 50.1-0ubuntu2.1 → 2.2) since June 1, and you still crashed with a different backtrace. Let me pull the full backtrace out of your crash file to see exactly which mutter code path died, and check the upstream mutter issue it points to.
▶ Tool: web_search [query='launchpad bug 2160181 gnome-shell crash mutter']
▶ Tool: run_bash [command='grep -aE 'Oops|OopsText|UploadedOOPS|Whoopsie' /va]…
The user's crash backtrace is mostly unresolved (?? symbols) — apport didn't have debug symbols. The visible frames: g_h…
🤖 Assistant
Your crash backtrace is mostly unresolved (no debug symbols), but the visible chain is g_hash_table_remove ← gobject ← libmutter ← g_object_unref — a teardown crash in a worker thread, distinct from the meta_logical_monitor_get_layout site the published fix addresses. Let me check the newest duplicate (2160181) of that bug and whether your crash got an OOPS ID, plus the linked NVIDIA driver issue.
▶ Tool: fetch_url [url='https://bugs.launchpad.net/bugs/2160181']
Hmm, that was a lot of output (the crash file grep dumped way too much — I got the "ThreadStacktrace" with raw addresses…
🤖 Assistant
That crash file dump was noisy, but I got what I needed. Key confirmations: your modprobe config already has the NVIDIA suspend/resume workarounds (NVreg_PreserveVideoMemoryAllocations=1, NVreg_TemporaryFilePath=/var/tmp), and the crash was in a worker thread (Thread 27, g_hash_table_remove via gobject/mutter). Let me check the newest duplicate bug (2160181) to see if this crash family is still being reported after the fix.
▶ Tool: run_bash [command='apt-cache search '^nvidia-driver-[0-9]+(-open)?$' ]…
Now I have the full picture. Let me also quickly check the last two messages in the 2156471 thread (Olmo's reply and Dan…
🤖 Assistant
Let me do one final check on whether any newer NVIDIA driver branch is available beyond 595, and confirm the gnome-shell update status.
Interesting! There IS a newer driver branch available: **nvidia-driver-610** (610.43.02). The user is on 595.84. So the …
🤖 Assistant
Everything's checked. Here's the full answer to your question.
There's a well-documented crash family that matches your symptom almost exactly (Wayland session dies right after suspend/resume → dumped to the login screen, no reboot). But the nuance matters here.
Ubuntu LP #2148655 — "gnome-shell crashed with SIGSEGV in meta_logical_monitor_get_layout(logical_monitor=NULL) from send_output_events()" — reported April 17, 2026. Root cause: GNOME Shell crashes when monitors are hot-plugged (e.g. same EDID/serial), and resume-from-suspend on NVIDIA triggers exactly that output-event path.
Here's the catch: you installed mutter 50.1-0ubuntu2.2 on June 27 — which includes the 2.1 fix (2.2 only adds a touchscreen fix on top) — and your crash report on disk proves the crash happened while running 50.1-0ubuntu2.2. So the published fix did not prevent your crash.
Why? Your backtrace is different: g_hash_table_remove → gobject → libmutter in a worker thread, whereas the fixed bug crashes in meta_logical_monitor_get_layout. Same trigger (mutter reconfiguring outputs after the NVIDIA driver re-emits hotplug events on resume — your kernel even logged nv_drm_handle_hotplug_event hogged CPU), but a distinct failure point.
And this family is still being reported: LP #2160181 (July 9, 2026) is another meta_logical_monitor_get_layout crash from the field — Daniel van Vugt's response was literally "Let's hope this is bug 2148655." So Canonical themselves aren't certain the fix fully covers all variants. Upstream watches: mutter #4369 / #4736, and NVIDIA/open-gpu-kernel-modules #1117 (your /etc/modprobe.d already carries the standard workarounds from that driver issue — PreserveVideoMemoryAllocations=1, TemporaryFilePath=/var/tmp, EnableGpuFirmware=0).
Within the 595 series you're fully current (595.84, candidate == installed). However, a newer series exists: nvidia-driver-610 (610.43.02) is available in the Ubuntu 26.04 repos. Since the trigger is the NVIDIA driver's post-resume output state, a newer driver series is a legitimate thing to try — but it's untested territory, not a confirmed fix. Also pending: gnome-shell 50.1-0ubuntu1.2 (unrelated to this crash, but install it anyway).
ubuntu-bug /var/crash/_usr_bin_gnome-shell.1000.crash
Canonical explicitly asks for crash files reported this way (they can't accept .crash attachments). Reference bug 2148655 in the description.
Want me to draft the ubuntu-bug submission for you, or check what sleep mode you're currently using?
🧑 You
Ubuntu bug just showed a normal app crash screen and I clicked Send. Not much else to do?
▶ Tool: run_bash [command='ls -la /var/crash/ 2>/dev/null; echo '==='; tail -]…
▶ Tool: run_bash [command='cat /var/lib/whoopsie/whoopsie-id 2>/dev/null; ech]…
▶ Tool: run_bash [command='echo '--- .uploaded marker content:'; cat /var/cra]…
▶ Tool: run_bash [command='journalctl -b 0 --no-pager --since "2026-08-10 18:]…
▶ Tool: run_bash [command='od -c /var/crash/_usr_bin_gnome-shell.1000.uploade]…
▶ Tool: run_bash [command='echo '--- whoopsie-id now:'; cat /var/lib/whoopsie]…
The whoopsie-id file exists but we can't read it (Permission denied — it's owned by whoopsie probably with restrictive p…
🤖 Assistant
OK — I've verified what actually happened. Here's the honest status.
That "normal app crash screen" is the standard Ubuntu error-report dialog (whoopsie/apport), and "Send" uploads the crash to the Ubuntu Error Tracker (errors.ubuntu.com) — it does not open a triaged Launchpad bug. It feeds the aggregate crash bucket that the GNOME/desktop team watches.
And in your specific case, the system log shows at 18:41:48:
whoopsie: Crash already uploaded, skipping
The crash was already marked as uploaded back at 11:47 this morning (the automatic upload right after the crash). So your click may not have transmitted anything new — the signature was already in the tracker. The only new thing I can see is that the whoopsie client (re)wrote its ID file at 18:42 during the dialog.
Honestly, yes. In priority order:
sudo rm /var/crash/_usr_bin_gnome-shell.1000.crash
(or keep it if you want to file the optional Launchpad bug first — ubuntu-bug needs the file).
Want me to set up a quick check for the future (e.g., a cron/systemd snippet that flags new gnome-shell crash files and pending mutter updates), or draft the exact text for a Launchpad bug if you decide to file one?