Timeshift Segmentation fault on restore. #278

matthew-henry · 2024-02-26T01:25:06Z

Describe the bug
Timeshift restore on GUI fails silently (BTRFS snapshot).
Timeshift in CLI has a segmentation fault (not sure how to get more debugging info) (BTRFS snapshot).

Not 100% sure that this isn't me not having partitions and stuff looking right (I'm sorry if I am reporting user error).
To Reproduce
Steps to reproduce the behavior:

Sudo timeshift --restore
Select any snapshot
Program exits with Segmentation Fault

Expected behavior
Expected snapshot to be restored

Screenshots

System:

EndeavourOS (kernel 6.7.6-zen1-1-zen
KDE Plasma 5.27 (occurs in TTY as well)
timeshift 24.01.1-1
Disk information
[matt@Matt-Desktop ~]$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 465.8G 0 disk
├─sda1 8:1 0 16M 0 part
├─sda2 8:2 0 244.1G 0 part
└─sda3 8:3 0 221.6G 0 part /storagedrv
sdb 8:16 1 57.6G 0 disk
└─sdb1 8:17 1 57.6G 0 part
nvme0n1 259:0 0 931.5G 0 disk
├─nvme0n1p1 259:1 0 100M 0 part /boot/efi
├─nvme0n1p2 259:2 0 637.9G 0 part /home
└─nvme0n1p5 259:3 0 292.9G 0 part /run/timeshift/21382/backup
/run/timeshift/21200/backup
/
nvme1n1 259:4 0 3.6T 0 disk
└─nvme1n1p1 259:5 0 3.6T 0 part /mnt/new_game_drive
[matt@Matt-Desktop ~]$

[matt@Matt-Desktop ~]$ sudo btrfs subvolume list /
ID 648 gen 136175 top level 5 path @
ID 990 gen 136170 top level 5 path swap
ID 1034 gen 136170 top level 5 path timeshift-btrfs/snapshots/2024-02-25_14-55-27/@
ID 1040 gen 136170 top level 5 path timeshift-btrfs/snapshots/2024-02-25_15-18-47/@
ID 1042 gen 136170 top level 5 path timeshift-btrfs/snapshots/2024-02-25_15-24-05/@
ID 1670 gen 136175 top level 5 path timeshift-btrfs/snapshots/2024-02-25_19-12-17/@
[matt@Matt-Desktop ~]$

[matt@Matt-Desktop ~]$ sudo btrfs subvolume list /home
ID 256 gen 64430 top level 5 path matt/@

Found and attaching log file.
2024-02-25_21-43-17_restore.log

=======================================================================
Stepping through things it looks like we go off rails right after init_mount_list() which looks to be reading from fstab. So including fstab output below.

UUID=1E2F-5409 /boot/efi vfat noatime 0 2
UUID=baf2eb9e-0edc-4fd9-86b3-8959f11bff33 / btrfs defaults,subvol=/@ 0 1
/swap/swapfile none swap defaults 0 0
/dev/sda3 /storagedrv ext4 defaults 0 0
/dev/nvme0n1p2 /home btrfs defaults 0 0
/dev/nvme1n1p1 /mnt/new_game_drive btrfs defaults 0 0

Looking at the log I am noticing the following line
[21:43:24] missing: dev: UUID=baf2eb9e-0edc-4fd9-86b3-8959f11bff33, path: /, options: noatime

which does not match the options I have set for that volume in fstab( defaults,subvol=/@).

ILYAGVC · 2024-03-01T08:31:46Z

I have exactly the same problem.

matthew-henry · 2024-03-01T14:59:17Z

I have exactly the same problem.

Do you think you could grab a log and your fstab output as well. I was trying to go through and see if I could find where things break (never seen Vala before) and not having much luck. I'm curious if there's something similar about our configurations or if we are having similar related problems rather than identical.

ILYAGVC · 2024-03-01T18:19:38Z

I have exactly the same problem.

Do you think you could grab a log and your fstab output as well. I was trying to go through and see if I could find where things break (never seen Vala before) and not having much luck. I'm curious if there's something similar about our configurations or if we are having similar related problems rather than identical.

I couldn't wait to fix the problem so I used the GUI
sorry

matthew-henry · 2024-03-01T18:51:44Z

I have exactly the same problem.

Do you think you could grab a log and your fstab output as well. I was trying to go through and see if I could find where things break (never seen Vala before) and not having much luck. I'm curious if there's something similar about our configurations or if we are having similar related problems rather than identical.

I couldn't wait to fix the problem so I used the GUI sorry

Eh no problem. GUI also doesn't work for me so it might be multiple things wrong. Not even sure if I can do something, but figured I should make an attempt if I could figure out what's happening (not having much luck or time to look into it). Thanks for at least confirming I'm not the only one impacted.

ILYAGVC · 2024-03-01T18:59:32Z

I have exactly the same problem.

Do you think you could grab a log and your fstab output as well. I was trying to go through and see if I could find where things break (never seen Vala before) and not having much luck. I'm curious if there's something similar about our configurations or if we are having similar related problems rather than identical.

I couldn't wait to fix the problem so I used the GUI sorry

Eh no problem. GUI also doesn't work for me so it might be multiple things wrong. Not even sure if I can do something, but figured I should make an attempt if I could figure out what's happening (not having much luck or time to look into it). Thanks for at least confirming I'm not the only one impacted.

You need to install GUI manually.
Timeshift works well on Intel and AMD CPUs

matthew-henry · 2024-03-01T19:42:27Z

I have the gui installed. It'll also snapshot just fine from the GUI (I didn't try to use the CLI for restore until I had a broken desktop and had to work from TTY). But crashes in the same function as the CLI version if you click the restore button. I was trying to see if there might be an oddity with how my partition layout is made that caused the crashes. Checking the logs it looks like it doesn't figure out some information about my root partition when restoring.

[21:43:24] missing: dev: UUID=baf2eb9e-0edc-4fd9-86b3-8959f11bff33, path: /, options: noatime

The last log entry before crash (CLI or GUI) is always get_restore_messages() from called from Main.

I was trying to trace through the code but I don't see what could be happening. Might need to try building with debug flags and tracing with gdb when I have time.

matthew-henry · 2024-03-03T02:57:45Z

Built with debug symbols and ran through gdb. The program crashes in restore_current_system on line 1895.

Stepping through with gdb right before the seg fault get_dst_root is invoked and then falls through to returning null. Even still I'm not 100% certain why a seg fault happens in the line in question (unless trying to access a field of a null object causes a segfault). If returning null in these is a cause for potential segfaults it should probably be exception handled (to be clear I'm not sure that that IS the cause).

I'm assuming that the root cause is probably something about my partition setup where my root doesn't seem to be parsed. Whether it's a configuration issue on my end or an edge case, there is some situation that leads to a seg fault that could use some catching.

ILYAGVC · 2024-03-03T10:43:22Z

Built with debug symbols and ran through gdb. The program crashes in restore_current_system on line 1895.

Stepping through with gdb right before the seg fault get_dst_root is invoked and then falls through to returning null. Even still I'm not 100% certain why a seg fault happens in the line in question (unless trying to access a field of a null object causes a segfault). If returning null in these is a cause for potential segfaults it should probably be exception handled (to be clear I'm not sure that that IS the cause).

I'm assuming that the root cause is probably something about my partition setup where my root doesn't seem to be parsed. Whether it's a configuration issue on my end or an edge case, there is some situation that leads to a seg fault that could use some catching.

It's evident that Timeshift is attempting to access a non-existent resource. As previously mentioned, Timeshift performs smoothly on both AMD and Intel CPUs. You may need to await optimization from the developer to extend compatibility to other CPUs, particularly in command-line usage.

matthew-henry · 2024-03-03T20:03:40Z

This has nothing to do with CPU compatibility. I am running on an 7950x (an AMD x86 cpu). Even if I were on a different platform they aren't using CPU-specific low level stuff so any platform that Vala compiles to should work more or less. This has everything to do with unhandled conditions in the code (and in Main.vala so in my situation both GUI and CLI are impacted as both versions call in to Main.vala when performing restores) and with issues with the way in the formatting of my fstab (it fails to assign a device to main in the processing code as determined by logs and stepping through with gdb). The traces provided are necessary details for any developer not impacted by the issue to know where and how the crash is happening. Without logs and details on your issue we may very well have entirely separate crash causes and conditions.

I am trying to definitively identify a root-cause for when and if an developer does look at this (especially as I haven't provided definitive steps to reproduce yet they need some stuff to go on for it to be worth their time). And if it's something I think I can fix maybe do a pull request.

matthew-henry · 2024-03-03T23:21:51Z

I believe I have tracked down the reason my root is not found on the filesystem probe.

get_block_devices_using_lsblk in Utility/Devices.vala executes: lsblk --bytes --pairs --output NAME,KNAME,LABEL,UUID,TYPE,FSTYPE,SIZE,MOUNTPOINT,MODEL,RO,HOTPLUG,MAJ:MIN,PARTLABEL,PARTUUID,PKNAME,VENDOR,SERIAL,REV

Running this command, however, will not find a root partition on my system.

Looking at a basic lsblk:

There are two mountpoints listed for the partition containing root.

I'm assuming this logged missing root in the logs might follow from this point.

Per manpages for lsblk

so in situations like mine the MOUNTPOINTS column would be needed and output parsed appropriately.

khaliid2040 · 2024-06-08T14:07:48Z

still the issue is present in version 24.06.1-1
Steps to reproduce
just like the original post

timeshift --restore
select the snapshot and click enter in the grub whether you select yes or no the segfault will happen
Expected behaiviour
the bug is fixed in the privious versions and the reported

Fitski · 2024-08-13T18:18:25Z

I have the same problem and I am also able to reproduce the issue like @khaliid2040 did.
Let me know if I need to share logs or anything else.

Magentron · 2025-01-20T16:56:34Z

I have fixed the segmentation fault, but this still does not resolve the real issue, see: #386 (comment)

FYI: lsblk output on DigitalOcean Ubuntu 22.04 LTS droplet :

[2025-01-20 16:52:32] root@rollback:~# lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0     7:0    0  63.4M  1 loop /snap/core20/1950
loop1     7:1    0  63.7M  1 loop /snap/core20/2434
loop2     7:2    0 111.9M  1 loop /snap/lxd/24322
loop3     7:3    0  89.4M  1 loop /snap/lxd/31333
loop4     7:4    0  44.4M  1 loop /snap/snapd/23545
loop5     7:5    0  53.3M  1 loop /snap/snapd/19457
vda     252:0    0    60G  0 disk
├─vda1  252:1    0  59.9G  0 part /run/timeshift/backup
│                                 /
├─vda14 252:14   0     4M  0 part
└─vda15 252:15   0   106M  0 part /boot/efi
vdb     252:16   0   490K  1 disk

/etc/timeshift/timeshift.json:

{
  "backup_device_uuid" : "<UUID of /dev/vda1>",
  "parent_device_uuid" : "",
  "do_first_run" : "false",
  "btrfs_mode" : "false",
  "include_btrfs_home_for_backup" : "false",
  "include_btrfs_home_for_restore" : "false",
  "stop_cron_emails" : "true",
  "btrfs_use_qgroup" : "true",
  "schedule_monthly" : "false",
  "schedule_weekly" : "false",
  "schedule_daily" : "false",
  "schedule_hourly" : "false",
  "schedule_boot" : "false",
  "count_monthly" : "2",
  "count_weekly" : "3",
  "count_daily" : "5",
  "count_hourly" : "6",
  "count_boot" : "5",
  "snapshot_size" : "5085514029",
  "snapshot_count" : "165933",
  "date_format" : "%Y-%m-%d %H:%M:%S",
  "exclude" : [
    "/home/user/**"
  ],
  "exclude-apps" : []
}

Magentron · 2025-01-20T18:25:19Z

Perhaps the issue is caused by missing UUID's in /etc/fstab?

[2025-01-20 18:23:45] root@rollback:~/timeshift/builddir# cat /etc/fstab
LABEL=cloudimg-rootfs	/	 ext4	discard,errors=remount-ro	0 1
LABEL=UEFI	/boot/efi	vfat	umask=0077	0 1

Magentron · 2025-01-20T18:33:26Z

Well, that was not it. I was getting the device to restore to from the snapshot's /etc/fstab (which was not found due to use of a LABEL, and I guess it would fail also if it would only use UUID).

After updating the root entry in /etc/fstab in the snapshot to use, it finally got a step further:

[2025-01-20 18:33:04] root@rollback:~/timeshift/builddir# timeshift --restore --verbose --snapshot 2025-01-20_15-31-59 --skip-grub
[Warning] Deleted invalid lock
Mounted '/dev/vda1' at '/run/timeshift/15560/backup'


******************************************************************************
To restore with default options, press the ENTER key for all prompts!
******************************************************************************

Press ENTER to continue...
******************************************************************************
GRUB will NOT be reinstalled
******************************************************************************

======================================================================
WARNING
======================================================================
Data will be modified on following devices:

Device     Mount
---------  -----
/dev/vda1  /


Please save your work and close all applications.
System will reboot after files are restored.

======================================================================
DISCLAIMER
======================================================================
This software comes without absolutely NO warranty and the author takes no responsibility for any damage arising from the use of this program. If these terms are not acceptable to you, please do not proceed beyond this point!

Continue with restore? (y/n): ^C

ARKye03 · 2025-03-31T00:02:21Z

As of March 30 2025, I find myself on a situation where I can't just use Timeshift, generations are created, however each time I try to restore one, it just segfaults.

I'm on Arch Linux, these are my system specs:

os: Arch Linux x86_64
hardware: Dell Inspiron 3501
kernel: Linux 6.12.21-1-lts
shell: nushell 0.103.0
using Wayland
cpu: 11th Gen Intel(R) Core(TM) i5-1135G7 (8) @ 4.20 GHz
gpu: Intel Iris Xe Graphics @ 1.30 GHz [Integrated]
ram: 2.40 GiB / 15.35 GiB (16%)
disk: 8.69 GiB / 237.47 GiB (4%) - btrfs

I have created a subvolume @ at root "/", from wiki.
Then installed timeshift-systemd-timer, which does generates the snapshots, in my case 5 mins after boot.

However if I try to restore any particular snapshot it will just segfault, which I can't post because:

           PID: 12336 (timeshift)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV)
     Timestamp: Sun 2025-03-30 19:56:48 CDT (38s ago)
  Command Line: timeshift --restore
    Executable: /usr/bin/timeshift
 Control Group: /user.slice/user-1000.slice/[email protected]/app.slice/app-graphical.slice/app-Hyprland-alacritty-0e721b46.scope
          Unit: [email protected]
     User Unit: app-Hyprland-alacritty-0e721b46.scope
         Slice: user-1000.slice
     Owner UID: 1000 (archxekye)
       Boot ID: fe4df06326fc48c984c43ce7e0a3c507
    Machine ID: dcefdc526fe7400faf12fcc47409d24b
      Hostname: archlixelinux
       Storage: none
       Message: Process 12336 (timeshift) of user 0 terminated abnormally without generating a coredump.

Coredump entry has no core attached (neither internally in the journal nor externally on disk).

Magentron · 2025-04-01T06:30:50Z

As of March 30 2025, I find myself on a situation where I can't just use Timeshift, generations are created, however each time I try to restore one, it just segfaults.

@ARKye03 Could you confirm that #386 fixes your issue?

ARKye03 · 2025-04-02T15:22:22Z

@ARKye03 Could you confirm that #386 fixes your issue?

It prevents Timeshift from crashing (segfaulting), but it's still not working. The timeshift --restore command doesn't restore the snapshot. It exits with code 1 instead.

Magentron · 2025-04-02T15:57:43Z

It prevents Timeshift from crashing (segfaulting), but it's still not working. The timeshift --restore command doesn't restore the snapshot. It exits with code 1 instead.

@ARKye03 Did you see my comment about this?
#278 (comment)

ARKye03 · 2025-04-02T16:10:34Z

I'm already using UUID:

# /dev/nvme0n1p2
UUID=0596ac99-d87f-42bb-82a1-4ff0a77a588b	/         	btrfs     	rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=@	0 0

Just wanted to mention something I noticed:

I’ve been using timeshift-launcher (the GUI version), and it seems to work—no visible errors, and the terminal logs don’t show any obvious issues.

But here’s the problem:

I created a test directory full of files.
Took a snapshot (no errors).
Deleted that directory.
Restored the snapshot (which should have brought the directory back).
Rebooted… but the directory still doesn’t exist, even though Timeshift claimed success.

I’m not sure if this is happening because my /home isn’t a separate partition—it’s just a normal folder inside / (root). Could that be the reason?"

Timeshift cli still exits with error code 1 though.

Magentron · 2025-04-02T16:50:30Z

@ARKye03 Please try again using the device path instead of the UUID=... or LABEL=...

ARKye03 · 2025-04-02T17:07:44Z

@ARKye03 Please try again using the device path instead of the UUID=... or LABEL=...

No, it doesn't solve the problem either, I guess I'll try some snapshots manually, nor timeshift, nor grub-btrfsd with timeshift support work.

Perhaps there is some issue with my installation, which is odd, as its simple enough so not weird behaviours arise like this.

This is how my fstab for root looks:

/dev/nvme0n1p2	/         	btrfs     	rw,relatime,compress=zstd:3,ssd,discard=async,space_cache=v2,subvol=@	0 0

where nvme0n1p2 btrfs 0596ac99-d87f-42bb-82a1-4ff0a77a588b 227G 4% /

LinuxOnTheDesktop mentioned this issue Oct 8, 2024

Segfault 28 #352

Open

LinuxOnTheDesktop mentioned this issue Oct 22, 2024

Fix segmentation fault #169

Merged

Magentron linked a pull request Jan 20, 2025 that will close this issue

Update function restore_current_system() to check that dst_root is not null #386

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Timeshift Segmentation fault on restore. #278

Timeshift Segmentation fault on restore. #278

matthew-henry commented Feb 26, 2024 •

edited

Loading

ILYAGVC commented Mar 1, 2024

matthew-henry commented Mar 1, 2024 •

edited

Loading

ILYAGVC commented Mar 1, 2024

matthew-henry commented Mar 1, 2024

ILYAGVC commented Mar 1, 2024 •

edited

Loading

matthew-henry commented Mar 1, 2024

matthew-henry commented Mar 3, 2024

ILYAGVC commented Mar 3, 2024

matthew-henry commented Mar 3, 2024

matthew-henry commented Mar 3, 2024 •

edited

Loading

khaliid2040 commented Jun 8, 2024

Fitski commented Aug 13, 2024

Magentron commented Jan 20, 2025 •

edited

Loading

Magentron commented Jan 20, 2025

Magentron commented Jan 20, 2025

ARKye03 commented Mar 31, 2025

Magentron commented Apr 1, 2025

ARKye03 commented Apr 2, 2025

Magentron commented Apr 2, 2025

ARKye03 commented Apr 2, 2025 •

edited

Loading

Magentron commented Apr 2, 2025

ARKye03 commented Apr 2, 2025 •

edited

Loading

Timeshift Segmentation fault on restore. #278

Timeshift Segmentation fault on restore. #278

Comments

matthew-henry commented Feb 26, 2024 • edited Loading

ILYAGVC commented Mar 1, 2024

matthew-henry commented Mar 1, 2024 • edited Loading

ILYAGVC commented Mar 1, 2024

matthew-henry commented Mar 1, 2024

ILYAGVC commented Mar 1, 2024 • edited Loading

matthew-henry commented Mar 1, 2024

matthew-henry commented Mar 3, 2024

ILYAGVC commented Mar 3, 2024

matthew-henry commented Mar 3, 2024

matthew-henry commented Mar 3, 2024 • edited Loading

khaliid2040 commented Jun 8, 2024

Fitski commented Aug 13, 2024

Magentron commented Jan 20, 2025 • edited Loading

Magentron commented Jan 20, 2025

Magentron commented Jan 20, 2025

ARKye03 commented Mar 31, 2025

Magentron commented Apr 1, 2025

ARKye03 commented Apr 2, 2025

Magentron commented Apr 2, 2025

ARKye03 commented Apr 2, 2025 • edited Loading

Magentron commented Apr 2, 2025

ARKye03 commented Apr 2, 2025 • edited Loading

matthew-henry commented Feb 26, 2024 •

edited

Loading

matthew-henry commented Mar 1, 2024 •

edited

Loading

ILYAGVC commented Mar 1, 2024 •

edited

Loading

matthew-henry commented Mar 3, 2024 •

edited

Loading

Magentron commented Jan 20, 2025 •

edited

Loading

ARKye03 commented Apr 2, 2025 •

edited

Loading

ARKye03 commented Apr 2, 2025 •

edited

Loading