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 messagesOn 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: 32GThat 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-amd64The 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