Re: /etc/fstab question (problem)?
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.
Re: /etc/fstab question (problem)?
On Sun, 23 Apr 2023 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 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
old memory sticks (was Re: /etc/fstab question (problem)?
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
Re: /etc/fstab question (problem)?
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. David
Re: /etc/fstab question (problem)?
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.
Re: /etc/fstab question (problem)?
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. :-( "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 0x-0x7fff 2G online yes 0-15 0x0001-0x00087fff 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
Re: /etc/fstab question (problem)?
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: >
Re: gitification (was Re: /etc/fstab question (problem)?
Am 22.04.2023 um 08:33 schrieb 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) > > Thank you, Mr. Nikulin, for writing this long message. I am totally with you in many regards, and have been following this thread for some time, mostly wondering and finding myself unable to put into words, what was bugging me with it. It is quite a challenge to see it the way you (and i) do, while still being friendly and helpful to the OP. but you managed that, and i admire the way, you are doing it. Very nice and fine distinctions like (i'll give one example only: ) >> 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. Just saying: I do very much appreciate your post. Thank you for that. DdB
Re: gitification (was Re: /etc/fstab question (problem)?
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)
Re: /etc/fstab question (problem)?
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
Re: gitification (was Re: /etc/fstab question (problem)?
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
Re: /etc/fstab question (problem)?
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
Re: /etc/fstab question (problem)?
On Fri, Apr 21, 2023 at 04:59:36AM -0400, rhkra...@gmail.com wrote: > On Wednesday, April 19, 2023 05:02:16 PM Default User wrote: > > sudo cp -r 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.
Re: /etc/fstab question (problem)?
On Wednesday, April 19, 2023 05:02:16 PM Default User wrote: > sudo cp -r 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. ;-) '
Re: /etc/fstab question (problem)?
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 signature.asc Description: PGP signature
Re: /etc/fstab question (problem)?
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.
Re: gitification (was Re: /etc/fstab question (problem)?
On 4/20/23 14:51, songbird wrote: 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 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 /.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
Re: gitification (was Re: /etc/fstab question (problem)?
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)
Re: gitification (was Re: /etc/fstab question (problem)?
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
Re: gitification (was Re: /etc/fstab question (problem)?
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
Re: gitification (was Re: /etc/fstab question (problem)?
On 4/20/23 05:10, songbird wrote: 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 Please describe your use-case(s), what the requirements are and why, and how Git is failing. David
Re: gitification (was Re: /etc/fstab question (problem)?
>> 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
Re: gitification (was Re: /etc/fstab question (problem)?
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
Re: gitification (was Re: /etc/fstab question (problem)?
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
Re: gitification (was Re: /etc/fstab question (problem)?
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.
Re: /etc/fstab question (problem)?
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.
Re: /etc/fstab question (problem)?
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. - > > Am 19.04.2023 um 22:06 schrieb Default User: > > > 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. > > > > 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. > Do NOT delete the directory itself, only its content, as it will be > used > as the mountpoint for your /tmp drive. > > > > > 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
Re: gitification (was Re: /etc/fstab question (problem)?
> 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
Re: gitification (was Re: /etc/fstab question (problem)?
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)
Re: /etc/fstab question (problem)?
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
Re: /etc/fstab question (problem)?
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
gitification (was Re: /etc/fstab question (problem)?
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
Re: /etc/fstab question (problem)?
You got your plan mapped out. and i agree, except for one little detail: see below. - Am 19.04.2023 um 22:06 schrieb Default User: >> 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. > > 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 rootroot4.0K Apr 19 14:20 ./ > 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ > 88473618 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .font-unix/ > 88473615 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .ICE-unix/ > 88473620 drwx-- 2 rootroot4.0K Apr 19 14:20 lost+found/ > 88473619 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .Test-unix/ > 88473624 drwx-- 2 rootroot4.0K Apr 19 14:20 tracker- > extract-files.1000/ > 88473623 drwx-- 2 rootroot4.0K Apr 19 14:20 tracker- > extract-files.116/ > 88473621 -r--r--r-- 1 rootroot 11 Apr 19 14:20 .X1024-lock > 88473622 -r--r--r-- 1 rootroot 11 Apr 19 14:20 .X1025-lock > 88473612 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .X11-unix/ > 88473617 drwxr-xr-t 2 rootroot4.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. Do NOT delete the directory itself, only its content, as it will be used as the mountpoint for your /tmp drive. > > 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. Please report your success, will you?
Re: /etc/fstab question (problem)?
On Wed, 2023-04-19 at 23:40 +, davidson wrote: > On Wed, 19 Apr 2023 Default User wrote: > > On Wed, 2023-04-19 at 16:56 -0400, Default User wrote: > > > On Wed, 2023-04-19 at 15:36 -0500, David Wright wrote: > > > > On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: > > > > > > > > > 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 > > > > >
Re: [SOLVED] Re: /etc/fstab question (problem)?
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
[SOLVED] Re: /etc/fstab question (problem)?
On Wed, 2023-04-19 at 15:09 -0700, David Christensen wrote: > On 4/19/23 15:03, David Christensen wrote: > > On 4/19/23 14:26, Default User wrote: > > > On Wed, 2023-04-19 at 14:03 -0700, David Christensen wrote: > > > > On 4/19/23 13:06, Default User wrote: > > > > > On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote: > > > > > > > > Perhaps update-initramfs is necessary after restoring of > > > > > > /etc/fstab > > > > > > in > > > > > > any chosen approach. > > > > > > But, I cannot address Max's point about initrd(4). > > > > > > > > > > > > At this point, I would run my daily backups, use an editor to > > > > put the > > > > original /etc entry back into /etc/fstab, forget about messing > > > > with > > > > /etc > > > > on either file system, and reboot. After reboot, I would run > > > > 'df > > > > /etc' > > > > and check where /etc is mounted. If /etc is "Mounted on /", I > > > > would > > > > run > > > > update-initramfs(8), reboot, and look again. > > > > > I'm afraid I don't quit understand why 'If /etc is "Mounted on > > > /", I > > > would run update-initramfs(8), reboot, and look again." > > > > > > > > > Shouldn't etc always be expected to be mounted under /, as in > > > /etc? > > > For example, right now on my computer: > > > > > > df /etc > > > Filesystem 1K-blocks Used Available Use% Mounted on > > > /dev/nvme0n1p2 23854928 5841492 16776344 26% / > > > > > > /etc is a subdirectory of the / directory on the Unix "one big file > > system". > > > > > > Some file system must be mounted at /. > > > > > > Additional file systems must be mounted somewhere beneath /. Where > > they > > are mounted is call the "mountpoint". Mountpoints are > > traditionally > > subdirectories, and traditionally empty. When a file system is > > mounted > > there, the root of that file system is visible as the contents of > > the > > mountpoint. > > > > > > On my system, the virtual device /dev/mapper/sda4_crypt has a mount > > point of /. That file system contains a directory /etc. So, in > > the > > Unix "one big file system", the directories / and /etc both come > > from > > the file system on /dev/mapper/sda4_crypt. > > > > 2023-04-19 14:38:19 root@taz ~ > > # df / /etc > > Filesystem 1M-blocks Used Available Use% Mounted on > > /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / > > /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / > > > > > > AIUI you want the file system on the the partition /dev/nvme0n1p5 > > to be > > mounted at /tmp. The way to do that is to put the relevant entry > > back > > into /etc/fstab: > > > > UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2 > > > > And then reboot. > > > > > > > And, would there be anything wrong with, either way, running > > > update- > > > initramfs? > > > > > > Would that be run as: > > > > > > sudo update-initramfs -uv > > > > > > ? > > > > > > Unfortunately, more confusion -- there are two Linux "Initial > > ramdisk" > > solutions with very similar names -- initrd and initramfs. Forget > > about > > those for now. > > > > > > I would add the /etc entry back into /etc/fstab, reboot, run 'df / > > /etc', and see what happens. > > > Correction: > > add the /tmp entry back into /etc/fstab > > > > > > > > David > > > Okay . . . The problem seems to be solved! What I did: 1) Booted into Debian 11.6 Live/install usb thumb drive. 2) As root, mounted the / partition from the internal ssd. 3) On the internal ssd, replaced /etc/fstab with /etc/fstab.original. (On the internal ssd, I did not delete /tmp or its contents, and did not delete the tmp partition or its contents.) 4) Unmounted the / partition on the internal ssd. 5) Shutdown and removed the usb thumb drive. 6) Booted in to the computer as usual. It *seems* to have worked fine, with /tmp mounted on its dedicated partition again. But there may still be leftover stuff in /tmp, so maybe later I will again boot from the live usb, delete everything in /tmp (but not /tmp itself) on the internal ssd, and reboot into the system, which will presumably have re-populated with no leftovers. So far, so good. Much thanks to all who have weighed in on this!
Re: /etc/fstab question (problem)?
On Wed, 19 Apr 2023 Default User wrote: On Wed, 2023-04-19 at 16:56 -0400, Default User wrote: On Wed, 2023-04-19 at 15:36 -0500, David Wright wrote: On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: 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. 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. IIRC, I just did: sudo from the live usb. I didn't think about the changed times. Perhaps I should have used rsync . . . Grrr . . . Sorry! That should have been: sudo cp -r from the live usb. 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
Re: /etc/fstab question (problem)?
On 4/19/23 15:03, David Christensen wrote: On 4/19/23 14:26, Default User wrote: On Wed, 2023-04-19 at 14:03 -0700, David Christensen wrote: On 4/19/23 13:06, Default User wrote: On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote: Perhaps update-initramfs is necessary after restoring of /etc/fstab in any chosen approach. But, I cannot address Max's point about initrd(4). At this point, I would run my daily backups, use an editor to put the original /etc entry back into /etc/fstab, forget about messing with /etc on either file system, and reboot. After reboot, I would run 'df /etc' and check where /etc is mounted. If /etc is "Mounted on /", I would run update-initramfs(8), reboot, and look again. I'm afraid I don't quit understand why 'If /etc is "Mounted on /", I would run update-initramfs(8), reboot, and look again." Shouldn't etc always be expected to be mounted under /, as in /etc? For example, right now on my computer: df /etc Filesystem 1K-blocks Used Available Use% Mounted on /dev/nvme0n1p2 23854928 5841492 16776344 26% / /etc is a subdirectory of the / directory on the Unix "one big file system". Some file system must be mounted at /. Additional file systems must be mounted somewhere beneath /. Where they are mounted is call the "mountpoint". Mountpoints are traditionally subdirectories, and traditionally empty. When a file system is mounted there, the root of that file system is visible as the contents of the mountpoint. On my system, the virtual device /dev/mapper/sda4_crypt has a mount point of /. That file system contains a directory /etc. So, in the Unix "one big file system", the directories / and /etc both come from the file system on /dev/mapper/sda4_crypt. 2023-04-19 14:38:19 root@taz ~ # df / /etc Filesystem 1M-blocks Used Available Use% Mounted on /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / /dev/mapper/sda4_crypt 11145M 7016M 3542M 67% / AIUI you want the file system on the the partition /dev/nvme0n1p5 to be mounted at /tmp. The way to do that is to put the relevant entry back into /etc/fstab: UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2 And then reboot. And, would there be anything wrong with, either way, running update- initramfs? Would that be run as: sudo update-initramfs -uv ? Unfortunately, more confusion -- there are two Linux "Initial ramdisk" solutions with very similar names -- initrd and initramfs. Forget about those for now. I would add the /etc entry back into /etc/fstab, reboot, run 'df / /etc', and see what happens. Correction: add the /tmp entry back into /etc/fstab David
Re: /etc/fstab question (problem)?
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-blocksUsed 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_crypt11145M 7016M 3542M 67% / /dev/mapper/sda4_crypt11145M 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
Re: /etc/fstab question (problem)?
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: > > > 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 ;-) > > > > > > 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
Re: /etc/fstab question (problem)?
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 ;-) 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 rootroot4.0K Apr 19 14:20 ./ 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ 88473618 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .font-unix/ 88473615 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .ICE-unix/ 88473620 drwx-- 2 rootroot4.0K Apr 19 14:20 lost+found/ 88473619 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .Test-unix/ 88473624 drwx-- 2 rootroot4.0K Apr 19 14:20 tracker- extract-files.1000/ 88473623 drwx-- 2 rootroot4.0K Apr 19 14:20 tracker- extract-files.116/ 88473621 -r--r--r-- 1 rootroot 11 Apr 19 14:20 .X1024-lock 88473622 -r--r--r-- 1 rootroot 11 Apr 19 14:20 .X1025-lock 88473612 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .X11-unix/ 88473617 drwxr-xr-t 2 rootroot4.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. 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
Re: /etc/fstab question (problem)?
On Wed, 2023-04-19 at 16:56 -0400, Default User wrote: > On Wed, 2023-04-19 at 15:36 -0500, David Wright wrote: > > On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: > > > > > 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. > > > > 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. > > > > > IIRC, I just did: > > sudo from the live usb. > > I didn't think about the changed times. > > Perhaps I should have
Re: /etc/fstab question (problem)?
On Wed, 2023-04-19 at 15:36 -0500, David Wright wrote: > On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: > > > 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. > > 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. > IIRC, I just did: sudo from the live usb. I didn't think about the changed times. Perhaps I should have used rsync . . . Grrr . . .
Re: /etc/fstab question (problem)?
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.
Re: /etc/fstab question (problem)?
On Wed 19 Apr 2023 at 16:06:57 (-0400), Default User wrote: > 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 rootroot4.0K Apr 19 14:20 ./ > 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ > 88473618 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .font-unix/ > 88473615 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .ICE-unix/ > 88473620 drwx-- 2 rootroot4.0K Apr 19 14:20 lost+found/ > 88473619 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .Test-unix/ > 88473624 drwx-- 2 rootroot4.0K Apr 19 14:20 tracker- > extract-files.1000/ > 88473623 drwx-- 2 rootroot4.0K Apr 19 14:20 tracker- > extract-files.116/ > 88473621 -r--r--r-- 1 rootroot 11 Apr 19 14:20 .X1024-lock > 88473622 -r--r--r-- 1 rootroot 11 Apr 19 14:20 .X1025-lock > 88473612 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .X11-unix/ > 88473617 drwxr-xr-t 2 rootroot4.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. 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.
Re: /etc/fstab question (problem)?
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-
Re: /etc/fstab question (problem)?
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. > > 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.
Re: /etc/fstab question (problem)?
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. 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 rootroot4.0K Apr 19 14:20 ./ 88473603 drwxr-xr-x 3 [user] [user] 4.0K Apr 19 14:20 ../ 88473618 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .font-unix/ 88473615 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .ICE-unix/ 88473620 drwx-- 2 rootroot4.0K Apr 19 14:20 lost+found/ 88473619 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .Test-unix/ 88473624 drwx-- 2 rootroot4.0K Apr 19 14:20 tracker- extract-files.1000/ 88473623 drwx-- 2 rootroot4.0K Apr 19 14:20 tracker- extract-files.116/ 88473621 -r--r--r-- 1 rootroot 11 Apr 19 14:20 .X1024-lock 88473622 -r--r--r-- 1 rootroot 11 Apr 19 14:20 .X1025-lock 88473612 drwxr-xr-t 2 rootroot4.0K Apr 19 14:20 .X11-unix/ 88473617 drwxr-xr-t 2 rootroot4.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.
Re: /etc/fstab question (problem)?
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.
Re: /etc/fstab question (problem)?
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
Re: /etc/fstab question (problem)?
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/tmptmpfsdefaults,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 signature.asc Description: PGP signature
Re: /etc/fstab question (problem)?
> 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
Re: /etc/fstab question (problem)?
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.
Re: /etc/fstab question (problem)?
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: > # > > UUID=4fdd4399-6267-404a-a292- > cdc7761df3c9 / ext4errors=remount-ro 0 1 > UUID=26EE-0EF5 /boot/efi vfatumask=0077 0 1 > UUID=00f0c2db-0490-4354-b949- > f9af11a7f001 /home ext4defaults0 2 > UUID=8bfeee23-9c09-45b7-a73e- > bd2ff43e207c /varext4defaults0 2 > UUID=e2a56ec3-99d4-4b40-9aa4- > 24975143cdc7 noneswapsw 0 0 > Original /etc/fstab: > # /tmp was on /dev/nvme0n1p5 during installation > UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmpext4 > defaults0 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
Re: /etc/fstab question (problem)?
On Tue, 18 Apr 2023 21:12:33 -0400 Default User 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. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: /etc/fstab question (problem)?
On Tue, 2023-04-18 at 16:53 -0700, David Christensen wrote: > On 4/18/23 14:42, Default User wrote: > > On Tue, 2023-04-18 at 13:03 -0700, David Christensen wrote: > > > On 4/18/23 07:59, Default User wrote: > > > > Hey, I have a strange situation! > > > > > > > > I just realized that my /tmp partition is not being mounted at > > > > startup. > > > > Instead, I think the filesystem may be allocating space in > > > > another > > > > partition (maybe /root?) for tmp stuff. > > > > My / (root) and /tmp directories are on the same file system -- > > > the > > > root > > > filesystem: > > > > > > 2023-04-18 12:46:41 root@taz ~/taz.tracy.holgerdanske.com > > > # stat -c %d / /tmp > > > 65024 > > > 65024 > > > stat -c %d / /tmp > > 66306 > > 66306 > > (I am not sure what that means - is that saying that /tmp is > > mounted > > under / on the / partition?) > > > stat(1) is saying that the file system entries "/" and "/tmp" have > the > same "device number". Device numbers should be unique for the > various > file systems that are mounted on one computer: > > # mount | perl -ane '$_=$F[2];$dev=(stat)[0];print"$dev $_\n"' | sort > -n > /run/user/13250/doc > 5 /dev > 6 /sys/kernel/security > 7 /sys/kernel/debug > 11 /sys/kernel/tracing > 19 /dev/mqueue > 20 /sys > 21 /proc > 22 /dev/pts > 23 /run > 26 /dev/shm > 27 /run/lock > 28 /sys/fs/cgroup > 29 /sys/fs/pstore > 30 /sys/firmware/efi/efivars > 31 /sys/fs/bpf > 32 /proc/sys/fs/binfmt_misc > 33 /dev/hugepages > 34 /sys/fs/fuse/connections > 35 /sys/kernel/config > 39 /samba/dpchrist > 40 /samba/groupshare > 42 /run/user/13250 > 50 /run/user/0 > 2049 /boot/efi > 2050 /boot > 65024 / > 65026 /scratch > > > That said, I think I prefer the df(1) solution posted by Greg > Wooledge. > > > > (And BTW, the current /etc/fstab must have been written by some > > program, not manually by me. I would never have edited /etc/fstab > > to > > look like that!) My best guess is that I may have done a system > > restore > > using Timeshift on 2023-04-03, to back out of some unremembered > > problem, and the current /etc/fstab results from that. > > > Backing up system configuration files is good. > > > I use a version control system (CVS), create a project for each host, > and check in every system configuration file I create, update, or > delete. I also keep a log.txt file for each system, write notes to > myself, save console sessions, etc., for when I do need to remember > what > I did, when, and why. Rather than restoring entire system > configuration > files, I typically use an editor and restore specific settings. > > > > I COULD just continue as is with the current setup, but I would > > REALLY > > prefer not to! > > > Why not? > > > > Maybe I should just start by using Clonezilla to do a full image of > > the > > drive. Actual data of course, not the entire 256 Gb! > > > Putting your data on a different device than your OS allows you to > optimize device usage and backup, restore, archive, imaging, etc., > procedures. > > > > More later . . . > > > David > I have made 2 backups of the ssd, using Clonezilla. 1) a full disk backup,from which the whole disk can be restored. 2) a partitions backup, from which any or all of the individual partitions can be restored. Both have been checked by Clonezilla to be restorable. (Not so) fun fact: Clonezilla always refuses to back up swap partitions. I don't know why. FWIW: df /tmp Filesystem 1K-blocksUsed 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!
Re: /etc/fstab question (problem)?
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
Re: /etc/fstab question (problem)?
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.
Re: /etc/fstab question (problem)?
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. > > > > 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,pi > > pe_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,sho > > rtna > > me=mixed,utf8,errors=remount-ro) > > tmpfs on /run/user/1000 type tmpfs > > (rw,nosuid,nodev,relatime,size=788496k,nr_inodes=197124,mode=700,ui > > d=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: > > # > > > > UUID=4fdd4399-6267-404a-a292- > > cdc7761df3c9/ ext4errors=remount-ro 0 1 > > UUID=26EE-0EF5 /boot/efi vfatumask=0077 0 1 > > UUID=00f0c2db-0490-4354-b949- > > f9af11a7f001/home ext4defaults0 2 > > UUID=8bfeee23-9c09-45b7-a73e- > > bd2ff43e207c/varext4defaults0 2 > > UUID=e2a56ec3-99d4-4b40-9aa4- > > 24975143cdc7noneswapsw 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. > > # > > # > > > > # / 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
Re: /etc/fstab question (problem)?
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/tmptmpfsdefaults,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 ... signature.asc Description: PGP signature
Re: /etc/fstab question (problem)?
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. 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: # UUID=4fdd4399-6267-404a-a292- cdc7761df3c9/ ext4errors=remount-ro 0 1 UUID=26EE-0EF5 /boot/efi vfatumask=0077 0 1 UUID=00f0c2db-0490-4354-b949- f9af11a7f001/home ext4defaults0 2 UUID=8bfeee23-9c09-45b7-a73e- bd2ff43e207c/varext4defaults0 2 UUID=e2a56ec3-99d4-4b40-9aa4- 24975143cdc7noneswapsw 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. # # # / 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 vfatumask=0077 0 1 # /home was on /dev/nvme0n1p6 during installation UUID=00f0c2db-0490-4354-b949-f9af11a7f001 /home ext4 defaults0 2 # /tmp was on /dev/nvme0n1p5 during installation UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmpext4 defaults0 2 # /var was on /dev/nvme0n1p3 during installation UUID=8bfeee23-9c09-45b7-a73e-bd2ff43e207c /varext4 defaults0 2 # swap was on /dev/nvme0n1p4 during installation UUID=e2a56ec3-99d4-4b40-9aa4-24975143cdc7 noneswapsw 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
Re: /etc/fstab question (problem)?
On Tue, Apr 18, 2023 at 09:37:51AM -0600, Charles Curley wrote: > On Tue, 18 Apr 2023 10:59:19 -0400 > Default User 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/tmptmpfsdefaults,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 signature.asc Description: PGP signature
Re: /etc/fstab question (problem)?
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.
Re: /etc/fstab question (problem)?
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
Re: /etc/fstab question (problem)?
On Tue, 18 Apr 2023 10:59:19 -0400 Default User 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/
/etc/fstab question (problem)?
Am 18.04.2023 um 16:59 schrieb Default User: > Hey, I have a strange situation! Wow! Am I misunderstanding something? You seem to be well in control of your system, thus i am i bit surprised as of the simplicity of your question. If it was me, i would just find out, where exactly tmp resides now, then shutdown and boot from an ISO in order to have a "cold" system on disk. Then mount both tmp places to check, if there is anything worth keeping/consolidating. Otherwise clear the mountpoint and uncomment the /tmp line from your fstab. Rebooting should then just mount it as you want. Questions, i could not answer: What if you wanted to make the change without downtime? What if you want to make use of systemd services to mount /tmp? * I assume, that one gets created automatically, if a tmpfs is used for /tmp, but i dont know, when exactly, it would run. Is there any relevance? I guess not. -- Liebe ist ... Datakanja
/etc/fstab question (problem)?
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: # UUID=4fdd4399-6267-404a-a292- cdc7761df3c9/ ext4errors=remount-ro 0 1 UUID=26EE-0EF5 /boot/efi vfatumask=0077 0 1 UUID=00f0c2db-0490-4354-b949- f9af11a7f001/home ext4defaults0 2 UUID=8bfeee23-9c09-45b7-a73e- bd2ff43e207c/varext4defaults0 2 UUID=e2a56ec3-99d4-4b40-9aa4- 24975143cdc7noneswapsw 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. # # # / 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 vfatumask=0077 0 1 # /home was on /dev/nvme0n1p6 during installation UUID=00f0c2db-0490-4354-b949-f9af11a7f001 /home ext4 defaults0 2 # /tmp was on /dev/nvme0n1p5 during installation UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmpext4 defaults0 2 # /var was on /dev/nvme0n1p3 during installation UUID=8bfeee23-9c09-45b7-a73e-bd2ff43e207c /varext4 defaults0 2 # swap was on /dev/nvme0n1p4 during installation UUID=e2a56ec3-99d4-4b40-9aa4-24975143cdc7 noneswapsw 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
Re: /etc/fstab question
On Mon, 11 Nov 2013 04:06:16 +0100 berenger.mo...@neutralite.org wrote: I am sorry, I do not understand what you mean by minimize wear. ( yes, I do not only use that list to learn stuff about Debian, it also helps me to work my English since I have no other occasions to do that, sadly ;) ) Flash drives have a limited (and unknowable) number of write cycles available due to the nature of the electric charge storage used. They are now very much longer-lived than the early ones, but there will always be a limit. It is spoken of as 'wear' even though there are no physically moving parts. There are filesystem strategies to avoid concentrating this wear on a small number of locations, but even so, many people try to minimise the writing by avoiding journalling filesystems and unnecessary timestamp updating. Also, writing to flash memory cannot be done to single locations, as with RAM, but blocks have to be written at a time, which is another reason to minimise writing. This naturally slows down the write speed, although again, modern devices have hardware assistance to improve the speed. I have one of the original Acer Aspire One netbooks, with an 8GB SSD, and it is almost unusable. I almost always run the netbook with an external USB hard drive, which gives decent speeds. I am aware that there are faster drives that can be used to upgrade the machine, but they cost a substantial fraction of the value of the computer, which I bought refurbished. -- Joe -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013090940.06cc3...@jretrading.com
Re: /etc/fstab question
Le 11.11.2013 10:09, Joe a écrit : On Mon, 11 Nov 2013 04:06:16 +0100 berenger.mo...@neutralite.org wrote: I am sorry, I do not understand what you mean by minimize wear. ( yes, I do not only use that list to learn stuff about Debian, it also helps me to work my English since I have no other occasions to do that, sadly ;) ) Flash drives have a limited (and unknowable) number of write cycles available due to the nature of the electric charge storage used. They are now very much longer-lived than the early ones, but there will always be a limit. It is spoken of as 'wear' even though there are no physically moving parts. Thanks for explanations. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/13ab929da9f5bae10b7043fae5f2c...@neutralite.org
Re: /etc/fstab question
berenger.mo...@neutralite.org wrote: Le 10.11.2013 19:54, Richard Owlett a écrit : berenger.mo...@neutralite.org wrote: Le 10.11.2013 18:06, Richard Owlett a écrit : Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? TIA It will, but remember that it will also allow them to change file permissions, and so to remove rights to other users. That's not an actual problem. I'm the only physical user. The laptop in question is dedicated to my learning experiments. It physically does not even have network access of any kind. So, security and user errors are not so important, indeed. In my opinion, if you want such kind of partition, the easier solution is to use a partition system which does not have the user right feature. The first one which comes to my mind, is the FAT family. DUH! I'm already doing that for a USB stick exchanging text files with my Windows machine. And why not doing the same on that partition? Actually I am _NOW_ ;/ The DUH! is slang {approximately expression idomatique} for a exclamation conveying how intellectually deficient could I have been not to have seen the obvious. Since you seems to use ext2, you anyway do not have the log feature ( the thing which avoid corrupted files in case of a problem ) so I only see the drawback of file names not doing difference between uppercase and lowercase characters. I had use ext2 as eventually I intend to use flash drive and wanted minimize wear. I am sorry, I do not understand what you mean by minimize wear. ( yes, I do not only use that list to learn stuff about Debian, it also helps me to work my English since I have no other occasions to do that, sadly ;) ) Wear in this case refers to flash devices be useable for only a finite number of read/write cycles. It is used in an analogous sense to an unlubricated wheel bearing will eventually wear out. I would suggest reading alt.english.usage to see the breath of English usages - even among native speakers. [snip] -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5280c9a1.6060...@cloud85.net
Re: /etc/fstab question
David Christensen wrote: On 11/10/2013 09:06 AM, Richard Owlett wrote: I wish to have all users of all Debian installs on my laptop have unrestricted access to everything on a particular partition. It was suggested adding a line to /etc/fstab would accomplish my goal. ... /dev/sda5 /owlett ext2 rw,users,exec On rebooting it failed with a missing mount point message. As root I did a mkdir. There were no error messages on the next reboot. Yes. Mount needs an existing directory in the file system to mount /dev/sda5. 'mkdir /owlett' was the correct solution. However when I displayed the directory with Nautilus, the icons for all existing files and folders were flagged with the lock icon adjacent. They had been created under a Debian install which no longer is present. Is this the expected result? If your system has the default UMASK of 0022 (e.g. no write permission for 'group' and 'other'), then regular files will be created with a mode of (in C) 0666 ~UMASK, which equals 0644, and directories will be created with a mode of 0777 ~MASK, which equals 0755. So, yes, when you log in using a different account, you don't have write permission for those files and directories, and Nautilus is letting you know that with the lock icon. Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? You want 0777 for directories, but 0666 for files. Use a symbolic mode specification for 'chmod' that reverses the effect of UMASK: # chmod --recursive go+w /owlett HTH, David I'll have to re-read the chmod documentation and investigate UMASK. Thank you. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5280cc51.2010...@cloud85.net
Re: /etc/fstab question
David Christensen wrote: On 11/10/2013 10:54 AM, Richard Owlett wrote: I'm the only physical user. The laptop in question is dedicated to my learning experiments. It physically does not even have network access of any kind. Ouch. I assume you mean no Ethernet interface. Note that it is possible to network over other connections (serial, parallel, Firewire, etc.). No ouch at all. It is by design. The only external items connected are a mouse and an occasional USB drive for intentional file transfers. My normal install also skips the network install step. Some in this group have accused me of not being security conscious.I just take a more brute force approach on the machine in question. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5280c40a.9070...@cloud85.net
Re: /etc/fstab question
Hi, On 11/10/2013 05:28 PM, berenger.mo...@neutralite.org wrote: Le 10.11.2013 18:06, Richard Owlett a écrit : Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? TIA It will, but remember that it will also allow them to change file permissions, and so to remove rights to other users. In my opinion, if you want such kind of partition, the easier solution is to use a partition system which does not have the user right feature. The first one which comes to my mind, is the FAT family. Since you seems to use ext2, you anyway do not have the log feature ( the thing which avoid corrupted files in case of a problem ) so I only see the drawback of file names not doing difference between uppercase and lowercase characters. But, still IMO, this one is more a drawback of ext* partition tables than of FAT, since it is not really natural for me and people I know to differentiate words by the case of their letters*. On the other hand, since you spoke about icons and graphical stuff, I bet that your users are not console users, so they won't be that annoyed. *: and if someone have any clue to allow my terminal to stop bothering me with that damned case difference in file names, I would really be grateful to know it. For now, I simply stop using case when naming files, but it is less readable and is not applicable to other people's files... I tried something similar - without the mount point in /etc/fstab - and found the best options was to create a folder with user=someuser group=somegroup and add the users to that group, and assure the file permissions for group were rw. In /etc/fstab i believe you can specify, in the filesystem option, the owner or the group of the mount point. -- Bandarra LiCo #544119 Enjoy while you can 'cos you'll never know when it'll end -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5280de1a.1040...@gmail.com
Re: /etc/fstab question
On Mon, 2013-11-11 at 04:06 +0100, berenger.mo...@neutralite.org wrote: Le 10.11.2013 19:54, Richard Owlett a écrit : Since you seems to use ext2, you anyway do not have the log feature ( the thing which avoid corrupted files in case of a problem ) so I only see the drawback of file names not doing difference between uppercase and lowercase characters. I had use ext2 as eventually I intend to use flash drive and wanted minimize wear. I am sorry, I do not understand what you mean by minimize wear. ( yes, I do not only use that list to learn stuff about Debian, it also helps me to work my English since I have no other occasions to do that, sadly ;) ) To minimize wear means to use something gently, so that it will last a very long time. Ext2 accesses the disk less than ext4 in the same amount of reading and writing. He expects that it will use less power, and allow the disk media itself to last longer. He is probably right. I use ext2 for a different reason. There is information on my system (cryptographic keys) that I must control. The journaling capabilities of ext3 and ext4 filesystems cause complexity that means they may still be available in some way even if I erase and write over them. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1384207356.4022.104.ca...@excessive.dsl.static.sonic.net
/etc/fstab question
I wish to have all users of all Debian installs on my laptop have unrestricted access to everything on a particular partition. It was suggested adding a line to /etc/fstab would accomplish my goal. 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). # # file system mount point type options dump pass proc/proc procdefaults0 0 # / was on /dev/sda1 during installation UUID=4df6d0f9-d98b-47da-9e2c-90b5a65b208d /ext2 errors=remount-ro 0 1 # swap was on /dev/sda6 during installation UUID=226e866a-4952-4a8f-a172-35fa263df9f5 none swapsw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto 0 0 to which I added this line /dev/sda5 /owlett ext2 rw,users,exec On rebooting it failed with a missing mount point message. As root I did a mkdir. There were no error messages on the next reboot. However when I displayed the directory with Nautilus, the icons for all existing files and folders were flagged with the lock icon adjacent. They had been created under a Debian install which no longer is present. Is this the expected result? Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? TIA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527fbd00.1020...@cloud85.net
Re: /etc/fstab question
On Sun, 2013-11-10 at 11:06 -0600, Richard Owlett wrote: /dev/sda5/owlettext2rw,users,exec Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? I can't say anything about your fstab entry, but at least chmod -R 777 will permit the needed permissions, but then the permissions are the same for other installs too. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1384104274.1074.28.camel@archlinux
Re: /etc/fstab question
Le 10.11.2013 18:06, Richard Owlett a écrit : Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? TIA It will, but remember that it will also allow them to change file permissions, and so to remove rights to other users. In my opinion, if you want such kind of partition, the easier solution is to use a partition system which does not have the user right feature. The first one which comes to my mind, is the FAT family. Since you seems to use ext2, you anyway do not have the log feature ( the thing which avoid corrupted files in case of a problem ) so I only see the drawback of file names not doing difference between uppercase and lowercase characters. But, still IMO, this one is more a drawback of ext* partition tables than of FAT, since it is not really natural for me and people I know to differentiate words by the case of their letters*. On the other hand, since you spoke about icons and graphical stuff, I bet that your users are not console users, so they won't be that annoyed. *: and if someone have any clue to allow my terminal to stop bothering me with that damned case difference in file names, I would really be grateful to know it. For now, I simply stop using case when naming files, but it is less readable and is not applicable to other people's files... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9f531cff3ca0845996515f7fa56e9...@neutralite.org
Re: /etc/fstab question
Am Sonntag, 10. November 2013, 18:28:54 schrieb berenger.mo...@neutralite.org: Le 10.11.2013 18:06, Richard Owlett a écrit : Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? TIA It will, but remember that it will also allow them to change file permissions, and so to remove rights to other users. Wouldn't it be much easier to define a group, give the partition or directory this group write permission and put all users, which are allowed to write (and trusted) into this group? Just an idea... Hans -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2192793.iz7pLIGik3@protheus2
Re: /etc/fstab question
On Sun, 2013-11-10 at 11:06 -0600, Richard Owlett wrote: On rebooting it failed with a missing mount point message. And it failed for the first reboot only? Didn't you mount the fstab entries manually before rebooting? $ mount --help | grep fstab -a, --all mount all filesystems mentioned in fstab -T, --fstab path alternative file to /etc/fstab However, IIUC this ... On Sun, 2013-11-10 at 18:46 +0100, Hans wrote: Wouldn't it be much easier to define a group, give the partition or directory this group write permission and put all users, which are allowed to write (and trusted) into this group? ... is what you want. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1384108129.1074.48.camel@archlinux
Re: /etc/fstab question
Richard Owlett wrote: I wish to have all users of all Debian installs on my laptop have unrestricted access to everything on a particular partition. It was suggested adding a line to /etc/fstab would accomplish my goal. I saw that thread, and the suggestion, but didn't comment then because I had not run the experiment myself yet. And David Christensen had an excellent suggestion in that thread to use group level access permissions. I would definitely do that instead. But though I didn't comment then I will go back and make a comment now. On rebooting it failed with a missing mount point message. As root I did a mkdir. For any mount point you will need to have a directory to mount it upon. There were no error messages on the next reboot. Right. Mounted it by root as user:group root:root. As it was configured to do. However when I displayed the directory with Nautilus, the icons for all existing files and folders were flagged with the lock icon adjacent. Yes. Makes sense to me. They had been created under a Debian install which no longer is present. This sentence came from somewhere but I know not where. I think this may be something that should be discussed as its own topic. Is this the expected result? Yes. Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? That would be a bad thing to do for several reasons. One is that not all files should be executable. Mode 777 will make all files executable even files that should not be executable. Another is that if you ever copy a file out of there then the permissions will be preserved and elsewhere they will be the wrong permissions. Another is that doing that only fixes the current crop of files. As soon as you create a new file the problem will reappear with that new file. This just isn't going to work out well in the end. Don't do it! :-) In the previous thread: How do I force all files to be written to that partition to be readable AND writable to everybody? I didn't comment there previously but will go back and make one now. Because I think my response to it should be threaded there. Bob signature.asc Description: Digital signature
Re: /etc/fstab question
berenger.mo...@neutralite.org wrote: Le 10.11.2013 18:06, Richard Owlett a écrit : Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? TIA It will, but remember that it will also allow them to change file permissions, and so to remove rights to other users. That's not an actual problem. I'm the only physical user. The laptop in question is dedicated to my learning experiments. It physically does not even have network access of any kind. In my opinion, if you want such kind of partition, the easier solution is to use a partition system which does not have the user right feature. The first one which comes to my mind, is the FAT family. DUH! I'm already doing that for a USB stick exchanging text files with my Windows machine. Since you seems to use ext2, you anyway do not have the log feature ( the thing which avoid corrupted files in case of a problem ) so I only see the drawback of file names not doing difference between uppercase and lowercase characters. I had use ext2 as eventually I intend to use flash drive and wanted minimize wear. But, still IMO, this one is more a drawback of ext* partition tables than of FAT, since it is not really natural for me and people I know to differentiate words by the case of their letters*. On the other hand, since you spoke about icons and graphical stuff, I bet that your users are not console users, so they won't be that annoyed. I'm the universe of users. I've spent too many decades with Windows. I started out when only TTY at 110 baud was available. When I first got Win 3.1, I regularly dropped to DOS box in order to get work done. Have come full circle now. *: and if someone have any clue to allow my terminal to stop bothering me with that damned case difference in file names, I would really be grateful to know it. For now, I simply stop using case when naming files, but it is less readable and is not applicable to other people's files... I vaguely recall something addressing that from the Win3.1/DOS era involving a shadow directory. But may have been concerned with long file names vs 8.3 format names. Thanks -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527fd66a.3080...@cloud85.net
Re: /etc/fstab question
Ralf Mardorf wrote: On Sun, 2013-11-10 at 11:06 -0600, Richard Owlett wrote: /dev/sda5/owlettext2rw,users,exec Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? I can't say anything about your fstab entry, but at least chmod -R 777 will permit the needed permissions, but then the permissions are the same for other installs too. I'm not sure chmod -R 777 alone gives my desired result. I'll have do see if I can DUPLICATE FROM MEMORY situation which led to question. IIRC I had created some folders and files on a partition as root. Later realized I wanted read/write access as a normal user. As root did chmod -R 777 which gave me desired access as normal user. Later, for reasons I don't recall, I created more files as root. Those files DID NOT allow write access to a normal user. The question has become somewhat academic as another reply reminded me I could simply use a fat format. DUH! ;/ Especially as that's how I'm currently sharing some text files with my Windows machine. Thanks. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/527fce8c.5000...@cloud85.net
Re: /etc/fstab question
Richard Owlett wrote: to which I added this line /dev/sda5/owlettext2rw,users,exec 'users' should be 'user'. Also add '0 0' at he end of the line. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131110204748.ab3c4975.shiems...@kpnplanet.nl
Re: /etc/fstab question
On 11 November 2013 06:47, Siard shiems...@kpnplanet.nl wrote: Richard Owlett wrote: to which I added this line /dev/sda5/owlettext2rw,users,exec 'users' should be 'user'. Also add '0 0' at he end of the line. According to 'man 5 fstab', adding '0 0' is unecessary: If the fifth field is not present, a value of zero is returned and If the sixth field is not present or zero, a value of zero is returned. The zeros are only required as placeholders for following nonzero values. If they are all zero, they don't do anything. And in my observation, the same goes for defaults in the 4th field, it is only required as a placeholder if either of field 5 or 6 are in use. Otherwise it can be omitted too. Typically, field4=defaults and field5=0 are required when field6 is nonzero to activate a fsck on the device at boot. If fsck is not required at boot, and field 6 is zero, then I omit all these values. I have /etc/fstab entries with only 3 fields, it works as I describe. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMPXz=o2mc0=vBBGRHb35ewb6u6fhckip=Czrb-MKfqgQ=1...@mail.gmail.com
Re: /etc/fstab question
Le 10.11.2013 19:54, Richard Owlett a écrit : berenger.mo...@neutralite.org wrote: Le 10.11.2013 18:06, Richard Owlett a écrit : Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? TIA It will, but remember that it will also allow them to change file permissions, and so to remove rights to other users. That's not an actual problem. I'm the only physical user. The laptop in question is dedicated to my learning experiments. It physically does not even have network access of any kind. So, security and user errors are not so important, indeed. In my opinion, if you want such kind of partition, the easier solution is to use a partition system which does not have the user right feature. The first one which comes to my mind, is the FAT family. DUH! I'm already doing that for a USB stick exchanging text files with my Windows machine. And why not doing the same on that partition? Since you seems to use ext2, you anyway do not have the log feature ( the thing which avoid corrupted files in case of a problem ) so I only see the drawback of file names not doing difference between uppercase and lowercase characters. I had use ext2 as eventually I intend to use flash drive and wanted minimize wear. I am sorry, I do not understand what you mean by minimize wear. ( yes, I do not only use that list to learn stuff about Debian, it also helps me to work my English since I have no other occasions to do that, sadly ;) ) But, still IMO, this one is more a drawback of ext* partition tables than of FAT, since it is not really natural for me and people I know to differentiate words by the case of their letters*. On the other hand, since you spoke about icons and graphical stuff, I bet that your users are not console users, so they won't be that annoyed. I'm the universe of users. I've spent too many decades with Windows. I started out when only TTY at 110 baud was available. When I first got Win 3.1, I regularly dropped to DOS box in order to get work done. dosshell was nice at that time. But I stopped using consoles between win3.1 and win95, included. Started anew when I learned programming, with ncurses IDE. Those where by far better that the IDEs I can play with currently... But that's another topic. Have come full circle now. I did the same, but I would not speak about a circle. It is more like a spiral, because 1) DOS can not compete at all with our modern shells/terminals, and 2) those shells/terminals into a tiling window manager are just so powerful that they beat any graphical file browser. And I only does it in a weak way. *: and if someone have any clue to allow my terminal to stop bothering me with that damned case difference in file names, I would really be grateful to know it. For now, I simply stop using case when naming files, but it is less readable and is not applicable to other people's files... I vaguely recall something addressing that from the Win3.1/DOS era involving a shadow directory. But may have been concerned with long file names vs 8.3 format names. I did not played enough with the older FAT formats, but I think that a good part of the reasons behind the 8.3 format names were DOS limitations. That OS was first named Quick and Dirty Operating System after all, and that long file names stuff shows it too. Shadowing things is very easy with FAT, and the format is itself a child game to understand. I was less than 16 when I played with winhex, an hexadecimal editor able to edit hard disks on windows (and the best hexadecimal editor I have ever seen. Unfortunately, I never had the money to buy license and now that I could buy the cheaper ones, I no longer use windows... ) and used that knowledge to do various things, from most basic ones (file recovery) to more complex ones (I do not remember what however. More that 10 years is a lot of time for me). I can not understand how a patent can be made on such a primitive system, in fact, since it is so close to what you can find in a novel: summary of chapters with some informations (position, number of blocks, names), and chapters (files). But I can not understand a lot of USA's patents. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/58b60bfe2aad57d308ceab08910b2...@neutralite.org
Re: /etc/fstab question
On 11/10/2013 09:06 AM, Richard Owlett wrote: I wish to have all users of all Debian installs on my laptop have unrestricted access to everything on a particular partition. It was suggested adding a line to /etc/fstab would accomplish my goal. ... /dev/sda5 /owlett ext2 rw,users,exec On rebooting it failed with a missing mount point message. As root I did a mkdir. There were no error messages on the next reboot. Yes. Mount needs an existing directory in the file system to mount /dev/sda5. 'mkdir /owlett' was the correct solution. However when I displayed the directory with Nautilus, the icons for all existing files and folders were flagged with the lock icon adjacent. They had been created under a Debian install which no longer is present. Is this the expected result? If your system has the default UMASK of 0022 (e.g. no write permission for 'group' and 'other'), then regular files will be created with a mode of (in C) 0666 ~UMASK, which equals 0644, and directories will be created with a mode of 0777 ~MASK, which equals 0755. So, yes, when you log in using a different account, you don't have write permission for those files and directories, and Nautilus is letting you know that with the lock icon. Will doing chmod -R 777 /owlett allow all users of any Debian install having the edited /etc/fstab have unrestricted access to all files and folders on that partition? You want 0777 for directories, but 0666 for files. Use a symbolic mode specification for 'chmod' that reverses the effect of UMASK: # chmod --recursive go+w /owlett HTH, David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5280808e.2060...@holgerdanske.com
Re: /etc/fstab question
On 11/10/2013 09:28 AM, berenger.mo...@neutralite.org wrote: ... In my opinion, if you want [a scratch pad partition for all groups/users], the easier solution is to use a partition system which does not have the user right feature. The first one which comes to my mind, is the FAT family. +1 David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5280813a.7090...@holgerdanske.com
Re: /etc/fstab question
On 11/10/2013 10:37 AM, Bob Proulx wrote: ... ['chmod -R 777 /owlett'] would be a bad thing to do for several reasons. One is that not all files should be executable. Mode 777 will make all files executable even files that should not be executable. Another is that if you ever copy a file out of there then the permissions will be preserved and elsewhere they will be the wrong permissions. Another is that doing that only fixes the current crop of files. As soon as you create a new file the problem will reappear with that new file. This just isn't going to work out well in the end. Don't do it! :-) +1 David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/528081fa.1070...@holgerdanske.com
Re: /etc/fstab question
On 11/10/2013 09:46 AM, Hans wrote: Wouldn't it be much easier to define a group, give the partition or directory this group write permission and put all users, which are allowed to write (and trusted) into this group? It's been a while, but I've done that. I seem to recall that the key was to set the SETGID bit on all the directories. David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52808421.70...@holgerdanske.com
Re: /etc/fstab question
On 11/10/2013 10:54 AM, Richard Owlett wrote: I'm the only physical user. The laptop in question is dedicated to my learning experiments. It physically does not even have network access of any kind. Ouch. I assume you mean no Ethernet interface. Note that it is possible to network over other connections (serial, parallel, Firewire, etc.). David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52808568.3090...@holgerdanske.com
Re: /etc/fstab question
David Christensen wrote: On 11/10/2013 09:46 AM, Hans wrote: Wouldn't it be much easier to define a group, give the partition or directory this group write permission and put all users, which are allowed to write (and trusted) into this group? It's been a while, but I've done that. I seem to recall that the key was to set the SETGID bit on all the directories. +1 :-) Because the set-gid bit means that when new files are created that they will be created with the same group as the directory. So with that any new files will be of the correct group. This feature originated with BSD. But in BSD it is the default behavior regardless of the set-gid bit. In BSD you always get that behavior. (AFAIK. It has been a while since I have been on a BSD system.) When it was ported back to ATT Unix they made it selectable by using the g+s bit. That allowed SysV Unix to preserve the previous behavior and optionally enable the BSD behavior. POSIX then standardized the existing behavior. Since SysV had the most flexible interface and was more of the basis of POSIX than anything else that is the way POSIX standardized it. And Linux generally tries to be POSIX standard and so Linux follows SysV with this behavior of the set-gid bit behavior. Bob signature.asc Description: Digital signature