Red Hat Bugzilla – Bug 506175
anaconda tries to set up networking after partitioning; shuts down if network isn't available
Last modified: 2009-09-04 16:57:16 EDT
I'm booting from a F11 PowerPC DVD. After partitioning and formatting the drive anaconda immediately brings up a network interface setup dialog for some reason - there's nothing on the virtual consoles that gives a hint. This shouldn't happen to begin with, and after I press 'Cancel' anaconda shuts itself down and prompts to reboot. Trying to force the interface setup doesn't help either - timout on dhcp, rinse, repeat (the computer isn't connected to anything at installation time). This effectively blocks F11 installation.
Are you enabling the Fedora Updates repo or another repo only available via the network during installation? If not, could you please attach /tmp/anaconda.log, /tmp/storage.log, etc. to this bug report so we can investigate why anaconda may want the network? Thanks.
Created attachment 356718 [details]
Created attachment 356719 [details]
Created attachment 356720 [details]
Created attachment 356721 [details]
I'm not enabling anything special - just trying to install a default configuration. The network dialog goes up immediately after partitioning and formatting, so I'm not even getting to the repository selection dialog. The logs have been attached.
What happens if you add the "askmethod" parameter to your boot up arguments and manually tell anaconda the DVD contains the installation source?
Exactly same thing happens (plus the appearance of a dialog that asks me for installation source early on). I've attached the logs for this case as well.
Created attachment 356932 [details]
anaconda log - askmethod
Created attachment 356933 [details]
program log - askmethod
Created attachment 356934 [details]
storage log - askmethod
Created attachment 356935 [details]
syslog - askmethod
The Fedora Updates repo is to be enabled by default. When you connect the computer to the Internet, you can proceed with the installation.
Correction: The Fedora Updates repo _is_ enabled by default.
Any links/references to back up your claim? I believe the updates repo is in fact *not* enabled by default, and the only enabled repository is the installation media. I'm not even getting to the repo selection screen - the network interface dialog is shown before that.
I worked on an install yesterday.
My best recollection is that the repo selection screen is visible immediately after the connection to the Internet is established (via the dialog).
One the repo selection screen is visible, one can see that both the Fedora repo and the Fedora Updates repo are enabled by default.
This has been incorrect in all my testing - Installation Repo and Updates Repo are *offered*, but only the Installation Repo and the "Office and Productivity" group in the box above are selected by default.
Can you attach a picture of the screen? If your install is enabling the Updates Repo by default, something somewhere is going really wrong.
Created attachment 359098 [details]
screen shot of the repo selection screen
Right. I attached an ethernet cable to make it through to the repo dialog and Aram is right - both installation and updates repo are selected by default, pictorial evidence attached. So something is clearly wrong here.
Those checkboxes are controlled by the repo config files in /etc/anaconda.repos.d. Can you please verify whether or not the updates repo has enabled=1? Sorry for all the leg work, but this is how it goes when we're unable to reproduce a problem.
Yes - the updates repo has enabled=1, and so does the main fedora repo. If I manually edit the updates repo file before starting the installation to have enabled=0 then it doesn't get deselected but simply disappears from the list. Before that the network dialog still shows, and main repo database is still retrieved from the internet.
If I also disable the main repo, then the installer simply says it can't proceed because it can't read the repo info.
So the problem might be something else entirely. Why is the repo on the DVD not picked up?
*** This bug has been marked as a duplicate of bug 505639 ***