I just upgraded to udev-200. The boot sequence is now faster, as it does not seem to wait anymore for for an answer from the server (dhcp) to go to the next step. So while the system is slowly acquiring carrier, asking for a lease, etc. ntp-client is already running, and fails to start on dns errors (of course network is not up yet). Then X starts, but time is not set.

I tried to add /etc/init.d/ntp-client restart in /etc/local.d/baselayout.start so that it would try again, but this is too early as well. I could add a sleep 5 to make sure it waits enough time, but this is not very robust to network conditions, and not elegant either. Is there a better solution ?

I noticed this as well. Seems the init scripts are confused as to when "net" is up and running - the ntp-client init script clearly states "after net". Prolly best to wait until the devs have sorted out the persistent net naming stuff._________________A mouse is a device used to point at the xterm you want to type in.

I believe I've seen something similar happening to me once on one system. Editing rc_hotplug= line in /etc/rc.conf helped that system. Perhaps it's worth a shot to try disable
hotplugging for the interface(s), like with "!net.*"

Quote:

# rc_hotplug is a list of services that we allow to be hotplugged.
# By default we do not allow hotplugging.
# A hotplugged service is one started by a dynamic dev manager when a matching
# hardware device is found.
# This service is intrinsically included in the boot runlevel.
# To disable services, prefix with a !
# Example - rc_hotplug="net.wlan !net.*"
# This allows net.wlan and any service not matching net.* to be plugged.
# Example - rc_hotplug="*"
# This allows all services to be hotplugged
#rc_hotplug="*"

This is related to the Gentoo specific /lib/udev/rules.d/90-network.rules and /lib/udev/net.sh. However I'm not sure yet.

I'm a bit loathe to use a workaround and just put the 80-net-name-slot.rules dummy file back in place. Reason is that using the hack only treats the symptom for that one package, and while there may not seem to be other problems right now others may crop up.

It seems to be a serious issue when the startup scripts do not know whether "net" is available or not. This root problem really needs to be resolved here._________________A mouse is a device used to point at the xterm you want to type in.

I'm a bit loathe to use a workaround and just put the 80-net-name-slot.rules dummy file back in place. Reason is that using the hack only treats the symptom for that one package, and while there may not seem to be other problems right now others may crop up.

It seems to be a serious issue when the startup scripts do not know whether "net" is available or not. This root problem really needs to be resolved here.

I agree we need to find the root cause.

I'm suprised to hear adding empty 80-net-name-slot.rules is somehow fixing the problem for you? I can't see anything eth* specific in OpenRC's code that would make difference here
I'll look at dhcpcd next

I see that "after" is also used in the net.* scripts, and maybe others.

Is "after" broken? Would it not be better to just fix "after", or if "after net" is the only broken implementation then maybe it should be fixed or replaced._________________A mouse is a device used to point at the xterm you want to type in.

It's not an empty file it's the dummy file that the udev upgrade installed. Contents are:

Code:

#
# Udev 197 and above has implemented predictable network interface names
# for hardware network interfaces. This new scheme does not affect
# stacked network interfaces such as bonds, bridges or vlans.
#
# This file is here to prevent your interfaces from being renamed automatically,
# because the new names will be drastically different from the eth*, wlan*, etc
# names you are used to working with.
#
# To activate this function, move this file to a name that doesn't end in.rules,
# or remove it then reboot your system.
#
# If you want to deactivate this function, install a udev rules file as
# /etc/udev/rules.d/80-net-name-slot.rules then reboot your system.
#
# This functionality has not been tested with gentoo. In fact, we are aware that
# things will break if you activate it.
#
# If you are not comfortable testing this, leave this file as is. We will
# publish a news item when you can migrate.
#
# If you do want to activate and help us come up with a migration plan, feel
# free to do so and report bugs.
# Your bugs should block the following tracker:
# https://bugs.gentoo.org/show_bug.cgi?id=450938
#
# Before you activate this function, it is important that you fully understand
# the following documentation:
#
# http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
#
# Also, be aware that you can get the attributes of your network interface that
# would be used to name the interface in the new scheme by doing the following
# with this version of udev running:
#
# udevadm test-builtin net_id /sys/class/net/ifname 2> /dev/null
#
# for example, on my system, I can find that eth0's new name would be enp1s5.
#

Notice that it claims (and works that way here) that being in place prevents the new automatic naming system._________________A mouse is a device used to point at the xterm you want to type in.

but I removed it also, as I'm not currently using kvm and I'm not even sure it's still needed if I was. There's sure to be some cruft in my system as the install was probably 6 years ago or more._________________A mouse is a device used to point at the xterm you want to type in.

I see that "after" is also used in the net.* scripts, and maybe others.

Is "after" broken? Would it not be better to just fix "after", or if "after net" is the only broken implementation then maybe it should be fixed or replaced.

Having subj problem on fresh arm stage3.
Tried adding "use net" statement to /etc/init.d/ntp-client, but didn't help (my active net connection is wireless, and its initscript has that specific of returning before connection is actually functioning.
Currently made a local.d script which loops in background restarting ntp-client each minute. (Correct time is critical for openvpn connection to verify remote party certificate.)