Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 1022725[details]
ks-c7-urna04
The GUI installer (as opposed to the TUI one) breaks when I use boot options which set up bonding with a non-standard name of the bonding interface.
I'm booting a late-2013 Mac Pro with CentOS 7.1 via PXE using some black magic involving grub2 on an USB flash. The grub on USB flash loads its config from PXE, and the config contains quite an involved network config:
- enp12s0 and enp11s0 bonded together via LACP into a "bond-te" interface
- VLAN on top of the bond-te, because the DHCP & PXE server is untagged, and that untagged VLAN0 has no access to the Internet.
This is my Grub2's config:
linuxefi (tftp)/centos7-vmlinuz libata.force=noncq nomodeset text raid=noautodetect vlanid=121 dns=195.113.144.194 ip=195.113.161.154::195.113.161.129:27:urna04.vesnicky.cesnet.cz:vlan121:none:9000 nameserver=195.113.144.194 bond=bond-te:enp12s0,enp11s0:mode=802.3ad,xmit_hash_policy=layer3+4 vlan=vlan121:bond-te rd.md=0 rd.dm=0 inst.repo=http://ftp.fi.muni.cz/pub/linux/centos/7/os/x86_64/ ks=http://panteleimon.vesnicky.cesnet.cz/ks/ks-c7-urna04
initrdefi (tftp)/centos7-initrd.img
They key is the bond=... option. When this option is in place *AND* my Kickstart file specifies graphical installation, an exception is thrown and shown in a pop-up dialog soon after the GUI shows up. The TUI mode finishes without a problem with no change of kernel's/dracut's boot options. As a workaround, removing bond=... and settings up just the VLAN over enp12s0 works, too, because the switch is configured to allow direct connection on that port, too.
This is hand-typed from the BT:
- pyanaconda/nm.py:618 raise SettingsNotFoundError(name)
- pyanaconda/ui/gui/spokes/network.py:233
- pyanaconda/ui/gui/spokes/network.py:702
- pyanaconda/ui/gui/spokes/network.py:426
- pyanaconda/ui/gui/spokes/network.py:1422 (last digit uncertain)
- pyanaconda/ui/gui/hubs/__init__.py:228
- pyanaconda/ui/gui/hubs/__init__.py:397
- pyanaconda/ui/gui/__init__.py:471
Local variables in the innermost frame:
settings_paths: []
key2: uuid
key1: connection
name: bond0
Because it wasn't possible to specify bonding, VLANs and bridging back in 7.0 when these KS files were produced, the KS does not contain any network options, just this one:
network --bootproto=static --hostname=urna04.vesnicky.cesnet.cz
In other words, we're relying on the kernel's command-line options which are handled by Dracut, and expect Anaconda to ignore them. The network config of the newly installed system is configured by simply `cat`-ing stuff into /etc/sysconfig/network-scripts/ifcfg-* from a %post section.
Please attach the entire anaconda-tb-* file from /tmp when you see the backtrace window appear. You can collect that file by going to tty1, then switching to the second tmux window, then scp'ing that file to a location that allows you to attach it to this bug report as a plain text file.
David, unfortunately I won't have access to these servers for purposes of additional debugging in the next month or two -- had you asked earlier, it would have been much easier for me. Can you reproduce this yourself?
We don't have the hardware in question. But that's not as important as starting with the log files from the installation environment. That gives us the information we need to start investigation.
I'm going to close this out, but there's a reason for that. If you are able to get access to the system in question, perform the install again and grab the log files from the installation environment (do this before rebooting in to the newly installed system) and attach those files individually to this bug report as text/plain files. Hang on to the system too because we may need further help from you.
Now, if you can do all that, then reopen the bug. It will hit our bug queue with a reopen notice that you've been able to provide the information we need.