Portal:KIWI/FAQ

FAQ edit

Q: Is there a GUI for KIWI ?

Yes,

• there is YaST module for kiwi called Image Creator providing graphical interaction
• SUSE Studio is a web based front end for Kiwi.

FAQ edit

Q: How can I build a 32-bit image on a 64-bit system?

Prefix your kiwi commands with "linux32", e.g.

linux32 kiwi --prepare ...
linux32 kiwi --create ...

FAQ edit

Q: Is there an appliance that contains Kiwi?

Well, Kiwi is available but not installed by default in openSUSE or SLES distributions. But you can still customise a JeOS image and add it by default.

FAQ edit

Q:How can I influence the state of services using chkconfig?

You can call chkconfig from within the config.sh script in your image descriptions.

The config.sh script is called in a chroot environment in the unpacked image. Distribution specific functions are prefixed accordingly, for example "suseInsertService".

Consult the man pages for a list of functions available in the config.sh script ("man KIWI::config.sh")

FAQ edit

Q: How can I change the keyboard layout?

The "keytable" tag within the "preferences" element in the config.xml file determines the keyboard layout of the image. Add the tag, or change the value to a keyboard layout of your liking.

<preferences>
   ...
      <keytable>us.map.gz</keytable>
   ...
</preferences>

FAQ edit

Q: Can I use YaST in the unpacked image area?

No, the unpacked image area is an incomplete root file system with important pieces missing. Any modification to the unpacked image outside of the Kiwi prepare step leads to inconsistencies between the resulting image after the create step and the image description.

It is strongly recommended to avoid any manual changes on the unpacked image.

FAQ edit

Q: Which package format can I use with KIWI?

At the moment KIWI supports the package managers smart and zypper. The package format is dependent on the selected packag manager. The table below shows the repository format supported by the two package managers.

type	smart	zypper
apt-dep	yes	no
apt-rpm	yes	no
dep-dir	yes	no
mirrors	yes	no
red-carpet	yes	yes
rpm-dir	yes	yes
rpm-md	yes	yes
slack-site	yes	no
up2date-mirrors	yes	no
urpmi	yes	no
yast2	yes	yes

FAQ edit

Q: How can I add NVIDIA and/or ATI binary drivers?

Adding these binary drivers requires changes to the boot-image. You will need to change the boot-image config.xml file for your image type, for example /usr/share/kiwi/image/usbboot/suse-xx.x/config.xml for a usb image, by adding the drivers.

<drivers type="drivers">
   <file name="drivers/nvidia/*"/>
   <file name="drivers/ati/*"/>
</drivers>

Warning: PLEASE MAKE SURE YOU WORK ON A COPY

Then you will need to modify the config.xml file for your image to point to your newly created boot-image description.

The drivers element is optional and useful only in the context of the boot image description (initrd). It is not required that a boot image is comprised of drivers and a complete kernel. Therefore, one can save significant space by only including the required drivers in the boot image. The use of the "drivers" element supports this space optimization paradigm.

When the "drivers" element is specified Kiwi will include only the drivers matching the specified file name or glob pattern in the boot image. Kiwi will search pre-defined directories for matching drivers based on the "type" attribute value as listed below.

• drivers

Each file is specified relative to the /lib/modules/<Version>/kernel directory.

• netdrivers

Each file is specified relative to the /lib/modules/<Version>/kernel/drivers directory.

• scsidrivers

Each file is specified relative to the /lib/modules/<Version>/kernel/drivers

• usbdrivers

Each file is specified relative to the /lib/modules/<Version>/kernel/drivers directory.

The provided information in the "drivers" element will only take effect if a images.sh script exists in the boot-image description and the function suseStripKernel is called from the script.

FAQ edit

Q: How can I create an encrypted password for use in the config.xml file?

The password can be created using

kiwi --createpassword

on the command line. This process is interactive and you will be prompted to enter a password.

The output is an encrypted string for the plain text password you entered. You can cut and paste this string into the config.xml file as the value for the "pwd" attribute of the "user" element.

FAQ edit

Q: When booting from the network via PXE the following message is displayed

Found TFTP server in kernel cmdline
Checking TFTP server name: 192.168.0.10
TFTP server: 192.168.0.10 not found
Using TFTP server from dhcp-info

In this case the address given by the "kiwitftp" kernel parameter cannot be resolved and the address of the DHCP server is used for TFTP server as well.

This default behavior could potentially be incorrect. However, there is no risk with this behavior. The client already receives data from the DHCP server and therefore it should be permissible to receive additional data from the same server.

If the tftp server is not running on the DHCP server the image download will fail. It is recommended to provide the tftp server address in the pxelinux configuration file, even if it is the same address as the DHCP server.

FAQ edit

FAQ edit

Q: How to build a JeOS with a graphical firstboot

Use the JeOS template and in order to enable the SUSE feature "firstboot" you need the file config-yast-firstboot.xml in you config-directory.

It could be a copy from /etc/YaST2/firstboot.xml which is included in the the package yast2-firstboot-2.17.4-1.64

Please enable your needed steps in the workflow http://forgeftp.novell.com/yast/doc/SLES11/tdg/bk09ch01s02.html

You _DON'T_ need to create the file /var/lib/YaST2/reconfig_system! This is done by KIWI

In order to use firstboot, please add the following packages in your config.xml

 yast2-ncurses
 yast2-firstboot

If you want a graphical firstboot system you need additionally the following packages in your config.xml

 yast2-installation
 yast2-qt
 xorg-x11-server

You also need and a simple xorg.conf in the directory which is provided by our template

 <your_kiwi_config_dir>/root/etc/x11

Here as reference:

 /usr/share/kiwi/image/suse-SLE10-JeOS/root/etc/X11/xorg.conf

You may copy your own scripts into the directory

 /usr/share/firstboot/scripts

If you want to reconfigure your keyboard with firstboot, you need the packages

 sax2-tools
 sax2-ident
 kbd

That's it - now you should have a graphical firstboot with JeOS

FAQ edit

Q: Can i build a SLE10 image with openSUSE 11.x and later or SLE 11 and later?

Yes, but you need the appropriate tools installed on your build system and the repositories for SLE10 (DVD/iso/...)

Zypper from SLE10 is too old and does not provide the features we need. So you must use smart as packagemanager in your config.xml

<packagemanager>smart</packagemanager>

In order to use it, you must install smart in you build system.

So please add the repository to your system http://download.opensuse.org/repositories/system:/packagemanager/ and install smart into your system.

If you are use kiwi version < 3.60 and use ext3 as filesystem, you must use a different inode size, because openSUSE 11.1 uses a different one as SLE10.

--fs-inodesize 128

Tip: Use the SLES10 JeOS template as basis for your build

FAQ edit

Q: I got the error "dbus is not running, check your installation" at login

Please add the following package to your config.xml

 <package name="dbus-1-x11"/>

FAQ edit

FAQ edit

Q: Where can I request enhancements, report bugs or submit patches?

1) Searching the list archives is your best starting point. Should you be unable to find an answer to your question in the archives, you can post to the mailing lists after subscribing.

• Developers: kiwi-devel@lists.berlios.de
• Users: kiwi-users@lists.berlios.de

2) There is an IRC channel on freenode

• IRC: #opensuse-kiwi on irc.freenode.net

3) You may file bugs using the openSUSE bugzilla (a Novell account is required)

• Classification: All
• Product: openSUSE.org
• Component: System Imaging
• Summary : "kiwi: summarize your report here"

• Convenient URL to file new KIWI bug (with the settings above)

FAQ edit

TIP: SUSE Studio

You may also want to visit the SUSE Studio Wiki. KIWI is the back end to SUSE Studio and therefore many of the SUSE Studio Howtos apply to KIWI

FAQ edit

Q: How could i get an list of packages from an installed system for using it in KIWI

An easy way would be

rpm -qa --queryformat "\<package name=\"%{NAME}\"/\>\n" >rpms.txt

That will produce a list of all rpm's installed in the following format;

<package name="kernel-xen"/>

You can then simply open up your config.xml file and paste the content of rpms.txt in between the following two tags;

<packages type="image">
</packages>

FAQ edit

TIP: Hybrid Live Systems

( from http://lizards.opensuse.org/2009/08/05/hybrid-live-systems/ by marcus )

When talking about live systems on USB sticks people reported many problems with bootloaders like grub to boot the stick. Even though this is most often a problem with the stick hardware or the PC BIOS it’s an annoying situation which should have a better solution. There are also many people who wants to use the stick as a data container in combination with a live system to work with

With the ISO hybrid technology and the integration into kiwi there is a way to create such a stick very easily. A hybrid ISO is an iso filesystem which contains a MBR and thus it’s seen as a disk to the PC BIOS. As it’s an ISO the isolinux bootloader is used instead of grub which works better on many systems. Additionally the hybrid ISO can be used as a live system on CD/DVD as well as on a USB stick.

What’s required to use this

   * kiwi v3.68 or later
   * syslinux-3.82-2.1 or later

How do I setup a hybrid ISO in kiwi

In order to activate the creation of a hybrid iso in kiwi you only have to add the hybrid=”true” attribute as part of your iso image type in config.xml:

<type boot="isoboot/suse-11.2" flags="clic" hybrid="true">iso

You can use the suse-11.2-JeOS from the kiwi-templates package as example image description for your hybrid testing. The generated .iso file can be dumped via a simple dd call onto the USB stick. The same file also can be used to be burned on a CD/DVD

dd if=LimeJeOS-openSUSE-11.2.i686-1.11.2.iso of=/dev/... bs=32k

After that the stick can be tested. By default all attempts to write data will go into the RAM of the system. As a stick allows storing data persistently you can create a write partition on the stick using fdisk:

fdisk /dev/...

kiwi will prevent using a vfat partition for the operating system. So make sure you create a 0×83 (linux) type partition and not a vfat partition for the write support. If you additionally create a vfat partition you can use it as a container for any kind of data independently from the live system. We choose vfat here to stay compatible with Windows systems.

Known bugs

• when using the clicfs filesystem (flags=”clic”) the persistently write feature into a single partition will fail because clicfs currently can’t deal with raw block specials as cow device. Will be fixed as soon as possible

Have fun :-)

FAQ edit

Q:Using Kiwi suse-ec2-guest on OpenSuSE 11.4 x86_64 errors on AMI startup when Updating AMI tools

I used Kiwi to create a openSuSE 11.4 AMI which boots up great if I show the console on AWS, but it looks like it fails to create the SSH keys properly with:

ec2:failed to retrieve ec2-ami-tools from S3
ec2:unable to update ec2-ami-tools
ec2:failed
ec2:BEGIN SSH HOST KEY FINGERPRINTS
ec2:/etc/ssh/ssh_host_key.pub: no such file or directory
ec2:/etc/ssh/ssh_host_dsa_key.pub:no such file or directory
ec2:/etc/ssh/ssh_host_rsa_key.pub: no such file or directory

I also tried creating the keys locally after running kiwi 'prepare' by mounting the image in a chroot and manually running ssh-keygen to try to obtain the keys this way. then running kiwi create, which does give the keys, but still fails to update AMI tools or allow remote SSH.

SSH is authorised on the AWS firewall, and if I install apache2 package I can connect to that, so host is definitely 'responding'.

- Any ideas what I have missed?

FAQ edit

Q: How may I debug problems during Kiwi startup

Debugging problems that show up when Kiwi is starting a system require some special tricks. The first is to command Kiwi to create a debugging console by adding the string "kiwidebug=1" to the boot options line. When Kiwi fails, use CTRL-ALT-F2 to switch to that console, which will make a limited shell available. Use CTRL-ALT-F1 to return to the main console.

The Kiwi debug shell does not have a pager such as less, thus it is difficult to use it alone to examine the Kiwi boot log found at /var/log/boot.kiwi. For this reason, it is usually better to start the Kiwi boot process in a virtual machine (VM) created by qemu (32-bit only) or qemu-kvm (32- or 64-bit systems) where the -serial option may be used to transfer the content of the log file back to the host where a full set of tools is available.

In most cases, the image being booted will be a CD such as a KDE or Gnome Live CD. To start the VM use one of the two following commands:

qemu-kvm -serial stdio -cdrom <path to image to be booted>
qemu-kvm -serial file:<path to saved file> -cdrom <path to image to be booted>

The first form of the command will log any data output from debugging to the terminal used to start qemu-kvm, while the second will write it to a file on the host.

When debugging in a qemu VM, the CTRL-ALT-FX keystrokes are captured by the host, and a few extra steps are required. First, switch to the qemu command console by using CTRL-ALT-2. From there you can switch to the Kiwi debugging console using the command

sendkey ctrl-alt-f2

Pressing CTRL-ALT-1 returns you to the VM.

For serial output in the VM to reach the host, debugfs must be mounted - a step not well documented in other tutorials. To do this, use the command

mount -t debugfs /dev /dev

At this point, you can capture the log file using

cat /var/log/boot.kiwi > /dev/ttyS0