On Wed, 2023-04-19 at 15:09 -0700, David Christensen wrote: > On 4/19/23 15:03, David Christensen wrote: > > On 4/19/23 14:26, Default User wrote: > > > 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: > > > > > > > > Perhaps update-initramfs is necessary after restoring of > > > > > > /etc/fstab > > > > > > in > > > > > > any chosen approach. > > > > > > 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. > > > > > 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% / > > > > > > /etc is a subdirectory of the / directory on the Unix "one big file > > system". > > > > > > Some file system must be mounted at /. > > > > > > Additional file systems must be mounted somewhere beneath /. Where > > they > > are mounted is call the "mountpoint". Mountpoints are > > traditionally > > subdirectories, and traditionally empty. When a file system is > > mounted > > there, the root of that file system is visible as the contents of > > the > > mountpoint. > > > > > > On my system, the virtual device /dev/mapper/sda4_crypt has a mount > > point of /. That file system contains a directory /etc. So, in > > the > > Unix "one big file system", the directories / and /etc both come > > from > > the file system on /dev/mapper/sda4_crypt. > > > > 2023-04-19 14:38:19 root@taz ~ > > # df / /etc > > Filesystem 1M-blocks Used Available Use% Mounted on > > /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / > > /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / > > > > > > AIUI you want the file system on the the partition /dev/nvme0n1p5 > > to be > > mounted at /tmp. The way to do that is to put the relevant entry > > back > > into /etc/fstab: > > > > UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2 > > > > And then reboot. > > > > > > > And, would there be anything wrong with, either way, running > > > update- > > > initramfs? > > > > > > Would that be run as: > > > > > > sudo update-initramfs -uv > > > > > > ? > > > > > > Unfortunately, more confusion -- there are two Linux "Initial > > ramdisk" > > solutions with very similar names -- initrd and initramfs. Forget > > about > > those for now. > > > > > > I would add the /etc entry back into /etc/fstab, reboot, run 'df / > > /etc', and see what happens. > > > Correction: > > add the /tmp entry back into /etc/fstab > > > > > > > > David > > >
Okay . . . The problem seems to be solved! What I did: 1) Booted into Debian 11.6 Live/install usb thumb drive. 2) As root, mounted the / partition from the internal ssd. 3) On the internal ssd, replaced /etc/fstab with /etc/fstab.original. (On the internal ssd, I did not delete /tmp or its contents, and did not delete the tmp partition or its contents.) 4) Unmounted the / partition on the internal ssd. 5) Shutdown and removed the usb thumb drive. 6) Booted in to the computer as usual. It *seems* to have worked fine, with /tmp mounted on its dedicated partition again. But there may still be leftover stuff in /tmp, so maybe later I will again boot from the live usb, delete everything in /tmp (but not /tmp itself) on the internal ssd, and reboot into the system, which will presumably have re-populated with no leftovers. So far, so good. Much thanks to all who have weighed in on this!