On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote:
Anyway, here is where I am at:
I have two Clonezilla backups.
1) a full disk backup.
2) a "partitions" backup.
So, if things really go bad, I can theoretically revert to the
setup as
of 2023-04-18, when this thread was started.
I also have a backup of the current /tmp directory (from under
the
/
directory).
And I have a backup of the old tmp partition.
Both of these tmp backups were made using a Debian Stable 11.6
Live/install usb thumb drive, as root user.
All of these backups are on an external usb hdd.
Here is what was in the (root) tmp directory:
_root_partition/tmp
total 32K
88473604 drwxr-xr-t 8 [user] [user] 4.0K Apr 19 14:18 ./
88473602 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:18 ../
88473608 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .font-unix/
88473606 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .ICE-unix/
88473609 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .Test-unix/
88473610 drwx------ 2 [user] [user] 4.0K Apr 19 14:18 tracker-
extract-
files.116/
88473605 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .X11-unix/
88473607 drwxr-xr-t 2 [user] [user] 4.0K Apr 19 14:18 .XIM-unix/
And here is what was in the old tmp partition:
total 48K
88473611 drwxr-xr-t 10 root root 4.0K Apr 19 14:20 ./
88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../
88473618 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .font-
unix/
88473615 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .ICE-
unix/
88473620 drwx------ 2 root root 4.0K Apr 19 14:20
lost+found/
88473619 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .Test-
unix/
88473624 drwx------ 2 root root 4.0K Apr 19 14:20 tracker-
extract-files.1000/
88473623 drwx------ 2 root root 4.0K Apr 19 14:20 tracker-
extract-files.116/
88473621 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1024-
lock
88473622 -r--r--r-- 1 root root 11 Apr 19 14:20 .X1025-
lock
88473612 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .X11-
unix/
88473617 drwxr-xr-t 2 root root 4.0K Apr 19 14:20 .XIM-
unix/
As far as I can tell, there is nothing crucial in either tmp
backup.
BTW, I know nothing about bind or mount --bind. I looked them up
briefly, and decided that they are too difficult and maybe
dangerous to
try to learn and use under the current circumstances.
So here is what I am thinking of doing:
While running from within the Debian Stable 11.6 Live/install usb
thumb
drive, as root user:
1) On the computer's internal ssd, delete the /tmp directory and
its
contents.
2) On the computer's internal ssd, delete the contents of the old
tmp
partition, but not the partition itself.
3) On the computer's internal ssd, replace /etc/fstab with
/etc/fstab.original, renaming it /etc/fstab. I have already made
a
copy
of the current /etc/fstab as /etc/fstab.as-of-2023-04-19.
The UUIDs of all partitions on computer's internal ssd seem to be
the
same as in /etc/fstab.original.
(Note: in /etc/fstab.original, it states "Please run 'systemctl
daemon-
reload' after making changes here." Since I am doing all this
from
a
live usb, I do not think that applies, so I would skip that.)
Then I would shut down, remove the usb thumb drive, and boot into
the
Debian system on the computer's internal ssd.
I hope that from then on, the system would mount the old tmp
partition
on the computer's internal ssd as /tmp, re-populating it
automatically,
and use it as such from then on.
Does that seem reasonable?
Or am I missing something, obvious or not.
I see nothing unreasonable. The only oddity to me is that the
listings
you give (which are from the backups, I assume) have today's date,
which means that the backup method is not preserving the file
metadata.
(If you've not used partition 5 for a while, the dates should be
old.)
It doesn't affect what you're doing now, as all the originals are
heading into oblivion, but I'd be reading the backup spec sometime
to see if I could improve that.
Cheers,
David.