Testing Fedora 22 Beta TC3: https://dl.fedoraproject.org/pub/alt/stage/22_Beta_TC3/ using the Server boot.iso, unless you pass inst.updates or inst.ks (which trigger dracut to bring up the network), the network is not activated on boot, so anaconda fails to configure the default repos. Hub shows 'Error setting up base repository' for the INSTALLATION SOURCE spoke. 'ip addr' shows the ethernet interface (ens3, in my VM) as 'UP' but with no IP address at all, only a 'link/ether' (MAC address). 'systemctl status NetworkManager.service' shows 'active (running)', but with very few log messages. There is no /etc/resolv.conf file. There is no default route. Proposing as a Beta blocker: Alpha criterion https://fedoraproject.org/wiki/Fedora_22_Alpha_Release_Criteria#Remote_package_sources , "When using a release-blocking dedicated installer image, the installer must be able to use either HTTP or FTP repositories (or both) as package sources. Release-blocking network install images must default to a valid publicly-accessible package source." - can't do that if the network doesn't work.
/tmp/syslog shows activation of the network interface reaches stage 3, then: dhclient started with pid 1342 Activation: Stage 3 of 5 (IP Configure Start) complete. DHCPv4 client pid 1432 exited with status 127 DHCPv4 state changed unknown -> done canceled DHCP transaction all that happens within the space of one second. Beta TC3 has: systemd-219-8.fc22 NetworkManager-1.0.0-8.fc22 dhcp-client-4.3.2-2.fc22
well, running dhclient manually gives us a big honkin' clue: dhclient: error while loading shared libraries: libirs-export.so.91: cannot open shared object file: No such file or directory That file is actually present. It's provided by bind99-libs and it's at /usr/lib64/bind99/libirs-export.so.91 . bind99-libs also provides a /etc/ld.so.conf.d/bind99-x86_64.conf which adds /usr/lib64/bind99 , and that file is *also* present in anaconda's environment. What's missing, though, is /etc/ld.so.conf , and that's a problem because: [adamw@adam lorax (master)]$ cat /etc/ld.so.conf include ld.so.conf.d/*.conf so the thing that should cause the ld.so.conf.d files to be included isn't there, so /usr/lib64/bind99 never winds up in the linker path, so dhclient can't find it. lorax excludes /etc/ld.so.conf explicitly (and has done since 2011): [adamw@adam lorax (f22-branch)]$ git blame share/runtime-cleanup.tmpl | grep ld.so.conf e7e07059 (Will Woods 2011-06-22 14:20:02 -0400 194) removefrom glibc /etc/gai.conf /etc/ld.so.conf /etc/localtime /etc/rpc so, that seems to be the immediate problem here. Why it only showed up now I don't know for sure, but we *did* pull an updated bind into TC3, so that probably moved stuff around and caused the problem.
I confirmed that after re-creating /etc/ld.so.conf by hand and running 'ldconfig' I can bring up the network connection.
CCing thozza for any needed input on what's the deal with all the moving stuff around in bind.
An additional wrinkle here: the images as built actually have an OK ld cache that's built during image generation (when package %post scripts run ldconfig). The reason it breaks is systemd's 'ldconfig.service', which runs 'ldconfig -X' on boot. It re-generates the cache and, because of the missing /etc/ld.so.conf , loses all the libraries in directories listed in files in /etc/ld.so.conf.d . I tested this: if I boot with 'systemd.confirm_spawn=true', which is kinda like the old 'interactive boot' thing - it asks you to confirm each process spawned during init - and say 'no' when it asks if it should run 'ldconfig -X', then things work correctly (network comes up, and I can run dhclient manually). So I think at least as long as ldconfig.service is active for anaconda, we need to have /etc/ld.so.conf in the installer environment (i.e. lorax shouldn't strip it).
I think it makes more sense to just turn it off. This matches the behavior of live and of lorax master.
lorax-22.7-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/lorax-22.7-1.fc22
Package lorax-22.7-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing lorax-22.7-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-4398/lorax-22.7-1.fc22 then log in and leave karma (feedback).
(In reply to awilliam from comment #4) > CCing thozza for any needed input on what's the deal with all the moving > stuff around in bind. I added bind99 since ISC DHCP is not able to function correctly when built against BIND 9.10.x. bind99 installs libraries and headers into a different location so they don't conflict with the original bind package. This is due to Bug #1184173 and Bug #1199428
Discussed at 2015-03-23 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-03-23/f22-blocker-review.2015-03-23-16.02.log.txt . Accepted as a Beta blocker per criterion cited in #c0.
lorax-22.7-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.