Steps to reproduce
- On an Arch-based Linux system, install/run Obsidian
1.12.7with the package stack that includes:electron39 39.8.10-1libdrm 2.4.133-1obsidian 1.12.7-2
- Launch Obsidian with community plugins disabled or Restricted Mode enabled.
- Open a vault containing a known-good PDF that renders correctly in external PDF viewers.
- Open the PDF directly in Obsidian’s built-in PDF viewer.
- Also test the same PDF embedded in a note, for example:
![[test.pdf]]
Did you follow the troubleshooting guide? [Y/N]
Y
Expected result
The PDF should render normally in Obsidian’s built-in PDF viewer and when embedded in a note.
Actual result
The PDF viewer/preview area is blank. The same PDFs render correctly in external PDF viewers.
Disabling PDF++ did not change the behavior. Clearing Obsidian/Electron render caches did not fix it. Removing custom Electron flags and launching Obsidian with clean package defaults did not fix it.
Rolling back the related packages made PDF rendering work again immediately:
electron39: 39.8.10-1 -> 39.8.9-1
libdrm: 2.4.133-1 -> 2.4.131-1
obsidian: 1.12.7-2 -> 1.12.7-1
Follow-up isolation test: with electron39 39.8.9-1 and obsidian 1.12.7-1, upgrading only libdrm to 2.4.133-1 did not reproduce the issue; PDFs still rendered. This makes electron39 39.8.10-1, or the interaction between Electron and the graphics stack, the stronger suspect.
Environment
Obsidian version: v1.12.7
Operating system: Arch Linux / Omarchy 3.8.0
Kernel at original report: 7.0.3-arch1-1-ptl
Kernel during later libdrm-only follow-up test: 7.0.3-arch1-2-ptl
Session: Wayland / Hyprland
Machine: Dell XPS 16 DA16260
CPU: Intel Core Ultra X7 358H
GPU: Intel Panther Lake [Arc B390] [8086:b080]
Affected package set:
electron39 39.8.10-1
libdrm 2.4.133-1
obsidian 1.12.7-2
Known-good rollback package set:
electron39 39.8.9-1
libdrm 2.4.131-1
obsidian 1.12.7-1
Additional information
The regression appeared after a system update on May 7, 2026. Obsidian itself had already been upgraded to 1.12.7-2 on May 4, 2026, but the PDF blanking behavior did not appear until after the May 7 update that included electron39 and libdrm.
Package timeline from pacman log:
[2026-05-04T17:03:02-0400] upgraded obsidian (1.12.7-1 -> 1.12.7-2)
[2026-05-07T16:06:57-0400] upgraded libdrm (2.4.131-1 -> 2.4.133-1)
[2026-05-07T16:06:58-0400] upgraded electron39 (39.8.9-1 -> 39.8.10-1)
Known-good rollback command:
pkexec pacman -U --noconfirm \
/var/cache/pacman/pkg/electron39-39.8.9-1-x86_64.pkg.tar.zst \
/var/cache/pacman/pkg/libdrm-2.4.131-1-x86_64.pkg.tar.zst \
/var/cache/pacman/pkg/obsidian-1.12.7-1-x86_64.pkg.tar.zst
This was first reported in the Omarchy tracker because the regression appeared through an Omarchy/system update path on Dell XPS Panther Lake hardware:
https://github.com/basecamp/omarchy/issues/5671
Another user in that issue reported the same symptom on CachyOS and said the rollback suggestions worked for them. Their exact hardware is unknown.
I searched the Obsidian forum and did not find an exact duplicate for this Arch/CachyOS + electron39/libdrm PDF viewer regression. The closest older/different reports I found were:
https://forum.obsidian.md/t/pdf-viewer-seems-to-be-broken/97628https://forum.obsidian.md/t/pdf-files-take-too-long-to-open-or-dont-open-at-all/96524https://forum.obsidian.md/t/some-pdfs-are-shown-as-empty-in-internal-pdf-viewer/73058https://forum.obsidian.md/t/graph-view-is-blank-on-linux-after-os-update/69495/9https://forum.obsidian.md/t/pdf-files-fail-to-load-in-obsidian-when-file-names-contain-non-ascii-characters/100298
Official AppImage/Snap under GNOME or KDE has not yet been confirmed. Current confirmed reports are Arch/Omarchy/Hyprland and CachyOS.
Omarchy debug log from the original report:
https://github.com/user-attachments/files/27525286/omarchy-debug.log
