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 i
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
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
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:
* W
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 att
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,
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 pr
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 yo
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
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
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
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
cert
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 pr
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) sym
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
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,
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 begi
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
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
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 diff
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 partitio
>> 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 maintai
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/
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
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
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 hat
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 pa
> 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 m
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 destroyi
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 whe
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
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 sh
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
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:
> > > >
> > > > >
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
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 +0
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 backu
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
/
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
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
> > >
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
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)
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 theoreti
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 mo
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 star
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 wh
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 fo
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 fo
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
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
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/tmptmpfsdefault
> 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.
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 ba
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 pr
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 re
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 part
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 spa
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:~$
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
> > pa
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, rep
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, wh
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
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 s
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 i
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
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,
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 s
67 matches
Mail list logo
