Re: /etc/fstab question (problem)?
On Tue, 2023-04-18 at 16:53 -0700, David Christensen wrote:
> On 4/18/23 14:42, Default User wrote:
> > On Tue, 2023-04-18 at 13:03 -0700, David Christensen wrote:
> > > On 4/18/23 07:59, Default User wrote:
> > > > Hey, I have a strange situation!
> > > >
> > > > I just realized that my /tmp partition is not being mounted at
> > > > startup.
> > > > Instead, I think the filesystem may be allocating space in
> > > > another
> > > > partition (maybe /root?) for tmp stuff.
>
> > > My / (root) and /tmp directories are on the same file system --
> > > the
> > > root
> > > filesystem:
> > >
> > > 2023-04-18 12:46:41 root@taz ~/taz.tracy.holgerdanske.com
> > > # stat -c %d / /tmp
> > > 65024
> > > 65024
>
> > stat -c %d / /tmp
> > 66306
> > 66306
> > (I am not sure what that means - is that saying that /tmp is
> > mounted
> > under / on the / partition?)
>
>
> stat(1) is saying that the file system entries "/" and "/tmp" have
> the
> same "device number". Device numbers should be unique for the
> various
> file systems that are mounted on one computer:
>
> # mount | perl -ane '$_=$F[2];$dev=(stat)[0];print"$dev $_\n"' | sort
> -n
> /run/user/13250/doc
> 5 /dev
> 6 /sys/kernel/security
> 7 /sys/kernel/debug
> 11 /sys/kernel/tracing
> 19 /dev/mqueue
> 20 /sys
> 21 /proc
> 22 /dev/pts
> 23 /run
> 26 /dev/shm
> 27 /run/lock
> 28 /sys/fs/cgroup
> 29 /sys/fs/pstore
> 30 /sys/firmware/efi/efivars
> 31 /sys/fs/bpf
> 32 /proc/sys/fs/binfmt_misc
> 33 /dev/hugepages
> 34 /sys/fs/fuse/connections
> 35 /sys/kernel/config
> 39 /samba/dpchrist
> 40 /samba/groupshare
> 42 /run/user/13250
> 50 /run/user/0
> 2049 /boot/efi
> 2050 /boot
> 65024 /
> 65026 /scratch
>
>
> That said, I think I prefer the df(1) solution posted by Greg
> Wooledge.
>
>
> > (And BTW, the current /etc/fstab must have been written by some
> > program, not manually by me. I would never have edited /etc/fstab
> > to
> > look like that!) My best guess is that I may have done a system
> > restore
> > using Timeshift on 2023-04-03, to back out of some unremembered
> > problem, and the current /etc/fstab results from that.
>
>
> Backing up system configuration files is good.
>
>
> I use a version control system (CVS), create a project for each host,
> and check in every system configuration file I create, update, or
> delete. I also keep a log.txt file for each system, write notes to
> myself, save console sessions, etc., for when I do need to remember
> what
> I did, when, and why. Rather than restoring entire system
> configuration
> files, I typically use an editor and restore specific settings.
>
>
> > I COULD just continue as is with the current setup, but I would
> > REALLY
> > prefer not to!
>
>
> Why not?
>
>
> > Maybe I should just start by using Clonezilla to do a full image of
> > the
> > drive. Actual data of course, not the entire 256 Gb!
>
>
> Putting your data on a different device than your OS allows you to
> optimize device usage and backup, restore, archive, imaging, etc.,
> procedures.
>
>
> > More later . . .
>
>
> David
>
I have made 2 backups of the ssd, using Clonezilla.
1) a full disk backup,from which the whole disk can be restored.
2) a partitions backup, from which any or all of the individual
partitions can be restored.
Both have been checked by Clonezilla to be restorable.
(Not so) fun fact: Clonezilla always refuses to back up swap
partitions. I don't know why.
FWIW:
df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/nvme0n1p2 23854928 5841496 16776340 26% /
Several different approaches to solve the problem have been suggested.
I think I will wait until tomorrow and ponder the options, before
performing "surgery".
Note: It was asked why I don't just use the current setup, with no
/tmp partition. I guess it goes back to years ago, when I used OpenBSD
for a while. They really pushed the idea of having at least /, /tmp,
/var, swap, and /home partitions. I think the idea is that if something
happens to one partition, it won't affect the others. Like if a process
unexpectedly fills up one partition (/tmp /var, etc.) it probably won't
send the whole system crashing down.
Finally, after the current situation is resolved, I would still like to
know what caused the problem in the first place. I would really like to
not have it happen again!
Reply to: