I noticed that you have already added 80-net-name-slot.rules to initramfs in master, I opened this BZ just to track the issue (https://bugzilla.redhat.com/show_bug.cgi?id=965718#c10) so that we in installer know when the support is in new dracut build and check it as soon as possible. Also we'll probably need to have z BZ to refer to from other reports for device naming inconsistencies (sorry for the process chore).
commit 630aed8b66c6f9460f81ad7b58abfa9c4f294d6f
dracut-028-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/dracut-028-1.fc19
Package dracut-028-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing dracut-028-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-10777/dracut-028-1.fc19 then log in and leave karma (feedback).
dracut-029-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/dracut-029-1.fc19
dracut-029-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
Does not work for me in installer with F19 TC5. The naming from 80-net-name-slot.rules is not applied. Also when I install with root on iscsi, the boot options contain biosdevname=0 ip=enp9s0:dhcp and ifname=enp9s0:XX:XX:XX:XX:XX:XX so the boot succeeds. If I remove the ifname option (which should anaconda stop writing I suppose) the boot fails - apparently because the device is not renamed, because if i change ip= to ip=eth0:dhcp, it works again. I'd like to test device renaming when booting installed system without root on iscsi but simple rd.neednet=1 doesn't cause bring-up of network in initramfs.
What is the output of: # cat /etc/initrd-release in the initramfs? or in the real root: # lsinitrd <initramfs-image> etc/initrd-release
meh.. you are right. 75-net-description.rules is of course missing
commit 282e058
Hmm, 75-net-description.rules should not change any behaviour, it's usually only dead text in the udev database. Why is it needed?
dracut-30 works for me in my tests with networking in initramfs triggered by boot on iscsi (both with biosdevname=0 ... systemd naming is used, and biosdevname=1 ... biosdevname naming is used). But I have problems in installer. biosdevname=0 works perfectly, biosdevname=1 with net.ifaces=0 too, but biosdevname=1 without net.ifaces=0 seems to lead to some races (systemd naming scheme overrides biosdevname). Examples of renaming I am seeing with 3 devices: eth0 -> em1 eth0 -> p3p1 p3p1 -> ens3f0 em1 -> enp63s0 eth1 -> p3p1 another run: eth0 -> em1 eth1 -> p3p2 eth0 -> p3p1 p3p2 -> ens3p1 p3p1 -> ens3p0 em1 -> enp63s0 Given naming works in initramfs of installed system. I'd guess it might be caused by anaconda-dracut hackery so something to solve on anaconda side, but I've noted it here in case you have some hints or ideas.
(In reply to Radek Vykydal from comment #11) > dracut-30 works for me in my tests with networking in initramfs triggered by > boot on iscsi (both with biosdevname=0 ... systemd naming is used, and > biosdevname=1 ... biosdevname naming is used). > > But I have problems in installer. biosdevname=0 works perfectly, > biosdevname=1 with net.ifaces=0 too, but > biosdevname=1 without net.ifaces=0 seems to lead to some races (systemd > naming scheme overrides biosdevname). Examples of renaming I am seeing with > 3 devices: > > eth0 -> em1 > eth0 -> p3p1 > p3p1 -> ens3f0 > em1 -> enp63s0 > eth1 -> p3p1 > > another run: > > eth0 -> em1 > eth1 -> p3p2 > eth0 -> p3p1 > p3p2 -> ens3p1 > p3p1 -> ens3p0 > em1 -> enp63s0 > > Given naming works in initramfs of installed system. I'd guess it might be > caused by anaconda-dracut hackery so something to solve on anaconda side, > but I've noted it here in case you have some hints or ideas. That is very interesting! Please open a bug against systemd-udevd with that finding!