[SOLVED] Re: /etc/fstab question (problem)?
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!
Reply to: