[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Informations about Systemd Stage3 Image and Systemd profile
From:       Geaaru <geaaru () gmail ! com>
Date:       2017-10-23 11:30:34
Message-ID: 1508758234.3113.7.camel () gmail ! com
[Download RAW message or body]

Hi,

thanks for reply.

Yeah, I know that through bootstrap command I can force a different
init binary as describe on gentoo wiki. It is equal also for LXD/LXC
containers.

But there are three different arguments to handle:

1) Currently if I want compile a pure systemd environment without
openrc it is needed change profile/base/packages (or mask package
openrc).
I think that this could be fixed now that gentoo-functions package fix
bug about /lib/gentoo/functions.sh.

2) I think that on a systemd pure environment could be correct that
/sbin/init is a link to systemd so it isn't needed force init argument
from kernel argument and/or on LXC/LXD through lxd.init.cmd option.
This can be done with step of point 1 and with use of sys-utils use
flag on systemd package. This is not mandatory, it is only a preference
 .
For example, Sabayon adopt this solution on install systemd package.
Could be correct enable sys-utils useflag on systemd package by default
on profile related with systemd ?

3) For users that want maintain netifrc with systemd as described by
robbat2 I think there is an issue on openrc or systemd ebuild.
When is installed openrc is not possible use sys-utils useflag on
systemd for conflicts on /sbin/init file, etc and FWIS it seems that
there aren't check about this.

FWIS I think that for point 1 we are ready.

G.

On Mon, 2017-10-23 at 13:45 +0300, Mart Raudsepp wrote:
> Ühel kenal päeval, P, 22.10.2017 kell 21:41, kirjutas Geaaru:
> > Hi,
> > i'm trying to review some docker image based of Stage3 systemd
> > image
> > for Sabayon Os. I see that currently also when it is used
> > default/linux/amd64/13.0/systemd profile there is a dependency to
> > openrc package.
> > 
> > This means that on daily gentoo-stage3-systemd image /sbin/init
> > binary
> > is not a link to systemd service.
> > 
> > I think that this is result of the dependency to sys-apps/openrc
> > inside
> > file  /usr/portage/profiles/base/packages.
> > 
> > So, my first question is why dependency to openrc is not inserted
> > to
> > a
> > specific profile and so when is configured a systemd profile is
> > possible prepare a pure systemd environment without openrc package
> > ?
> > 
> > Maybe, the main reason could be related to a problem on describe
> > this
> > on ebuild ? Because if openrc is not present is preferable sysv-
> > utils
> > use flag ?
> > 
> > For both arm and amd64 I remove automatically this dependency after
> > portage sync to rebuild a pure systemd environment and I haven't
> > issues.
> > 
> > I know that another workaround about this is configure kernel init
> > option to force use of systemd binary but this is not possible for
> > docker/lxc/lxd image without force lxc.cmd.init option.
> 
> USE=sysv-utils seems to just be to use systemd halt/poweroff etc
> binaries/symlinks, instead of sysvinit. It also happens to provide a
> /sbin/init symlink, as otherwise none would exist (as with that USE,
> sysvinit is blocked from being installed). All the documentation says
> to set init kernel command line, or use dracut, with which systemd
> already starts on its own or something. E.g,
> https://wiki.gentoo.org/wiki/Systemd#GRUB_2
> 
> If for docker you need something else, you can consider migrating the
> images to USE=sysvinit, which can be troublesome if you need to keep
> openrc for dependency resolution (I believe the work towards gentoo-
> functions for non-openrc gentoo stuff is ongoing and hopefully soon
> fully finished), or maybe you use dracut there too as initramfs, so
> it
> presumably wouldn't matter, if that doc is right?
> Or there's something to improve in packages for this use case, but
> this
> might be easier once gentoo-functions is fully baked..
> 
> 
> Mart
> 

[prev in list] [next in list] [prev in thread] [next in thread]