[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /etc/fstab question (problem)?



On Wed, 2023-04-19 at 16:56 -0400, Default User wrote:
> On Wed, 2023-04-19 at 15:36 -0500, David Wright wrote:
> > 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.
> > 
> 
> 
> IIRC, I just did:
> 
> sudo <source> <destination> from the live usb. 
> 
> I didn't think about the changed times. 
> 
> Perhaps I should have used rsync . . .
> 
> Grrr . . .
> 
> 
> 


Sorry! That should have been: 

sudo cp -r <source> <destination> from the live usb.

"The Times regrets the error."

:)




Reply to: