Overview

The tool used to create Mer images is called "MIC" (to distinguish from obsolete MIC - Moblin Image Creator and the equally obsolete MIC2). MIC is composed of a series of tools to create images, convert images, chroot, etc. MIC is primarily based on Fedora livecd-tools and appliance-tools.

With MIC tools, users can create different types of images for different purposes, including live CD images, live USB images, raw images for KVM, VMDK images for Vmware, vdi images for VirtualBox, loop images for IVI platforms, NAND images for Moorestown platforms, ubi images for N900, fs image for MeeGo developers. Also, users can use MIC tools to manipulate images, like transforming an image from a virtual machine to a live image, and providing a chroot environment based on an existing live image. With these features, developers can do development work on a host virtual machine running MeeGo or a Meego chroot environment, and transfer the resulting new live image to a target device for final debug/verification.

Features

MIC offers these major tools:

mic-image-creator: create images.

mic-image-convertor: convert a raw/vmdk/vdi/live image into a live image.

mic-chroot: provide a MeeGo environment from a live/loop image for development, it also can translate that chroot file system into a live image.

mic-image-writer: write a MeeGo image to a USB disk. This is a safe alternative to dd.

Supports image coversion from virtual machine/live images to live images.

Uses kickstart (.ks) files for image creation. Through this, users can specify which software repositories to use, which packages to install, and basic system configuration directives. Please refer to http://fedoraproject.org/wiki/Anaconda/Kickstart for more information about kickstart configuration files.

Usage

Installation

mic is preinstalled in the Mer SDK

You should load these modules into the host if they're not loaded automatically by the kernel:
(Use lsmod to list modules.)

Of course, you need to change proxy.yourcompany.com:8888 and .yourcompany.com according to your network.

Running mic-image-creator

Configuration of images is based on kickstart, the format used for unattended installation in Fedora and Redhat.

Super user privileges are needed. The tool is more or less self-documented, use the --help option to see options.

sudo mic-image-creator --help

Creating Supported Image Types

KickStart (.ks) configuration files are passed to MIC to create tailored images. KickStart files specify what repos to pull from, what packages to include, what post-scripts to run and what type of images to create.

creating arm images needs 'qemu-arm' os 'qemu-arm-static' command available, and creating vdi or vmdk images needs 'vboxmanager' available, so be sure your system have installed them before creating these types of images.

This tells image-creator to use the kickstart file default.ks to obtain info about which packages to download and include in the image, and --cache is the directory on your local machine which will host a cache of these packages. The cache is very useful if you are remote to the server and reduces the amount of downloaded packages next time you create an image. Next time the command is run, this cache will simply be 'updated' if there are changes, rather than re-downloading from the repositories again.

The output of this command will be a file named meego-1.2-default-XX.iso created. This ISO image is a hybrid image and can be either written to a disk device or burned onto a cd.

To burn it onto a USB stick, just run the following command, assuming the USB stick is /dev/sdb in your system:

Liveusb image can be created in two different ways, interactive and non-interactive (default). When running MIC in a non-interactive mode, MIC creates a USB images file that can be copied directly into a USB stick. The non-interactive mode can be used for daily build or automated testing. The interactive mode will write the images onto a USB disk, it will detect if a USB stick is available and detects and verifies a partition is available. If two or more USB devices are present, you will be asked to select the target device. This way the contents of the existing USB stick won't be destroyed unless no appropriate partition is found, end user should use it to create the live USB.

Create Loop Image

This is the simplest image format available. Such images can be loop mounted and chrooted into, for example, to build applications or for debugging purposes.

VMDK images can be loaded into Vmware or Vmware player. MIC also generates a VMX file that has image configuration and can be used to launch the image in Vmware by just clicking the file. If you have vmplayer, it should open automatically.

KickStart Files (configuration files used for image creation)

MIC Configuration file

MIC options can be specified in a global configuration file (/etc/mic/mic.conf) and local configuration file ($HOME/.mic.conf), where you can specify:

Repository configuration

proxy settings

cache directories and

other variables

that you normally would have to re-type in your command-line.

The two configuration files have the same format, /etc/mic/mic.conf is global, no matter whoever is running MIC, this configuration file will be read first, $HOME/.mic.conf is just valid for current user, every user can have their own settings.
The final configuration is a combination of two configuration files, options in $HOME/.mic.conf will override those from /etc/mic/mic.conf. Options from command line have the highest priority.
If an option is specified on the command line, the same option in both configuration files, global and local will be ignored.

Once there is this repository info in your configuration files, and both image_format and default_ks are set, you can just run "sudo mic-image-creator" to create a image, there isn't any extra argument needed.

Use Bootstrap

MIC highly depends on yum and librpm, but different Linux distributions used diffrent yum and librpm versions, so MIC has some compatibility issues on OpenSUSE, Ubuntu and Debian, bootstrap is just for fixing these compatibility issues.

bootstrap is a minimal MeeGo file system, MIC can run very smoothly on it using chroot mode. You can use the below command to create a bootstrap:

-n is used to specify repository name, if you have its cache before, it can reduce runtime dramatically to use it with -k option, -k is used to specify your repository cache dir, -r is used to specify MeeGo main repository.

Once you created your bootstrap, you can use this bootstrap to run MIC as follows

Running mic-image-writer

mic-image-writer writes a Meego image to a USB disk as an alternative to dd.

mic-image-writer can run in both console mode and GUI mode. It can decide which mode to run, according to current system environment. You can also use a given option to force it to run in some other mode. Run 'mic-image-writer --help' to get usage information:

Usage: mic-image-writer [options] [image file]
Options:
-h, --help Show this help message and exit
-c, --console Run in console mode
-g, --gui Run in GUI mod

mic-image-writer can estimate how long it will take to write the given image to your USB disk and reports current writing progress. It automatically unmounts your USB disk, if it is mounted. If your USB can't be unmounted, it will terminate.

If you love UI mode, you can run it in X enviroment. The command with the added -g flag:

A new livecd image of meego-converted-from-raw-200902201804.iso is generated. The tool can detect the type of input image, either raw or vmdk.

This tool is very useful. For example, the developer can launch a virtual machine running MeeGo v2 and make whatever changes on the virtual system like yum install/remove a package, scp a source tarball to VM and build and try, and etc. Then with a simple "sync" or shutdown of VM, the VM image now contains his changes. With this tool, the VM image can be transformed to a live image and burned to a USB flash disk. Now developers can have final verifications in a target device, with changes in the live system.

Running mic-chroot

There are two major usage models for mic-chroot for developers.

chroot directly into the image to use it as a development environment, then optionally create a new image based off of your changes

sudo mic-chroot -c livecd meego-core-200903131337.iso

The above command would present a chroot, using the livecd image, to developers with some bind mounts like /proc /sys /dev/pts and /parentroot. With those bind mounts, developers now can easily exchange files in chroot env with host /parentroot, and conduct yum install, yum remove and any other network related operations. After done and typing "exit", a new live ISO image is created from the chroot env with the changes developers made.

Unpack and modify the image's filesystem (which you can save), and create a new image based off of your changes

Sometimes, developers want to keep the chroot env, so that they can do multiple changes in that root file system at different times. So they want to execute following:

The above command creates a folder called 'my-chroot-fs' in the current directory, using the chroot environment from the livecd image. Of course, if one forgets to add the --bind-mounts options, you'll need to manually do the bind mounting yourself. Don't forget copying /etc/reslov.conf into my-chroot-fs if you need to use DNS. Should you wish to create an image from the chroot, just execute following to create a livecd image

sudo mic-chroot -c livecd --convert-only my-chroot-fs/

Enabling Autoinstallation

You need to copy a kickstart file into /root/mic-ks.cfg which is used for
automated installation of the image. To activate autoinstall mode, boot with autoinst on the command line
or add --menus=autoinst to the bootloader directive in the kickstart file you use to
create the image.

This error occurs when MIC is unable to find the proper version of libgcc. This usually happens on x86_64 systems - MIC is looking for the 32 bit version of libgcc, but only the 64 bit version is installed. Installing the 32 bit version of libgcc should resolve this.

device-mapper issues

python related issues

from urlgrabber.grabber import URLGrabber
ImportError: No module named urlgrabber.grabber

Some people are using python they built themselves, so some python modules aren't under their python library path. For such error, only one way is not to use your own python but to use python your system installed.

debian-based distros related issues

On debian-based distros, we used pycentral to package mic, but mic source installtion used distutils, so two kinds of installation have different installation path, if they exist there at the same time, it will result in some unpredictable errors to run mic. To run it correctly, you can keep only one installation, source or binary.

Proxy cache

Some servers (such as with squid as a proxy) may cache more aggressively than
others, and as a result repomd.xml is invalid (old copy) and
references out of date metadata files (primary, comps, filelists, etc). This is
because the server is returning a cached/old copy of repomd.xml.

build btrfs image

From version 0.20.1 on, mic can support btrfs, you can create btrfs image by change fstype=ext3 in your kickstart file to fstype=btrfs. A successful creation will depend on btrfs-progs (btrfs-tools on debian-based distros, btrfsprogs on openSUSE) and btrfs kernel module in your local system, the known issue is we can't create btrfs image on Fedora 11, the issue is the default btrfs kernel module has some issue which will make kernel panic, so for this case, you must make sure you have a stable and latest kernel and btrfs-progs 0.19 on your system. You'll need to build your kernel by yourself and use it to boot your system.

Btrfs-progs is a prerequisite tool, it includes /sbin/mkfs.btrfs, but its version must match btrfs kernel module, so you must ensure this, mic repo http://repo.meego.com/MeeGo/tools/repos/ has an issue which will install btrfs-progs 0.19 when you install mic, this is an repo sync error, so please make sure you have your distro's btrfs-progs after mic is installed, if your distro's btrfs-progs version is 0.19, this isn't an issue, otherwise you must remove btrfs-progs installation introduced by mic and reinstall your distro's btrfs-progs.

How to build btrfs image on Fedora 11 or lower version?

Download kernel-2.6.34 or kernel-2.6.35

Configure btrfs as module

make; make modules; make install; make modules_install

Reboot your system using this built-newly kernel

Install btrfs-progs 0.19

Done, you're ready for creating btrfs image.

Metapackages, Patterns, and Repository Creation

Meta-packages are discouraged in MeeGo. The preferred method is to use patterns in the repository (supported by both zypper and mic). This is done by creating a patterns.xml file, which is a fairly simple XML file:

Now, GPG sign your repos/repodata/repomd.xml file. Note that `modifyrepo` is a part of the `createrepo` package.

Patterns and OBS

23:03 <@faenil> Aard, you there?
23:03 < Aard> no
23:03 <@faenil> Aard, great! I'd need a bit of revising, about patterns
23:03 <@faenil> how are they handled, and stuff like that
23:03 <@faenil> how they are*
23:09 <@faenil> alright.... :( :p
23:12 < sledges> faenil: an OBS admin points special script to a repo which has package providing patterns. then _patterns meta-package
appears in that repo
23:13 < sledges> you then mic a .ks with that repo and can use those patterns
23:15 <@faenil> sledges, so, for example, OBS admin points the script here https://github.com/nemomobile/nemo-patterns/tree/patterns-n950
23:15 <@faenil> I guess it runs the makefile in there
23:16 < sledges> faenil: admin points script to a package on OBS, not github
23:16 <@faenil> ok
23:17 <@faenil> ok, found https://build.merproject.org/package/show/nemo:devel:hw:ti:omap3:n950-n9/_pattern
23:18 <@faenil> sledges, ok so this is what happens server sude
23:18 <@faenil> what about client side
23:19 < sledges> faenil: iiyc: osc meta pattern nemo:devel:hw:ti:omap3:n950-n9
23:19 < sledges> to check they are really there
23:20 < sledges> then add pattern to .ks in form of @Pattern
23:20 < locusf> no HA patterns available on Jolla repos
23:24 < sledges> locusf: zypper search -t pattern