Bug 1418835

Summary: Lenovo RD350 hangs on localboot after being provisioned by Satellite 6.2
Product: Red Hat Enterprise Linux 7 Reporter: Landon LaSmith <llasmith>
Component: syslinuxAssignee: Peter Jones <pjones>
Status: CLOSED WONTFIX QA Contact: Release Test Team <release-test-team-automation>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: jmatthew
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-01-15 07:31:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1418361    

Description Landon LaSmith 2017-02-02 20:57:12 UTC
Description of problem: During a QCI deployment (Satellite provisioning) the pxelinux config will use "localboot 0" to boot the hard disk.  Our Lenovo RD 350 machines will fail to boot from the hard disk using this config and restart.  If I replace the option for 

"LOCALBOOT 0" ==> COM32 chain.c32
              ==> APPEND hd0

Then the machine will boot from the local disk as expected. Manually booting from the primary disk works as expected. I also use an HP DL60 machine during this process and it will boot the local disk with no problems


Syslinux Version: syslinux-4.05-13.el7.x86_64
Lenovo RD350 Bios Version: VB3TS381 (V3.81.0)

How reproducible: 100%

Steps to Reproduce:
1. Install QCI from ISO
2. Provision a Lenovo RD350 OR create pxelinux config with "LOCALBOOT 0" 
3. Pxe boot

Actual results: Lenovo machine reboots after pxeboot tells it to boot from the local disk.

Expected results: "LOCALBOOT 0" causes the Lenovo RD350 machine to boot from primary drive

Comment 3 RHEL Program Management 2021-01-15 07:31:21 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.