Summary: | sys-apps/baselayout-1.12.x - net.lo starting too late | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | cilly <cilly> |
Component: | [OLD] baselayout | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | VERIFIED INVALID | ||
Severity: | major | CC: | lars.langhans |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
cilly
2006-09-29 13:37:09 UTC
additional info: net.lo is in boot level. named is in default level. rc-update show * Invalid runlevel entry: /etc/runlevels/boot/.keep * Invalid runlevel entry: /etc/runlevels/default/.keep * Invalid runlevel entry: /etc/runlevels/nonetwork/.keep * Invalid runlevel entry: /etc/runlevels/single/.keep apache2 | default atd | default bootmisc | boot checkfs | boot checkroot | boot clock | boot consolefont | boot courier-authlib | default courier-imapd | default courier-imapd-ssl | default dhcpd | default fail2ban | default hdparm | default hostname | boot ifplugd | default iptables | default keymaps | boot lm_sensors | default local | default nonetwork localmount | boot modules | boot mrtg | default mysql | default named | default net.eth0 | default net.eth1 | default net.lo | boot netmount | default nfs | default nfsmount | default portmap | default postfix | default quota | boot rmnologin | boot saslauthd | default shape-traffic | default smartd | default snmpd | default sshd | default syslog-ng | default tor | default urandom | boot vixie-cron | default I saw this first in baselayout 1.12.x. Since it's linux I am not restarting too often, so it may be necessary to check against all versions 1.12 of the baselayout. The problem is for sure in sys-apps/baselayout-1.12.5-r2. Does net.lo try to start in the boot runlevel? Please attach your /etc/conf.d/net It tries to start in boot-level but sometimes it seems the default runlevel is starting before net.lo has been started successfully. The Gateway is running with ppp0 on eth1 as the WAN-interface. I use "adsl" instead of config_ppp0=( "ppp" ) since config_ppp0=( "ppp" ) is not usable on a dynamic dsl-line cause it does not control the pppd daemon if it crashes, i.e. if line is totally dead for a long time. In this case adsl is way superiour. $ cat /etc/conf.d/net config_eth0=( "172.16.17.1 netmask 255.255.255.0 broadcast 172.16.17.255" ) config_eth1=( "adsl" ) adsl_user_eth1="someusername" Try removing those .keep files in /etc/runlevels Won't the .keep-files be readded while reemerging the baselayout? No Well, the init-script handling should not pay attention to .keep files. The init scripts themselves don't On the other hand, rc uses the contents of each runlevel folder to determine what needs to be started. So again, remove those .keep files and see if it fixes it for you or not. I removed those .keep files, already. But as it didn't happen on every reboot before, I need to further investigate and find out if it is fixed. Btw, rc should ignore .keep files in those folders. Maybe you need to set RC_NET_STRICT_CHECKING="yes" in your /etc/conf.d/rc because I saw 2 network cards (eth0, eth1) Only an idea. (In reply to comment #12) (In reply to comment #12) I have two interfaces, eth0 and eth1, where eth1 is configured as ppp0. If I set > RC_NET_STRICT_CHECKING="yes" in your /etc/conf.d/rc what will happen, if the WAN connection ppp0 can not be established? Well, I need the services to come up whether ppp0 is active or not. Deleting .keep files did not help. Bug not resolved. Is this bug still valid after solving your ppp problem in irc? If so, please re-open. The last couple of restarts went fine. I will reopen if this bug appears again. This bug is not invalid, it is caused of this bug: https://bugs.gentoo.org/show_bug.cgi?id=153798 changed from Resolved Invalid >>> Closed |