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

Re: /etc/fstab question (problem)?



On Thu, 2023-04-20 at 10:09 +0200, DdB wrote:
> You got your plan mapped out. and i agree, except for one little
> detail:
> see below. -
> 
> Am 19.04.2023 um 22:06 schrieb Default User:
> > > I think, it is the case when reboot is safer. Open file
> > > descriptors
> > > remain on the original partition. However I do not expect that
> > > single
> > > user mode or booting from live image is required. Just restore
> > > original
> > > /etc/fstab and reboot.
> > > 
> > > Perhaps update-initramfs is necessary after restoring of
> > > /etc/fstab
> > > in
> > > any chosen approach.
> > > 
> > > 
> > 
> > 
> > Well, now I am totally confused.
> > 
> > I had hoped for, and really expected, an easy, obvious, intuitive
> > solution.  But I guess that may be a distant memory of the good old
> > days, before [insert string of four-letter words here] like dbus,
> > systemd, and Gnome 3. And when partitions were named /dev/hda5, not
> > 6a105a72-f5d5-441b-b926-1e405151ee84.
> > 
> > Sigh.
> > 
> > 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.
> Do NOT delete the directory itself, only its content, as it will be
> used
> as the mountpoint for your /tmp drive.
> 
> > 
> > 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.
> 
> Please report your success, will you?
> 



Actually, I did not end up having to delete anything. From within the
live usb, essentially I just replaced by copying /etc/fstab with
/etc/fstab.original, and the rebooted. I did seem to work, but just to
be thorough, I again booted into the live usb and deleted the contents
of /tmp, which was of course by then on the dedicated tmp partition,
and then rebooted again into the system.

Okay so far, but note that my system is relatively simple, without
anything complex or exotic. Users with more complicated setups might
experience less favorable results. 




Reply to: