after baselayout 1.12.x update mysql daemon tries to start before net.lo so it
I added in /etc/init.d/net.lo the line:
And now it starts fine....
Steps to Reproduce:
mysql daemon failed to start at boot time.
mysql should start after the net.lo initialization
move mysql from the boot runlevel to the default runlevel
mysql IS at the default level
net.lo IS at boot level.
but after the baselayout update net.lo was loading towards the end of the boot
process even if it was at boot level
post the output of `rc-config list`
This happend to me too with some other packages from time to time.
Kernel version or netdrivers as modules seemed to have a effect on it, not
sure if it does in your case.
Available init scripts
hostname boot default
local default nonetwork
I have encountered this issue too, currently using
sys-apps/baselayout-1.12.0_pre8-r1 with net.lo in the boot runlevel and lo was
started just before local at the very end. I have mysql in the default run
level also. This is on an amd64 machine if that makes any difference at all.
Does mysql start before you enter runlevel 3?
Does net.lo end before you enter runlevel 3?
mysql starts in runlevel 3 as expected. Like I said before it is net.lo which
doesn't start until right at the end of runlevel 3 just before local starts and
you get the login prompt.
What's the value of RC_STRICT_NET_CHECKING in /etc/conf.d/rc?
I have RC_NET_STRICT_CHECKING="no" which I believe was the default as set. This
still means that lo should be brought up first doesn't it?
I have also RC_STRICT_NET_CHECKING set to no.
But this was the default.
maybe a change to yes, will help?
Try setting RC_PARALLEL_STARTUP="yes".
Although it seems 100% unrelated to the issue at hand, it has cured this problem
for one user.
the last time I found about
RC_PARALLEL_STARTUP and set it to "yes"
A lot o things (daemon) didn't like my decision.
It meshed up a lot of things.
We recently fixes a lot of parallel startup isses, why not try it again and see
if it helps this issue? If parallel causes issues (but not related to this bug)
then please open a new bug.
Yes, but it will be a 'workaround' not a fix.
If this can work right in the one-by-one service mode. it is unacceptable.
It maybe run fine in parallel but just from luck.
I am having the same problem of net.lo starting right before local as well
except famd is failing because of it. Tried the suggestion of
RC_PARALLEL_STARTUP="yes" and problem is cured for now, but as mentioned this is
just a work around and not a fix as the default behaviour seems to be broken.
Also this is on a x86 system so it seems to go beyond a AMD64 problem.
*** Bug 106119 has been marked as a duplicate of this bug. ***
I've tried everything here and in forums
the only workaround on my box
is setting RC_STRICT_NET_CHECKING to "yes"
and with this set to yes,
my "lo" comes up in console in run lvl 3
right before mysql
o - and eth0 is still booting in background
eth0 don't even show up in console
I'm having the same problem.
nfs & nfsmount starts before net.lo & net.eth0 and fail.
I even tried to bypass it by moving net.* to boot level and it helps only 50% of
the time, part of the boots net services still starts only at the end.
It looks like a dependency problem.
I'm using baselayout 1.12.0_pre8-r2, without parallete startup feature.
Actually, this also affects samba if it is configured to work with cups, as
samba cannot reach the cups server.
net.lo is started AFTER init.d/local.
Another weired thing is that also the dhcpcd started very late (after local and
and even net.lo!), but a IP address is assigned with DHCP very early ?!
All righty then - I think I've found the problem.
Either a baselayout ebuild or a stage3 tarball has placed invalid default links
baselayout-1.12.0_pre10 ships with an improved rc-status that will display the
word "broken" for broken runlevel links regardless of if it's
started/stopped/whatever. If you see a broken link here's how you fix it :
rc-update del $service
rc-update add $service $runlevel
(where $service is the broken service and $runlevel is the runlevel it was
If that fails to fix it, please download this script
Into /etc/init.d, start it and then attach the results here.
Re-open this bug too ....