User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 (.NET CLR 3.5.30729) I absolutely cannot get anaconda to get an ip address for a network install or for a regular CD install with updates downloaded from the Internet. In addition, post-install I cannot get an ip address either, so I cannot update software. Since X-Windows does not work out-of-the-box on my graphics card in Anaconda either, this pretty much turned my Power Mac G4 into an electronic brick until I went back and installed Fedora 11, which can at least get an IP address. Reproducible: Always Steps to Reproduce: 1. Run Fedora 12 installation in text mode (since graphical mode does not work on my computer in Fedora 12). 2. Try with network install or CD-install with updates download. Neither mode can get an IP address 3. Do a standard text-mode CD-install 4. Try "ifup eth0" post-installation, does not work either. Actual Results: I just can't get an IP address on my computer in Fedora 12 Expected Results: I should be able to get an IP address. I believe that my model of Apple Power Mac G4 is designated as the "Apple Power Mac G4 with AGP Graphics).
Hi William, what does 'service network restart' ? If it's not working, I need some more information to discover where the problem is. So in case 'service network restart' is not working show me what does: 1) ip addr show 2) cat /etc/sysconfig/network-scripts/ifcfg-eth0 3) cat /etc/sysconfig/network 4) chkconfig --list | grep etwork
I had to type this in manually, so please forgive any typographical errors. [root@localhost ~]# service network restart Shutting down interface eth0 [ OK ] Shutting down loopback interface [ OK ] IPv6 over IPv4 tunneling driver sit0: Disabled Privacy Extensionstions Bringing up loopback interface: lo: Disabled Privacy Extensions [ OK ] [root@localhost ~]# ping 192.168.0.1 connect: Network is unreachable [root@localhost ~]# ifup eth0 eth0: Link is up at 100 Mbps, full-duplex. eth0: Pause is disabled [root@localhost ~]# ping 192.168.0.1 connect: Network is unreachable [root@localhost ~]# ip addr show 1: lo: <LOOPBACKUP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.1/8 scope host lo inet6 ::1/128 valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:30:65:5a:07:6e brd ff:ff:ff:ff:ff:ff inet6 fe80::230::65ff::fe5a:76e/64 scope link valid_lft forever preferred_lft forever 3: sit0 <NOARP> mtu 1400 qdisc noop state DOWN link/sit 0.0.0.0 brd 0.0.0.0 [root@localhost ~]# cat /etc/sysconfig/network-script/ifcfg-eth0 # Apple Computer Inc. UniNorth GMAC (Sun GEM) DEVICE=eth0 HWADDR=00:30:65:5A:07:6E ONBOOT=no [root@localhost ~]# cat /etc/sysconfig/network NETWORKING=yes HOSTNAME=localhost.localdomain [root@localhost ~]# chkconfig --list | grep etwork network 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root@localhost ~]#
Thanks for your effort with typing in all this. Last try from my side and if it won't work I'll find somebody with more experiences. So I suggest to try this: 1) Edit /etc/sysconfig/network-script/ifcfg-eth0, add line with 'BOOTPROTO=dhcp' and change 'ONBOOT=no' to 'ONBOOT=yes' 2) Type 'chkconfig network on' 3) Now restart computer or type 'service network restart'
That worked, thank you. Now I guess someone has something to fix with Anaconda or elsewhere so that this doesn't happen in Fedora 13.
Hang on a second... yum didn't get set up right by Anaconda either. That or something is wrong with the yum service tonight, because I keep getting the message: Error: Cannot retrieve repository metadata (repomd.xml) for repository: fedora. Please verify its path and try again (Someone needs to make sure that a period gets put on the end of that message at some point, too.)
Hi William, do you still see the repository problem ?
I'm changing component to Anaconda, because I don't know answer for this question: Is it alright, that after text-mode installation, no network interface is configured ? After text-mode installation every ifcfg-ethX contains only DEVICE, HWADDR and ONBOOT=no.
I can reproduce the problem on my G4 MDD. Yes, after text-mode installation every ifcfg-ethX contains only DEVICE, HWADDR and ONBOOT=no. But not only after text-mode installation. Graffic-mode asks only for hostname. So it is not only a dhcp problem. The installtion dont asks for the needed IP infos. So you cant do any network configuration. You need to do this after the installation and you need to start the networx by hand. --- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It sounds like you're doing a media install and not a network install of Fedora. The way anaconda works currently is to only configure the network if it needs it during installation. Since we use NetworkManager in anaconda, we start by disabling all network interfaces. Then, if you are doing a network install, you are asked how to configure the network (choose the interface and configuration method). At that point, we modify the ifcfg file written during installation to contain the settings you gave us and we change ONBOOT to 'yes'. NetworkManager detects this change and brings the interface up, which then lets you continue with installation. Regardless of the installation method you are using, either media or a network method, anaconda mirrors the /etc/sysconfig/network-scripts/ifcfg-* files created during installation to /etc/sysconfig/network-scripts on the installed system. That means if you did a media install and never used the network during installation, all of those files will have ONBOOT=no. This is typically not a problem for desktop users because you can use the NetworkManager applet to bring up the network connection you want and then it remembers the settings. It tends to present an issue for servers where people do not want NetworkManager running or have performed a media install, but still need the network up immediately on reboot. The current solution for the server use case is to perform a kickstart installation, since we give you greater flexibility over network interface configuration through kickstart than we do in the interactive installer. What you are experiencing is not really a bug as this is how anaconda's NetworkManager integration was designed. The functionality will be changing in F-14, giving users the ability to control all sorts of details about their network interface during installation.
Apparently you never read the first sentence on this bug: "I absolutely cannot get anaconda to get an ip address for a network install or for a regular CD install with updates downloaded from the Internet." Please reopen this bug.
OK, well Jiri already had you test dhclient manually and that worked. And I've provided an explanation of how the network configuration files are written out by anaconda. anaconda uses dhclient by way of NetworkManager, so I guess let's play pass the bug. Dan, you're up next.
Ok, note that ONBOOT=no means eth0 wont' get brought up automatically, you'll have to pick it manually from the menu. But in any case, can I get some logs from /var/log/messages when the problem occurs?
What menu? In what program? Please note that graphical install does not work on Fedora 12 because the newer ATI drivers that were in use when Fedora 12 was released don't work. I'm not sure of which problem you are speaking when you say "when the problem occurs." Are you asking me to reinstall Fedora 12 or do something else?
After the install, from the network applet in the top-right of the panel... Pick "Auto eth0" from the menu and lets see if that works. If not, we need /var/log/messages to see what's going on.
And if this isn't a graphical install, we can do some extra debugging to see what debug output dhclient is spitting out when it's trying to get a lease.
Graphical install doesn't work on this machine with the Fedora 11 and 12 installation discs. I think I was able to get Fedora 11 with a GUI up after the installation with updates, I don't recall what happened to Fedora 12. I'll need some time to get back to you on this bug.
Sure. For extra debugging, try: service NetworkManager stop NetworkManager --no-daemon which will give us a bunch more output from dhclient I believe.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.