network interface doesnt come up on boot when static ip set

confirmed - i'm having the same problem with static IP configuration.

Hi there
do you still experience this issue with the current version of the application?, could you please try to reproduce this using the live environment of the Desktop CD of the development release - Hardy Heron.

Thanks in advance

I've been having the same problem for a while now; it still exists on a fresh install of Hardy Beta.

It worked just fine on installation when it was set to roaming mode, however I require a static IP on my private network. Once changing to the correct static IP settings via the Network Settings window, it works correctly.

Once I reboot, it does not work anymore (ifconfig simply lacks the 'inet addr' line, however the unused 'inet6 addr' line is there). I have set up profiles in Network Settings so that I change to DHCP (which gives me a working connection, albeit with an IP I do not want), then change to my static IP settings (which provides me with my proper connection). I must do this each time upon logging in.

$ apt-show-versions | grep -i network
network-manager/hardy uptodate 0.6.6-0ubuntu2
network-manager-gnome/hardy uptodate 0.6.6-0ubuntu1

$ uname -a
Linux hostname 2.6.24-12-generic #1 SMP Wed Mar 12 22:31:43 UTC 2008 x86_64 GNU/Linux

seems to be fixed after latest update.

I'm still experiencing this issue with the same symptoms described above. Anything you might have done that has fixed it for you, Artur? I just did a fresh restart of my up to date system, and it's apparent the network was down again (Pidgin complains on startup).

I also thought it might be worth mentioning that I'm using an ASUS P5B motherboard, using the onboard "RTL8111B PCI-E Gb LAN".

$ apt-show-versions | grep -i network
network-manager/hardy uptodate 0.6.6-0ubuntu3
network-manager-gnome/hardy uptodate 0.6.6-0ubuntu1

Unfortunately, I'm not able to identify any particular changes.
I'm using static ip conf on my laptop at work - and I just had two weeks off; it was broken before and today
everything seems to just work.

I can confirm that the bug still exists. I've two AMD64 Hardy machines and both of them are connected using the "static ip" via wireless.
One of the two is working perfectly with Gutsy, installed in another partition.
When booting, the wifi interfaces aren't ifupped and I have to do it manually. Same applies when suspending both to disk or to ram.

More, I'd suggest to rise the "low" importance to "medium" or "high" because it's quite a big problem for newbies and don't think that final Hardy should get out with that.

I found this in daemon.log with System Log Viewer.
...
NetworkManager: <info> /etc/network/interface changed: rebuilding the device list.
NetworkManager: <info> Recreating the device list.
NetworkManager: <WARN> ifparser_init(): Error: Can't parse inet line 'inet'
NetworkManager: <WARN> ifparser_init(): Error: Can't parse inet line 'inet'
NetworkManager: <info> Device list recreated successfully.
NetworkManager: <info> /etc/network/interface changed: rebuilding the device list.
NetworkManager: <info> Recreating the device list.
NetworkManager: <info> Device list recreated successfully.
...

The inet warning looks exactly like the problem I'm having, where inet simply doesn't exist in ifconfig on startup. I'm by no means an expert on this stuff, so if someone else knows what file it "can't parse" then please let me know so I can have a look at it.

I also recommend raising the importance; I think medium would properly represent the severity of this bug.

I can confirm I'm also seeing this on Hardy (beta as of March 29th when I upgraded from Gutsy).
The ether worked fine after the first reboot after upgrade - but on a resume from hibernate my static IP'd eth0 didn't come back;
and ifconfig showed the interface and I think showed it was UP - but no IP.
Flipping to dhcp and then back and it seems OK.

I can confirm that I am showing the same symptoms as Dave Gilbert (above) -- the static ip had the exact same problem for me (and I also worked around this by flipping to dchp and back).

But I have just now found what I believe to be the problem:

'auto eth0' needs to be added to /etc/network/interfaces so that it will be brought up when the os boots and runs 'ifup -a'. This should be added when NetworkManager sets interfaces to static ip.

Anyways, I don't know how to fix that in NetworkManager, but it doesn't seem too difficult. I hope this helps someone get it fixed.

EDIT: The gui network-admin application is what I actually mean. The NetworkManager applet is doing its job just fine by ignoring eth0 since I am 'manually' (gui-ally) configuring it.

Adding 'auto eth0' to /etc/network/interfaces works for me too. Thanks to Scott for this fix!

It's worth noting that even when making a change from static -> DHCP with network-admin, the 'auto eth0' line is removed.

I've added gnome-system-tools to the bug as I believe it's actually network-admin at fault.

Looks like I changed to gnome-system-tools rather than adding it. My apologies if this is a bad thing to do. I'm not quite experienced with launchpad yet, so if things need changing then please do.

Adding "auto" works at boot but it isn't re-enabled after suspend/resume

Might be related to bug #178775 ...

I can't stand how such a big bug is marked as "low".
For most people ubuntu, in the current status, won't have such a basic thing like the static ip address functionallity.

Simple things like this will make a lot of people think that ubuntu sucks.

Probably related to bug #185854

This bug seems to have stopped happening for me in the last week or two; (perhaps related to the update in bug #185854) ?

Is this true for everyone else?

Dave

Thank you for taking the time to report this bug and helping to make Ubuntu better. This particular bug has already been reported so it is being marked as a duplicate. Please look at the other bug report to see if there is any missing information that you can provide, or to see if there is a workaround for the bug. Additionally, any further discussion regarding the bug should occur in the other report. Feel free to continue to report any other bugs you may find.