System restore tool for Linux. Creates filesystem snapshots using rsync+hardlinks, or BTRFS snapshots. Supports scheduled snapshots, multiple backup levels, and exclude filters. Snapshots can be restored while system is running or from Live CD/USB.
Describe the bug
First off, thanks for the awesome software!
I am working on Ubuntu 22.04.3, and debugging some software issues that arose from upgrading to 22.04.4.
When trying to restore to a prior system state for 22.04.3, I noticed that it would simply "skip" most of the restore, and reboot quickly. I noticed that after reboot, my system did not seem to actually be restored. (Kernel version was still new, and cat /etc/issue still showed 22.04.4).
Note: I am using LUKS encryption for my install.
When I did reboot, I saw a notification that /boot had 0 bytes left of free space (it was configured to have about 1.7GB of space).
To Reproduce
Steps to reproduce the behavior:
Configure system to use rsync
Create a snapshot
Somehow make /boot run low on disk space (e.g. keep a whole bunch of kernel images around, or perhaps just use dd to squeeze space out)
Restore prior snapshot, but with /boot running low on disk space
See error messages about disk space running low, e.g. SIGUSR1 or some io.c error.
The following is what I saw in /run/timeshift/backup/timeshift/snapshots/2024-04-25_19-27-44/rsync-log-restore:
2024/04/25 20:33:14 [6099] building file list
2024/04/25 20:33:18 [6099] done
2024/04/25 20:33:19 [6099] .d..t...... boot/
2024/04/25 20:33:21 [6099] rsync: [sender] write error: Broken pipe (32)
2024/04/25 20:33:21 [6099] sent 231242281 bytes received 32794 bytes total size 47422097036
2024/04/25 20:33:21 [6099] rsync error: error in socket IO (code 10) at io.c(848) [sender=3.2.7]
It then rebooted, and per above, it did not actually restore.
Workaround
~I think I will be able to "workaround" this by just deleting everything in /boot (but not /boot/efi), and then requesting a restore.~
I will post a comment confirming / denying this.
EDIT: Nope, bad idea. This seemed to break my system. Trying fresh reinstall, but changing /boot size
EDIT 2: Ah, maybe unrelated. I reinstalled my system, this time changing /boot to have more space (4 GB, using this post, editing via sudo gedit /lib/partman/recipes*/*, and changing the /boot allocation lines to 4096 1024 4096, then running installer).
However, I ran into the same problem, in that it seems to have lost the "correct" UUID for cryptsetup to use --> #302
Expected behavior
Ideally, timeshift could somehow detect if it were to run out of space, and perhaps perform deletes first before restoring, or if there is an error, avoid rebooting and drop back into the original OS (not sure how feasible that is).
Perhaps the generated bash scripts should have something like set -e, so that errors cause script to immediately abort?
Screenshots
N/A
System:
Linux Distribution Name and Version: Ubuntu 22.04.3 and 22.04.4
Describe the bug First off, thanks for the awesome software!
I am working on Ubuntu 22.04.3, and debugging some software issues that arose from upgrading to 22.04.4. When trying to restore to a prior system state for 22.04.3, I noticed that it would simply "skip" most of the restore, and reboot quickly. I noticed that after reboot, my system did not seem to actually be restored. (Kernel version was still new, and
cat /etc/issuestill showed 22.04.4).Note: I am using LUKS encryption for my install.
When I did reboot, I saw a notification that
/boothad 0 bytes left of free space (it was configured to have about 1.7GB of space).To Reproduce Steps to reproduce the behavior:
rsync/bootrun low on disk space (e.g. keep a whole bunch of kernel images around, or perhaps just useddto squeeze space out)/bootrunning low on disk spaceSIGUSR1or someio.cerror.The following is what I saw in
/run/timeshift/backup/timeshift/snapshots/2024-04-25_19-27-44/rsync-log-restore:It then rebooted, and per above, it did not actually restore.
Workaround
~I think I will be able to "workaround" this by just deleting everything in
/boot(but not/boot/efi), and then requesting a restore.~ I will post a comment confirming / denying this.EDIT: Nope, bad idea. This seemed to break my system. Trying fresh reinstall, but changing
/bootsizeEDIT 2: Ah, maybe unrelated. I reinstalled my system, this time changing
/bootto have more space (4 GB, using this post, editing viasudo gedit /lib/partman/recipes*/*, and changing the/bootallocation lines to4096 1024 4096, then running installer). However, I ran into the same problem, in that it seems to have lost the "correct" UUID forcryptsetupto use --> #302Expected behavior Ideally,
timeshiftcould somehow detect if it were to run out of space, and perhaps perform deletes first before restoring, or if there is an error, avoid rebooting and drop back into the original OS (not sure how feasible that is).Perhaps the generated bash scripts should have something like
set -e, so that errors cause script to immediately abort?Screenshots N/A
System:
\cc @calderpg-tri