[gentoo-user] openrc->systemd command comparison

[Daniel Frey]

Hey all,

I've now converted two systems to systemd and so far haven't had too
much issues with systemd itself, other than me constantly forgetting
commands.

Is there a nice table or chart somewhere that lists openrc commands with
equivalent systemd commands? That would really help me from bashing my
head and then wandering through man pages for a while trying to figure
out what I want to do. I'll eventually remember but it would be nice to
have something to help me along. My memory sure isn't what it used to be.

Dan

[Canek Peláez Valdés]

I remember seeing a table like that in the wiki a long time ago, but I can't find it now. Anyway, the translatable commands are obvious:

/etc/init.d/service start → systemctl start service

/etc/init.d/service stop → systemctl stop service

and the rest are usually are not translatable. There is nothing like "systemctl mask service" in OpenRC, AFAIK, and there is no equivalent for "/etc/init.d/service zap" in systemd (the whole idea of systemd is that an ugly hack like zap will never be necessary).

Not sure if this will help you.

Regards.
--
Canek Peláez Valdés
Profesor de asignatura, Facultad de Ciencias
Universidad Nacional Autónoma de México

[Bob Wya]

I've not seen any that are OpenRC specific... But this one is pretty decent for SysVInit vs. systemd...
http://linoxide.com/linux-command/systemd-vs-sysvinit-cheatsheet/

--

All the best,

Robert

[Daniel Frey]

On 03/17/2015 06:56 AM, Bob Wya wrote:
> I've not seen any that are OpenRC specific... But this one is pretty
> decent for SysVInit vs. systemd...
> http://linoxide.com/linux-command/systemd-vs-sysvinit-cheatsheet/

Yeah I found one similar to that, but located elsewhere. Maybe if I have
some time today I'll do some research and create an openrc-specific one
on the wiki. This way it'll help others (besides me.)

Dan

[Rich Freeman]

The cheat sheets are useful for reference, but I'd strongly encourage
anybody using systemd to get a decent understanding of the
fundamentals.

I gave a presentation along these lines which can be found at:
https://docs.google.com/presentation/d/1YpW7h-sUSXtmroppd-S46dxtPYo3rcF32rh7vF99aVs/edit?usp=sharing

(granted, that wasn't really designed to stand completely on its own)

Some key concepts you should understand:
1. Targets as "virtuals" - if you think about them the way you'd
think about a virtual package you'll probably grok it.
2. Before/After/Wants/Requires and what they actually mean
3. Drop-ins
4. Creating dependencies using /etc/systemd/system/foo.xxx.d
symlinks, and how these tie into enabling services

Just as with openrc there are a lot of building blocks which are used
to create a working configuration, there are many ways to do the same
thing, and some of those ways are usually better than others. The
overall design is somewhat different, so you need to look at things
differently to make the most of it.

--
Rich

[Marc Joliet]

Am Tue, 17 Mar 2015 13:20:45 -0400
schrieb Rich Freeman <ri...@gentoo.org>:

> On Tue, Mar 17, 2015 at 10:41 AM, Daniel Frey <djq...@gmail.com> wrote:
> > On 03/17/2015 06:56 AM, Bob Wya wrote:
> >> I've not seen any that are OpenRC specific... But this one is pretty
> >> decent for SysVInit vs. systemd...
> >> http://linoxide.com/linux-command/systemd-vs-sysvinit-cheatsheet/
> >
> > Yeah I found one similar to that, but located elsewhere. Maybe if I have
> > some time today I'll do some research and create an openrc-specific one
> > on the wiki. This way it'll help others (besides me.)
>
> The cheat sheets are useful for reference, but I'd strongly encourage
> anybody using systemd to get a decent understanding of the
> fundamentals.

[...]

Having recently migrated to systemd myself I vehemently agree with this. I
don't think you'll understand systemd as well as you could by trying to force
it into your mental model of OpenRC (despite some superficial similarities).

--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup

[Daniel Frey]

On 03/17/2015 10:20 AM, Rich Freeman wrote:
> The cheat sheets are useful for reference, but I'd strongly encourage
> anybody using systemd to get a decent understanding of the
> fundamentals.

Oh, certainly - but going in completely blind and being stuck for 15
minutes trying to do a simple task sucks. I'm not saying that a
cheatsheet is enough to avoid reading manpages, but at least it's a
start where users can find information to do basic stuff with systemd.
I'm also not talking about a cheatsheet about writing units/services/etc.

When I did the switch there wasn't anything in the gentoo-related wikis
for even things like starting kdm. This is what I'm talking about - how
to list services, start and stop things - basic stuff.

Anyway, I've finally gotten around to putting together a short
cheatsheet @ https://wiki.gentoo.org/wiki/OpenRC_to_Systemd_Cheatsheet .

Dan

[Canek Peláez Valdés]

Thanks for doing this, I think it will help all the people switching to systemd from OpenRC in Gentoo.

However, I think the zap command is a little misleading, even with the note stating that is no "exactly" the same.

AFAIR, zap doesn't do anything to the processes of a service; it just "zaps" back the internal state of OpenRC as if the service is stopped. It's needed because OpenRC cannot really follow the status of its services, so sometimes they die and OpenRC is none the wiser, and you need to zap the service because trying to stopping them would fail.

With systemd you don't need this, since it can track the real state of its services thanks to cgroups. And kill *really* kills all the processes associated to a service, something that OpenRC, by design, cannot do.

I believe the difference is substantial enough that it should not be stated that they are equivalent.

But except for that minor nitpick, it looks great.

Thanks again.

Regards.

[Daniel Frey]

On 03/31/2015 07:05 PM, Canek Peláez Valdés wrote:
> Thanks for doing this, I think it will help all the people switching to
> systemd from OpenRC in Gentoo.
>
> However, I think the zap command is a little misleading, even with the
> note stating that is no "exactly" the same.

Duly noted, I've removed it and the note. I was thinking "this is really
stretching it here" when I put that in there. I knew it manually reset
its status in OpenRC.

Dan

[Marc Joliet]

Am Tue, 31 Mar 2015 20:05:50 -0600
schrieb Canek Peláez Valdés <can...@gmail.com>:

[...]

> With systemd you don't need this, since it can track the real state of its
> services thanks to cgroups. And kill *really* kills all the processes
> associated to a service, something that OpenRC, by design, cannot do.

[...]

I wonder if that's accurate. I know that OpenRC also uses cgroups for grouping
services, but how much does it actually exploit them?

[Canek Peláez Valdés]

On Wed, Apr 1, 2015 at 1:55 AM, Marc Joliet <mar...@gmx.de> wrote:
>
> Am Tue, 31 Mar 2015 20:05:50 -0600
> schrieb Canek Peláez Valdés <can...@gmail.com>:
>
> [...]
> > With systemd you don't need this, since it can track the real state of its
> > services thanks to cgroups. And kill *really* kills all the processes
> > associated to a service, something that OpenRC, by design, cannot do.
> [...]
>
> I wonder if that's accurate.  I know that OpenRC also uses cgroups for grouping
> services, but how much does it actually exploit them?

According to [1]:

"""

# If you have cgroups turned on in your kernel, this switch controls

# whether or not a group for each controller is mounted under

# /sys/fs/cgroup.

[...]

# Set this to YES if yu want all of the processes in a service's cgroup

# killed when the service is stopped or restarted.

# This should not be set globally because it kills all of the service's

# child processes, and most of the time this is undesirable. Please set

# it in /etc/conf.d/<service>.

# To perform this cleanup manually for a stopped service, you can

# execute cgroup_cleanup with /etc/init.d/<service> cgroup_cleanup or

# rc-service <service> cgroup_cleanup.

# rc_cgroup_cleanup="NO"

"""

So it's available if you have cgroups turned on, and then you need to set it up globally (which is not recommended), or by service. That wasn't available when I stopped using OpenRC; but then again, that was almost five years ago.

Is nice to see OpenRC catching up to systemd.

Regards.

[1] https://github.com/OpenRC/openrc/blob/master/etc/rc.conf.Linux

[Peter Humphrey]

On Wednesday 01 April 2015 02:04:05 Canek Peláez Valdés wrote:

> """
> # If you have cgroups turned on in your kernel, this switch controls
> # whether or not a group for each controller is mounted under
> # /sys/fs/cgroup.
> [...]
> # Set this to YES if yu want all of the processes in a service's cgroup
> # killed when the service is stopped or restarted.
> # This should not be set globally because it kills all of the service's
> # child processes, and most of the time this is undesirable. Please set
> # it in /etc/conf.d/<service>.
> # To perform this cleanup manually for a stopped service, you can
> # execute cgroup_cleanup with /etc/init.d/<service> cgroup_cleanup or
> # rc-service <service> cgroup_cleanup.
> # rc_cgroup_cleanup="NO"
> """

# grep -i cgroup /usr/src/linux/.config
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CGROUP_CPUACCT=y
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set
# CONFIG_NETFILTER_XT_MATCH_CGROUP is not set
# CONFIG_CGROUP_NET_PRIO is not set
# CONFIG_CGROUP_NET_CLASSID is not set

I wonder which of those, taken from my openrc system, are needed for the
feature you quoted. I don't remember now why any of them are set at all,
unless it was from a recommendation in a help text.

--
Rgds
Peter.

[Volker Armin Hemmann]

so somebody showed you that you were spouting crap and all you are saying it 'that is nice'.

Well done.


Btw, if you need a 'cheat sheet' for INIT the whole thing is broken beyond repair.

[Marc Joliet]

Am Wed, 01 Apr 2015 09:43:21 +0100
schrieb Peter Humphrey <pe...@prh.myzen.co.uk>:

Apparently it's (partially) due to CONFIG_GENTOO_LINUX_PORTAGE (not
CONFIG_GENTOO_LINUX_INIT_SCRIPT as I originally thought):

Selects: CGROUPS [=y] && NAMESPACES [=y] && IPC_NS [=y] && NET_NS [=y]

[Neil Bothwick]

On Wed, 01 Apr 2015 10:57:33 +0200, Volker Armin Hemmann wrote:

> Btw, if you need a 'cheat sheet' for INIT the whole thing is broken
> beyond repair.

You don't *need* it, it's just a convenience when switching from one
syntax to the other. The order of the switch doesn't matter, the notes
would be just as useful for someone switching from systemd to openrc.


--
Neil Bothwick

PCMCIA: People Can't Memorize Computer Industry Acronyms

[Canek Peláez Valdés]

On Wed, Apr 1, 2015 at 3:18 AM, Neil Bothwick <ne...@digimed.co.uk> wrote:
>
> On Wed, 01 Apr 2015 10:57:33 +0200, Volker Armin Hemmann wrote:
>
> > Btw, if you need a 'cheat sheet' for INIT the whole thing is broken
> > beyond repair.
>
> You don't *need* it, it's just a convenience when switching from one
> syntax to the other. The order of the switch doesn't matter, the notes
> would be just as useful for someone switching from systemd to openrc.

Don't feed the troll Neil. Almost nobody does.

Regards.

[Peter Humphrey]

Hmm. I have no instances of PORTAGE in my 3.18.9 .config; was this
introduced in 3.19?

--
Rgds
Peter.

[Neil Bothwick]

On Tue, 31 Mar 2015 18:53:39 -0700, Daniel Frey wrote:

> Anyway, I've finally gotten around to putting together a short
> cheatsheet @ https://wiki.gentoo.org/wiki/OpenRC_to_Systemd_Cheatsheet .

Nice! Apart from the zap thing that Canek has already covered, I think it
could be useful. Could you add a link to it to the main systemd page.

It doesn't help me with the problem I still have running a mixture of
openrc and systemd setups, the different order of the arguments. I still
keep trying to run

systemctl someservice start :(


--
Neil Bothwick

Obscenity is the crutch of inarticulate motherfuckers.

[Volker Armin Hemmann]

says the troll.

[Rich Freeman]

On Wed, Apr 1, 2015 at 4:04 AM, Canek Peláez Valdés <can...@gmail.com> wrote:

> # If you have cgroups turned on in your kernel, this switch controls
> # whether or not a group for each controller is mounted under
> # /sys/fs/cgroup.
> [...]
> # Set this to YES if yu want all of the processes in a service's cgroup
> # killed when the service is stopped or restarted.
> # This should not be set globally because it kills all of the service's
> # child processes, and most of the time this is undesirable. Please set
> # it in /etc/conf.d/<service>.
> # To perform this cleanup manually for a stopped service, you can
> # execute cgroup_cleanup with /etc/init.d/<service> cgroup_cleanup or
> # rc-service <service> cgroup_cleanup.
> # rc_cgroup_cleanup="NO"

As pointed out in the comments, using this feature is apparently
unrecommended - probably because most init.d scripts were never
written with it in mind. A few notes that might be helpful for
anybody trying this out, based on my systemd experiences (where this
is standard functionality, but units are written with this in mind).
Please note that I'm not 100% sure about how this is implemented in
openrc, so some potential issues below may be mitigated.

Also note, I'm not trying to make any value statements here (foo is
better than bar) - the purpose of my email is to help educate
sysadmins about some of the possible unintended consequences of using
features like these.

1. As far as I'm aware, openrc still doesn't have any concept of
scripts stopping/failing unless you explicitly tell it to stop them.
With systemd if the main process dies, the unit stops (and possibly
fails), and the child processes are killed automatically if this is
not overridden. So, don't expect the behavior to be exactly the same.

2. Some scripts like apache might attempt to do graceful shutdowns.
I have no idea how the kill behavior of openrc interacts with this.
With systemd care had to be taken in the script to ensure that kills
were only sent after a suitable timeout to allow graceful shutdown a
chance to complete - otherwise an apache2 graceful completes instantly
and SIGTERMs get sent almost immediately afterwards. The openrc
init.d script already does its own attempts at polling/killing for a
restart, so you might get issues with how these features interact.

3. Sometimes leaving orphan processes around might be considered
intended behavior. Any screen launched from an ssh session is going
to be a child of sshd and in its cgroup. If you completely kill the
cgroup, then you'll kill any user sessions inside unless they were
given some kind of special handling. I'm actually not 100% sure how
this is done in systemd (logind may put these in a different cgroup
already), but you'll certainly want to think about things like this.

4. Not really an issue for openrc, but if you're running systemd
timer units keep in mind that anything you fork from the main process
dies when the main process dies, so be careful about a cron shell
scripts that runs stuff in the background without waiting at the end.

I'd think that this is a feature openrc would want to make the default
at some point. However, for that transition to be made maintainers
need to take another look at their scripts to make sure they still
work correctly. That was never an issue for systemd since the
behavior was there from the start.

One thing I will say is that doing this sort of thing in the service
manager makes a LOT more sense than doing it in individual scripts.
Look at the apache2 init.d script sometime and compare it to the
systemd unit. Most of the complexity in the init.d script is just
implementing stuff that systemd does natively, like graceful restarts
with cleanup of orphans and all that. I'm not criticizing the apache2
script, but rather pointing out that one of the advantages of systemd
is that all of its units benefit from that kind of care without the
need to implement it in each script. And, of course, killing child
processes can be configured per-service or even globally (though doing
it globally probably isn't advisable, since many units probably depend
on systemd to just send SIGTERMs followed by SIGKILLs as its default
action and stuff wouldn't stop at all without this).

--
Rich

[Daniel Frey]

On 04/01/2015 02:21 AM, Neil Bothwick wrote:
> Nice! Apart from the zap thing that Canek has already covered, I think it
> could be useful. Could you add a link to it to the main systemd page.

I've added it to the "See Also" section at the end of the Systemd page.
I didn't know where else to put it.

Dan

[Daniel Frey]

On 04/01/2015 02:21 AM, Neil Bothwick wrote:

> On Tue, 31 Mar 2015 18:53:39 -0700, Daniel Frey wrote:
>
>> Anyway, I've finally gotten around to putting together a short
>> cheatsheet @ https://wiki.gentoo.org/wiki/OpenRC_to_Systemd_Cheatsheet .
>
> Nice! Apart from the zap thing that Canek has already covered, I think it
> could be useful. Could you add a link to it to the main systemd page.
>
> It doesn't help me with the problem I still have running a mixture of
> openrc and systemd setups, the different order of the arguments. I still
> keep trying to run
>
> systemctl someservice start :(
>
>

I feel your pain. I maintain Windows boxes at works, every time I drop
to a shell it goes like:

> ls
Command not found

Me: ??

> ifconfig
Command not found

Me: ????? Oh, right.

:-)

For systemd, I kept tripping up on the difference between list-units and
list-unit-files. I'd use list-units and go "WHY isn't systemd &#%($#
telling me what's installed???"

Dan

[Neil Bothwick]

On Wed, 01 Apr 2015 08:19:18 -0700, Daniel Frey wrote:

> > Nice! Apart from the zap thing that Canek has already covered, I
> > think it could be useful. Could you add a link to it to the main
> > systemd page.
>
> I've added it to the "See Also" section at the end of the Systemd page.
> I didn't know where else to put it.

That's where I was thinking of. It's not there right now, are edits
moderated?


--
Neil Bothwick

Pound for pound, the amoeba is the most vicious animal on the earth.

[Marc Joliet]

Am Wed, 01 Apr 2015 10:29:15 +0100

schrieb Peter Humphrey <pe...@prh.myzen.co.uk>:

> On Wednesday 01 April 2015 10:53:15 Marc Joliet wrote:
> > Am Wed, 01 Apr 2015 09:43:21 +0100
> >

[...]

> > Apparently it's (partially) due to CONFIG_GENTOO_LINUX_PORTAGE (not
> > CONFIG_GENTOO_LINUX_INIT_SCRIPT as I originally thought):
> >
> > Selects: CGROUPS [=y] && NAMESPACES [=y] && IPC_NS [=y] && NET_NS [=y]
>
> Hmm. I have no instances of PORTAGE in my 3.18.9 .config; was this
> introduced in 3.19?

I had to check my kernel config archive, but I found the answer to be "yes".

[Canek Peláez Valdés]

I think (I could be wrong) that most of the detection magic in systemd is thanks to the use of cgroups. If that's the case, then OpenRC should be able to do the same (if someone cared to code it).

> 2.  Some scripts like apache might attempt to do graceful shutdowns.
> I have no idea how the kill behavior of openrc interacts with this.
> With systemd care had to be taken in the script to ensure that kills
> were only sent after a suitable timeout to allow graceful shutdown a
> chance to complete - otherwise an apache2 graceful completes instantly
> and SIGTERMs get sent almost immediately afterwards.  The openrc
> init.d script already does its own attempts at polling/killing for a
> restart, so you might get issues with how these features interact.
>
> 3.  Sometimes leaving orphan processes around might be considered
> intended behavior.  Any screen launched from an ssh session is going
> to be a child of sshd and in its cgroup. If you completely kill the
> cgroup, then you'll kill any user sessions inside unless they were
> given some kind of special handling. I'm actually not 100% sure how
> this is done in systemd (logind may put these in a different cgroup
> already), but you'll certainly want to think about things like this.

As you correctly guessed, logind takes care of that:

$ systemd-cgls 

├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17

[...]

└─user.slice

  └─user-1024.slice

    ├─session-1395.scope

    │ ├─13984 sshd: canek [priv]     

    │ ├─13989 sshd: canek@pts/0      

    │ ├─13994 -bash

    │ ├─14012 systemd-cgls

    │ └─14013 /usr/bin/less

    └─us...@1024.service

      ├─13986 /usr/lib/systemd/systemd --user

      └─13987 (sd-pam)                                                          

So OpenRC should implement something similar to logind (which would be actually awesome, since GNOME, KDE and other sutff is starting to depend on it) to be able to work like systemd.

> 4.  Not really an issue for openrc, but if you're running systemd
> timer units keep in mind that anything you fork from the main process
> dies when the main process dies, so be careful about a cron shell
> scripts that runs stuff in the background without waiting at the end.
>
> I'd think that this is a feature openrc would want to make the default
> at some point.  However, for that transition to be made maintainers
> need to take another look at their scripts to make sure they still
> work correctly.  That was never an issue for systemd since the
> behavior was there from the start.
>
> One thing I will say is that doing this sort of thing in the service
> manager makes a LOT more sense than doing it in individual scripts.

No argument from me here ;)

> Look at the apache2 init.d script sometime and compare it to the
> systemd unit.  Most of the complexity in the init.d script is just
> implementing stuff that systemd does natively, like graceful restarts
> with cleanup of orphans and all that.  I'm not criticizing the apache2
> script, but rather pointing out that one of the advantages of systemd
> is that all of its units benefit from that kind of care without the
> need to implement it in each script.  And, of course, killing child
> processes can be configured per-service or even globally (though doing
> it globally probably isn't advisable, since many units probably depend
> on systemd to just send SIGTERMs followed by SIGKILLs as its default
> action and stuff wouldn't stop at all without this).

Regards.

[Daniel Frey]

On 04/01/2015 09:26 AM, Neil Bothwick wrote:
> On Wed, 01 Apr 2015 08:19:18 -0700, Daniel Frey wrote:
>> I've added it to the "See Also" section at the end of the Systemd page.
>> I didn't know where else to put it.
>
> That's where I was thinking of. It's not there right now, are edits
> moderated?
>
>

I just hit Ctrl+F5 and it's visible for me. (I'm logged in to the wiki
though.)

https://wiki.gentoo.org/wiki/Systemd#See_Also

I just logged out of the wiki and it's still showing for me.

Odd. I put it under "Sakaki's EFI Install Guide".

Dan

[Peter Humphrey]

On Wednesday 01 April 2015 19:12:14 Marc Joliet wrote:
> Am Wed, 01 Apr 2015 10:29:15 +0100
>
> schrieb Peter Humphrey <pe...@prh.myzen.co.uk>:
> > On Wednesday 01 April 2015 10:53:15 Marc Joliet wrote:
> > > Am Wed, 01 Apr 2015 09:43:21 +0100
>
> [...]
>
> > > Apparently it's (partially) due to CONFIG_GENTOO_LINUX_PORTAGE (not
> > >
> > > CONFIG_GENTOO_LINUX_INIT_SCRIPT as I originally thought):
> > > Selects: CGROUPS [=y] && NAMESPACES [=y] && IPC_NS [=y] && NET_NS
> > > [=y]
> >
> > Hmm. I have no instances of PORTAGE in my 3.18.9 .config; was this
> > introduced in 3.19?
>
> I had to check my kernel config archive, but I found the answer to be
> "yes".

I was hoping that equery c gentoo-sources would tell you. Never mind -
thanks anyway.

--
Rgds
Peter.

[Marc Joliet]

Am Thu, 02 Apr 2015 10:48:13 +0100

schrieb Peter Humphrey <pe...@prh.myzen.co.uk>:

> On Wednesday 01 April 2015 19:12:14 Marc Joliet wrote:
> > Am Wed, 01 Apr 2015 10:29:15 +0100
> >
> > schrieb Peter Humphrey <pe...@prh.myzen.co.uk>:
> > > On Wednesday 01 April 2015 10:53:15 Marc Joliet wrote:
> > > > Am Wed, 01 Apr 2015 09:43:21 +0100
> >
> > [...]
> >
> > > > Apparently it's (partially) due to CONFIG_GENTOO_LINUX_PORTAGE (not
> > > >
> > > > CONFIG_GENTOO_LINUX_INIT_SCRIPT as I originally thought):
> > > > Selects: CGROUPS [=y] && NAMESPACES [=y] && IPC_NS [=y] && NET_NS
> > > > [=y]
> > >
> > > Hmm. I have no instances of PORTAGE in my 3.18.9 .config; was this
> > > introduced in 3.19?
> >
> > I had to check my kernel config archive, but I found the answer to be
> > "yes".
>
> I was hoping that equery c gentoo-sources would tell you. Never mind -
> thanks anyway.

Ha! I think I made it sound like more work than it really was:

% grep PORTAGE /etc/kernels/*
/etc/kernels/kernel-config-3.19.2-gentoo:CONFIG_GENTOO_LINUX_PORTAGE=y
/etc/kernels/kernel-config-3.19.3-gentoo:CONFIG_GENTOO_LINUX_PORTAGE=y

And you're welcome :) .

[Neil Bothwick]

On Wed, 01 Apr 2015 10:13:38 -0700, Daniel Frey wrote:

> > That's where I was thinking of. It's not there right now, are edits
> > moderated?

> I just hit Ctrl+F5 and it's visible for me. (I'm logged in to the wiki
> though.)
>
> https://wiki.gentoo.org/wiki/Systemd#See_Also
>
> I just logged out of the wiki and it's still showing for me.
>
> Odd. I put it under "Sakaki's EFI Install Guide".

It still wasn't there this morning but it is now and all is well.

Yesterdays massive site upgrade must have slowed it down :)


--
Neil Bothwick

Talk is cheap because supply exceeds demand.

[Peter Humphrey]

On Thursday 02 April 2015 18:19:47 Marc Joliet wrote:

> % grep PORTAGE /etc/kernels/*
> /etc/kernels/kernel-config-3.19.2-gentoo:CONFIG_GENTOO_LINUX_PORTAGE=y
> /etc/kernels/kernel-config-3.19.3-gentoo:CONFIG_GENTOO_LINUX_PORTAGE=y

# ls -l /etc/kernels
/bin/ls: cannot access /etc/kernels: No such file or directory

> And you're welcome :) .

Thanks again.

--
Rgds
Peter.