Bug #17919
closed
Provisioning fails for a system with two interfaces
Description
Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1404521
Description of problem:
Satellite doesn't change pxelinux config files on tftp if the provisioning interface is different from the primary interface. The system gets build successfully but not able to boot because TFTP still has the config file for provisioning interface and not for primary.
Version-Release number of selected component (if applicable):
6.2.4
6.2.5
How reproducible:
100% with RHEV and bare metal machines
Steps to Reproduce:
1. Create a new host with two network interfaces and relevant MAC addresses
2. Choose one interface as primary and another one as provision
3. Build the host
Actual results:
The host will be provisioned but unable to boot from its primary interface. TFTP directory will has only PXE config for provision MAC address.
Expected results:
1. TFTP has the PXE config for primary interface
2. Host can boot correctly from its primary interface
Additional info:
Updated by Dominic Cleal over 7 years ago
- Category set to TFTP
- Status changed from New to Need more information
- Priority changed from High to Normal
TFTP menus are created for every managed interface that satisfies the requirements (see http://projects.theforeman.org/projects/foreman/wiki/Troubleshooting#No-TFTP-menus-or-files-are-created-for-new-hosts). It seems likely to me that the primary interface is missing those requirements.
Booting should still occur from either the provisioning interface PXE boot or simply fall back to the hard drive, so I'm unsure why this means it "fails".
Updated by Lukas Zapletal over 7 years ago
Shlomi, can you check if you provided interface identifiers (eth0, eth1)? There is another bug (now fixed in nightly) when these are blank or same, TFTP orchestration won't happen.
Updated by Marek Hulán over 7 years ago
I don't think in nightly only, Lukas is #15238 what you meant? If so, it was fixed in 1.11 branch.
Updated by Lukas Zapletal over 7 years ago
Marek Hulán wrote:
I don't think in nightly only, Lukas is #15238 what you meant? If so, it was fixed in 1.11 branch.
Yep. thanks for correcting me.
Updated by Anonymous
Updated by Marek Hulán about 7 years ago
I repinged the reporter, I'll update this issue when I get some info.
EDIT: just to let you know, the workaround from #15238 didn't help, so it might be different problem.
Updated by Marek Hulán almost 7 years ago
- Status changed from Need more information to Resolved
Works for the reporter, marking as resolved.