Re: /etc/fstab question (problem)?

[David Wright]

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

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

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

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

I take it you're not running an i386:

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

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

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

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

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

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

Cheers,
David.

Re: /etc/fstab question (problem)?

[Celejar]

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

[songbird]

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

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


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

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


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


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


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


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


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


  songbird

Re: /etc/fstab question (problem)?

[David Christensen]

On 4/22/23 21:11, David Wright wrote:

On Sat 22 Apr 2023 at 18:51:26 (-0700), David Christensen wrote:

On 4/22/23 08:24, David Wright wrote:

On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:

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

On 20/04/2023 04:03, David Christensen wrote:

* What if root attempts to remove everything under /etc, in
anticipation of mounting a file system at /etc, when one or
more programs have one or more open temporary files?


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



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

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

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


On 4/21/23 15:46, David Christensen wrote:

I apologize for the errors.  :-(


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



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


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

2.  The path may not exist.

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

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



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





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

But today, this is my Linux daily driver:



Total online memory:  32G


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



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




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



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


I think your kernel is probably more like 12.3MB of code. 



Where do you get 12.3MB?


Your initrd
is larger than mine: I'd have to see inside to tell why, but no matter.


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


Overkill for what? I don't understand.



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





David

Re: /etc/fstab question (problem)?

[David Wright]

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

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

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

> Total online memory:  32G

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

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

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

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

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

Overkill for what? I don't understand.

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

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

Cheers,
David.

Re: /etc/fstab question (problem)?

[David Christensen]

On 4/22/23 08:24, David Wright wrote:

On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:

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

On 20/04/2023 04:03, David Christensen wrote:

* What if root attempts to remove everything under /etc, in
anticipation of mounting a file system at /etc, when one or
more programs have one or more open temporary files?


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



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

On 4/21/23 08:12, Max Nikulin wrote:
> David, you were wrote /etc instead of /tmp in several messages

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




"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)?

[David Wright]

On Fri 21 Apr 2023 at 15:46:30 (-0700), David Christensen wrote:
> On 4/21/23 08:12, Max Nikulin wrote:
> > On 20/04/2023 04:03, David Christensen wrote:
> > > * What if root attempts to remove everything under /etc, in
> > > anticipation of mounting a file system at /etc, when one or
> > > more programs have one or more open temporary files?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> As for systemd:
> 

Re: gitification (was Re: /etc/fstab question (problem)?

[DdB]

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

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

Re: /etc/fstab question (problem)?

[David Christensen]

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

On 20/04/2023 04:03, David Christensen wrote:
* What if root attempts to remove everything under /etc, in 
anticipation of mounting a file system at /etc, when one or more 
programs have one or more open temporary files?


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



I apologize for the errors.  :-(


I will strive to do more proofreading before posting.


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



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



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



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



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


I think, in this case live image (unlike reboot) was not strictly 
necessary and may reduce down time if it is critical. I think, the 
following is safe enough (not verified, may contain typos or even errors):

- backup /etc/fstab and current initrd
- have a look into grub.cfg and grub manual to be able to boot using 
backup file

- restore /etc/fstab from backup
- Do not run "systemctl daemon-reload", since till shutdown systemd 
should work accordingly to content of old fstab version

- update-initramfs -u
- reboot. It is required after adding /tmp to fstab to make new fstab 
active and after update-initramfs to verify that new fstab does cause 
boot issue. Single reboot should be enough, however another one before 
update-initramfs is possible.

- mount --bind / /mnt
- remove files from /mnt/tmp/ remained from the previous boot. Otherwise 
some large file hidden by mounted /tmp may reduce free space available 
on the / partition

- umount /mnt
- remove initrd backup



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


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


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



As for systemd:

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


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



David

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

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

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

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

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

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


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

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


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

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


  songbird

Re: /etc/fstab question (problem)?

[Max Nikulin]

On 20/04/2023 04:03, David Christensen wrote:
* What if root attempts to remove everything under /etc, in anticipation 
of mounting a file system at /etc, when one or more programs have one or 
more open temporary files?


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


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


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


I think, in this case live image (unlike reboot) was not strictly 
necessary and may reduce down time if it is critical. I think, the 
following is safe enough (not verified, may contain typos or even errors):

- backup /etc/fstab and current initrd
- have a look into grub.cfg and grub manual to be able to boot using 
backup file

- restore /etc/fstab from backup
- Do not run "systemctl daemon-reload", since till shutdown systemd 
should work accordingly to content of old fstab version

- update-initramfs -u
- reboot. It is required after adding /tmp to fstab to make new fstab 
active and after update-initramfs to verify that new fstab does cause 
boot issue. Single reboot should be enough, however another one before 
update-initramfs is possible.

- mount --bind / /mnt
- remove files from /mnt/tmp/ remained from the previous boot. Otherwise 
some large file hidden by mounted /tmp may reduce free space available 
on the / partition

- umount /mnt
- remove initrd backup

Re: /etc/fstab question (problem)?

[Greg Wooledge]

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

[rhkramer]

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

[tomas]

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

[David Wright]

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

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

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

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

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

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

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

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

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

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

¹ originally applied to servers, I believe.

Cheers,
David.

Re: gitification (was Re: /etc/fstab question (problem)?

[David Christensen]

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

[Jeremy Ardley]

On 21/4/23 05:41, songbird wrote:

Stefan Monnier wrote:


   songbird


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


lfs has the ability to script xattr handling

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

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


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

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

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


--
Jeremy
(Lists)

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

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

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


  songbird

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

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

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

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

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

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


  songbird

Re: gitification (was Re: /etc/fstab question (problem)?

[David Christensen]

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

[Stefan Monnier]

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

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

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


Stefan

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

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

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


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

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

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


  songbird

Re: gitification (was Re: /etc/fstab question (problem)?

[songbird]

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

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

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

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


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

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


  songbird

Re: gitification (was Re: /etc/fstab question (problem)?

[Max Nikulin]

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

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


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

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


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

Re: /etc/fstab question (problem)?

[Max Nikulin]

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

Default User wrote:

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


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

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


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


Partition UUIDs are affected as well, but e.g. sgdisk has a dedicated 
option:

https://www.rodsbooks.com/gdisk/sgdisk.html

-G, --randomize-guids
Randomize the disk's GUID and all partitions' unique GUIDs (but not
their partition type code GUIDs). This function may be used after
cloning a disk in order to render all GUIDs once again unique


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

Re: /etc/fstab question (problem)?

[Default User]

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

[Stefan Monnier]

>   one of the worst design decisions i've come across in 
> the modern era was the lack of Git respecting file metadata.
>
>   i got bit by this a few weeks ago yet again.  i hate using
> Git because of it destroying my file meta data.

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

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

It could be a sister project of Git.


Stefan

Re: gitification (was Re: /etc/fstab question (problem)?

[Jeremy Ardley]

On 20/4/23 20:10, songbird wrote:


   aside rant,

   thank gitification for that IMO.

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

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


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


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


--
Jeremy
(Lists)

Re: /etc/fstab question (problem)?

[songbird]

Default User wrote:
...
> Well, now I am totally confused. 
>
> I had hoped for, and really expected, an easy, obvious, intuitive
> solution.  But I guess that may be a distant memory of the good old
> days, before [insert string of four-letter words here] like dbus,
> systemd, and Gnome 3. And when partitions were named /dev/hda5, not
> 6a105a72-f5d5-441b-b926-1e405151ee84.
>
> Sigh.
...

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

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


  songbird

Re: /etc/fstab question (problem)?

[songbird]

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

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

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


  songbird

gitification (was Re: /etc/fstab question (problem)?

[songbird]

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

  aside rant,

  thank gitification for that IMO.

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

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


  songbird

Re: /etc/fstab question (problem)?

[DdB]

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

[Default User]

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

[David Christensen]

On 4/19/23 17:24, Default User wrote:

>> On Wed, 2023-04-19 at 18:07 +0700, Max Nikulin wrote:
>>> Perhaps update-initramfs is necessary after restoring of
>>> /etc/fstab in any chosen approach.


Looking at the Wikipedia page "Initial ramdisk":

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

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




Okay . . .  The problem seems to be solved!

What I did:

1) Booted into Debian 11.6 Live/install usb thumb drive.

2) As root, mounted the / partition from the internal ssd.

3) On the internal ssd, replaced /etc/fstab with /etc/fstab.original.
(On the internal ssd, I did not delete /tmp or its contents, and did
not delete the tmp partition or its contents.)

4) Unmounted the / partition on the internal ssd.

5) Shutdown and removed the usb thumb drive.

6) Booted in to the computer as usual.

It *seems* to have worked fine, with /tmp mounted on its dedicated
partition again.
  
But there may still be leftover stuff in /tmp, so maybe later I will

again boot from the live usb, delete everything in /tmp (but not /tmp
itself) on the internal ssd, and reboot into the system, which will
presumably have re-populated with no leftovers.

So far, so good.

Much thanks to all who have weighed in on this!



I am glad it worked out.  :-)


David

[SOLVED] Re: /etc/fstab question (problem)?

[Default User]

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

[davidson]

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

[David Christensen]

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

[David Christensen]

On 4/19/23 14:26, Default User wrote:

On Wed, 2023-04-19 at 14:03 -0700, David Christensen wrote:

On 4/19/23 13:06, Default User wrote:

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



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



But, I cannot address Max's point about initrd(4).


At this point, I would run my daily backups, use an editor to put the
original /etc entry back into /etc/fstab, forget about messing with
/etc
on either file system, and reboot.  After reboot, I would run 'df
/etc'
and check where /etc is mounted.  If /etc is "Mounted on /", I would
run
update-initramfs(8), reboot, and look again.



I'm afraid I don't quit understand why 'If /etc is "Mounted on /", I
would run update-initramfs(8), reboot, and look again."


Shouldn't etc always be expected to be mounted under /, as in /etc?
For example, right now on my computer:

df /etc
Filesystem 1K-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)?

[Default User]

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

[David Christensen]

On 4/19/23 13:06, Default User wrote:

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

On 19/04/2023 16:16, David Christensen wrote:

On 4/18/23 20:16, Stefan Monnier wrote:


You can also do

  mount --bind / /mnt

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


+1  I like that better than the reboot/ live drive idea I posted.


I think, it is the case when reboot is safer. Open file descriptors
remain on the original partition. However I do not expect that single
user mode or booting from live image is required. Just restore
original
/etc/fstab and reboot.

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





Well, now I am totally confused.



+1  I am confused most of the time.  LOL  ;-)




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

[Default User]

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

[Default User]

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

[David Wright]

On Wed 19 Apr 2023 at 18:07:51 (+0700), Max Nikulin wrote:
> On 19/04/2023 16:16, David Christensen wrote:
> > On 4/18/23 20:16, Stefan Monnier wrote:
> > 
> > > You can also do
> > > 
> > >  mount --bind / /mnt
> > > 
> > > and then look at /mnt/tmp.
> > > No need to reboot into single-user mode for that.

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

> > +1  I like that better than the reboot/ live drive idea I posted.
> 
> I think, it is the case when reboot is safer. Open file descriptors
> remain on the original partition. However I do not expect that single
> user mode or booting from live image is required. Just restore
> original /etc/fstab and reboot.

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

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

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

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

Cheers,
David.

Re: /etc/fstab question (problem)?

[David Wright]

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

[Dan Ritter]

Default User wrote: 
> 
> Well, now I am totally confused. 
> 
> I had hoped for, and really expected, an easy, obvious, intuitive
> solution.  But I guess that may be a distant memory of the good old
> days, before [insert string of four-letter words here] like dbus,
> systemd, and Gnome 3. And when partitions were named /dev/hda5, not
> 6a105a72-f5d5-441b-b926-1e405151ee84.

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

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

> Does that seem reasonable? 

Yes, it is.

-dsr-

Re: /etc/fstab question (problem)?

[Default User]

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

[Default User]

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

[Max Nikulin]

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

[David Christensen]

On 4/18/23 20:16, Stefan Monnier wrote:


You can also do

 mount --bind / /mnt

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



+1  I like that better than the reboot/ live drive idea I posted.


David

Re: /etc/fstab question (problem)?

[tomas]

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

[Stefan Monnier]

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

You can also do

mount --bind / /mnt

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


Stefan

Re: /etc/fstab question (problem)?

[David Wright]

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

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

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

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

If you add the "lost line" back into fstab:
  UUID=6a105a72-f5d5-441b-b926-1e405151ee84 /tmp ext4 defaults 0 2
then when the system starts up, partition 5 will be mounted onto
/tmp in the root filesystem, and then it'll be cleaned of any files
left over from the last time it was used. It might be a long, long
time since you used it so there could conceivably be files that you
want to check out.

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

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

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

> Finally, after the current situation is resolved, I would still like to
> know what caused the problem in the first place. I would really like to
> not have it happen again!

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

Cheers,
David.

Re: /etc/fstab question (problem)?

[David Christensen]

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


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



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



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



Looking back at previous posts:


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

> Current /etc/fstab:
> #  
>
> 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)?

[Charles Curley]

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

[Default User]

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

[David Christensen]

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

On Tue, 2023-04-18 at 13:03 -0700, David Christensen wrote:

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

Hey, I have a strange situation!

I just realized that my /tmp partition is not being mounted at
startup.
Instead, I think the filesystem may be allocating space in another
partition (maybe /root?) for tmp stuff.



My / (root) and /tmp directories are on the same file system -- the
root
filesystem:

2023-04-18 12:46:41 root@taz ~/taz.tracy.holgerdanske.com
# stat -c %d / /tmp
65024
65024



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



stat(1) is saying that the file system entries "/" and "/tmp" have the 
same "device number".  Device numbers should be unique for the various 
file systems that are mounted on one computer:


# mount | perl -ane '$_=$F[2];$dev=(stat)[0];print"$dev $_\n"' | sort -n
 /run/user/13250/doc
5 /dev
6 /sys/kernel/security
7 /sys/kernel/debug
11 /sys/kernel/tracing
19 /dev/mqueue
20 /sys
21 /proc
22 /dev/pts
23 /run
26 /dev/shm
27 /run/lock
28 /sys/fs/cgroup
29 /sys/fs/pstore
30 /sys/firmware/efi/efivars
31 /sys/fs/bpf
32 /proc/sys/fs/binfmt_misc
33 /dev/hugepages
34 /sys/fs/fuse/connections
35 /sys/kernel/config
39 /samba/dpchrist
40 /samba/groupshare
42 /run/user/13250
50 /run/user/0
2049 /boot/efi
2050 /boot
65024 /
65026 /scratch


That said, I think I prefer the df(1) solution posted by Greg Wooledge.



(And BTW, the current /etc/fstab must have been written by some
program, not manually by me.  I would never have edited /etc/fstab to
look like that!) My best guess is that I may have done a system restore
using Timeshift on 2023-04-03, to back out of some unremembered
problem, and the current /etc/fstab results from that.



Backing up system configuration files is good.


I use a version control system (CVS), create a project for each host, 
and check in every system configuration file I create, update, or 
delete.  I also keep a log.txt file for each system, write notes to 
myself, save console sessions, etc., for when I do need to remember what 
I did, when, and why.  Rather than restoring entire system configuration 
files, I typically use an editor and restore specific settings.




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



Why not?



Maybe I should just start by using Clonezilla to do a full image of the
drive. Actual data of course, not the entire 256 Gb!



Putting your data on a different device than your OS allows you to 
optimize device usage and backup, restore, archive, imaging, etc., 
procedures.




More later . . .



David

Re: /etc/fstab question (problem)?

[Greg Wooledge]

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

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

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

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

Re: /etc/fstab question (problem)?

[Default User]

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

[Tom Furie]

On Tue, Apr 18, 2023 at 09:00:00PM +0200, to...@tuxteam.de wrote:
> Since Debian erases /tmp at each boot anyway: wouldn't it be
> much easier to set up an entry in fstab along the lines of
> 
>   tmpfs/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)?

[David Christensen]

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

[tomas]

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

[Max Nikulin]

On 18/04/2023 22:37, Charles Curley wrote:

1) Preserve the current contents of /tmp,
2) Adjust fstab to include the /tmp partition,
3) Mount the /tmp partition
4) Restore the contents of /tmp


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


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

Re: /etc/fstab question (problem)?

[songbird]

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

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

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


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


  songbird

Re: /etc/fstab question (problem)?

[Charles Curley]

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

[DdB]

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

[Default User]

Hey, I have a strange situation! 

I just realized that my /tmp partition is not being mounted at startup.
Instead, I think the filesystem may be allocating space in another
partition (maybe /root?) for tmp stuff. 

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

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

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

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

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

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

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

Current /etc/fstab:
#  

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: an fstab question

[Martin McCormick]

Ben Caradoc-Davies  writes:
> Martin, please show us the failing line. noatime works fine for me in 
> fstab

Thank you. Your example reminded me of the error of my
ways or rather syntax.

The , was missing in the following line:

UUID=[] /   noatime,errors=remount-ro   
0   1
and now everything seems to be quite normal. I tested it by 

mount -a

so now I will try a reboot and hope I don't need the rescue disk.

Again, many thanks.

Re: an fstab question

[Ben Caradoc-Davies]

On 10/05/17 14:50, Martin McCormick wrote:

One of the suggestions for improving the longevity of solid-state drives is
to mount them using the noatime flag which reduces the number of
times that inodes are written to. if I try something like:
UUID=[string] /   ext4 errors=remount-ro 0   1
It works. If I put relatime there, that works but if I use
noatime, the line is flagged as bad.
The man page for mount shows noatime and relatime so why
does noatime not work?
Many thanks.
Martin McCormick


Martin, please show us the failing line. noatime works fine for me in fstab:

/dev/mapper/vg-root /   ext4 
noatime,errors=remount-ro   0   1


mount confirms that it is being honoured:

/dev/mapper/vg-root on / type ext4 
(rw,noatime,errors=remount-ro,data=ordered)


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

an fstab question

[Martin McCormick]

One of the suggestions for improving the longevity of solid-state drives is
to mount them using the noatime flag which reduces the number of
times that inodes are written to. if I try something like:

UUID=[string] /   ext4 errors=remount-ro 0   1

It works. If I put relatime there, that works but if I use
noatime, the line is flagged as bad.

The man page for mount shows noatime and relatime so why
does noatime not work?

Many thanks.

Martin McCormick

Re: /etc/fstab question

[Joe]

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

[berenger . morel]

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

[Richard Owlett]

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

[Richard Owlett]

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

[Richard Owlett]

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

[Luis Bandarra]

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

[Bear]

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

[Richard Owlett]

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

[Ralf Mardorf]

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

[berenger . morel]

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

[Hans]

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

[Ralf Mardorf]

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

[Bob Proulx]

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

[Richard Owlett]

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

[Richard Owlett]

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

[Siard]

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

[David]

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

[berenger . morel]

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

[David Christensen]

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

[David Christensen]

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

[David Christensen]

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

[David Christensen]

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

[David Christensen]

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

[Bob Proulx]

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

mount/fstab question [WAS: Re: SV: Unidentified subject!]

[Brad]

On Tue, 20 Jul 1999 [EMAIL PROTECTED] wrote:

 Oki. I just put a 'defaults' there... What does nosuid,nodev and use do?
 Where is the man page for this? (Not the normal man fstab)

The fstab manpage refers you to the mount manpage. In there, it tells what
nearly all the options for all the various filesystems will do.

Re: mount/fstab question [WAS: Re: SV: Unidentified subject!]

[Carl Mummert]

 Oki. I just put a 'defaults' there... What does nosuid,nodev and use do?
 Where is the man page for this? (Not the normal man fstab)

The options are filesystem-specific.  Try mount(8) and nfs(5) to see
what options are available for the filesystem you are mounting.
Skip the nfs page if you do't use nfs.

Oh... mount(8) means to run
$  man 8 mount

Carl

Re: fstab question

[Pollywog]

On 12-Mar-99 shaul wrote:
 I am using sudo for doing it. Perhaps the automounter can also help, but I 
 have not tried it. I do not know if there is a way to do it with groups 
 permitions and fstab. If there is I would also like to know.
 
   hope this help.
 
 Isn't it possible to set up fstab to that only users of a certain group can
 mount or unmount floppies or CDROM?  I don't want just anyone to be able to
 do
 it, but I would like to be able to do it without being root.
 

I did use sudo and then I took a different route.  I made the 'mount'
binary executable only by root.wheel.  It works great.

--
Andrew


*happiness is a clean pond*
[PGP5.0 KeyID 0x5EE61C37]

Re: fstab question

[Matt Folwell]

On Thu, Mar 11, 1999 at 04:33:04AM -, Pollywog wrote:

 Is there a way for me to be able to mount both /a and /floppy on the KDE
 desktop (no, not at the same time)?  It seems I will have to mount /a from the
 command line only, when I need to mount a dos floppy (not often).

Do you really need to have separate mount points according to the
filesystem?  You can set the filesystem type to auto and let the kernel
work out what it is.  That's what I do for floppies, although I don't
use KDE, so I don't know exactly what you want.

-- 
Matt Folwell, P2 Whewell's Court, Trinity College, Cambridge.  CB2 1TQ
[EMAIL PROTECTED]

Re: fstab question

[Andrew Holmes]

Hi,

When I use the 'auto' filesystem type in fstab, my vfat floppies are
detected as umsdos and I lose the long filenames. Is there a way around
this?

Andy Holmes  West Sussex, England

[EMAIL PROTECTED]

The path of my life is strewn with cow pats from the devil's own satanic
herd!, Edmund Blackadder

Re: fstab question

[shaul]

 Is there a way for me to be able to mount both /a and /floppy on the KDE
 desktop (no, not at the same time)?  It seems I will have to mount /a from the
 command line only, when I need to mount a dos floppy (not often).
 

Using mtools can save you the trouble of dealing with fstab when dos/vfat 
floppies are concerned and let you use groups permitions in order restrict 
access to the floppy drive.