Bug 640668

Summary: grub.conf modification logic can lead to errors when provisioning
Product: Red Hat Satellite 5 Reporter: Alexander Todorov <atodorov>
Component: ProvisioningAssignee: Justin Sherrill <jsherril>
Status: CLOSED DUPLICATE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: low    
Version: 540CC: cperry
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-10-14 18:53:03 UTC Type: ---
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: 462714    

Description Alexander Todorov 2010-10-06 15:02:42 UTC
Description of problem:
When scheduling a system to be re-provisioned grub.conf is modified so that the system will boot into new kernel+initrd pair and will start the installer. The way this kernel entry is configured can lead to errors in some cases.

Currently the default kernel entry is duplicated with all of its parameters and then parameters needed for provisioning are appended (like ks=http://, kssendmac, etc.). There are 2 issues with that:

1) Parameters like root=/dev/VolGroup/LogVol and rd_* (for dracut) are present but not really useful to anaconda. They are ignored and should not affect the installer. In some cases however those can lead to errors because anaconda can read fixed command line length (255 characters I think) and the important parameters be left behind or incomplete (for example incomplete kickstart URL).

2) The other thing is that if the default kernel entry has broken configuration it will be copied to the entry for provisioning and this will cause it to fail.
This can be easily reproduced when entering ks=link instead of ksdevice=link in the kernel options in the webUI. Then schedule the provisioning, fix the mistake and re-schedule again. The 2nd entry resulted in lots of duplicate parameters along the wrong ks=link

Version-Release number of selected component (if applicable):
5.4.0
koan-2.0.3.1-11.el6sat.noarch.rpm

How reproducible:
Always

Steps to Reproduce:
1. See description
2.
3.
  
Actual results:


Expected results:
The safest way is to generate kernel parameters from scratch. This is to say: 
vmlinuz initrd=initrd.img ks=http://... kssendmac ksdevice=link <user defined params>

Additional info:

Comment 1 Clifford Perry 2010-10-14 18:53:03 UTC

*** This bug has been marked as a duplicate of bug 642629 ***