4.3 KiB
Incident log
Dated entries for diagnosed-and-fixed system incidents on this machine. Newest first. Keep entries factual: symptom, root cause, what was ruled out, fix applied, and any follow-up.
2026-06-24 — Chrome repeatedly crashing (SIGBUS), corrupt Favicons block on single-copy Btrfs
Symptom
Google Chrome crashed within seconds of launch, repeatedly. Three crashes in three minutes on 2026-06-24 (13:15, 13:16, 13:17), all signal SIGBUS. History of crashes back to April (mixed SIGTRAP / SIGILL / SIGSEGV / SIGBUS), 18 minidumps total.
Root cause
A single corrupt data block at offset 942080 of
~/.config/google-chrome/Profile 2/Favicons (a SQLite DB, inode 141150,
btrfs root 257). Chrome mmap()s the file on startup; the kernel raises SIGBUS
when it cannot fault in the bad page.
Each SIGBUS coredump correlated to the second with a kernel log line:
BTRFS warning: csum failed root 257 ino 141150 off 942080 csum 0x0858109c expected 0x0858109e mirror 1
Same single-bit flip every time (9c vs 9e). The volume is Data, single
(no mirror), so Btrfs detects but cannot self-heal. corruption_errs was
climbing (41 → 42). Disk read / write / flush io_errs were all 0 —
silent at-rest corruption; the NVMe is not reporting hardware faults.
Ruled out
- OOM — 87 GiB RAM free, and SIGBUS ≠ SIGKILL.
- Disk full — 5% used.
- Chrome version / update — install dated 2026-06-20 predates the crashes;
rpm -Vclean. - Profile / extension corruption.
- Dual-GPU / Wayland stack — GPU libs in the dump were merely mapped; the
gpu_channel.cc Buffer Handle is nullline was a downstream symptom logged ~2s after the SIGBUS.
Fix applied (2026-06-24)
Confirmed Chrome not running, then deleted the regenerable cache files
Favicons and Favicons-journal from Profile 2/. Chrome regenerates these on
next launch. Verified gone.
Scrub result (2026-06-24 13:28)
sudo btrfs scrub start -B /home finished in 0:55, scanned 79.57 GiB.
Error summary: csum=2, Corrected 0, Uncorrectable 2. The corruption is
not isolated to the Favicons file — two further uncorrectable blocks, in
two different subvolumes, both regenerable/reinstallable:
| File | Subvol | Action |
|---|---|---|
~/.cache/google-chrome/Profile 1/Cache/Cache_Data/5f188fe6012a3cdc_0 |
home (root 257) | Deleted (regenerates) ✅ |
/usr/share/help/fr/gdm/index.docbook |
root (root 259) | Owned by gdm-49.2-2.fc43; restore via sudo dnf reinstall gdm |
corruption_errs 44; read/write/flush io_errs 0.
Remediation + verification (2026-06-24 13:38–13:42)
- Deleted the Chrome cache block (
rm, regenerates). - Restored the gdm file:
sudo dnf reinstall gdm. - SSD health is clean —
sudo nvme smart-log /dev/nvme0n1:critical_warning 0,media_errors 0,percentage_used 0%. The drive has logged zero media errors at the hardware level → a failing SSD is unlikely; corruption reached good flash from upstream (RAM/bus). - Second scrub (13:41) still reports
csum=2uncorrectable — but at the exact same two physical blocks as the first scrub (logical 1754923008,logical 21439315968), and this time with no resolvable path. The live files now point at fresh extents; the corrupt extents are orphaned dead blocks (not snapshot-pinned —snapper/timeshiftnot installed).
Assessment
Same two static blocks across two scrubs 13 min apart = corruption is static, not actively spreading (no new blocks appeared). Combined with the clean SSD SMART, this most likely stems from a single past corruption event rather than an actively-failing component. The crash-causing live files are fixed; the residual scrub errors affect no live file.
Outstanding / follow-up
- Re-scrub in a day or two (
sudo btrfs scrub start -B /home). If the two orphaned blocks have cleared (reclaimed) and no new errors appear → fully resolved. New blocks appearing = corruption is ongoing → back up now and run memtest. - Run memtest86+ (Fedora GRUB boot entry) for confidence — scattered multi-file corruption with zero drive I/O errors is the classic bad-RAM signature, even if currently static.
- The
corruption_errscounter will not drop on a single-copy volume — expected.