On Fri, Jul 24, 2020 at 09:49:04PM +0300, Andrei POPESCU wrote:
> On Vi, 24 iul 20, 17:53:53, to...@tuxteam.de wrote:
[...]
> Aren't those files an internal implementation detail? Most users won't
> ever need to interact with those files or even be aware of their
> existence.
Strictly speaking
On Fri, Jul 24, 2020 at 09:49:04PM +0300, Andrei POPESCU wrote:
> Aren't those files an internal implementation detail? Most users won't
> ever need to interact with those files or even be aware of their
> existence.
The whole design is built around "you can do this with systemctl commands,
or b
On Vi, 24 iul 20, 17:53:53, to...@tuxteam.de wrote:
> On Fri, Jul 24, 2020 at 05:18:24PM +0300, Andrei POPESCU wrote:
> > On Vi, 24 iul 20, 15:00:32, Jonathan Dowland wrote:
> > > On Thu, Jul 23, 2020 at 01:26:50PM +0300, Andrei POPESCU wrote:
> > > > Seriously?
> > >
> > > Yes seriously. This is
On Fri, Jul 24, 2020 at 05:18:24PM +0300, Andrei POPESCU wrote:
> On Vi, 24 iul 20, 15:00:32, Jonathan Dowland wrote:
> > On Thu, Jul 23, 2020 at 01:26:50PM +0300, Andrei POPESCU wrote:
> > > Seriously?
> >
> > Yes seriously. This is a pain point that could be avoided. I'm not a
> > systemd hater.
On Vi, 24 iul 20, 15:00:32, Jonathan Dowland wrote:
> On Thu, Jul 23, 2020 at 01:26:50PM +0300, Andrei POPESCU wrote:
> > Seriously?
>
> Yes seriously. This is a pain point that could be avoided. I'm not a
> systemd hater. I do some quite advanced things with it. But I don't
> think it's above cri
On Fri, Jul 24, 2020 at 09:52:29AM -0400, Greg Wooledge wrote:
[...]
> I don't know of any specific term for a directory's physical
> manifestation, other than "directory".
>
> In the olden days, a directory was basically a series of 16-byte
> records (14 bytes for the filename, 2 bytes for the
On Fri, Jul 24, 2020 at 09:56:27AM -0400, The Wanderer wrote:
> On 2020-07-24 at 09:50, to...@tuxteam.de wrote:
[...]
> Since writing that, I've had occasion to remember the term 'dirent',
> which I think is more the in-memory representation of a directory than
> the on-disk representation, but m
On Thu, Jul 23, 2020 at 01:26:50PM +0300, Andrei POPESCU wrote:
Seriously?
Yes seriously. This is a pain point that could be avoided. I'm not a
systemd hater. I do some quite advanced things with it. But I don't
think it's above criticism, and this is an area I feel is worthy of
criticism.
Co
On 2020-07-24 at 09:50, to...@tuxteam.de wrote:
>
> On Fri, Jul 24, 2020 at 09:42:24AM -0400, The Wanderer wrote:
>
>> On 2020-07-24 at 09:22, to...@tuxteam.de wrote:
>>> Nitpick: the directory entry is the one carrying the name.
>>
>> I had the impression that even a directory is stored in/as
On Fri, Jul 24, 2020 at 09:42:24AM -0400, The Wanderer wrote:
> On 2020-07-24 at 09:22, to...@tuxteam.de wrote:
>
> > On Fri, Jul 24, 2020 at 07:54:27AM -0400, Greg Wooledge wrote:
> >
> >> On Fri, Jul 24, 2020 at 07:49:26AM -0400, The Wanderer wrote:
> >>
> >>> Sounds like a case where directly
On Fri, Jul 24, 2020 at 09:42:24AM -0400, The Wanderer wrote:
On 2020-07-24 at 09:22, to...@tuxteam.de wrote:
On Fri, Jul 24, 2020 at 07:54:27AM -0400, Greg Wooledge wrote:
On Fri, Jul 24, 2020 at 07:49:26AM -0400, The Wanderer wrote:
Sounds like a case where directly editing the underlying
On Fri, Jul 24, 2020 at 09:42:24AM -0400, The Wanderer wrote:
> On 2020-07-24 at 09:22, to...@tuxteam.de wrote:
>
> > On Fri, Jul 24, 2020 at 07:54:27AM -0400, Greg Wooledge wrote:
> >
> >> On Fri, Jul 24, 2020 at 07:49:26AM -0400, The Wanderer wrote:
> >>
> >>> Sounds like a case where directly
On 2020-07-24 at 09:22, to...@tuxteam.de wrote:
> On Fri, Jul 24, 2020 at 07:54:27AM -0400, Greg Wooledge wrote:
>
>> On Fri, Jul 24, 2020 at 07:49:26AM -0400, The Wanderer wrote:
>>
>>> Sounds like a case where directly editing the underlying device,
>>> to modify inode-or-equivalent contents s
On Fri, Jul 24, 2020 at 07:54:27AM -0400, Greg Wooledge wrote:
> On Fri, Jul 24, 2020 at 07:49:26AM -0400, The Wanderer wrote:
> > Sounds like a case where directly editing the underlying device, to
> > modify inode-or-equivalent contents such that the slash is no longer
^
Nitpick:
On Fri, Jul 24, 2020 at 07:49:26AM -0400, The Wanderer wrote:
> Sounds like a case where directly editing the underlying device, to
> modify inode-or-equivalent contents such that the slash is no longer
> there, might even be *advisable*.
Yeah, some sort of direct hex-edit on the unmounted file sy
On 2020-07-24 at 07:45, Greg Wooledge wrote:
> On Thu, Jul 23, 2020 at 07:16:06PM -0400, The Wanderer wrote:
>
>> On 2020-07-23 at 06:26, Andrei POPESCU wrote:
>>> Seriously? Could you please show me how would I create a file on
>>> *nix containing '/' in the name?
>>
>> It's theoretically possi
On Thu, Jul 23, 2020 at 07:16:06PM -0400, The Wanderer wrote:
> On 2020-07-23 at 06:26, Andrei POPESCU wrote:
> > Seriously? Could you please show me how would I create a file on *nix
> > containing '/' in the name?
>
> It's theoretically possible, but AFAIK basically nothing would support
> it or
On Vi, 24 iul 20, 10:58:24, to...@tuxteam.de wrote:
>
> It's as if they were copying the disruptive antipatterns of proprietary
> software companies. But we don't need those antipatterns in the free
> software context, do we?
One person's bug is another's feature.
Kind regards,
Andrei
--
http:/
On Thu, Jul 23, 2020 at 06:48:10PM -0500, David Wright wrote:
> On Thu 23 Jul 2020 at 10:12:09 (+0200), to...@tuxteam.de wrote:
[...]
> > Hours of fun :-)
>
> Sure, I agree. But they're hours I don't really have. That's one
> reason why I don't run a DE: I just don't understand what's going on
>
On Thu 23 Jul 2020 at 10:12:09 (+0200), to...@tuxteam.de wrote:
> On Wed, Jul 22, 2020 at 02:22:32PM -0500, David Wright wrote:
> > On Wed 22 Jul 2020 at 14:23:48 (-0400), rhkramer wrote:
>
> [...]
>
> > > The basic solution involved stopping gparted [...]
>
> > AIUI gparted locks up the disks w
>>> Yes. Unfortunately Systemd decided to forbid '/' in unit names,
You can probably work around that by using '⁄', for example ;-)
Stefan
On 2020-07-23 at 06:26, Andrei POPESCU wrote:
> On Mi, 22 iul 20, 16:26:24, Jonathan Dowland wrote:
>
>> On Wed, Jul 22, 2020 at 07:38:54AM -0400, Greg Wooledge wrote:
>>
>>> Apparently this unit refers to the root file system. I have no
>>> idea why it's masked for you, but that's where I'd st
On Mi, 22 iul 20, 16:26:24, Jonathan Dowland wrote:
> On Wed, Jul 22, 2020 at 07:38:54AM -0400, Greg Wooledge wrote:
> > Apparently this unit refers to the root file system. I have no idea
> > why it's masked for you, but that's where I'd start looking.
>
> Yes. Unfortunately Systemd decided to f
On Wed, Jul 22, 2020 at 02:22:32PM -0500, David Wright wrote:
> On Wed 22 Jul 2020 at 14:23:48 (-0400), rhkramer wrote:
[...]
> > The basic solution involved stopping gparted [...]
> AIUI gparted locks up the disks when you run it [...]
Whatever "locking up the disks" means, in this context.
N
On Wednesday, July 22, 2020 02:54:27 PM Greg Wooledge wrote:
> On Wed, Jul 22, 2020 at 02:23:48PM -0400, rhkramer wrote:
> > The basic solution involved stopping gparted (I don't know why, but
> > google found a page that described the same problem I had and the page
> > said it occurred with gpart
On Wed 22 Jul 2020 at 14:23:48 (-0400), rhkramer wrote:
> On Wednesday, July 22, 2020 7:08:40 AM EDT Andrew Cater wrote:
> > It should "just work" - if you can "ssh localhost" - the server is running.
>
> Thanks for the reply. The problem is solved, and I'll mention the solution
> here with mayb
On Wed, Jul 22, 2020 at 02:23:48PM -0400, rhkramer wrote:
> The basic solution involved stopping gparted (I don't know why, but google
> found a page that described the same problem I had and the page said it
> occurred with gparted running and went away with gparted stopped.
Fascinating.
Greg Wooledge writes:
> unicorn:~$ systemctl status -.mount
> systemctl: invalid option -- '.'
> Hint: to specify units starting with a dash, use "--":
> systemctl [OPTIONS...] {COMMAND} -- -.mount ...
> unicorn:~$ systemctl status -- -.mount
> ● -.mount - /
>Loaded: loaded (/etc/fstab;
On Wednesday, July 22, 2020 7:08:40 AM EDT Andrew Cater wrote:
> It should "just work" - if you can "ssh localhost" - the server is running.
Thanks for the reply. The problem is solved, and I'll mention the solution
here with maybe more details in replies to Greg Wooledge and/or Jonathan
Dowla
On Wed, Jul 22, 2020 at 07:38:54AM -0400, Greg Wooledge wrote:
Apparently this unit refers to the root file system. I have no idea
why it's masked for you, but that's where I'd start looking.
Yes. Unfortunately Systemd decided to forbid '/' in unit names, and also
to map all mounts to units. '
On Tue, Jul 21, 2020 at 09:48:22PM -0400, rhkramer wrote:
> I get this error when trying to apt-get install openssh-server on my (up to
> date) Buster system:
>
> Error: GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit -.mount is
> masked.
>
> I tried (based on the reference below):
>
> r
It should "just work" - if you can "ssh localhost" - the server is running.
Hope this helps
Andy C
On Wed, Jul 22, 2020 at 2:06 AM rhkramer wrote:
> I get this error when trying to apt-get install openssh-server on my (up
> to
> date) Buster system:
>
> Error: GDBus.Error:org.freedesktop.syste
I get this error when trying to apt-get install openssh-server on my (up to
date) Buster system:
Error: GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit -.mount is
masked.
I tried (based on the reference below):
root@s32:/# systemctl unmask org.freedesktop.systemd1.UnitMasked
Unit org.fre
33 matches
Mail list logo