Hide Forgot
Description of problem: The network panel of the Anaconda GUI allows to create a bridged VLAN interface. The resulting ifcfg files looks good, but the resulting anaconda-ks.cfg doesn't allow to reproduce the network configuration. Version-Release number of selected component (if applicable): anaconda-29.19.0.41-1.el8_0.x86_64 How reproducible: Steps to Reproduce: 1. Use the following kickstart directive (supposing ens3 is your parent device) network --bootproto=dhcp --device=bridge0 --ipv6=auto --bridgeslaves=ens3.100 --bridgeopts=priority=32768,stp=yes --no-activate network --bootproto=dhcp --device=ens3 --onboot=off --ipv6=auto --activate network --hostname=localhost.localdomain 2. Install a minimal server with this kickstart. 3. Observe the garbage connection which is created (not a VLAN and not enslaved) Actual results: # cat ifcfg-bridge0_slave_1 # Generated by parse-kickstart TYPE="Ethernet" NAME="bridge0 slave 1" UUID="db232faa-7741-42af-a047-2b16fd91a44e" ONBOOT="yes" BRIDGE="bridge0" DEVICE="ens2.100" # ls /sys/class/net/bridge0/brif ==> nothing enslaved Expected results: # nmcli con show NAME UUID TYPE DEVICE bridge0 slave 1 a98a9142-cffe-4100-81d2-c5bc4a7e18e0 vlan ens3.100 ens3 d281553e-a52b-4254-9adc-f0390eea1098 ethernet ens3 Bridge connection 1 2c0aaf4c-a77f-4fce-a1e6-73ada5e53153 bridge bridge0 # ls /sys/class/net/bridge0/brif ens3.100 # cat ifcfg-Bridge_connection_1 STP=yes BRIDGING_OPTS=priority=32768 TYPE=Bridge NAME="Bridge connection 1" DEVICE=bridge0 ONBOOT=yes ... # cat ifcfg-bridge0_slave_1 VLAN=yes TYPE=Vlan PHYSDEV=ens3 VLAN_ID=100 NAME="bridge0 slave 1" DEVICE=ens3.100 ONBOOT=yes BRIDGE=bridge0 ... Additional info: I made a lot of tests, and it seems to be impossible to get this configuration working automatically. The most close result should be: network --bootproto=dhcp --device=ens2 --noipv6 --vlanid=100 --interfacename=ens2.100 --onboot=on --activate network --bootproto=dhcp --device=bridge0 --noipv6 --bridgeslaves=ens2.100 --bridgeopts=priority=32768,stp=yes --onboot=on --activate But this doesn't work as expected: -> The VLAN interface isn't enslaved -> A garbage slave interface still remains It can be easily workarounded in a 2nd time with the following commands: # echo BRIDGE=bridge0 >> /etc/sysconfig/network-scripts/ifcfg-ens2.100 # ifup ens2.100 [ 797.023870] bridge0: port 1(ens2.100) entered blocking state [ 797.025089] bridge0: port 1(ens2.100) entered disabled state [ 797.026845] device ens2.100 entered promiscuous mode [ 797.028420] device ens2 entered promiscuous mode [ 797.029773] bridge0: port 1(ens2.100) entered blocking state [ 797.031301] bridge0: port 1(ens2.100) entered listening state Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7) [ 812.300352] bridge0: port 1(ens2.100) entered learning state [ 827.660025] bridge0: port 1(ens2.100) entered forwarding state [ 827.660772] bridge0: topology change detected, propagating [ 827.661520] IPv6: ADDRCONF(NETDEV_CHANGE): bridge0: link becomes ready # ls /sys/class/net/bridge0/brif ens2.100 # nmcli con delete "bridge0 slave 1" Connection 'bridge0 slave 1' (db232faa-7741-42af-a047-2b16fd91a44e) successfully deleted.
Could you please provide us logs from the installation? You can find them in /tmp/*.log.
Created attachment 1592580 [details] Anaconda logs from installed system
I cloned this bug since the same problem occurs on RHEL 7. https://bugzilla.redhat.com/show_bug.cgi?id=1731969
Did you find any evidence from the anaconda logs?
Anaconda does not support configuration of bridged vlan devices via kickstart. If you care about adding it we should modify this BZ to a feature request that would be evaluated and prioritized.