4 simple kiwi commands used to generate appliance in Suse Studio

Following are the 4 kiwi commands called by create_appliance.sh, which provided by Suse studio.

1) kiwi --prepare bootsource --root bootbuild/root --logfile boot-prepare.log
2) kiwi --create bootbuild/root -d bootimage/initrd --logfile boot-create.log
3) kiwi --prepare source --root build/root --logfile prepare.log
4) kiwi --create build/root -d image --prebuiltbootimage bootimage/initrd --logfile create.log

Following are the equivalent 4 kiwi commands run by Suse Studio internally
1) /usr/sbin/kiwi --gzip-cmd /usr/bin/pigz --prepare /studio/runner/bootsource/a29-0.0.8-vmx-x86_64
   --logfile /studio/runner/log/a29-0.0.8-vmx-x86_64/boot-prepare.log --root /studio/runner/bootbuild/a29-0.0.8-vmx-x86_64/root  --package-manager ensconce --ignore-repos
   --add-repo "http://127.0.0.1/repositories/SLES_11_SP1_x86_64" --add-repotype rpm-md
   --add-repo "http://127.0.0.1/repositories/SLE_11_SP1_SDK_x86_64" --add-repotype rpm-md
   --add-repo "http://127.0.0.1/repositories/SLES_11_SP1_Updates_x86_64" --add-repotype rpm-md
   --add-repo "http://127.0.0.1/repositories/SLE_11_SP1_SDK_Updates_x86_64" --add-repotype rpm-md

2) /usr/sbin/kiwi --gzip-cmd /usr/bin/pigz --create /studio/runner/bootbuild/a29-0.0.8-vmx-x86_64/root
  -d /studio/runner/bootimage/a29-0.0.8-vmx-x86_64/initrd --logfile /studio/runner/log/a29-0.0.8-vmx-x86_64/boot-create.log

3) /usr/sbin/kiwi --gzip-cmd /usr/bin/pigz --prepare /studio/runner/source/a29-0.0.8-vmx-x86_64 --root /studio/runner/build/a29-0.0.8-vmx-x86_64/root --ignore-repos
 --add-repo "http://127.0.0.1/repositories/SLES_11_SP1_x86_64" --add-repotype rpm-md
--add-repo "http://127.0.0.1/repositories/SLE_11_SP1_SDK_x86_64" --add-repotype rpm-md
--add-repo "http://127.0.0.1/repositories/SLES_11_SP1_Updates_x86_64" --add-repotype rpm-md
--add-repo "http://127.0.0.1/repositories/SLE_11_SP1_SDK_Updates_x86_64" --add-repotype rpm-md
--logfile /studio/runner/log/a29-0.0.8-vmx-x86_64/prepare.log 2>&1

4) /usr/sbin/kiwi --gzip-cmd /usr/bin/pigz --create /studio/runner/build/a29-0.0.8-vmx-x86_64/root -d /studio/runner/image/a29-0.0.8-vmx-x86_64 --logfile /studio/runner/log/a29-0.0.8-vmx-x86_64/create.log --prebuiltbootimage /studio/runner/bootimage/a29-0.0.8-vmx-x86_64/initrd 2>&1

Jenkins Failed to locate Cygwin installation. Is Cygwin installed?

You configured a new Windows  (64 bit) node in Jenkins  (either run as Windows servvice or JNLP or ssh) and when you try to execute a shell command from it, you may get the below mentioned error.

FATAL: command execution failedhudson.util.IOException2: Failed to locate Cygwin installation. Is Cygwin installed? at hudson.plugins.cygpath.CygpathLauncherDecorator$GetCygpathTask.getCygwinRoot(CygpathLauncherDecorator.java:122) at hudson.plugins.cygpath.CygpathLauncherDecorator$GetCygpathTask.call(CygpathLauncherDecorator.java:127) at hudson.plugins.cygpath.CygpathLauncherDecorator$GetCygpathTask.call(CygpathLauncherDecorator.java:112) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source)Caused by: hudson.util.jna.JnaException: Win32 error: 2 - null at hudson.util.jna.RegistryKey.check(RegistryKey.java:124) at hudson.util.jna.RegistryKey.open(RegistryKey.java:223) at hudson.util.jna.RegistryKey.openReadonly(RegistryKey.java:218) at hudson.plugins.cygpath.CygpathLauncherDecorator$GetCygpathTask.getCygwinRoot(CygpathLauncherDecorator.java:115) ... 11 more

You can try the fix provided in the link https://issues.jenkins-ci.org/browse/JENKINS-6992

If you are still getting the same issue, then check in your Jenkins shell, whether you have
#!/bin/bash
in the first line.
If you have this, remove it. Your shell script will work fine.

fortifyclient uploadFPR An internal error has occurred

When you try to upload a .fpr file to Fortify 360 server and you get the below mentioned error. Then, this blog provides one of the route cause info and fix.

fortifyclient -url http://some-fortify-server:8282/f360 -authtoken xxxxxxx-xxxx-xxxx-xxxx-xx1231324 uploadFPR -file myproject.fpr -project myproject -version 3.1


An internal error has occurred.
(org.springframework.oxm.jaxb.JaxbUnmarshallingFailureException: JAXB unmarshalling exception: null; nested exception is javax.xml.bind.UnmarshalException
 - with linked exception:

One of the reason this error occurs is "If the date/time on the machine where you run fortifyclient is ahead or too behind"

Solution: Set current date/time on the client machine.

Upgrading Virtual Machine hardware versions using Kiwi

In this blog, I'm providing information on upgrading the VMWare Virtual machine hardware version. Also this VM is generated using the SuSe appliance build utility - KIWI.

What hardware versions in VM's mean?

Refer the links 

   http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003746

and

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1014006

How to determine the current hardware version of a virtual machine ?

In the vSphere Client

  1) Click the virtual machine.

  2) Click the Summary tab.

  3) Find the hardware version in the VM Version field.

Upgrading hardware versions using VMWare utilities

 Refer the above mentioned links for this info.

Ugrading hardware versions in automated builds generated using kiwi (Suse Studio)

KIWI is an application for making a wide variety of image sets for Linux supported hardware platforms as well as virtualisation systems. 

We use Kiwi to build our virtual appliances. Kiwi builds appliances by referring a configuration file config.xml . To upgrade the VM machine HW version, you just need to make an entry to this config.xml file (source/config.xml  not bootsource/config.xml).

Your config.xml file may have a "vmwareconfig" section as shown below (in our case) and that describes the properties of a VM it is going to generate. Add desired HWversion field to this line as shown below (we upgraded from 4 to 7).

<vmwareconfig memory='4096' usb='true' arch='ix86' HWversion='7' guestOS='sles'>

    <vmwaredisk id='0' controller='scsi'/>

    <vmwarecdrom id='0' controller='ide'/>

    <vmwarenic mode='bridged' interface='0' driver='e1000'/>

 </vmwareconfig>

By default it was generating HW version 4 images. After adding HWversion='7', now it generated version 7 images for us. This is the working in our case.

If you don't find "vmwareconfig" section in your config.xml, then you need to deal it under "preferences" section as described in Kiwi cookbook. 

<machine arch="arch" memory="MB" HWversion="number" guestOS="suse|sles" domain="dom0|domU"/>

   <vmconfig-entry>Entry_for_VM_config_file<\vmconfig-entry>

   <vmconfig-entry .../>

   <vmnic driver="name" interface="number" mode="mode"/>

   <vmnic ...>

   <vmdisk controller="ide|scsi" id="number"/>

   <vmdvd controller="ide|scsi" id="number"/>

</machine>

Refer Kiwi cookbook for details.