Skip to content

Unable to restore if /boot is full #301

@EricCousineau-TRI

Description

@EricCousineau-TRI

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:

  1. Configure system to use rsync
  2. Create a snapshot
  3. 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)
  4. Restore prior snapshot, but with /boot running low on disk space
  5. 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
  • Desktop: Ubuntu
  • Application Version: 21.09.1-1 (dpkg)

\cc @calderpg-tri

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions