|Summary:||No ID_FS_TYPE on DVD drives leads to a network install|
|Product:||[Fedora] Fedora||Reporter:||Ed Avis <ed>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||11||CC:||anaconda-maint-list, jgranado, joachim.backes, jvonau3, vanmeeuwen+fedora|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-09-01 16:11:11 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Ed Avis 2009-08-15 19:00:00 UTC
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'.
Comment 1 Ed Avis 2009-08-16 14:56:31 UTC
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?
Comment 2 Joel Andres Granados 2009-08-17 09:53:59 UTC
Does this behavior occur with the rawhide iso images?
Comment 3 Chris Lumens 2009-08-17 13:55:33 UTC
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.
Comment 4 Jerry Vonau 2009-08-20 01:21:53 UTC
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...
Comment 5 Jerry Vonau 2009-08-20 01:38:39 UTC
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-22.214.171.124-1.fc11.i586 handleUdevDeviceFormat is the function, it has not changed in rawhide.
Comment 6 Ed Avis 2009-08-23 14:42:01 UTC
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.
Comment 7 Chris Lumens 2009-08-24 15:01:12 UTC
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.
Comment 8 Chris Lumens 2009-08-28 19:57:13 UTC
*** Bug 520098 has been marked as a duplicate of this bug. ***
Comment 9 Chris Lumens 2009-08-28 19:58:43 UTC
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
Comment 10 Jerry Vonau 2009-08-28 22:57:54 UTC
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.
Comment 11 Ed Avis 2009-09-01 15:47:22 UTC
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.)
Comment 12 Jerry Vonau 2009-09-01 15:58:55 UTC
Chris I think this is dup of 505639, sleep not on the initrd.