Re: /etc/fstab question (problem)?
On Wed, 2023-04-19 at 14:03 -0700, David Christensen wrote:
> On 4/19/23 13:06, Default User wrote:
> > On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote:
> > > On 19/04/2023 16:16, David Christensen wrote:
> > > > On 4/18/23 20:16, Stefan Monnier wrote:
> > > >
> > > > > You can also do
> > > > >
> > > > > mount --bind / /mnt
> > > > >
> > > > > and then look at /mnt/tmp.
> > > > > No need to reboot into single-user mode for that.
> > > >
> > > > +1 I like that better than the reboot/ live drive idea I
> > > > posted.
> > >
> > > 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.
>
>
> +1 I am confused most of the time. LOL ;-)
>
>
> >
> > 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.
> >
> > 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.
>
>
> Subsequent to my last post, I had realizations similar to the reply
> by
> Max Nikulin:
>
> * What if root attempts to remove everything under /etc, in
> anticipation
> of mounting a file system at /etc, when one or more programs have one
> or
> more open temporary files?
>
> * What if root attempts to mount a file system at /etc when one or
> more
> programs have one or more open temporary files?
>
>
> Rebooting avoids having to answer the above questions, or suffer the
> consequences.
>
>
> But, I cannot address Max's point about initrd(4).
>
>
> At this point, I would run my daily backups, use an editor to put the
> original /etc entry back into /etc/fstab, forget about messing with
> /etc
> on either file system, and reboot. After reboot, I would run 'df
> /etc'
> and check where /etc is mounted. If /etc is "Mounted on /", I would
> run
> update-initramfs(8), reboot, and look again.
>
>
> David
>
I'm afraid I don't quit understand why 'If /etc is "Mounted on /", I
would run update-initramfs(8), reboot, and look again."
Shouldn't etc always be expected to be mounted under /, as in /etc?
For example, right now on my computer:
df /etc
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/nvme0n1p2 23854928 5841492 16776344 26% /
And, would there be anything wrong with, either way, running update-
initramfs?
Would that be run as:
sudo update-initramfs -uv
?
Reply to: