/etc/fstab question (problem)?

[Default User]

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.

I would like to return to the prior setup, where the /tmp partition is
mounted at startup, and is used for the tmp stuff.

Can I do so without trashing my system, and having to reinstall from
scratch.

Note: I have current system bakups using Timeshift, and current data
(/home/[user]) backups using Borgbackup.

And I can image the ssd with Clonezilla, or even dd, if I have to. But
I would prefer not to go through the hassle of doing so, if it is not
really needed.

I am running Debian 11 Stable (Bullseye).
My computer has a single internal 256 Gb ssd.
I am using Gnome Version 3.38.5 as my desktop environment.

uname -a:
Linux [host name] 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.0.12-1~bpo11+1 (2022-12-19) x86_64 GNU/Linux

mount:
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs
(rw,nosuid,relatime,size=3907040k,nr_inodes=976760,mode=755,inode64)
devpts on /dev/pts type devpts
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=788500k,mode=755,inode64)
/dev/nvme0n1p2 on / type ext4 (rw,relatime,errors=remount-ro)
securityfs on /sys/kernel/security type securityfs
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2
(rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs
(rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs
(rw,relatime,fd=29,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_i
no=786)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs
(rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs
(rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs
(rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl
(rw,nosuid,nodev,noexec,relatime)
/dev/nvme0n1p3 on /var type ext4 (rw,relatime)
/dev/nvme0n1p6 on /home type ext4 (rw,relatime)
/dev/nvme0n1p1 on /boot/efi type vfat
(rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=ascii,shortna
me=mixed,utf8,errors=remount-ro)
tmpfs on /run/user/1000 type tmpfs
(rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,uid=10
00,gid=1000,inode64)
gvfsd-fuse on /run/user/1000/gvfs type fuse.gvfsd-fuse
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
portal on /run/user/1000/doc type fuse.portal
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)

Current /etc/fstab:
# <file system> <mount point> <type> <options> <dump> <pass>

UUID=4fdd4399-6267-404a-a292-
cdc7761df3c9 / ext4 errors=remount-ro 0 1
UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1
UUID=00f0c2db-0490-4354-b949-
f9af11a7f001 /home ext4 defaults 0 2
UUID=8bfeee23-9c09-45b7-a73e-
bd2ff43e207c /var ext4 defaults 0 2
UUID=e2a56ec3-99d4-4b40-9aa4-
24975143cdc7 none swap sw 0 0

Original /etc/fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name
devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see
systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/nvme0n1p2 during installation
UUID=4fdd4399-6267-404a-a292-cdc7761df3c9 / ext4
errors=remount-ro 0 1
# /boot/efi was on /dev/nvme0n1p1 during installation
UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1
# /home was on /dev/nvme0n1p6 during installation
UUID=00f0c2db-0490-4354-b949-f9af11a7f001 /home ext4
defaults 0 2
# /tmp was on /dev/nvme0n1p5 during installation
UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4
defaults 0 2
# /var was on /dev/nvme0n1p3 during installation
UUID=8bfeee23-9c09-45b7-a73e-bd2ff43e207c /var ext4
defaults 0 2
# swap was on /dev/nvme0n1p4 during installation
UUID=e2a56ec3-99d4-4b40-9aa4-24975143cdc7 none swap sw
0 0

ls -lahFi /etc/fstab:
522243 -rw-r--r-- 1 root root 368 Apr 3 17:01 /etc/fstab

ls -lahFi /etc/fstab.original:
522547 -rw-r--r-- 1 root root 1.3K Mar 11 12:02 /etc/fstab.original

lsblk:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
├─nvme0n1p2 259:2 0 23.3G 0 part /
├─nvme0n1p3 259:3 0 9.3G 0 part /var
├─nvme0n1p4 259:4 0 977M 0 part [SWAP]
├─nvme0n1p5 259:5 0 1.9G 0 part
└─nvme0n1p6 259:6 0 202.6G 0 part /home

blkid:
/dev/nvme0n1p1: UUID="26EE-0EF5" BLOCK_SIZE="512" TYPE="vfat"
PARTUUID="c0b4b1bb-bdf3-4066-b75a-f3cf56186e27"
/dev/nvme0n1p2: UUID="4fdd4399-6267-404a-a292-cdc7761df3c9"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="706ab20c-ea65-4c25-a632-
b7858550f966"
/dev/nvme0n1p3: UUID="8bfeee23-9c09-45b7-a73e-bd2ff43e207c"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="0831f4bf-98fc-4189-a3cb-
fc2781e580fb"
/dev/nvme0n1p4: UUID="e2a56ec3-99d4-4b40-9aa4-24975143cdc7" TYPE="swap"
PARTUUID="b32e1385-6518-4d1d-9181-66d31929c7ab"
/dev/nvme0n1p5: UUID="6a105a72-f5d5-441b-b926-1e405151ee84"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="834502f5-08b3-42ad-a322-
cf86732f8155"
/dev/nvme0n1p6: UUID="00f0c2db-0490-4354-b949-f9af11a7f001"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="40721dda-02ba-49a1-abfc-
b624fc739d9f"

What to do?

And if further information is needed, please let me know, and I will
try to get it for you.

Thanks!

[Charles Curley]

On Tue, 18 Apr 2023 10:59:19 -0400
Default User <hungupo...@gmail.com> wrote:

> What to do?

I suspect that what you need to do is:

1) Preserve the current contents of /tmp,

2) Adjust fstab to include the /tmp partition,

3) Mount the /tmp partition

4) Restore the contents of /tmp

You should probably do all of this in single user mode so you don't
have other processes changing things while you're doing this. In
multi-user mode, a process might have a tmp file open, which could
also cause problems.

All of this assumes that the backup from step 1 will fit onto the /tmp
partition. Otherwise you may have to do some manual trimming.

1) Use tar or equivalent to preserve the current contents of /tmp. Then
delete the contents of /tmp. Your Timeshift backups might be recent
enough; check that they include everything currently in /tmp.

2) Copy the lines for /tmp from fstab.original to fstab. Ensure that
the UUIDs are correct, and that you are specifying the partition you
want. Check to see if you are missing any other partitions while you
are at it.

3) Mount the /tmp partition. You will likely find that there are old
files in the partition. You can probably delete them, but the more
paranoid types will preserve them first.

4) Restore the contents of /tmp from the backup you made in step 1.

Good luck!

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[songbird]

Default User wrote:
...
> What to do?

if the tmp partition exists then put it back in your
fstab and see if you can mount it manually. it may or
may not mount. if it doesn't you can reboot and it
should then mount.

of course, make sure you have the mount point defined.

> And if further information is needed, please let me know, and I will
> try to get it for you.
>
> Thanks!

songbird

[Max Nikulin]

On 18/04/2023 22:37, Charles Curley wrote:
> 1) Preserve the current contents of /tmp,
> 2) Adjust fstab to include the /tmp partition,
> 3) Mount the /tmp partition
> 4) Restore the contents of /tmp

Some issues may arise due to files (regular ones, already deleted,
sockets, fifos) opened by running services. /tmp is specific in the
sense that no files are assumed to survive after reboot. I think, it is
better to add the entry for tmp to /etc/fstab and to reboot.

As a final step / may be bind mounted to some other directory to remove
remaining files (to avoid wasting of disk space) or to move them to new
location if you do something special, so it is necessary to keep some
files in /tmp.

[to...@tuxteam.de]

On Tue, Apr 18, 2023 at 09:37:51AM -0600, Charles Curley wrote:
> On Tue, 18 Apr 2023 10:59:19 -0400
> Default User <hungupo...@gmail.com> wrote:
>
> > What to do?
>
> I suspect that what you need to do is:
>
> 1) Preserve the current contents of /tmp,
>
> 2) Adjust fstab to include the /tmp partition,
>
> 3) Mount the /tmp partition
>
> 4) Restore the contents of /tmp

Since Debian erases /tmp at each boot anyway: wouldn't it be
much easier to set up an entry in fstab along the lines of

tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0

(assuming you want a tmpfs there, replace by suitable partition,
options, etc)... and wait for the next reboot to pick it up?

No need to preserve anything, then.

Cheers
--
t

[David Christensen]

I have a 2.5" SATA SSD with an installation of
debian-11.6.0-amd64-netinst via Debian GNU/Linux UEFI Installer menu ->
Install. I tried to KISS and OOTB:

2023-04-18 12:42:22 root@taz ~
# cat /etc/debian_version ; uname -a
11.6
Linux taz 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64
GNU/Linux


Our kernels are different. Did you install a backports kernel?


2023-04-18 12:52:49 root@taz ~
# mount | grep tmp

udev on /dev type devtmpfs

(rw,nosuid,relatime,size=16328088k,nr_inodes=4082022,mode=755)

tmpfs on /run type tmpfs

(rw,nosuid,nodev,noexec,relatime,size=3271028k,mode=755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/user/13250 type tmpfs
(rw,nosuid,nodev,relatime,size=3271024k,nr_inodes=817756,mode=700,uid=13250,gid=13250)
tmpfs on /run/user/0 type tmpfs
(rw,nosuid,nodev,relatime,size=3271024k,nr_inodes=817756,mode=700)

2023-04-18 12:53:32 root@taz ~
# grep tmp /etc/fstab

2023-04-18 12:53:50 root@taz ~
#


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


Your root filesystem is on the NVMe drive, and your /tmp appears to be
on the root filesystem. Run 'stat -c %d / /tmp' to confirm.


I would leave /tmp where it is, unless you have some specific need (such
as a server or application than uses /tmp heavily).


That said, I keep my FOSS OS images small enough to fit onto a "16 GB"
device -- typically an SSD, but also HDD or USB flash drive. When I
want to do audio/ video editing and the SSD has leftover space, I
frequently create a "scratch" partition and filesystem in the free space
and configure the app to use that for temporary files.


David

[Tom Furie]

On Tue, Apr 18, 2023 at 09:00:00PM +0200, to...@tuxteam.de wrote:
> Since Debian erases /tmp at each boot anyway: wouldn't it be
> much easier to set up an entry in fstab along the lines of
>
> tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
>
> (assuming you want a tmpfs there, replace by suitable partition,
> options, etc)... and wait for the next reboot to pick it up?

That gives a memory backed /tmp, which, depending on resources/requirements
may be more or less suitable, for some definition of "suitable".

Cheers,
Tom

--
We are now enjoying total mutual interaction in an imaginary hot tub ...

[Default User]

I did indeed install a kernel from backports, since the sound would not
work on my computer running any earlier kernel. Otherwise, the system
is an updated Debian Stable 11.6 (Bullseye).

>From Ls -lahFi /boot:
total 121M
1305601 drwxr-xr-x 4 root root 4.0K Feb 20 11:51 ./
2 drwxr-xr-x 19 root root 4.0K Feb 19 11:06 ../
1 drwx------ 3 root root 4.0K Dec 31 1969 efi/
1318571 drwxr-xr-x 5 root root 4.0K Apr 17 11:53 grub/
1306753 -rw-r--r-- 1 root root 231K Jan 21 09:35 config-5.10.0-21-
amd64
1318578 -rw-r--r-- 1 root root 252K Dec 19 09:14 config-6.0.0-
0.deb11.6-amd64
1318434 -rw-r--r-- 1 root root 45M Feb 19 09:35 initrd.img-5.10.0-21-
amd64
1318576 -rw-r--r-- 1 root root 61M Feb 19 11:06 initrd.img-6.0.0-
0.deb11.6-amd64
1306752 -rw-r--r-- 1 root root 83 Jan 21 09:35 System.map-5.10.0-21-
amd64
1318577 -rw-r--r-- 1 root root 83 Dec 19 09:14 System.map-6.0.0-
0.deb11.6-amd64
1306754 -rw-r--r-- 1 root root 6.7M Jan 21 09:35 vmlinuz-5.10.0-21-
amd64
1318579 -rw-r--r-- 1 root root 7.4M Dec 19 09:14 vmlinuz-6.0.0-
0.deb11.6-amd64

And this is from the (current) ls -lahFi /tmp:
total 80K
130561 drwxrwxrwt 16 root root 4.0K Apr 18 16:46 ./
2 drwxr-xr-x 19 root root 4.0K Feb 19 11:06 ../
402051 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .font-
unix/
399211 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .ICE-
unix/
402078 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-colord.service-51WIZe/
402064 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-ModemManager.service-fdBA5h/
402060 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-switcheroo-control.service-
el9DGh/
402062 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-systemd-logind.service-sIXjpi/
402055 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-systemd-timesyncd.service-
UtAMlf/
402072 drwx------ 3 root root 4.0K Apr 18 14:44 systemd-
private-9df1dff59a9240c4a708cb146e08a36c-upower.service-yLsogf/
402052 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .Test-
unix/
402080 drwx------ 2 [user] [user] 4.0K Apr 18 14:44 tracker-
extract-files.1000/
402071 drwx------ 2 Debian-gdm Debian-gdm 4.0K Apr 18 14:44 tracker-
extract-files.116/
399209 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .X11-
unix/
402049 drwxrwxrwt 2 root root 4.0K Apr 18 14:44 .XIM-
unix/
136530 srwxrwxrwx 1 root root 0 Apr 18 14:55 dbus-
3cgiNF1x8f=
136016 srwxrwxrwx 1 root root 0 Apr 18 14:55 dbus-
9nSrGDn5m4=
136531 srwxrwxrwx 1 [user] [user] 0 Apr 18 14:44 dbus-
ZLiotP4WWe=
136532 -r--r--r-- 1 [user] [user] 11 Apr 18 14:44 .X0-lock
136017 -r--r--r-- 1 Debian-gdm Debian-gdm 11 Apr 18 14:44 .X1024-
lock
136018 -r--r--r-- 1 Debian-gdm Debian-gdm 11 Apr 18 14:44 .X1025-
lock
136533 -r--r--r-- 1 [user] [user] 11 Apr 18 14:44 .X1-lock

And . . .

cat /etc/debian_version ; uname -a
11.6

Linux dogen 6.0.0-0.deb11.6-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.0.12-
1~bpo11+1 (2022-12-19) x86_64 GNU/Linux

mount | grep tmp:
udev on /dev type devtmpfs

(rw,nosuid,relatime,size=3907040k,nr_inodes=976760,mode=755,inode64)

tmpfs on /run type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=788500k,mode=755,inode64)

tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs
(rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)

tmpfs on /run/user/1000 type tmpfs
(rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,uid=10
00,gid=1000,inode64)

stat -c %d / /tmp

66306
66306
(I am not sure what that means - is that saying that /tmp is mounted
under / on the / partition?)

(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.

I COULD just continue as is with the current setup, but I would REALLY
prefer not to!

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!

More later . . .

[Greg Wooledge]

On Tue, Apr 18, 2023 at 05:42:52PM -0400, Default User wrote:
> stat -c %d / /tmp
> 66306
> 66306
> (I am not sure what that means - is that saying that /tmp is mounted
> under / on the / partition?)

Yes. And by the way, "df /tmp" is a much more intuitive way to get
that same answer.

unicorn:~$ df /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda7 23854928 20508268 2109568 91% /

On my system, just like yours, /tmp is simply a plain ol' directory in
the root file system.

[David Christensen]

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

[Default User]

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!

[Charles Curley]

On Tue, 18 Apr 2023 21:12:33 -0400
Default User <hungupo...@gmail.com> wrote:

> (Not so) fun fact: Clonezilla always refuses to back up swap
> partitions. I don't know why.

Because there is no reason to do so. It has nothing in it of any value,
except possibly to a cracker, and even that is stale.

[David Christensen]

On 4/18/23 18:12, Default User wrote:

>>>> On 4/18/23 07:59, Default User wrote:

>>>>> I just realized that my /tmp partition is not being mounted at
>>>>> startup.

> Finally, after the current situation is resolved, I would still like to
> know what caused the problem in the first place.

Looking back at previous posts:

On 4/18/23 07:59, Default User wrote:

> Current /etc/fstab:
> # <file system> <mount point> <type> <options> <dump> <pass>
>
> UUID=4fdd4399-6267-404a-a292-
> cdc7761df3c9 / ext4 errors=remount-ro 0 1
> UUID=26EE-0EF5 /boot/efi vfat umask=0077 0 1
> UUID=00f0c2db-0490-4354-b949-
> f9af11a7f001 /home ext4 defaults 0 2
> UUID=8bfeee23-9c09-45b7-a73e-
> bd2ff43e207c /var ext4 defaults 0 2
> UUID=e2a56ec3-99d4-4b40-9aa4-
> 24975143cdc7 none swap sw 0 0

> Original /etc/fstab:

> # /tmp was on /dev/nvme0n1p5 during installation
> UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4
> defaults 0 2

It appears that the fstab(5) entry for /etc was dropped when:

On 4/18/23 14:42, Default User wrote:

> 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.

I would try adding the fstab(5) entry for /tmp from the original
/etc/fstab to the current /etc/fstab, and then rebooting.


(If this works, the contents of the /tmp directory of the root file
system will be overlaid by the /tmp file system. To reclaim space on
the root file system, I would boot the system using a live drive or the
d-i rescue shell, mount the root file system at /mnt, and then remove
the contents of /mnt/tmp. Note that you do not want to remove the
/mnt/tmp directory, because it is the mount point for the /tmp file system.)


David

[David Wright]

On Tue 18 Apr 2023 at 21:12:33 (-0400), Default User wrote:
>
> (Not so) fun fact: Clonezilla always refuses to back up swap
> partitions. I don't know why.

It's not clear to me how you could restore the entire rest of the
system to the state it was in when you made your backup of swap.
So the backup copy becomes instantly useless except for forensics
or theft, ie scanning for fragments of text, passwords etc.
That's why I encrypt my swap partitions with a random key.

> Several different approaches to solve the problem have been suggested.
> I think I will wait until tomorrow and ponder the options, before
> performing "surgery".

If you're prepared to reboot, it should be straightforward, but there
is one factor I haven't seen mentioned, and that's to do with cleaning.

If you add the "lost line" back into fstab:

UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2

then when the system starts up, partition 5 will be mounted onto
/tmp in the root filesystem, and then it'll be cleaned of any files
left over from the last time it was used. It might be a long, long
time since you used it so there could conceivably be files that you
want to check out.

So, I would mount partition 5 on /mnt and look it over. Yes, you've
backed up the partition, but you might never look at that, whereas
this is something you can do straightaway.

That aspect was already mentioned by DbB. But there is one further
point to make. AIUI, cleaning will be carried out on /tmp after the
partition (5) has been mounted. It wouldn't make sense otherwise.
But look at your usage of /tmp now—that is, the /tmp in the root
partition. If it contains some large files when you shut down in
preparation to change fstab, then those files, sitting on /, will
never get cleaned. They'll be hidden by mounting partition 5 on
top of them, and use disk space for ever.

So—I would clean /tmp as best you can before you close down, then
boot in single user mode, clean anything still remaining in /tmp,
edit your fstab, and then reboot.

> 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!

It looks as if someone edited the entries with tabs to make it line up
neatly, removed the installers comments, and accidentally removed the
/tmp line too. I don't know of any software that would do that to fstab.

Cheers,
David.

[Stefan Monnier]

> So—I would clean /tmp as best you can before you close down, then
> boot in single user mode, clean anything still remaining in /tmp,
> edit your fstab, and then reboot.

You can also do

mount --bind / /mnt

and then look at /mnt/tmp.
No need to reboot into single-user mode for that.


Stefan

[to...@tuxteam.de]

On Tue, Apr 18, 2023 at 10:15:30PM +0100, Tom Furie wrote:
> On Tue, Apr 18, 2023 at 09:00:00PM +0200, to...@tuxteam.de wrote:
> > Since Debian erases /tmp at each boot anyway: wouldn't it be
> > much easier to set up an entry in fstab along the lines of
> >
> > tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
> >
> > (assuming you want a tmpfs there, replace by suitable partition,
> > options, etc)... and wait for the next reboot to pick it up?
>
> That gives a memory backed /tmp, which, depending on resources/requirements
> may be more or less suitable, for some definition of "suitable".

That's what I meant above with "assuming you want a tmpfs..."

Cheers
--
t

[Max Nikulin]

On 19/04/2023 11:30, to...@tuxteam.de wrote:
>
> That's what I meant above with "assuming you want a tmpfs..."

Some arguments for consideration may be found in

Summary: Moving /tmp to tmpfs makes it useless
https://lists.debian.org/debian-devel/2012/06/msg00311.html

That is linked from
https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK

Or another link:
https://lwn.net/Articles/499410/
Jake Edge. Temporary files: RAM or disk? May 31, 2012

[to...@tuxteam.de]

On Wed, Apr 19, 2023 at 01:15:01PM +0700, Max Nikulin wrote:
> On 19/04/2023 11:30, to...@tuxteam.de wrote:
> >
> > That's what I meant above with "assuming you want a tmpfs..."
>
> Some arguments for consideration may be found in
>
> Summary: Moving /tmp to tmpfs makes it useless
> https://lists.debian.org/debian-devel/2012/06/msg00311.html
>
> That is linked from https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK

What I didn't like from the post is that it doesn't clearly
state the downsides. Too much handwaving and repetition that
"there are downsides" (well, duh), that "some applications
rely on... " (what?). Then he goes on to explain alternatives.

There is one downside to /tmp on tmpfs: it eats RAM. You gotta
have some of it (currently I've 9G free on / and 16G RAM).
That's the only one I can read between the lines in the above
linked post. Do you see any other?

The upsides aren't that spectacular either. If you've enough
RAM, file system caching is so good that tmpfs will only be
marginally faster: The write path to the disk will be a bit
clearer. There will be a bit less CPU usage if your /tmp would
be otherwise on a LUKS partition (mine would).

With a modern (2010s!) laptop not much to write home about.

Of course, I wouldn't propose to set it as a default for a
distro.

Cheers
--
t

[Nicolas George]

to...@tuxteam.de (12023-04-19):

> What I didn't like from the post is that it doesn't clearly
> state the downsides. Too much handwaving and repetition that
> "there are downsides" (well, duh), that "some applications
> rely on... " (what?). Then he goes on to explain alternatives.

“If I can't write gigabytes files, it's completely and utterly useless”
is what I managed to read.

I am not that surprised to find this level of argumentation in a text
that announces its unbalanced conclusion in the title. Like all those
“foobar considered harmful” essays: they usually blame a caricature of
the other side, they argue against the worst possible version of the
idea and thus miss the points of their proponents.

I have only a limited sympathy for the self-styled rational “community”,
but their principle of “steelmaning” the other side argument before
trying to reply is a good one.

> The upsides aren't that spectacular either. If you've enough
> RAM, file system caching is so good that tmpfs will only be
> marginally faster: The write path to the disk will be a bit
> clearer. There will be a bit less CPU usage if your /tmp would
> be otherwise on a LUKS partition (mine would).

Another minor difference that can be a minor upside or downside
depending on the use case: with a tmpfs, the files disappear when the
computer is turned off, with a real filesystem they disappear when it is
turned on.

(I do not know if Debian has provisions to format a /tmp partition with
an ephemeral encryption key on boot, like it has for the swap.)

Regards,

--
Nicolas George

[to...@tuxteam.de]

On Wed, Apr 19, 2023 at 08:55:25AM +0200, Nicolas George wrote:
> to...@tuxteam.de (12023-04-19):

> > What I didn't like from the post [...]

> I am not that surprised to find this level of argumentation in a text

> that announces its unbalanced conclusion in the title [...]

I wouldn't be so harsh, but yes, one gets the impression that
the author wants to reach that conclusion.

I'd agree with them on not chosing that option by default, though.

[...]

> Another minor difference that can be a minor upside or downside
> depending on the use case: with a tmpfs, the files disappear when the
> computer is turned off, with a real filesystem they disappear when it is
> turned on.

Definitely. If you care about minimising data leak opportunities,
keeping /tmp in an encrypted partition seems mandatory.

> (I do not know if Debian has provisions to format a /tmp partition with
> an ephemeral encryption key on boot, like it has for the swap.)

This would be a nice thing, yes (but we know that /tmp is, by default,
on the root partition).

One case where tmpfs for /tmp makes a ton of sense is when you want
to have most things read only (or read mostly), because your devices
die from too much writes (the Raspi/SD pattern, for example -- note
that I wrote SD, not SSD: no monster thread on that, please ;-)

Cheers
--
t

[David Christensen]

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.


David

[Max Nikulin]

On 19/04/2023 13:34, to...@tuxteam.de wrote:
> On Wed, Apr 19, 2023 at 01:15:01PM +0700, Max Nikulin wrote:
>> Summary: Moving /tmp to tmpfs makes it useless
>> https://lists.debian.org/debian-devel/2012/06/msg00311.html
>>
>> That is linked from https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK
>
> What I didn't like from the post is that it doesn't clearly
> state the downsides.

Particular user may run applications requiring more space in /tmp than
is configured by default for RAM disk. Examples are image manipulation,
processing scientific data. The thread contains links to earlier
discussions. I admit that I have more free RAM + buffers than free space
on / as well, but it is a conscious choice.

That is a link that I had. I do not have another one with a better
balanced opinion. My point that the suggestion may lead beginners to
trouble, so they should be warned.

Notice that debian wiki recommends tmp.mount systemd unit instead of
/etc/fstab line. Unsure if provides more flexibility or other advantages.

P.S. Arbitrary time may be invested in optimization attempts. There are
interesting features like swap in RAM (compressed memory pages). Some
people get better performance for tasks like compiling chrome. Some can
not achieve it.

[Max Nikulin]

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.

[to...@tuxteam.de]

On Wed, Apr 19, 2023 at 06:00:53PM +0700, Max Nikulin wrote:
> On 19/04/2023 13:34, to...@tuxteam.de wrote:
> > On Wed, Apr 19, 2023 at 01:15:01PM +0700, Max Nikulin wrote:
> > > Summary: Moving /tmp to tmpfs makes it useless
> > > https://lists.debian.org/debian-devel/2012/06/msg00311.html
> > >
> > > That is linked from https://wiki.debian.org/SSDOptimization/#Reduction_of_SSD_write_frequency_via_RAMDISK
> >
> > What I didn't like from the post is that it doesn't clearly
> > state the downsides.
>
> Particular user may run applications requiring more space in /tmp than is
> configured by default for RAM disk. Examples are image manipulation,
> processing scientific data. The thread contains links to earlier
> discussions. I admit that I have more free RAM + buffers than free space on
> / as well, but it is a conscious choice.

Definitely -- but this will happen to you whatever device you have
backing your /tmp. Arguably, you'll be better off if /tmp has an
own device than when sharing one with /.

> That is a link that I had. I do not have another one with a better balanced
> opinion. My point that the suggestion may lead beginners to trouble, so they
> should be warned.

I don't mind opinions being unbalanced. They usually are (I know mine
are). What miffed me was that they went over many paragraphs telling
that it is bad whithout stating clearly /why/ they think it's bad. I
had to pick up between the lines that they possibly mean you might run
out of space. Well... yes?

> Notice that debian wiki recommends tmp.mount systemd unit instead of
> /etc/fstab line. Unsure if provides more flexibility or other advantages.

No idea. No systemd over here.

> P.S. Arbitrary time may be invested in optimization attempts. There are
> interesting features like swap in RAM (compressed memory pages). Some people
> get better performance for tasks like compiling chrome. Some can not achieve
> it.

Definitely,but we nerds gotta nerd :)

Cheers
--
t

[Default User]

Well, now I am totally confused. 

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.

[David Wright]

I see nothing unreasonable. The only oddity to me is that the listings
you give (which are from the backups, I assume) have today's date,
which means that the backup method is not preserving the file metadata.
(If you've not used partition 5 for a while, the dates should be old.)
It doesn't affect what you're doing now, as all the originals are
heading into oblivion, but I'd be reading the backup spec sometime
to see if I could improve that.

Cheers,
David.

[Default User]

On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote:

1) Would there be anything actually wrong with doing the procedure from
a live usb as I suggested? Even if not strictly necessary?

2) At what point in the procedure would I need to issue the update-
initramfs command. I assume it would be as root user.

[David Wright]

On Wed 19 Apr 2023 at 18:07:51 (+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.

Yes, whichever method you're most comfortable with. Not using
bind mounts for anything that they're required for, I find
them "complicated".

> > +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.

I was merely posting the results of a thought experiment. In reality,
I can just cleanup /tmp on one root filesystem whenever I happen to
have booted into the other system on the same disk (which always exists).

But the point of my post was that past evidence from this list shows
that people have run systems with significant disk usage hidden from
them by being mounted over, and all because they didn't think to look.

> Perhaps update-initramfs is necessary after restoring of /etc/fstab in
> any chosen approach.

I've never seen /etc/fstab other than empty inside an initrd. Maybe
it's init-scheme dependent, IDK.

Cheers,
David.

[Dan Ritter]

Default User wrote:
>
> Well, now I am totally confused. 
>
> 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.

None of dbus, systemd, or any of the Gnome products are relevant
here, and if you want to refer to a partition as /dev/nvme0n1p5,
you can do that.

The extended directions that people have given you are intended
to keep things safe.

> Does that seem reasonable?

Yes, it is.

-dsr-

[Default User]

IIRC, I just did:

sudo <source> <destination> from the live usb.

I didn't think about the changed times.

Perhaps I should have used rsync . . .

Grrr . . .

[David Christensen]

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 ;-)

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

[Default User]

Sorry! That should have been: 

sudo cp -r <source> <destination> from the live usb.

"The Times regrets the error."

:)

[Default User]

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

?

[David Christensen]

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.


David

[David Christensen]

Correction:

add the /tmp entry back into /etc/fstab


>
>
> David
>

[davidson]

Consider the -a option to cp for backup/backdown operations, to
preserve all attributes (including timestamps), recursively copy
directories, and more. Read the manual for details.

--
Hackers are free people. They are like artists. If they are in a good
mood, they get up in the morning and begin painting their pictures.
-- Vladimir Putin

[Default User]

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!

[David Christensen]

On 4/19/23 17:24, 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.

Looking at the Wikipedia page "Initial ramdisk":

https://en.wikipedia.org/wiki/Initrd

AIUI /tmp is mounted after the boot process is finished with the initial
ramdisk. So, there is no need to run update-initramfs(8).

> 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!

I am glad it worked out. :-)


David

[Default User]

Actually, I did it again, using: 
sudo rsync -avv

I don't use cp very often, so I didn't recall the -a option.
Thanks for the info.

Don't know why I didn't use rsync before . . .

[songbird]

David Wright wrote:
...

> I see nothing unreasonable. The only oddity to me is that the listings
> you give (which are from the backups, I assume) have today's date,
> which means that the backup method is not preserving the file metadata.
> (If you've not used partition 5 for a while, the dates should be old.)
> It doesn't affect what you're doing now, as all the originals are
> heading into oblivion, but I'd be reading the backup spec sometime
> to see if I could improve that.

aside rant,

thank gitification for that IMO.

one of the worst design decisions i've come across in
the modern era was the lack of git respecting file metadata.

i got bit by this a few weeks ago yet again. i hate using
git because of it destroying my file meta data.


songbird

[songbird]

<to...@tuxteam.de> wrote:
...

> Definitely,but we nerds gotta nerd :)

haha! :)


songbird (nerd lives matta!

[songbird]

davidson wrote:
...

> Consider the -a option to cp for backup/backdown operations, to
> preserve all attributes (including timestamps), recursively copy
> directories, and more. Read the manual for details.

that's what i use by default for all copies. saves me
a lot of wondering where something might have come from
and also acts as a warning to me when i see something that
should not have changed.

since i frequenlty run into issues with git doing things
i do not like to my file metadata it's something i've become
a bit more wary about. ugh!, blah! and drats!


songbird

[songbird]

Default User wrote:
...

> Well, now I am totally confused. 
>
> 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.

...

i use labels on all of my partitions and give them a
legible name. those are what i use in my fstab and also
in any grub or refind configs.

i hate UUIDS. i do understand what they're for and know
about them, but i do not need them for the simple stuff i'm
doing.


songbird

[Jeremy Ardley]

On 20/4/23 20:10, songbird wrote:
>
> aside rant,
>
> thank gitification for that IMO.
>
> one of the worst design decisions i've come across in
> the modern era was the lack of git respecting file metadata.
>
> i got bit by this a few weeks ago yet again. i hate using
> git because of it destroying my file meta data.
>
>

Not ideal, but you can store your files in a container that maintains
metadata and then store that in git.

Ideally you would want a container application that restores files with
every metadata attribute as at insertion into the container, but for
some purposes that may not be essential for all metadata elements.

--
Jeremy
(Lists)

[Stefan Monnier]

> one of the worst design decisions i've come across in

> the modern era was the lack of Git respecting file metadata.

>
> i got bit by this a few weeks ago yet again. i hate using

> Git because of it destroying my file meta data.

FWIW, I think it makes perfect sense for Git to ignore such metadata
in the context of the intended use of Git (i.e. tracking source code).

But I wish there was a concerted effort to develop/maintain "Git as
a general purpose data storage tool" where various things can be tweaked
depending on the use-case, such as storing metadata, trying to handle
terabyte sized repositories, hash-splitting large files/directories, ...

It could be a sister project of Git.


Stefan

[Vincent Lefevre]

On 2023-04-19 08:34:50 +0200, to...@tuxteam.de wrote:
> There is one downside to /tmp on tmpfs: it eats RAM. You gotta
> have some of it (currently I've 9G free on / and 16G RAM).

True, and when I used tmpfs in the past (in 2012), I got many failures
due to lack of space (because of limited RAM).

> That's the only one I can read between the lines in the above
> linked post. Do you see any other?
>
> The upsides aren't that spectacular either. If you've enough
> RAM, file system caching is so good that tmpfs will only be
> marginally faster: The write path to the disk will be a bit
> clearer. There will be a bit less CPU usage if your /tmp would
> be otherwise on a LUKS partition (mine would).

"marginally faster" is incorrect, but this probably depends on
how fast the disk is. For the MPFR svn-to-git conversion with
reposurgeon 2 years ago, I had to use /dev/shm (tmpfs) because
it was awfully slow on /tmp (but the SSD disk was rather slow:
the new one I got several months later was about 50 times as
fast, IIRC).

--
Vincent Lefèvre <vin...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[Default User]

On Thu, 2023-04-20 at 10:09 +0200, DdB wrote:
> You got your plan mapped out. and i agree, except for one little
> detail:
> see below. -

> Do NOT delete the directory itself, only its content, as it will be
> used
> as the mountpoint for your /tmp drive.

> Please report your success, will you?
>



Actually, I did not end up having to delete anything. From within the
live usb, essentially I just replaced by copying /etc/fstab with
/etc/fstab.original, and the rebooted. I did seem to work, but just to
be thorough, I again booted into the live usb and deleted the contents
of /tmp, which was of course by then on the dedicated tmp partition,
and then rebooted again into the system.

Okay so far, but note that my system is relatively simple, without
anything complex or exotic. Users with more complicated setups might
experience less favorable results.

[to...@tuxteam.de]

On Thu, Apr 20, 2023 at 04:13:48PM +0200, Vincent Lefevre wrote:

[...]

> "marginally faster" is incorrect, but this probably depends on
> how fast the disk is. For the MPFR svn-to-git conversion with
> reposurgeon 2 years ago, I had to use /dev/shm (tmpfs) because
> it was awfully slow on /tmp (but the SSD disk was rather slow:
> the new one I got several months later was about 50 times as
> fast, IIRC).

Hm. Interesting. I'd expected the buffer cache to paper over the
difference (provided you have enough RAM for that, but since we
are comparing that to putting things in tmpfs, by definition, you
have :)

Cheers
--
t

[Jeffrey Walton]

On Thu, Apr 20, 2023 at 10:14 AM Vincent Lefevre <vin...@vinc17.net> wrote:
>
> On 2023-04-19 08:34:50 +0200, to...@tuxteam.de wrote:
> > There is one downside to /tmp on tmpfs: it eats RAM. You gotta
> > have some of it (currently I've 9G free on / and 16G RAM).
>
> True, and when I used tmpfs in the past (in 2012), I got many failures
> due to lack of space (because of limited RAM).

That makes me want to cringe. It brings back memories of Solaris
constantly running out of RAM when trying to run the SunCC compiler.
(Solaris does not over commit memory. You need boatloads of RAM).

Who would want to torture themselves like that?

Jeff

[to...@tuxteam.de]

These were other times. My current lowly laptop's RAM is quite possibly
bigger than your whole hard disk back then.

And -- with one exception (firefox, I'm looking at you!) -- software's
hunger hasn't been able to keep up with that.

Cheers
--
t

[Max Nikulin]

On 20/04/2023 19:05, songbird wrote:

> Default User wrote:
>> And when partitions were named /dev/hda5, not
>> 6a105a72-f5d5-441b-b926-1e405151ee84.
>

> i use labels on all of my partitions and give them a
> legible name. those are what i use in my fstab and also
> in any grub or refind configs.
>
> i hate UUIDS. i do understand what they're for and know
> about them, but i do not need them for the simple stuff i'm
> doing.

Since Default User is playing with restoring partitions from backup and
cloning disks lies somewhere nearby, it may happen that 2 disks with
identical partition labels may be installed simultaneously.

Partition UUIDs are affected as well, but e.g. sgdisk has a dedicated
option:
https://www.rodsbooks.com/gdisk/sgdisk.html
> -G, --randomize-guids
> Randomize the disk's GUID and all partitions' unique GUIDs (but not
> their partition type code GUIDs). This function may be used after
> cloning a disk in order to render all GUIDs once again unique

P.S. Some people hate consistent network device naming that was
introduced to solve the same problem with eth0-like names as the one
caused widespread of UUID in fstab instead of /dev/hdaX.

[Vincent Lefevre]

I think that the issue is that even though there is a buffer cache,
data are written to disk, even when this is not needed for really
temporary data. These write operations make the system slow when it
tries to read other data from the disk.

[Max Nikulin]

On 20/04/2023 19:10, songbird wrote:
> one of the worst design decisions i've come across in
> the modern era was the lack of git respecting file metadata.

In the case of git you can get commit time from git log.

Version control systems update modification time on operations like "git
checkout" or "git pull" to allow build systems, relying on timestamp
comparison (make), to recompile changed files even if source tree is
switched to an older version.

Some build systems make decisions based on file hashes, not their
modification times. It may require a daemon watching file changes to
avoid recalculation of all hashes on each build. So such approach is a
kind of trade-off.

[songbird]

Max Nikulin wrote:
> On 20/04/2023 19:10, songbird wrote:
>> one of the worst design decisions i've come across in
>> the modern era was the lack of git respecting file metadata.
>
> In the case of git you can get commit time from git log.

i do not want commit time, i want the file attributes to
not be f'd with. i know what all you've written below but
it does not apply to what i want or how i use those tools
and i consider git broken that it caters to broken tools
and intentionally then has to screw up information which i
consider both useful and critical to how i do things.

...

> Version control systems update modification time on operations like "git
> checkout" or "git pull" to allow build systems, relying on timestamp
> comparison (make), to recompile changed files even if source tree is
> switched to an older version.

to me that's broken and wrong. if i need to remake a
project then i clean it out and remake it i don't rely
upon anything else to do it and that is also what compiler
caching is for if the project is large enough where it
makes that much of a difference. i don't force another
tool to destroy information.

> Some build systems make decisions based on file hashes, not their
> modification times. It may require a daemon watching file changes to
> avoid recalculation of all hashes on each build. So such approach is a
> kind of trade-off.

not a choice i agree with and so i have to work around
it for my purposes.


songbird

[songbird]

Stefan Monnier wrote:
...

> FWIW, I think it makes perfect sense for Git to ignore such metadata
> in the context of the intended use of Git (i.e. tracking source code).

it didn't make sense to me then and still doesn't
but whatever... :)

> But I wish there was a concerted effort to develop/maintain "Git as
> a general purpose data storage tool" where various things can be tweaked
> depending on the use-case, such as storing metadata, trying to handle
> terabyte sized repositories, hash-splitting large files/directories, ...
>
> It could be a sister project of Git.

there are other attempts which are done for it and
process flows for me but i'd really prefer just a
simple flag or environment variable i could set which
would do it instead so then i'd be able to get rid of
the gyrations.

but it really sux to get a directory structure set
up how i'd like it and the forget that git has this
effect and then come back some time later and see the
mess it's made.


songbird

[Stefan Monnier]

>> It could be a sister project of Git.
> there are other attempts which are done for it and
> process flows for me but i'd really prefer just a
> simple flag or environment variable i could set which
> would do it instead so then i'd be able to get rid of
> the gyrations.

AFAIK the Git maintainers aren't very interested in pushing Git in that
direction (i.e. a generic file storage tool), which is why I think it
needs to be a sister project (at least at first).

BTW, the `bup` tool does add some of the needed functionality
(e.g. storing metadata), but it's not developed with an eye towards
merging some of that extra functionality into Git, and it doesn't aim to
be a "generic file storage tool" either :-(


Stefan

[David Christensen]

Please describe your use-case(s), what the requirements are and why, and
how Git is failing.


David

[songbird]

David Christensen wrote:
...

> Please describe your use-case(s), what the requirements are and why, and
> how Git is failing.

i require maintaining an accurate record of the
file and it's attributes - i consider that a part of
the reason the file exists to begin with (otherwise
why have a different file at all?).

if you change a file, do a git commit then go back
later and do a git restore of a different version it
will not restore the file attributes of that version.
so while i expect to see the right date and time
stamp on a file that has been restored it isn't what
happens.

and no, i don't considering catering to make being
broken or needing to use a time stamp to keep track
of changed file a requirement, if i personally need
to rebuild a project and i'm using git i would make
sure to have things properly cleaned up so that it
would work without me having to not properly record
the file attributes (or to restore them if i need to
use a different version).

in my recent case of git screwing me over i had a
series of files in several directories all with proper
dates and time stamps and i forgot about git being a
git and did a git restore and every subdirectory was
corrupted and i had to go back and restore them
again (and then i removed that project from using git
so i'd not do it again).


songbird

[songbird]

Stefan Monnier wrote:
...

> BTW, the `bup` tool does add some of the needed functionality
> (e.g. storing metadata), but it's not developed with an eye towards
> merging some of that extra functionality into Git, and it doesn't aim to
> be a "generic file storage tool" either :-(

i tried bup for a while but ended up just going back to
using tar as my backups and depending upon other factors
i may use git or not during some development but ultimately
i end up ditching git.


songbird

[Jeremy Ardley]

On 21/4/23 05:41, songbird wrote:
> Stefan Monnier wrote:
>
>
> songbird

I have not used these, but there seem to be some work-arounds for
storing metadata in/with git

lfs has the ability to script xattr handling

https://git-lfs.github.com/

These applications work directly with metadata and can be scripted into
the git process:

Metastore: https://github.com/przemoc/metastore

Git-meta: https://github.com/chasinglogic/git-meta

None of these will handle NTFS Alternate Data Streams, so archive
operations between windows and linux are guaranteed to lose data and
metadata.

--
Jeremy
(Lists)

[David Christensen]

On 4/20/23 14:51, songbird wrote:

So, you need preservation of mtime (?).


Another reader pointed to Git work-arounds, so I will not repeat that.


Another idea would be to use ZFS:

1. Create a ZFS file system for one project.

2. Check-out or create the project working directory within the ZFS
file system.

3. Whenever you check-in, also create a ZFS snapshot.

4. ZFS snapshots can be accessed via the Unix file system at
<mountpoint>/.zfs/snapshot. Both the data and metadata are read-only,
and match the state of the file system when the snapshot was taken.

5. You can roll back a file system to the most recent snapshot with the
'zfs rollback' command. ZFS can also roll back to an older snapshot, if
you are willing to destroy all intermediate snapshots. 'rsync -a' could
achieve the same result without destroying snapshots.

6. Another possibility would be to make a clone based upon a snapshot.


David

[David Wright]

On Thu 20 Apr 2023 at 22:16:56 (+0700), Max Nikulin wrote:
> On 20/04/2023 19:05, songbird wrote:
> > Default User wrote:
> > > And when partitions were named /dev/hda5, not
> > > 6a105a72-f5d5-441b-b926-1e405151ee84.

With modern hardware, you'd probably not want to go back to those
device names, because the way the buses work, the internal drives
can be assigned different names according to what's plugged into
the computer.

> > i use labels on all of my partitions and give them a
> > legible name. those are what i use in my fstab and also
> > in any grub or refind configs.
> >
> > i hate UUIDS. i do understand what they're for and know
> > about them, but i do not need them for the simple stuff i'm
> > doing.
>
> Since Default User is playing with restoring partitions from backup
> and cloning disks lies somewhere nearby, it may happen that 2 disks
> with identical partition labels may be installed simultaneously.
>
> Partition UUIDs are affected as well,

Precisely, and users with a small collection of disks are far more
likely to anticipate and rectify a LABEL collision than a UUID one.
Humans prefer working with names and small numbers rather than
128-bit numbers. It takes little effort to devise a satisfactory
naming scheme.

> but e.g. sgdisk has a dedicated
> option:
> https://www.rodsbooks.com/gdisk/sgdisk.html
> > -G, --randomize-guids
> > Randomize the disk's GUID and all partitions' unique GUIDs (but not
> > their partition type code GUIDs). This function may be used after
> > cloning a disk in order to render all GUIDs once again unique

Very useful for the sysadmin who has a way of keeping track of the
filesystem and partition UUIDS on each disk; the point being that
UUIDs scale well, particularly when handled by software.

Repurposing a well-known meme¹: UUIDs are for people who treat their
disks like cattle, LABELs are for those who treat them like pets.

Were I using UUIDs for unlocking and mounting disks at the command
line, or in files like fstab, the giveaway is that I would have to
depend on the machine to tell me what the UUIDs were, either by
completion, or by copy/paste. Seriously, no one ever types a UUID
into a computer, do they?

> P.S. Some people hate consistent network device naming that was
> introduced to solve the same problem with eth0-like names as the one
> caused widespread of UUID in fstab instead of /dev/hdaX.

That's not the same problem at all. Network device names aren't, and
don't need to be, unique across even just two machines. What they need
to be is stable and persistent on each individual machine. Typically,
the people who dislike them seem to be those who have no necessity for
them, often because their machines contain but a single device. It
seems simple to configure any device names you like, so I don't really
understand why they complain.

¹ originally applied to servers, I believe.

Cheers,
David.

[to...@tuxteam.de]

On Thu, Apr 20, 2023 at 11:29:26PM -0500, David Wright wrote:
> On Thu 20 Apr 2023 at 22:16:56 (+0700), Max Nikulin wrote:
> > On 20/04/2023 19:05, songbird wrote:
> > > Default User wrote:
> > > > And when partitions were named /dev/hda5, not
> > > > 6a105a72-f5d5-441b-b926-1e405151ee84.
>
> With modern hardware, you'd probably not want to go back to those
> device names, because the way the buses work, the internal drives
> can be assigned different names according to what's plugged into
> the computer.

FWIW, I do live with that (laptop here, one spinning rust inside).

The built-in disk is sda, when I stuff a usb stick in, it'll become
sdb unless... I stuff the usb stick too early in the boot process :)

I know this and can cope with it pretty well. But that's what labels
or (ugh) UUIDs were designed to solve.

There's a sweet spot between how much the user should "know" and
how much the system solves implicitly. Where this exactly is depends
on many factors, and it isn't the same for everyone.

Sometimes I doubt we are doing us a favour by making systems "smarter"
and users dumber: we create more and more dependencies.

But hey, that's me.

Cheers
--
t

[rhkr...@gmail.com]

On Wednesday, April 19, 2023 05:02:16 PM Default User wrote:
> sudo cp -r <source> <destination> from the live usb.

Recently I've been trying to get in the habit of using cp -aru because those
options do what I usually want:

* -a preserves dates (and ownership and permissions), and doesn't follow
(copy from) symbolic links
* -r recurses through subdirectories
* -u copies only if the destination file is older than the file to be copied

--
rhk

(sig revised 20230312 -- modified first paragraph, some other irrelevant
wordsmithing)

| No entity has permission to use this email to train an AI.

If you reply: snip, snip, and snip again; leave attributions; avoid HTML;
avoid top posting; and keep it "on list". (Oxford comma (and semi-colon)
included at no charge.) If you revise the topic, change the Subject: line.
If you change the topic, start a new thread.

Writing is often meant for others to read and understand (legal documents
excepted?) -- make it easier for your reader by various means, including
liberal use of whitespace (short paragraphs, separated by whitespace / blank
lines) and minimal use of (obscure?) jargon, abbreviations, acronyms, and
references.

If someone has already responded to a question, decide whether any response
you add will be helpful or not ...

A picture is worth a thousand words. A video (or "audio"): not so much --
divide by 10 for each minute of video (or audio) or create a transcript and
edit it to 10% of the original.

A speaker who uses ahhs, ums, or such may have a real physical or mental
disability, or may be showing disrespect for his listeners by not properly
preparing in advance and thinking before speaking. (That speaker might have
been "trained" to do this by being interrupted often if he pauses.) (Remember
Cicero who did not have enough time to write a short missive.)

A radio (or TV) station which broadcasts speakers with high pitched voices (or
very low pitched / gravelly voices) (which older people might not be able to
hear properly) disrespects its listeners. Likewise if it broadcasts
extraneous or disturbing sounds (like gunfire or crying), or broadcasts
speakers using their native language (with or without an overdubbed
translation).

A person who writes a sig this long probably has issues and disrespects (and
offends) a large number of readers. ;-)
'

[Greg Wooledge]

On Fri, Apr 21, 2023 at 04:59:36AM -0400, rhkr...@gmail.com wrote:
> On Wednesday, April 19, 2023 05:02:16 PM Default User wrote:
> > sudo cp -r <source> <destination> from the live usb.
>
> Recently I've been trying to get in the habit of using cp -aru because those
> options do what I usually want:
>
> * -a preserves dates (and ownership and permissions), and doesn't follow
> (copy from) symbolic links
> * -r recurses through subdirectories
> * -u copies only if the destination file is older than the file to be copied

In GNU cp(1):

-a, --archive
same as -dR --preserve=all

-d same as --no-dereference --preserve=links

-R, -r, --recursive
copy directories recursively

So, your -r is redundant. It's included in the -a.

[Max Nikulin]

On 20/04/2023 04:03, David Christensen wrote:
> * 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?

David, you were wrote /etc instead of /tmp in several messages, so at
certain moment I thought that original issue was due to attempt to
really mount another partition to /etc (e.g. for easier backups). Later
an entry for /tmp was added to fstab on mounted partition, perhaps new
version of fstab even propagated to initramfs. However after reboot
there was no an entry for /etc in the /etc/fstab file residing on the
root partition, so init had no change to mount /etc with another fstab
(with the entry for /etc). It is literally bootstrap problem.
Fortunately Default User posted complete fstab, so it was possible to
rule out such hypothesis.

I used initramfs and initrd as synonyms because of file names
/boot/initrd* and update-initramfs command. Even though /tmp entry
should not be necessary during early init, I believe, it is safer to run
"update-initrams -u" just to avoid surprise due to changes in fstab
several days or weeks later when kernel update will arrive. It would be
much harder to associate boot failure with fstab restored from backup
instead of "broken" kernel package.

I am glad to read that the issue is solved, I see no problem with using
of live image (it is wise to always have it available).

I think, in this case live image (unlike reboot) was not strictly
necessary and may reduce down time if it is critical. I think, the
following is safe enough (not verified, may contain typos or even errors):
- backup /etc/fstab and current initrd
- have a look into grub.cfg and grub manual to be able to boot using
backup file
- restore /etc/fstab from backup
- Do not run "systemctl daemon-reload", since till shutdown systemd
should work accordingly to content of old fstab version
- update-initramfs -u
- reboot. It is required after adding /tmp to fstab to make new fstab
active and after update-initramfs to verify that new fstab does cause
boot issue. Single reboot should be enough, however another one before
update-initramfs is possible.
- mount --bind / /mnt
- remove files from /mnt/tmp/ remained from the previous boot. Otherwise
some large file hidden by mounted /tmp may reduce free space available
on the / partition
- umount /mnt
- remove initrd backup

[songbird]

Jeremy Ardley wrote:
...

> I have not used these, but there seem to be some work-arounds for
> storing metadata in/with git
>
> lfs has the ability to script xattr handling
>
> https://git-lfs.github.com/

i'll look at that one and see if it brings things to mind
that i've already messed with it before. sometimes i go
looking and do try things, but my recent few months have
been busy with other projects.

um, no, i don't want large files being shipped off or
linked to some other service. that's not what my gripe
is about at all.

> These applications work directly with metadata and can be scripted into
> the git process:
>
> Metastore: https://github.com/przemoc/metastore
>
> Git-meta: https://github.com/chasinglogic/git-meta

i've dabbled with that one but not gone further.

> None of these will handle NTFS Alternate Data Streams, so archive
> operations between windows and linux are guaranteed to lose data and
> metadata.

i don't do stuff with Windows or NTFS any longer so that
doesn't matter to me, i just want file attributes copied
and restored properly.


songbird

[David Christensen]

On 4/21/23 08:12, Max Nikulin wrote:
> On 20/04/2023 04:03, David Christensen wrote:
>> * 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?
>
> David, you were wrote /etc instead of /tmp in several messages,

I apologize for the errors. :-(


I will strive to do more proofreading before posting.

> I used initramfs and initrd as synonyms because of file names
> /boot/initrd* and update-initramfs command. Even though /tmp entry
> should not be necessary during early init, I believe, it is safer to run
> "update-initrams -u" just to avoid surprise due to changes in fstab
> several days or weeks later when kernel update will arrive. It would be
> much harder to associate boot failure with fstab restored from backup
> instead of "broken" kernel package.

I am unaware of any single document that would allow us to definitively
answer the question "what does initrd.img depend upon?". If anyone
knows of such, please provide a citation.


I find it strange that we run a tool named "update-initramfs" to update
a file named "initrd.img-*". Should not the tool be named "update-initrd"?


I would like to imagine that running update-initramfs(8) is always safe,
but I seem to be running into a lot of WTF's on Linux and/or Debian again.

> I am glad to read that the issue is solved, I see no problem with using
> of live image (it is wise to always have it available).
>
> I think, in this case live image (unlike reboot) was not strictly
> necessary and may reduce down time if it is critical. I think, the
> following is safe enough (not verified, may contain typos or even errors):
> - backup /etc/fstab and current initrd
> - have a look into grub.cfg and grub manual to be able to boot using
> backup file
> - restore /etc/fstab from backup
> - Do not run "systemctl daemon-reload", since till shutdown systemd
> should work accordingly to content of old fstab version
> - update-initramfs -u
> - reboot. It is required after adding /tmp to fstab to make new fstab
> active and after update-initramfs to verify that new fstab does cause
> boot issue. Single reboot should be enough, however another one before
> update-initramfs is possible.
> - mount --bind / /mnt
> - remove files from /mnt/tmp/ remained from the previous boot. Otherwise
> some large file hidden by mounted /tmp may reduce free space available
> on the / partition
> - umount /mnt
> - remove initrd backup

As for the Linux initial ramdisk, and ignoring system configuration
settings in memory:

* The Linux initial ramdisk is a cache used by the boot process. If
system configuration settings in a file on primary storage are created/
updated/ deleted, if initrd.img depends upon those settings, and if the
initrd.img is not updated, then the system configuration settings exist
in two places and those settings are out-of-sync [1,2]. When the system
is rebooted, the resulting system configuration will be a mixture of
settings from primary storage files and from initrd.img.

* AIUI the BSD's do not have an initial ramdisk. If system
configuration settings in a file on primary storage are created/
updated/ deleted, then the system configuration settings exist in only
one place. When the system is rebooted, the resulting system
configuration will be unambiguous.


As for systemd:

* AIUI systemd is a system management database comprised of text and
binary files. systemd may hook into initrd.img. I assume systemd has a
non-trivial schema with referential integrity requirements. The text
files must have a syntax and the binary files must have a file
structure. There must be an API to perform operations on all or part of
the database. My interactions with systemd have been limited to running
systemd CLI programs. If and when the systemd database and/or
initrd.img components are damaged and/or out-of-sync such that boot
fails, I have no idea how to fix that.

* AIUI FreeBSD is configured via text files. I can edit them, check
them into a version control system, run them through shell pipelines,
etc.. If and when the system configuration is damaged such that boot
fails, I know how to boot live media, mount filesystems, and work on
those files.


David

[1] https://en.wikipedia.org/wiki/Don't_repeat_yourself

[2] https://www.martinfowler.com/bliki/TwoHardThings.html

[Max Nikulin]

On 21/04/2023 00:43, songbird wrote:
> Max Nikulin wrote:
>> On 20/04/2023 19:10, songbird wrote:
>>> one of the worst design decisions i've come across in
>>> the modern era was the lack of git respecting file metadata.
>

> i know what all you've written below but
> it does not apply to what i want or how i use those tools
> and i consider git broken that it caters to broken tools
> and intentionally then has to screw up information which i
> consider both useful and critical to how i do things.

Then I have no idea what you were trying to achieve by your original
message.

It is perfectly valid to warn people that git is not an appropriate tool
when file attributes audit is involved. I can understand if somebody is
pushing you toward git. At the same time I see nothing bad in tracking
config files in git.

If you are looking for a backup tool that keeps metadata then it is
better to ask it explicitly to to get suggestions like rdiff-backup.

Ignorance may be an excuse, but you said it is not the case. For me it
is too much to blame developers with harsh statements concerning design
decisions just because a tool was created for different tasks.

Git appeared as a tool for linux kernel, a project that relies on make.
Frequent incremental rebuilds are must have for developers. Git has some
weak sides, but there is no point to attack its features. Git is a great
step forward in comparison to CVS and SVN. Experiments with version
control systems and build tools have not seized, likely we will see
better ones.

Precise tracking of file attributes can cause troubles for VCS. Various
file systems have different set of attributes, incompatible time
precision. There is no point to track UIDs at all.

I admit, for reproducible builds that include unprocessed files from
repository, git behavior is not perfect.

Do not confuse a conscious design choice (even if it is a trade-off) and
wrong selection of a tool that is inappropriate for specific purpose.

>> Some build systems make decisions based on file hashes, not their
>> modification times. It may require a daemon watching file changes to
>> avoid recalculation of all hashes on each build. So such approach is a
>> kind of trade-off.
>
> not a choice i agree with and so i have to work around
> it for my purposes.

File hash approach is for developers relying on incremental rebuilds and
caching of build results. It is a way to avoid changing of mtime on
checkout.

P.S. Old version of git FAQ explains taken mtime approach in the same
way. Build tools relies of modification time comparison:
https://archive.kernel.org/oldwiki/git.wiki.kernel.org/index.php/Git_FAQ.html#Why_isn.27t_Git_preserving_modification_time_on_files.3F
(New one is rather brief https://git-scm.com/docs/gitfaq)

[David Wright]

On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:
> On 4/21/23 08:12, Max Nikulin wrote:
> > On 20/04/2023 04:03, David Christensen wrote:
> > > * 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?

With one exception, I've not seen root (whichever process that
refers to) doing anything like that in anticipation of mounting
a filesystem, so I wondered where that realisation came from.
The exception (which I haven't actually observed) is run-init
tearing down the initramfs before the true root is mounted.

> > I used initramfs and initrd as synonyms because of file names
> > /boot/initrd* and update-initramfs command. Even though /tmp entry
> > should not be necessary during early init, I believe, it is safer
> > to run "update-initrams -u" just to avoid surprise due to changes
> > in fstab several days or weeks later when kernel update will
> > arrive. It would be much harder to associate boot failure with
> > fstab restored from backup instead of "broken" kernel package.

The OP obviously has a problem with /etc/fstab, in that they reported
modifications having been made by an unknown agent. An important hint
in determining what might have been responsible is to know the
modification timestamp of the altered file, and whether any other
files were modified within a short period bracketing that time.
The OP's backup methods might not be up to that task if they're
losing the metadata, but it's worth checking: the backups might
also be stored elsewhere, with dates in their names, etc.

AFAICT running update-initramfs has no effect as its /etc/fstab will
remain empty. The booting kernel uses the root filesystem's fstab,
located by the root= on the kernel command line. Upgrading the kernel
will run update-initramfs, but not for any effect on the contained
/etc/fstab.

In fact, it's difficult to see any advantage in adding entries to
the /etc/fstab in the initramfs. You would lose one of the important
properties of the kernel/initrd pair which is that you can run it
on a different machine with different root filesystems (selected
by root=…) without having to modify them. (Cast your mind back to days
of yore, when we had to run rdev to modify bytes at a certain kernel
offset to change the root filesystem it would boot.)

> I am unaware of any single document that would allow us to
> definitively answer the question "what does initrd.img depend upon?".
> If anyone knows of such, please provide a citation.

/usr/sbin/mkinitramfs and the configuration parameters that it reads
from /etc/initramfs/, I guess. (I assume you're not wanting to read
about how the kernel turns compressed cpio archives into a cached
filesystem.)

> I find it strange that we run a tool named "update-initramfs" to
> update a file named "initrd.img-*". Should not the tool be named
> "update-initrd"?

No, the initrd ought to be called initramfs. I think the changeover
from ram disk to ram filesystem was during 2.6 kernel versions.
I assume the name just stuck.

> I would like to imagine that running update-initramfs(8) is always
> safe, but I seem to be running into a lot of WTF's on Linux and/or
> Debian again.

It should always be safe, but be aware that initrds have got quite
large nowadays, particularly with MODULES=most, so people with /boot
on its own partition have to keep an eye on free space.

> As for the Linux initial ramdisk, and ignoring system configuration
> settings in memory:
>

> * The Linux initial ram[fs] is a cache used by the boot process. If

> system configuration settings in a file on primary storage are
> created/ updated/ deleted, if initrd.img depends upon those settings,
> and if the initrd.img is not updated, then the system configuration
> settings exist in two places and those settings are out-of-sync [1,2].
> When the system is rebooted, the resulting system configuration will
> be a mixture of settings from primary storage files and from
> initrd.img.

That's why you see update-initramfs being run any time the relevant
parts of the configuration change, avoiding that situation.

> * AIUI the BSD's do not have an initial ramdisk. If system
> configuration settings in a file on primary storage are created/
> updated/ deleted, then the system configuration settings exist in only
> one place. When the system is rebooted, the resulting system
> configuration will be unambiguous.

Yes, I remember building custom kernels years ago, where you had to
build in all the modules that might ever be necessary to find and
mount the root filesystem. And all that code ran in kernel space.
The benefit of an initramfs is that you don't need any filesystem
drivers built into the kernel (you would need one were you to use
a ram /disk/), and most of the code, which can be complex and
extensive, runs in user space. Think decryption, RAID, networked
file systems etc.

> As for systemd:
>
> * AIUI systemd is a system management database comprised of text and
> binary files.

Is that right? I know systemd uses binary files for its logging
(though it can and does write traditional text ones too). But can
you point out some binary configuration files that systemd uses.

> systemd may hook into initrd.img.

Hmm, I got the impression that systemd, /sbin/init, PID1, started just
as run-init finished tearing down all remnants of the initramfs, and
mounted the real root filesystem.

Looking for the string systemd in my own initrd.img, I have the binary:

-rwxr-xr-x 1 678392 Apr 27 2020 main/usr/lib/systemd/systemd-udevd

which looks like a slimmed down version of /bin/udevadm. It's
difficult to imagine initramfs not containing udev. IDK whether
non-systemd users have their own, special version of udev to avoid
having a systemd hook into initrd.img.

Then I see main/usr/lib/modprobe.d/systemd.conf containing two lines:

options bonding max_bonds=0
options dummy numdummies=0

which is something to do with preventing bonding if/when some kernel
module is loaded during the initramfs phase.

Lastly, I see main/usr/lib/systemd/network/99-default.link containing:

[Link]
NamePolicy=keep kernel database onboard slot path
MACAddressPolicy=persistent

which is the backstop for udev's handling of network interfaces.

> I assume systemd has
> a non-trivial schema with referential integrity requirements. The
> text files must have a syntax and the binary files must have a file
> structure. There must be an API to perform operations on all or part
> of the database.

Sorry, which operations on what database?

> My interactions with systemd have been limited to
> running systemd CLI programs. If and when the systemd database and/or
> initrd.img components are damaged and/or out-of-sync such that boot
> fails, I have no idea how to fix that.

Sorry, you've lost me; I thought it was the kernel that booted a linux
system, not systemd.

> * AIUI FreeBSD is configured via text files. I can edit them, check
> them into a version control system, run them through shell pipelines,
> etc.. If and when the system configuration is damaged such that boot
> fails, I know how to boot live media, mount filesystems, and work on
> those files.

Funny—that's rather like what we sysadmins do on linux, apart from
being rather vague when compared with the specific details we are
dissecting here.

> [1] https://en.wikipedia.org/wiki/Don't_repeat_yourself

When an ocean liner leaves port, it doesn't use its main engines:
tugs tow it out of the harbour using their engines. The ship's master
wouldn't be able to navigate the liner into the main channel, but a
pilot handles that with ease, before disappearing over the side into
a pilot boat. Once at sea, the liner needs neither tugs nor pilot.

Cheers,
David.

[David Christensen]

On 4/22/23 08:24, David Wright wrote:
> On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:
>> On 4/21/23 08:12, Max Nikulin wrote:
>>> On 20/04/2023 04:03, David Christensen wrote:
>>>> * 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?
>
> With one exception, I've not seen root (whichever process that
> refers to) doing anything like that in anticipation of mounting
> a filesystem, so I wondered where that realisation came from.
> The exception (which I haven't actually observed) is run-init
> tearing down the initramfs before the true root is mounted.

You're right; what I wrote makes no sense -- because it is wrong:

On 4/21/23 08:12, Max Nikulin wrote:

> David, you were wrote /etc instead of /tmp in several messages

On 4/21/23 15:46, David Christensen wrote:
> I apologize for the errors. :-(

<snip>

"Back in the day", people running Linux had computers with limited
amounts of storage and memory. I imagine an initial ramdisk seemed like
an good trade-off/ work-around at that time.


But today, this is my Linux daily driver:

2023-04-22 16:25:50 root@taz ~
# cat /etc/debian_version ; uname -a
11.6
Linux taz 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64
GNU/Linux

2023-04-22 17:52:29 root@taz ~
# lsmem
RANGE SIZE STATE REMOVABLE BLOCK
0x0000000000000000-0x000000007fffffff 2G online yes 0-15
0x0000000100000000-0x000000087fffffff 30G online yes 32-271

Memory block size: 128M
Total online memory: 32G
Total offline memory: 0B

2023-04-22 18:40:09 root@taz ~
# df /boot
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/sda2 921M 114M 744M 14% /boot

2023-04-22 16:26:05 root@taz ~
# ls -l /boot/initrd.img-5.10.0-21-amd64 /boot/vmlinuz-5.10.0-21-amd64
-rw-r--r-- 1 root root 47837534 Mar 18 19:23
/boot/initrd.img-5.10.0-21-amd64
-rw-r--r-- 1 root root 7019136 Jan 21 06:35 /boot/vmlinuz-5.10.0-21-amd64


The Linux kernel is ~7 MB and initrd.img is ~48 MB. My daily driver is
complete overkill.


Even my 2007 laptop has 2 GB of memory an a 1 GB boot partition/
filesystem. Still overkill.


I would gladly accept a 48 MB vmlinuz to be rid of initrd.img and its
complexities.


The resource hogs today are the apps, not the OS. Give me a KISS OS.


David

[David Wright]

On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote:
> On 4/22/23 08:24, David Wright wrote:
> > On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:
> > > On 4/21/23 08:12, Max Nikulin wrote:
> > > > On 20/04/2023 04:03, David Christensen wrote:
> > > > > * 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?
> >
> > With one exception, I've not seen root (whichever process that
> > refers to) doing anything like that in anticipation of mounting
> > a filesystem, so I wondered where that realisation came from.
> > The exception (which I haven't actually observed) is run-init
> > tearing down the initramfs before the true root is mounted.
>
>
> You're right; what I wrote makes no sense -- because it is wrong:
>
> On 4/21/23 08:12, Max Nikulin wrote:
> > David, you were wrote /etc instead of /tmp in several messages
>
> On 4/21/23 15:46, David Christensen wrote:
> > I apologize for the errors. :-(

I had seen your correction, but my point wasn't dependent on any
particular choice of directory, but with mounting filesystems
in general—onto any mountpoint.

> "Back in the day", people running Linux had computers with limited
> amounts of storage and memory. I imagine an initial ramdisk seemed
> like an good trade-off/ work-around at that time.
>
> But today, this is my Linux daily driver:

> Total online memory: 32G

That must be nice. I don't know what it might have cost. I'm afraid
I only use cast-offs. The oldest has ½GB memory.

> # ls -l /boot/initrd.img-5.10.0-21-amd64 /boot/vmlinuz-5.10.0-21-amd64
> -rw-r--r-- 1 root root 47837534 Mar 18 19:23
> /boot/initrd.img-5.10.0-21-amd64
> -rw-r--r-- 1 root root 7019136 Jan 21 06:35 /boot/vmlinuz-5.10.0-21-amd64

> The Linux kernel is ~7 MB and initrd.img is ~48 MB. My daily driver
> is complete overkill.

I think your kernel is probably more like 12.3MB of code. Your initrd
is larger than mine: I'd have to see inside to tell why, but no matter.

> Even my 2007 laptop has 2 GB of memory an a 1 GB boot partition/
> filesystem. Still overkill.

Overkill for what? I don't understand.

> I would gladly accept a 48 MB vmlinuz to be rid of initrd.img and its
> complexities.
>
> The resource hogs today are the apps, not the OS. Give me a KISS OS.

I can't understand why one would want to load all that kernel code
just to not use it. OK, for some reason you find the initrd complex.
(I don't any details about how freeBSD boots up as I haven't used it.)
I know you not interested in how it works or what it's for. I don't
see any sign that you've had difficulties in setting it up; it's just
there. It gets generated by the installer, and updated at various
times, like kernel upgrades. So what are you here for? To tell us
you're confused? To debate its name? To campaign for its abolition?
To throw mud? To say WTF to yourself again?

Cheers,
David.

[David Christensen]

On 4/22/23 21:11, David Wright wrote:
> On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote:
>> On 4/22/23 08:24, David Wright wrote:
>>> On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:
>>>> On 4/21/23 08:12, Max Nikulin wrote:
>>>>> On 20/04/2023 04:03, David Christensen wrote:
>>>>>> * 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?
>>>
>>> With one exception, I've not seen root (whichever process that
>>> refers to) doing anything like that in anticipation of mounting
>>> a filesystem, so I wondered where that realisation came from.
>>> The exception (which I haven't actually observed) is run-init
>>> tearing down the initramfs before the true root is mounted.
>>
>>
>> You're right; what I wrote makes no sense -- because it is wrong:
>>
>> On 4/21/23 08:12, Max Nikulin wrote:
>>> David, you were wrote /etc instead of /tmp in several messages
>>
>> On 4/21/23 15:46, David Christensen wrote:
>>> I apologize for the errors. :-(
>
> I had seen your correction, but my point wasn't dependent on any
> particular choice of directory, but with mounting filesystems
> in general—onto any mountpoint.

AIUI open(2) returns a file handle that a process uses to access file
contents. If a second file system is mounted such that it overlays the
file path while the file is still open, the process can still make
system calls using the file descriptor (read(2), write(2), lseek(2),
close(2)). But if the process makes system calls using the file path
(notably unlink(2)), there are several possibilities:

1. The process may not have authority to access that path.

2. The path may not exist.

3. The process may find an old file, directory, or something at that path.

4. The process may find a new and in-use something at that path which
belongs to another process.


My conclusion was that the safest approach would be for the OP to
restore the fstab(5) entry for /tmp and reboot. This keeps file
descriptors and file paths consistent -- both during shutdown and during
the next start-up (including the case where mounting the second file
system fails).

>
>> "Back in the day", people running Linux had computers with limited
>> amounts of storage and memory. I imagine an initial ramdisk seemed
>> like an good trade-off/ work-around at that time.
>>
>> But today, this is my Linux daily driver:
>
>> Total online memory: 32G
>
> That must be nice. I don't know what it might have cost. I'm afraid
> I only use cast-offs. The oldest has ½GB memory.

https://www.ebay.com/itm/393918586141

>
>> # ls -l /boot/initrd.img-5.10.0-21-amd64 /boot/vmlinuz-5.10.0-21-amd64
>> -rw-r--r-- 1 root root 47837534 Mar 18 19:23
>> /boot/initrd.img-5.10.0-21-amd64
>> -rw-r--r-- 1 root root 7019136 Jan 21 06:35 /boot/vmlinuz-5.10.0-21-amd64
>
>> The Linux kernel is ~7 MB and initrd.img is ~48 MB. My daily driver
>> is complete overkill.
>
> I think your kernel is probably more like 12.3MB of code.

Where do you get 12.3MB?

> Your initrd
> is larger than mine: I'd have to see inside to tell why, but no matter.
>
>> Even my 2007 laptop has 2 GB of memory an a 1 GB boot partition/
>> filesystem. Still overkill.
>
> Overkill for what? I don't understand.

2 GB of memory and 1 GB of boot file system are more than enough to boot
Linux or FreeBSD.


<snip>

David

[songbird]

David Wright wrote:
...

> That must be nice. I don't know what it might have cost. I'm afraid
> I only use cast-offs. The oldest has ½GB memory.

i have some older memory sticks and chips that i will gladly
send to anyone who has older machines. the only condition i
would have for the gift is to pass them on to anyone else who
might need them as i'm not going to "part out" the list to one
item at a time. so you get the whole small pile of sticks/chips.


first come, first served. send me an e-mail (to this address)
with your mailing address.

let me see what i have (i'm in need of a distraction this
morning so here's the list as best i can see them - i'm not
a PC or memory guru so i don't know exactly what these are
now as it has been quite some time since i pulled them and
aside from what is right on the chips all i can say is that
they were working when i pulled them):


(pins not as well plated with gold)
2 pcs - IC side markings HYUNDAI KOREA, 8 IC's,
(markings on IC HY5117400A J-70 9629A KOREA)
- 1 other side markings ST-102A HYM532410AM-70 6H82AA
- 2 other side markings ST-103 HYM532410AM-70 6H82AA
- 72 pins if the numbers next to the pins are right


(these ones are heavier and have a nice layer of gold
on the pins compared to the ones above i'd say they
are works of art)
2 pcs - IC side markings MADE IN JAPAN, 8 IC's
both marked QQ18UU 94-VO HB56A13 2BV-7B 9419
- other side marking on both was SAN-TM94VO
one marked AD, other marked BB
- 72 pins


2 pcs - came from a COMPAC pc, 8 IC's on one side
(the B might be an 8)
both marked MTBLSDT864AG-10EC7 PC100-222-620,
one says 64MB, SYNCH, 100MHz, CL2 other doesn't
both have part number sticker and other numbers
on them - i'm not putting them on here...
- 84 pins


1 pc - 8 IC's on each side, very thin,
printed on tag:
MT1GLSTDT464AG-10BC4 9829 DA ST 617054 PC100-323-620
the printing is very light on the ICs, i can barely see
them (as best i can make it out)
9828 C USA MT 48LC2M8A1 TG -8B S
- 84 pins


1 pc - 8 IC's total more pins than 84 (i ain't counting them)
INFINEON
printed on tag:
HYS64D32300HU-5-C C3E53318
Assembled in Malaysia
256MB, DDR, 400, CL3 PC3200U-30330-A0


songbird

[songbird]

songbird wrote:


...
all set thanks for the reply.


songbird

[Celejar]

On Wed, 19 Apr 2023 08:55:25 +0200
Nicolas George <geo...@nsup.org> wrote:

...

> (I do not know if Debian has provisions to format a /tmp partition with
> an ephemeral encryption key on boot, like it has for the swap.)

It apparently does not, and apparently other distributions do not as
well. Here's a post on the CentOS Wiki describing how to do it, but it
involves a (small) unofficial, homegrown script:

https://wiki.centos.org/HowTos/EncryptTmpSwapHome

I wonder why this is not a standard option provided by distributions?

--
Celejar

[Celejar]

On Wed, 19 Apr 2023 09:52:23 +0200
to...@tuxteam.de wrote:

...

> One case where tmpfs for /tmp makes a ton of sense is when you want
> to have most things read only (or read mostly), because your devices
> die from too much writes (the Raspi/SD pattern, for example -- note
> that I wrote SD, not SSD: no monster thread on that, please ;-)

To be fair to the post [0] mentioned earlier, while the subject line was
provocative, the post itself explicitly acknowledges that tmpfs
for /tmp does make sense in some cases, although you may disagree that
they're as "rare" as it claims :)

"Mounting /tmp to tmpfs may be a good thing in some rare cases, but it's
a bad default. It breaks a lot of things and, which is more important,
brings nothing good."

[0] https://lists.debian.org/debian-devel/2012/06/msg00311.html

--
Celejar

[Celejar]

On Sun, 23 Apr 2023 01:14:05 -0700
David Christensen <dpch...@holgerdanske.com> wrote:

> On 4/22/23 21:11, David Wright wrote:
> > On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote:

...

> >> "Back in the day", people running Linux had computers with limited
> >> amounts of storage and memory. I imagine an initial ramdisk seemed
> >> like an good trade-off/ work-around at that time.
> >>
> >> But today, this is my Linux daily driver:
> >
> >> Total online memory: 32G
> >
> > That must be nice. I don't know what it might have cost. I'm afraid
> > I only use cast-offs. The oldest has ½GB memory.
>
>
> https://www.ebay.com/itm/393918586141

I have something similar - an HP Z440 with 32GB of RAM. It's not quite
as "modern" as the Precision at that link, but it can currently be
readily found for as little as $250 USD (doubtless less if one scrounges
around):

https://www.ebay.com/itm/225546840287

--
Celejar

[to...@tuxteam.de]

On Mon, Apr 24, 2023 at 12:16:36PM -0400, Celejar wrote:
> On Wed, 19 Apr 2023 09:52:23 +0200
> to...@tuxteam.de wrote:

[...]

> "Mounting /tmp to tmpfs may be a good thing in some rare cases, but it's
> a bad default. It breaks a lot of things and, which is more important,
> brings nothing good."

"A lot of things" means here: it can run out of space. That's it.

Any other downsides?

Cheers
--
t

[Celejar]

No. What the author means is that lots of different applications and
use cases can break badly with /tmp on tmpfs - see the '"/tmp on tmpfs
is bad" quotes' section of the post:

https://lists.debian.org/debian-devel/2012/06/msg00311.html

(BTW, I really think that you should avoid snipping the link to the post
that we're discussing from your replies.)

--
Celejar

[David Wright]

On Sun 23 Apr 2023 at 01:14:05 (-0700), David Christensen wrote:
> On 4/22/23 21:11, David Wright wrote:
> > On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote:
> > > "Back in the day", people running Linux had computers with limited
> > > amounts of storage and memory. I imagine an initial ramdisk seemed
> > > like an good trade-off/ work-around at that time.
> > >
> > > But today, this is my Linux daily driver:
> >
> > > Total online memory: 32G
> >
> > That must be nice. I don't know what it might have cost. I'm afraid
> > I only use cast-offs. The oldest has ½GB memory.
>
> https://www.ebay.com/itm/393918586141

When the boat comes in, maybe. The most expensive piece of computing
equipment I've bought is my first 500GB internal PATA disk, which was
£120 in 2007. It still runs.

> > > # ls -l /boot/initrd.img-5.10.0-21-amd64 /boot/vmlinuz-5.10.0-21-amd64
> > > -rw-r--r-- 1 root root 47837534 Mar 18 19:23
> > > /boot/initrd.img-5.10.0-21-amd64
> > > -rw-r--r-- 1 root root 7019136 Jan 21 06:35 /boot/vmlinuz-5.10.0-21-amd64
> >
> > > The Linux kernel is ~7 MB and initrd.img is ~48 MB. My daily driver
> > > is complete overkill.
> >
> > I think your kernel is probably more like 12.3MB of code.
>
> Where do you get 12.3MB?

$ sudo dmesg | grep -e 'kernel code' -e 'Freeing'
[ 0.073101] Memory: 261408K/2087060K available (12295K kernel code, 2537K rwdata, 7560K rodata, 2660K init, 5468K bss, 85560K reserved, 0K cma-reserved)
[ 0.216704] Freeing SMP alternatives memory: 32K
[ 1.301737] Freeing initrd memory: 11472K
[ 1.417122] Freeing unused decrypted memory: 2036K
[ 1.418881] Freeing unused kernel image (initmem) memory: 2660K
[ 1.436299] Freeing unused kernel image (text/rodata gap) memory: 2040K
[ 1.436768] Freeing unused kernel image (rodata/data gap) memory: 632K
$ uname -vsor
Linux 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) GNU/Linux
$

I take it you're not running an i386:

$ sudo dmesg | grep -e 'kernel code' -e 'Freeing'
[ 0.067626] Memory: 472644K/522744K available (8213K kernel code, 1158K rwdata, 2516K rodata, 872K init, 476K bss, 50100K reserved, 0K cma-reserved, 0K highmem)
[ 0.126156] Freeing SMP alternatives memory: 32K
[ 2.906178] Freeing initrd memory: 30656K
[ 3.694974] Freeing unused kernel image (initmem) memory: 872K
$ uname -vsor
Linux 5.10.0-21-686 #1 SMP Debian 5.10.162-1 (2023-01-21) GNU/Linux
$

> > Your initrd
> > is larger than mine: I'd have to see inside to tell why, but no matter.
> >
> > > Even my 2007 laptop has 2 GB of memory an a 1 GB boot partition/
> > > filesystem. Still overkill.
> >
> > Overkill for what? I don't understand.
>
> 2 GB of memory and 1 GB of boot file system are more than enough to
> boot Linux or FreeBSD.

That looks like a restatement, so in order to understand /why/ you
might say that, I have to put words into your mouth; sorry if they're
the wrong ones.

You seem to be saying that because 2GB/1GB is enough to boot a system,
then that's a good reason to allow the running kernel to be 48+12=60MB
in size, just to eliminate the initramfs. And the sole reason for
wishing to eliminate it is because of its "complexity", as you see it.

I don't buy that, and I don't think most linux users want their kernel
stuffed with 80% of code that's never used and is only there for other
people who might some day boot their kernel on a system that has a
fancy way of accessing the root filesystem that doesn't interest them,
and I, for one, would never be able to afford.

And that's before you look at the advantages of developing and running
that 80% of the code in user-mode rather than kernel-mode, in terms of
debugging, security, etc.

Cheers,
David.