View previous topic :: View next topic |
Author |
Message |
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Tue Oct 29, 2013 3:53 pm Post subject: |
|
|
Resume so far:
Jaglover; I believe this is the fallback address you get if your network connection cannot be established.
I'd already mentioned APAPI, the question is why is this interface not using the fixed IP provided.
NeddySeagoon: I guess your net file is in a mess ?
Good guess but , no.
NeddySeagoon:Look in emerge.log to see what got updated in the last 3 or 4 days
Not neither.
aim nano : Perhaps their is an issue, then, with your DHCP server/modem/router... broken DHCP server
DHCP seems to work, what you are suggesting is broken client. Where is evidence of this being a known issue?
Hu: Although this is not the root of your problem, setting your address as a /8 when you are clearly using the standard reserved address range is wrong. You probably want a /24.
right , so that's another thing that is NOT the cause of this problem.
Tom Wij: If you don't have that udev rule and use the name it normally gives, can you still replicate the problem?
Yes, so it's not that either.
---------o : Regardless of whether you've added static ip some mechanism in modern routers trigger dhcp.
Sounds rather nonsensical since it is the dhcp CLIENT that runs on gentoo. It is the client that "triggers" dhcp , not the server.
After that, five posts by me with no reply from anyone.
Guess we're out of ideas of a possible explanation then. _________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54216 Location: 56N 3W
|
Posted: Tue Oct 29, 2013 8:34 pm Post subject: |
|
|
Gentree,
dhcp is the default for any interface not listed in the net file.
your interface starts out with a ethX assigned by the kernel
It may get a udev permanent name before your own rule renames it again
Maybe dhcpcd runs when the interface has one of its transient names and it is therefore not listed in the net file.
dmesg may help. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Tue Oct 29, 2013 8:56 pm Post subject: |
|
|
Thanks Neddy.
As previously posted output shows, the udev renaming happens during boot phase. dhcpd seems to be the first thing to happeni in runlevel 3 by which time I have the renamed interfaces. As the experiment of removing renaming showed this is not a factor and some critical time oddity is not the cause.
If I add net.eth_real to default , it gets configured from conf.d/net but dhcpd no longer fires and I don't get WLAN.
I have added both net.eth_real and net.eth_real (the outward pointing NIC) to default and get network configured in an equivalent state to before but cannot guarantee this is the same way I had it before.
One think is sure, I did not use rc-update to remove them nor explicitly touch network config in any way to provoke this change.
Exactly what broke the LAN config remains a mystery. _________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54216 Location: 56N 3W
|
Posted: Tue Oct 29, 2013 9:13 pm Post subject: |
|
|
Gentree,
How does dhcpcd get run?
Is it in your default runlevel or called by the network startup script? _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Tue Oct 29, 2013 10:23 pm Post subject: |
|
|
No, dhcpcd is not explicitly in any runlevel.
hotplug is in runlevel 3 but I don't see anything in logs explicitly stating it as starting
current log (with both net.eth scripts explicitly in default) looks that same as before:
Code: | Oct 29 22:27:19 localhost init: Entering runlevel: 3
Oct 29 22:27:20 localhost dhcpcd[1892]: version 5.5.6 starting
Oct 29 22:27:20 localhost dhcpcd[1892]: all: not configured to accept IPv6 RAs
Oct 29 22:27:20 localhost dhcpcd[1892]: eth_mobo: rebinding lease of 192.168.0.10
|
conf.d/net specifies it to use dhcp but as noted above it was still doing this even when that file was not present.
conf.d/net seems to get called when a net.eth* is explicitly started. If none are in rc-update -s it is not read.
Quote: | dhcp is the default for any interface not listed in the net file. |
Default for what? What needs a default ? Knowing what process is triggering all this may help in understanding how it is configured and why it is or is not running.
I get the impression you know and you are just pointing me to asking the right question.
If you have an idea what is running what it may speed things to up a bit to say so. I'm going to have quit for tonight very shortly.
thanks. _________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Tue Oct 29, 2013 10:51 pm Post subject: |
|
|
It really sounds like /etc/conf.d/net isn't read at all somehow.
$ md5sum /etc/init.d/net.lo
be4d4227cd5c7647493edae9131f1798 /etc/init.d/net.lo
1. Please verify that you get the same result as above; if not, remove it and merge net-misc/netifrc again.
2. Remove any other /etc/init.d/net.* entries.
3. Symlink the entries again.
4. Use `rc-update add net.* default` for each entry you want to start by default.
5. Ensure /etc/conf.d/net has what you want it to do.
6. Reboot.
I think this should ensure /etc/conf.d/net is read; if not, you are suggested to file a bug at https://bugs.gentoo.org such that the maintainers can look further into what happened and how to fix it. |
|
Back to top |
|
|
Aiken Apprentice
Joined: 22 Jan 2003 Posts: 239 Location: Toowoomba/Australia
|
Posted: Tue Oct 29, 2013 11:08 pm Post subject: |
|
|
TomWij wrote: |
$ md5sum /etc/init.d/net.lo
be4d4227cd5c7647493edae9131f1798 /etc/init.d/net.lo
1. Please verify that you get the same result as above; if not, remove it and merge net-misc/netifrc again.
|
That looks like you are running unstable. My system is running stable and the md5 of my /etc/init.d/net.lo is 564bc20feda1883b3f7001cdbb3cfa04 and it comes from openrc. _________________ Beware the grue. |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Wed Oct 30, 2013 12:26 am Post subject: |
|
|
Err, sorry, I thought that change happened to stable yet, I was wrong and haven't checked that; though given that the hash is different, maybe it is interesting to try the unstable version?
Regardless, thank you for posting the stable hash such that he can check against that instead. |
|
Back to top |
|
|
ChrisJumper Advocate
Joined: 12 Mar 2005 Posts: 2390 Location: Germany
|
Posted: Wed Oct 30, 2013 1:34 am Post subject: |
|
|
Hi Gentree!
If you have still your /etc/conf.d/net like that:
Code: | config_eth_real="192.168.212.3/8"
dhcpcd_wlan0=" -C resolv.conf"
dhcpcd_wlan1=" -C resolv.conf"
config_eth_mobo="dhcp"
dhcpcd_eth_mobo=" -C resolv.conf"
|
Your issue should be that your udev-Rule named your device eth0 and your rules aim at a device named eth_real.
Try 192.168.212.3 with a slash 24 netmask:
Code: | config_eth0="192.168.212.3 netmask 255.255.255.0 brd 192.168.2.255" |
Or if you really use a slash 8 netmask:
Code: | config_eth0="192.168.212.3 netmask 255.0.0.0 brd 192.168.2.255" |
Gentree wrote: |
Well, I seems to be discussing this with myself by this stage but just in case:
I inserted a garbage line into /etc/conf.d/net and it produced no error.
messages:
Code: | Oct 29 11:19:36 localhost init: Entering runlevel: 3
Oct 29 11:19:37 localhost dhcpcd[1774]: version 5.5.6 starting
Oct 29 11:19:37 localhost dhcpcd[1774]: all: not configured to accept IPv6 RAs
Oct 29 11:19:37 localhost kernel: [ 14.064341] eth_real: link up, 100Mbps, full-duplex, lpa 0x41E1
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier lost
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier acquired
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier lost
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier acquired
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: acknowledged 192.168.0.10 from 192.168.0.254
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: checking for 192.168.0.10
Oct 29 11:19:42 localhost dhcpcd[1774]: eth_real: using IPv4LL address 169.254.102.87
Oct 29 11:19:42 localhost dhcpcd[1774]: forked to background, child pid 1824
Oct 29 11:19:42 localhost dhcpcd[1824]: eth_mobo: leased 192.168.0.10 for 864000 seconds
|
|
Wow with your init 3, your system switching to Init Lvl 3 :)
I think your issue is that the Network-Device names have changed. Your udev-Rule:
Code: | # PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:a1:73:74:e9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" |
Will declare your Network-Device as eth0.
What Names use ifconfig you have after your System boot?
And are you sure that your cleaning lady or cleaner did not unplug your Lan cable and put the plug back in the wrong Networkcard? But i suppose that you got the update of udev which rename your device-names if you have no rule as described before. |
|
Back to top |
|
|
Chiitoo Administrator
Joined: 28 Feb 2010 Posts: 2571 Location: Here and Away Again
|
Posted: Wed Oct 30, 2013 2:08 am Post subject: ><)))°€ |
|
|
Heya. ö/
Just a bit of a side-question from the sidelines!
TomWij wrote: | I think this should ensure /etc/conf.d/net is read; if not, you are suggested to file a bug at https://bugs.gentoo.org such that the maintainers can look further into what happened and how to fix it. |
Would that really be prudent, considering for one, they are using dhcpcd-5.5.6 (which, I think, was removed from Portage nearly 10 months ago)?
Just wondering. ^^;
As for the issue, I doubt I could come up with any better ideas. It does certainly seem like a very interesting one, especially since there has been “no emerge activity since June”. If no configuration files have been modified either, first thing that comes to my mind are external changes (router box, cables, and so on and so forth).
I wouldn't probably get /too/ paranoid just yet. Just.
Best of luck on your journey towards closure on this! _________________ Kindest of regardses. |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Wed Oct 30, 2013 2:30 am Post subject: |
|
|
Well spotted, interesting, can you (Gentree) check why the dhcpcd is like that? The latest stable seems to be different; so, maybe upgrading the system might yield a difference... |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Wed Oct 30, 2013 6:09 am Post subject: |
|
|
TomWij, this system is badly out of date. Part of my aim in looking at this is to decide whether it is worth updating (which will be problematic) or install a fresh system (which will be a PITA to get all the tweaks and configs just the way I want it like the current system). Either way I have a significant time investment that I'm not looking forward to.
Before considering introducing even more problems by changing package versions I need to know this box is in a stable state and essentials like networking are in a know running state. Until last week that had bee the case for a very long time.
something happened that broke networking and I still have little idea what caused that change. That, I do not like. _________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54216 Location: 56N 3W
|
Posted: Wed Oct 30, 2013 9:00 pm Post subject: |
|
|
Gentree
Code: | # PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:a1:73:74:e9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" |
What version of udev do you have?
udev-17? approx was the last version that supported renaming to kernel names
Hot plugging starts all detected interfaces. They need not be listed in the default runlevel.
See the comments in /etc/rc.conf
Try listing your transient interface names in the
Code: | rc_hotplug="!net...." | entry _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
eyoung100 Veteran
Joined: 23 Jan 2004 Posts: 1428
|
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54216 Location: 56N 3W
|
Posted: Wed Oct 30, 2013 9:42 pm Post subject: |
|
|
eyoung100,
... but dhcpcd shold never be run for the interface.
It should get the statically assigned IP, or no IP at all _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
eyoung100 Veteran
Joined: 23 Jan 2004 Posts: 1428
|
Posted: Wed Oct 30, 2013 9:58 pm Post subject: |
|
|
What's the default behavior of the *.net scripts, if manually assigning an IP Address Fails Following Logic:
Manual Assignment Fails for eth_real Other Scripts Require net to be up Fallback to DHCP Assignment for eth_mobo Manual Assignment tried again for eth_real, and Fails due to Hardware Failure. Evidence is in log:
Code: | Oct 29 11:19:36 localhost init: Entering runlevel: 3
Oct 29 11:19:37 localhost dhcpcd[1774]: version 5.5.6 starting
Oct 29 11:19:37 localhost dhcpcd[1774]: all: not configured to accept IPv6 RAs
Oct 29 11:19:37 localhost kernel: [ 14.064341] eth_real: link up, 100Mbps, full-duplex, lpa 0x41E1
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87 <-- Previous Address Failure Released
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier lost <--Address Assignment Fails
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier acquired <--Address Assignment Retries and fails again
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87 <--Static Attempt Fails
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier lost
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier acquired
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: acknowledged 192.168.0.10 from 192.168.0.254
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: checking for 192.168.0.10
Oct 29 11:19:42 localhost dhcpcd[1774]: eth_real: using IPv4LL address 169.254.102.87
Oct 29 11:19:42 localhost dhcpcd[1774]: forked to background, child pid 1824 <--Failing Card forked to background, because comms failed at DHCP Server Whiile Repeating Above Arrowed Steps
Oct 29 11:19:42 localhost dhcpcd[1824]: eth_mobo: leased 192.168.0.10 for 864000 seconds |
the DHCP Server is irrelevant here, but the Carrier Signal still needs to communicate with the router to tell the router, "Hey, I'm taking this address<static address> don't give it to anyone else," and that communication is failing when the process is forked. The process is forked because the self-assigned IP address cannot be released.
Hunch: Does this failure also occur on Windows, if machine has Windows _________________ The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper |
|
Back to top |
|
|
TomWij Retired Dev
Joined: 04 Jul 2012 Posts: 1553
|
Posted: Wed Oct 30, 2013 10:31 pm Post subject: |
|
|
dhcpcd shouldn't be working on that interface if it were configured as static; so, those lines shouldn't appear in the log at all. Dunno about a hardware failure, it appears that dmesg doesn't report it; so, it would be a silent hardware failure if it is. I stay by the thought that /etc/conf.d/net isn't getting read for one or another reason.
Given that the system has became outdated, this might be some bug with something that has since already been resolved; the interesting thing though, is that this just so suddenly happened which makes me think back about the timing bug mentioned near the start of the thread. Another option is that dhcpcd is somehow ran independent from the net scripts; but well, I suppose that would be known if that were the case.
I'd say a try to update or a reinstall is adviced to ensure a recent system; because well, at this point one would have to use more low level debugging techniques (changing the openrc shell scripts, firing up tcpdump or wireshark and look what goes wrong with the protocol, etc...) which might take longer than to just upgrade or reinstall the entire system instead.
Last edited by TomWij on Wed Oct 30, 2013 10:37 pm; edited 3 times in total |
|
Back to top |
|
|
eyoung100 Veteran
Joined: 23 Jan 2004 Posts: 1428
|
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Thu Oct 31, 2013 11:10 am Post subject: |
|
|
Quote: | I stay by the thought that /etc/conf.d/net isn't getting read for one or another reason. |
That is the case unless I add net.eth_mobo and net.eth_real to default.
It seems that without that, hotplug is running dhcpcd automatically and /etc/conf.d/net is not read at all. I confirmed that above by adding a deliberate syntax error and finally removing it altogether.
@ Neddy
dmesg | grep udev
[ 6.514642] udev: starting version 151
[ 7.002365] udev: renamed network interface eth0 to eth_real
[ 7.255754] udev: renamed network interface eth0 to eth_mobo
udev 151, last one to recognise /dev/hd* device names.
Removing that limitation was what started the kernel changes. All drives are now on /dev/sd* but I have not changed udev or any other packages because I want to know what broke networking in the few days I was making ata/sata change over. _________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
_______0 Guru
Joined: 15 Oct 2012 Posts: 521
|
Posted: Thu Oct 31, 2013 2:44 pm Post subject: |
|
|
Could this be related to the newnet USE flag in udev or openrc? I remember that was a headache.
What about some other program starting dhcp? Are you running a full blown DE by any chance? |
|
Back to top |
|
|
UberLord Retired Dev
Joined: 18 Sep 2003 Posts: 6835 Location: Blighty
|
Posted: Thu Oct 31, 2013 3:26 pm Post subject: |
|
|
Code: | Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo |
So the same instance of dhcpcd (as they have the same PID is working on two interfaces).
This means that dhcpcd is being started by /etc/init.d/dhcpcd (check for runlevels for it's presence).
As such it will ignore any conf.d/net rules you have inplace.
This is generally a good thing btw and how dhcpcd is designed to work since dhcpcd-5 especially on a multi homed system such as a laptop with wired and wireless potentially on the same subnet.
Also, you need dhcpcd-6.1.x to work well with udev device renaming OR have dhcpcd depend on udev-settle or similar if in the same runlevel or using something like systemd. _________________ Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Fri Nov 01, 2013 10:13 pm Post subject: |
|
|
thanks for the details, your uberness.
Code: | This means that dhcpcd is being started by /etc/init.d/dhcpcd (check for runlevels for it's presence).
As such it will ignore any conf.d/net rules you have inplace. |
That would explain net rules being ignored, thanks. However, dhpdcd is not in any run level.
I'm still unclear of the precise trigger for dhcpcd being the first thing to post output on runlevel 3 starting.
There were two clear changes in behaviour when this started. Firstly eth_real was getting dhcp APIPA fallback IP instead of the hard coded net rules static.
Secondly, during startup when router was not powered up I would have to wait for dhcp time-outs on eth_mobo, this was no longer after the change (or perhaps it was not visible once X11 came up, whereas I normally noticed it since I see boot messages scrolling).
These observations lead me to conclude that eth_real and eth_mobo were is default RL as they are again now and net setup seems to behave as before the problem.
All I was working on last w/e was changing ata/sata in kernel. I don't see any way this could have affected network settings.
I have a vague recollection of reviewing rc content many months ago. Is there any mechanism which could have cached the static IP on eth_real since then if I had removed it from the runlevel configuration at that time and that could have been cleared by the kernel rebuild last week? _________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
UberLord Retired Dev
Joined: 18 Sep 2003 Posts: 6835 Location: Blighty
|
Posted: Sun Nov 03, 2013 3:31 pm Post subject: |
|
|
Gentree wrote: | That would explain net rules being ignored, thanks. However, dhpdcd is not in any run level. |
Then maybe something is depending on it OR something is starting it with either 0 or >1 interface names.
I've not used Gentoo in ages, but iirc the rc-status command should show all services running in the runlevel.
If dhcpcd is running AND dhcpcd is listed then the former is true.
If dhcpcd is running AND dhcpcd is not listed then the latter is true. This is more tricky to find, but would either be the Gentoo net scripts or something like NetworkManager.
Quote: |
Secondly, during startup when router was not powered up I would have to wait for dhcp time-outs on eth_mobo, this was no longer after the change (or perhaps it was not visible once X11 came up, whereas I normally noticed it since I see boot messages scrolling).
|
Could be that one of your dhcpcd config settings is turning off carrier detection OR the carrier detection on eth_mobo is faulty.
If the router isn't powered then the carrier should be down, assuming a direct connection. If via a hub/switch then ofc carrier would be up and you're SOL.
Quote: |
I have a vague recollection of reviewing rc content many months ago. Is there any mechanism which could have cached the static IP on eth_real since then if I had removed it from the runlevel configuration at that time and that could have been cleared by the kernel rebuild last week? |
Very doubtful.
dhcpcd and dhclient do cache the last assigned address and try to re-use it, but this shouldn't affect any static config you may have. _________________ Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
Back to top |
|
|
Gentree Watchman
Joined: 01 Jul 2003 Posts: 5350 Location: France, Old Europe
|
Posted: Mon Nov 04, 2013 9:48 am Post subject: |
|
|
Thanks again,
in default run level to most likely things to cause dhpcd to start are netmount and udev-postmount.
Since, without the devices being explicitly started via net.eth* there will be nothing up, that is not worrying that something is triggering it.
My underlying mystery in all this is that something changed last week and I did not do it.
Clearly eth_mobo ( the DHCP configure net did use to be run in the boot run level since it used to hold up the boot process if the router was off.
The static device did used to get configured until the change last week. This would seem to imply that eth_real was being started explicitly before that time.
Since it seems high-fliers like Neddy and Uberlord can't see how my kernel change could have done this and considerable discussion has not shown anything that could account for the static rules being read without having eth_real started explicitly somewhere, I'm left with a problem to explain what changed my network config.
That is a worry. _________________ Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86 |
|
Back to top |
|
|
UberLord Retired Dev
Joined: 18 Sep 2003 Posts: 6835 Location: Blighty
|
|
Back to top |
|
|
|