Now that the tmpfiles.d code is more tested, actually call it from
init.d. It assumes that /run is already available when it runs.
Please note it runs TWICE.
- During sysinit, ideally just after /dev/shm is created, but before
udev has started. After udev is also acceptable, but not ideal.
- During boot, ideally just after localmount has completed.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Using the new dev-mount virtual, with udev-mount included until new udev
version is rolled out, we run devfs earlier now, before udev/mdev.
It only needs (u)dev-mount before it, so that /dev is mounted.
This opens the way for tmpfiles.d, which needs to be sandwiched in the
middle.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
net.* and module loading require sysfs now, and if udev is not in use,
it is not always loaded early enough, esp for net.lo. Force it to come
up during sysinit instead.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Urandom should not run in lxc containers since it is provided by the
host.
Reported-by: <walter@pratyeka.org>
X-Gentoo-Bug: 436270
X-Gentoo-Bug-URL: http://bugs.gentoo.org/436270
By design, restart is hard coded to run stop followed by start along
with all of the pre/post functions associated with them. Restart doesn't
need its own pre/post functions since it is possible to make any
function in an init script behave differently for a restart command by
testing against the RC_CMD environment variable.
The Gentoo developer manual covers how to handle restarts in init
scripts, but this was not officially covered in OpenRc's Documentation.
This commit adds an example to the runscript man page that shows how
this works.
On prefix systems, RC_SVCDIR was being defined based on the host
operating system. This is not correct because there will not be a /run
directory in a prefix.
This commit moves RC_SVCDIR on prefix systems to the same location as on
non-Linux systems.
Since nfs and nfs4 file systems require extra daemons to be running on
the client to function properly, netmount should not try to handle these
file systems.
Reported-by: <devurandom@gmx.net>
X-Gentoo-Bug: 427996
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=427996
This is needed in case of a read-only root filesystem such as a diskless
client.
Reported-by: <walter@pratyeka.org>
X-Gentoo-Bug: 430382
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=430382
We were not testing for carrier correctly when testing for ipv6
tentative addresses.
Reported-by: <ast@domdv.de>
X-Gentoo-Bug: 433012
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=433012
Make sure UPREFIX in our make files gets set correctly when
MKPREFIX=yes. In this situation, UPREFIX should be ${PREFIX}/usr.
Reported-by: <heroxdb@gentoo.org>
X-Gentoo-Bug: 415899
X-Gentoo-Bug-URL: http://bugs.gentoo.org/show_bug.cgi?id=415899
If CONFIG_SWAP is turned off in the kernel, this file may not exist. In
that case, we should not try to read from it.
reported-by: <walter@pratyeka.org>
X-Gentoo-Bug: 430378
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=430378
The OpenRC upstream default network stack was changed, but there was no
reason to change it. Now since we have the MKNET build switch, it is
easy for the gentoo ebuild to install oldnet by default.
The upstream default is newnet.
The MKNET variable can be used to select the network stack you want to
build and install with OpenRC.
The current default is the gentoo "oldnet" stack. If you want to install
the OpenRC newnet stack, use MKNET=newnet on the make command line.
Correct the reference in conf.d/dmesg from dmesg(8) to dmesg(1).
reported-by: <toralf.foerster@gmx.de>
X-Gentoo-Bug: 425370
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=425370
This reverts commit 5994e55937.
There are situations where these scripts can be useful, so I am bringing
them back. Also, I want to start discussions about simplifying the
OpenRC network stack.
Mount can't be used in vservers, but /run is still needed. So we create
the directory and clear it out instead of mounting a tmpfs in that
situation.
reported-by: <patrick@gentoo.org>
X-Gentoo-Bug: 423739
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=423739