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 ?
