I just did a fresh install of F14-RC1 (i.e. the gold version, x86_64) with default options and have no network. My F13 system on the same h/w and net had no problems. This is a bog-standard wired Ethernet using DHCP to a Belkin hub. The net itself is fine as other machines can connect, but F14 is dead. The "Edit Connections" dialogue is completely normal, IPv4, DHCP for everything etc.
Attempting to run nm-applet gives a mysterious message about "Could not get the session bus". It then dumps core.
This is about as uncomplicated a setup as it's possible to imagine, and yet it doesn't work out of the box. I hate to carp about free software, but how can this not have been caught in testing? (Yes I know, but we don't all have the time and resources to test the new stuff before release).
poc
PS Sending from my F13 netbook on the exact same network.
On Sun, Oct 31, 2010 at 05:12:33PM -0430, Patrick O'Callaghan wrote:
Attempting to run nm-applet gives a mysterious message about "Could not get the session bus". It then dumps core.
It appears that for whatever reasons your dbus is not running. Core dumping is a clear bug which is worthy of bugzilla.
You should have a better chance for some meaningfull feedback if you will look at /var/log/messages and/or try 'nmcli'.
Michal
On Sun, 2010-10-31 at 18:15 -0600, Michal Jaegermann wrote:
On Sun, Oct 31, 2010 at 05:12:33PM -0430, Patrick O'Callaghan wrote:
Attempting to run nm-applet gives a mysterious message about "Could not get the session bus". It then dumps core.
It appears that for whatever reasons your dbus is not running. Core dumping is a clear bug which is worthy of bugzilla.
I'll do that.
You should have a better chance for some meaningfull feedback if you will look at /var/log/messages and/or try 'nmcli'.
nmcli just says it's not connected. /var/log/messages appears to show a DHCP problem (it sends a series of DISCOVER packets at increasing intervals and then times out).
I've disabled iptables, ip6tables and SElinux as per MA Young's suggestion and at first it worked. I then did a yum update and rebooted (to a new kernel), and now the same sequence of actions doesn't work.
ifconfig shows the interface UP for IPv6 (although IPv6 is supposed to be disabled) but not for IPv4 of course. It also shows a few hundred RX packets, which could be DHCP replies I guess.
Finally, restarting NM does nothing, and ifup times out,
poc
On Sun, Oct 31, 2010 at 08:57:14PM -0430, Patrick O'Callaghan wrote:
On Sun, 2010-10-31 at 18:15 -0600, Michal Jaegermann wrote:
You should have a better chance for some meaningfull feedback if you will look at /var/log/messages and/or try 'nmcli'.
nmcli just says it's not connected.
Well, 'man nmcli' describes a number of commands; 'status' and 'con' with further options usually have the best chances to give you some insights. This is not a place to quote the whole 'man nmcli'.
/var/log/messages appears to show a DHCP problem (it sends a series of DISCOVER packets at increasing intervals and then times out).
Are you blocking DHCP responses on a firewall? It is difficult to guess what is happening without sitting at your console.
The first "sanity check" is to configure your network interface static to make sure that the basic hardware/driver are healthy. One thing at a time.
Michal
On Sun, 2010-10-31 at 19:46 -0600, Michal Jaegermann wrote:
On Sun, Oct 31, 2010 at 08:57:14PM -0430, Patrick O'Callaghan wrote:
On Sun, 2010-10-31 at 18:15 -0600, Michal Jaegermann wrote:
You should have a better chance for some meaningfull feedback if you will look at /var/log/messages and/or try 'nmcli'.
nmcli just says it's not connected.
Well, 'man nmcli' describes a number of commands; 'status' and 'con' with further options usually have the best chances to give you some insights. This is not a place to quote the whole 'man nmcli'.
The whole manpage doesn't say a lot, and the default is to give the connection status which I just commented on.
/var/log/messages appears to show a DHCP problem (it sends a series of DISCOVER packets at increasing intervals and then times out).
Are you blocking DHCP responses on a firewall? It is difficult to guess what is happening without sitting at your console.
As I said in another message, iptables is disabled, as is ip6tables. Also SElinux.
The first "sanity check" is to configure your network interface static to make sure that the basic hardware/driver are healthy. One thing at a time.
That's fine, however the only effect of configuring a manual IP (outside the pool managed by the DHCP server, which is also the router), plus netmask, router etc. is that nmcli now says "connected" and /var/log/messages no longer has DHCP errors, but pinging the router gets me "Destination unreachable" and several dropped packets.
poc
On Sun, Oct 31, 2010 at 11:06:53PM -0430, Patrick O'Callaghan wrote:
On Sun, 2010-10-31 at 19:46 -0600, Michal Jaegermann wrote:
The first "sanity check" is to configure your network interface static to make sure that the basic hardware/driver are healthy. One thing at a time.
That's fine, however the only effect of configuring a manual IP (outside the pool managed by the DHCP server, which is also the router), plus netmask, router etc. is that nmcli now says "connected" and /var/log/messages no longer has DHCP errors,
That is sort of expected. :-) You are not using DHCP anymore.
but pinging the router gets me "Destination unreachable" and several dropped packets.
On an assumption that this interface is correctly configured (an address without typos, right network) that says something, doesn't it? Your hardware appears to be ok, because of F13, so apparently its driver went south. 'lsmod' presumably lists it as loaded and in use, right? The situation possibly generated some additional info in dmesg and/or /var/log/messages. Did you check? What 'ifconfig eth0' has to say about RX and TX? It is not a great surprise that DHCP does not work, or works erraticaly, if your connection is basically shot. That would be a serious bug.
Michal
On Mon, 2010-11-01 at 14:58 -0600, Michal Jaegermann wrote:
On Sun, Oct 31, 2010 at 11:06:53PM -0430, Patrick O'Callaghan wrote:
On Sun, 2010-10-31 at 19:46 -0600, Michal Jaegermann wrote:
The first "sanity check" is to configure your network interface static to make sure that the basic hardware/driver are healthy. One thing at a time.
That's fine, however the only effect of configuring a manual IP (outside the pool managed by the DHCP server, which is also the router), plus netmask, router etc. is that nmcli now says "connected" and /var/log/messages no longer has DHCP errors,
That is sort of expected. :-) You are not using DHCP anymore.
but pinging the router gets me "Destination unreachable" and several dropped packets.
On an assumption that this interface is correctly configured (an address without typos, right network) that says something, doesn't it? Your hardware appears to be ok, because of F13, so apparently its driver went south. 'lsmod' presumably lists it as loaded and in use, right? The situation possibly generated some additional info in dmesg and/or /var/log/messages. Did you check? What 'ifconfig eth0' has to say about RX and TX? It is not a great surprise that DHCP does not work, or works erraticaly, if your connection is basically shot. That would be a serious bug.
ifconfig shows activity on the interface (RX and TX). I tried hard-wiring the IP address and pinging the router. tcpdump (running on the same machine) shows the ICMP requests and ARP "who-has" requests from the router . After a while (several 10s of seconds) I start to see ARP "is-at" replies, showing the correct MAC address, but still no ICMP replies.
/var/log/messages shows nothing wrong except for DHCP timeouts when in DHCP mode. dmesg shows the link going up, then into promiscuous mode (for the tcpdump) plus the "no IPv6 routers" message that apparently doesn't mean anything important (ip6tables is off and ipv6 is disabled in s-c-network).
poc
This just in: the problem fixed itself magically, Must be because yesterday was Halloween since I have no other explanation, rational or otherwise. What happened was this:
Despite no net, I wanted to recover some files from my backup NAS, so I booted with the F13 (note, not F14) rescue disk, which did have net access, chrooted to the new installation, net-mounted the NAS and restored my home directory. I also restored /etc/fstab and fixed up the UUIDs of the LVM volumes which of course had changed (this being a new install). I swear I didn't touch anything else, but when I rebooted from the new install, the net just came up as if nothing was wrong. I rebooted a couple of times to make sure but it seems solid.
Go figure ...
poc
On 11/1/10 10:34 PM, Patrick O'Callaghan wrote:
This just in: the problem fixed itself magically, Must be because yesterday was Halloween since I have no other explanation, rational or otherwise. What happened was this:
Despite no net, I wanted to recover some files from my backup NAS, so I booted with the F13 (note, not F14) rescue disk, which did have net access, chrooted to the new installation, net-mounted the NAS and restored my home directory. I also restored /etc/fstab and fixed up the UUIDs of the LVM volumes which of course had changed (this being a new install). I swear I didn't touch anything else, but when I rebooted from the new install, the net just came up as if nothing was wrong. I rebooted a couple of times to make sure but it seems solid.
Sigh. After doing the above I decided to use my now-working net to install KDE. This duly occurred without incident. I then rebooted and ... no net.
Current thinking (offlist correspondents etc.) is to try booting F13 and then F14. Perhaps F13 initializes the adaptor in some way that F14 doesn't. Another suggestion: boot w/o ACPI and see what happens. Also, make sure PXE is turned off in the BIOS. And check that the BIOS is up to date.
I 'll try all this in order this evening and report later.
Of course if it's not just me we should start to hear the screaming from today as F14 hits the public interwebs.
poc
On Sun, Oct 31, 2010 at 5:42 PM, Patrick O'Callaghan poc@usb.ve wrote:
I just did a fresh install of F14-RC1 (i.e. the gold version, x86_64) with default options and have no network. My F13 system on the same h/w and net had no problems. This is a bog-standard wired Ethernet using DHCP to a Belkin hub. The net itself is fine as other machines can connect, but F14 is dead. The "Edit Connections" dialogue is completely normal, IPv4, DHCP for everything etc.
Attempting to run nm-applet gives a mysterious message about "Could not get the session bus". It then dumps core.
This is about as uncomplicated a setup as it's possible to imagine, and yet it doesn't work out of the box. I hate to carp about free software, but how can this not have been caught in testing? (Yes I know, but we don't all have the time and resources to test the new stuff before release)
Does the driver happen to be the e1000e intel driver?
I have an instability problem with that one.
On Sun, Oct 31, 2010 at 11:38 PM, Patrick O'Callaghan <pocallaghan@gmail.com
wrote:
On Sun, 2010-10-31 at 23:36 -0400, Gregory Woodbury wrote:
Does the driver happen to be the e1000e intel driver?
Yes.
I have an instability problem with that one.
That's odd because F13 has never given me any trouble. What kind of instability and is there a fix?
It is basically what you are describing, the boot sequence shows it "bouncing" the connection attempts.
I filed BZ 635312 two weeks ago. Add your comments to that bug.
On Sun, 2010-10-31 at 23:43 -0400, Gregory Woodbury wrote:
From:
Gregory Woodbury redwolfe@gmail.com To: For testers of Fedora development releases test@lists.fedoraproject.org Subject: Re: Fresh install, no network Date: Sun, 31 Oct 2010 23:43:01 -0400 (31/10/10 23:13:01)
On Sun, Oct 31, 2010 at 11:38 PM, Patrick O'Callaghan <pocallaghan@gmail.com
wrote:
On Sun, 2010-10-31 at 23:36 -0400, Gregory Woodbury wrote:
Does the driver happen to be the e1000e intel driver?
Yes.
I have an instability problem with that one.
That's odd because F13 has never given me any trouble. What kind of instability and is there a fix?
It is basically what you are describing, the boot sequence shows it "bouncing" the connection attempts.
I filed BZ 635312 two weeks ago. Add your comments to that bug.
It doesn't seem to be the same. My interface is not bouncing (i.e. going up and down as evidenced in your /var/log/messages attachment). It comes up and stays up. It just doesn't receive DHCP replies. I'm leaning more towards https://bugzilla.redhat.com/show_bug.cgi?id=642596 but even there I think there are differences.
poc