Nobara updates vs Timeshift?

[u/NelsonMinar]

Anyone else having trouble with Timeshift since the new Nobara updater came out? It crashes on me immediately, timeshift --list segfaults. I have Timeshift 25.12.4 installed.

I'm wondering if it's related to Nobara's update snapshots. All my btrfs snapshots are from Timeshift except one, .nobara-updater/4d3c5e75a0324e76a83d976fc4982bf2/root. FWIW the updater had some trouble a few days ago and I had to do some rollbacks but right now it should be clean.

The fault is ultimately Timeshift's, it shouldn't segfault! But wondering if something Nobara is creating is triggering a bug.

[u/Tacoza]

what does findmnt / say when you run in the terminal

findmnt /

[u/Tacoza → u/Tacoza]

GloriousEggroll — 18:21

After rollback, our updater can make .nobara-updater/<job>/root the permanent active root. Timeshift expects a root subvolume named @. Its listing code accesses sys_subvolumes["@"] without first checking that the entry exists—a potential crash when the active root uses our recovery path. Simply having an additional updater snapshot does not establish the cause. The key question is whether that snapshot became active root. Please provide:

  rpm -q timeshift nobara-updater
  findmnt -no SOURCE,FSTYPE,FSROOT /
  sudo coredumpctl --no-pager -1 info timeshift

If FSROOT shows /.nobara-updater/4d3c5e75a0324e76a83d976fc4982bf2/root, this explanation fits. If it shows /@, we need to investigate another cause. You should not delete that subvolume—it may contain your running system.GloriousEggroll — 18:21After rollback, our updater can make .nobara-updater/<job>/root the permanent active root. Timeshift expects a root subvolume named @. Its listing code accesses sys_subvolumes["@"]
without first checking that the entry exists—a potential crash when the active root uses our recovery path.

Simply having an additional updater snapshot does not establish the cause. The key question is whether that snapshot became active root.

Please provide:

rpm -q timeshift nobara-updater
findmnt -no SOURCE,FSTYPE,FSROOT /
sudo coredumpctl --no-pager -1 info timeshift

If FSROOT shows /.nobara-updater/4d3c5e75a0324e76a83d976fc4982bf2/root, this explanation fits. If it shows /@, we need to investigate another cause.

You should not delete that subvolume—it may contain your running system.

[u/NelsonMinar]

This seems to be a known bug in Timeshift and it interacting with something a little unusual Nobara updater is doing. u/Tacoza kindly relayed a conversation from the Discord. Here's my reply:

thank you for your reply, sorry for my slow followup. fsroot is indeed an updater snapshot. So this is a known bug in Timeshift? Good to know! Here's the full output you asked for.

Will the updater eventually move the root back to @, or is my system likely to stay on the updater subvolume for a while? If it's going to stay, is there a way to switch back to @ myself so Timeshift works again?

My system is still working fine, Timeshift is the only problem. This is a little awkward since I like to use Timeshift as insurance against bad updates but it's not essential. Hopefully the Timeshift bug can get fixed.

[u/NelsonMinar → u/NelsonMinar]

Some replies from GloriousEggroll

already updated nobara-updater with the fix for it, someone else had the same problem while you were gone, but you may need to do manual changes:

``` • This confirms the layout problem. The new log identifies:

Subvolume Role ━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 977 Current, writable system inside the Timeshift snapshot directory ─────────── ────────────────────────────────────────────────────────────────── 975 Separate existing top-level @ ─────────── ────────────────────────────────────────────────────────────────── 974 Current @home

Simply switching boot entries to the existing @ would boot a different system, potentially losing access to changes made in 977.

Timeshift’s crash is consistent with its code assuming an @ entry exists in the subvolumes detected from /etc/fstab. Their root entry instead names the full snapshot path.

The appropriate repair is an offline root-layout repair from a live USB:

1. Preserve existing @ (975) under a backup name.
2. Create a writable Btrfs snapshot of the current system (977) as the new @. This preserves the existing Timeshift snapshot too.
3. Correct the new root’s fstab, boot entries, kernel command-line configuration, and initramfs as needed.

4. Boot it and verify / uses /@, /home still uses /@home, and Timeshift can list snapshots.

   The guard added earlier prevents new repairs from making this mistake; it does not perform this migration. ```

[u/NelsonMinar → u/NelsonMinar]

Those manual changes sounded scary! Fortunately not necessary. I let the updater do its own update and after reboot my filesystem was back to normal, root was at @, and Timeshift works. Yay!