Bug 572510

Public Summary:

How reproducible:
Always

RHN Satellite 530

>    Observed behavior:
When using Satellite 5.3, create a bare-metal kickstart profile.  Then proceed to enter 'mpath' within the 'Kernel Options' section of the profile.  You will notice the 'default' file for PXE boot is updated with 'mpath=~' which is _not_ what was entered.  Indeed, mpath=~ will result in the mpath module not loading and the kickstart build failing. Satellite adds a "=" to kickstart data's kernel options in cobbler profiles for options that are not supposed to have a value.

>    Desired behavior:

kernel options entered in Satellite's "kernel options" KS field in the
webUI would be expected to appear without modification in the installer
kernel

> 6. Does a proposed patch exist? yes/no

Just a wild guess:

diff --git a/java/code/src/org/cobbler/CobblerObject.java
b/java/code/src/org/cobbler/CobblerObject.java
index 57e0299..60b307a 100644
--- a/java/code/src/org/cobbler/CobblerObject.java
+++ b/java/code/src/org/cobbler/CobblerObject.java
@@ -376,7 +376,7 @@ public abstract class CobblerObject {
         for (String option : options) {
             String[] split = option.split("=");
             if (split.length == 1) {
-                toRet.put(split[0], "");
+                toRet.put(split[0], null);
             }
             else if (split.length == 2) {
                 toRet.put(split[0], split[1]);

(completely untested, not even sure it's the way to go... more an
illustration than a patch)

>    Relevant data found (if any):

For a "kernel options" field with value: mpath noipv6 

# cobbler profile dumpvars --name=peprheli386server5u3:1:RedHat
 ...
 'kernel_options': {'ksdevice': 'bootif',
                    'kssendmac': None,
                    'lang': ' ',
                    'mpath': '',
                    'noipv6': '',
                    'text': None},

# grep noipv6 /tftpboot/pxelinux.cfg/default 
        append initrd=/images/ks-rhel-i386-server-5-u3/initrd.img
ksdevice=bootif lang=  mpath= text noipv6= kssendmac 
ks=http://satellite.example.com/cblr/svc/op/ks/profile/pep-rhel-i386-server-5-u3:1:Red-Hat

Additional Information:

If you update the profile via Cobbler:

cobbler profile edit --name=bare-metal-rhel5:1:internaldev --kopts="mpath"

The option correctly updates in 'default', however if you return to the kickstart profile via the RHN GUI and click 'update' on the 'details' tab the option is - again - reset to mpath=~

So I don't think the specified patch will actually work, since XMLRPC does not have a notion of Null/None (and would throw and error if passed a null value).

Might have to make a cobbler change.

So this was fixed upstream in cobbler:

https://fedorahosted.org/pipermail/cobbler/2010-March/005463.html

OLD:
there is string 'mpath=' in ks:

.qa.[root@satellite-1 tps]# cat /tftpboot/pxelinux.cfg/default | grep mpath
        append initrd=/images/old-pkgs:1:SomeOrg/initrd.img ksdevice=bootif lang=  kssendmac mpath= text  ks=http://satellite-1.brq.redhat.com/cblr/svc/op/ks/profile/test-old:1:SomeOrg

NEW:
cobbler-1.6.6-8.el5sat.x86_64
spacewalk-java-0.5.44-77.el5sat.noarch
spacewalk-base-0.5.23-35.el5sat.noarch

when new packages was installed sign '=' was removed:
.qa.[root@satellite-1 tps]# cat /tftpboot/pxelinux.cfg/default | grep mpath
        append initrd=/images/old-pkgs:1:SomeOrg/initrd.img ksdevice=bootif lang=  kssendmac mpath text  ks=http://satellite-1.brq.redhat.com/cblr/svc/op/ks/profile/test-old:1:SomeOrg

new ks with my own distribution was also without '='
 cat /tftpboot/pxelinux.cfg/default | grep nostorage
        append initrd=/images/new-pkgs:1:SomeOrg/initrd.img ksdevice=bootif lang=  mpath text nostorage kssendmac  ks=http://satellite-1.brq.redhat.com/cblr/svc/op/ks/profile/new-ks-1:1:SomeOrg

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0498.html