Hide Forgot
I attempted to upgrade a Fedora 10 x86_64 system to 11 using the x86_64 install DVD. During installation I am prompted to set up one of the network interfaces (the system has two network cards eth0 and eth1). But if I cancel that, then I get the message Some of your software repositories require networking, but there was an error enabling the network on your system. The only option offered is to exit the installer. I was puzzled to see this, because the only repositories marked as enabled=1 in /etc/yum.repos.d are fedora.repo and fedora-updates.repo. Surely these two, containing vanilla Fedora 10 packages, can be upgraded to Fedora 11 from the upgrade DVD (if not then what is it for?). There are a few things I'd like to suggest, if I may use the same bug report for all of them: - The message should mention which repositories require networking and why. - There should be an option to skip the troublesome repositories and upgrade anyway. Packages from those wouldn't be automatically upgraded. This is the same situation as having an RPM installed on the system not belonging to any repository, which I assume is already handled. - The default set of repositories (fedora and fedora-updates) should not be reported as requiring networking. The packages on the DVD should be adequate to upgrade these. - In any case, if the networking really is required, then the option presented should be 'Back to network setup', not 'Exit'.
The 'repositories require networking' message appears even if you choose to do a clean install rather than an upgrade. Surely the Fedora 11 DVD is capable of installing a Fedora system without needing to use the network?
Does this behavior occur with the rawhide iso images?
Additionally, did you run media check? Are there read errors when attempting to use the repo on the DVD? You can check by examining /tmp/syslog or looking at tty5.
I have ran into this, have a look at the fix used here: http://forums.fedoraforum.org/showthread.php?t=225742 Where can I grab a iso image(s) of rawhide? Thought that was http only, until a release candidate is released? I'll have to pungi up a dvd to test the current rawhide...
just to save time.. diff /usr/lib/anaconda/storage/devicetree.py tmp/hold/storage/devicetree.py 1460a1461,1465 > # 7/12/2009 - Patrick J. Maloney > # Default fs to iso9660 for CDROM when it's not detected > if (not format_type) and udev_device_is_cdrom(info): > format_type = "iso9660" > log.debug("overriding type for device %s to be %s" % (name, format_type)) diff from anaconda-11.5.0.59-1.fc11.i586 handleUdevDeviceFormat is the function, it has not changed in rawhide.
I did run media check and it passed. I did not test Rawhide, this bug is against the final Fedora 11 release. I didn't notice any I/O errors in the log printed on the various virtual consoles including tty5.
If the problem is, in fact, that the CD-ROM format is not getting detected correctly, we need to solve that root cause. Ed - can you please attach /tmp/storage.log and /tmp/anaconda.log to this bug report? Thanks for checking the media as well.
*** Bug 520098 has been marked as a duplicate of this bug. ***
The attached bug 520998 has plenty of output in its storage.log to show what the underlying problem is, though I do not yet know how to solve it. Can someone being affected by this bug switch to tty2 and attach the output of: udevadm test --action=add /class/block/sr0
Chris, with F11: When I go to capture the output using > the file is blank... Got an idea on how to grab that info?? What I do see is a error at line 47 in /lib/udev/rule_generator.functions not being able to find "sleep" Joel, with Rawhide(12.16). the above problem doesn't appear, and getFormat returns iso9660.
Sorry, I don't have copies of the storage.log or anaconda.log files, and since the machine has already been reinstalled and is in use, I can't redo the process to generate them. (It would be better if the Anaconda bug reporter tool attached these files when it sends the backtrace.)
Chris I think this is dup of 505639, sleep not on the initrd.
Agreed. *** This bug has been marked as a duplicate of bug 505639 ***