Michal Marek – openSUSE Lizards

Mounting /usr in the initrd

Wed, 03 Aug 2011 15:41:06 +0000

Hi,

I changed the openSUSE mkinitrd to mount the /usr filesystem in the initrd, if /usr is a separate partition. I hope this will calm down some heated discussions about systemd, udev, etc. It’s not 100% ready yet, some setups like root or /usr on nfs or md might not work as expected (*), but the common usecases should be covered. Try updating mkinitrd from the Base:System project and let me know if it works for you. Before testing it, you should do a backup of your initrd:

# cp /boot/initrd-`uname -r`{,.orig}

and create a section in /boot/grub/menu.lst pointing to the /boot/initrd-*.orig file.

]]>

Improved Kernel Package Retention in 12.1

Thu, 14 Jul 2011 13:38:14 +0000

A long awaited feature of the openSUSE update stack is finally here!
Since some time, it has been possible to tell libzypp to not delete old
kernels on update:

multiversion = provides:multiversion(kernel)

in /etc/zypp/zypp.conf. That way, you don’t have to worry that a
brand new -rc kernel from Factory makes your system unbootable. This however
solves one problem and brings another one – you have to manually delete the
old kernel so that your /boot partition does not fill up. openSUSE 12.1 will
provide a solution to this, you will be able to tell what kernels you want to
keep after an update, other kernels will be deleted. The configuration is the
same file, /etc/zypp/zypp.conf:

## Comma separated list of kernel packages to keep installed in parallel, if the
## above multiversion variable is set. Packages can be specified as
## 2.6.32.12-0.7 - Exact version to keep
## latest        - Keep kernel with the highest version number
## latest-N      - Keep kernel with the Nth highest version number
## running       - Keep the running kernel
## oldest        - Keep kernel with the lowest version number (the GA kernel)
## oldest+N      - Keep kernel with the Nth lowest version number
##
## Default: Do not delete any kernels if multiversion = provides:multiversion(kernel) is set
multiversion.kernels = latest,running

If you configure this and the above multiversion variable, then after each
kernel update, during a subsequent reboot, a script will compare the list of
installed kernels with the multiversion.kernels setting and delete those that
are no longer needed. Examples:

Keep the latest kernel and the running one if it differs. This is similar to
no enabling the multiversion feature at all, except that the old kernel is
removed after reboot and not immediatelly after installation. BTW, you
probably always want to include “running”:
```
multiversion.kernels = latest,running
```

Keep last two kernels and the running one:

multiversion.kernels = latest,latest-1,running

Keep the latest kernel, the running and a my test kernel with a fancy
patch:
```
multiversion.kernels = latest,running,3.0.rc7-test
```

If you want to try it, it’s all in Factory already. Check if these packages are
recent enough and uncomment the two variables in zypp.conf:

$ rpm -q --changelog kernel-desktop mkinitrd libzypp | grep -B2 312018
* Fri Jun 17 2011 mmarek@suse.cz
- rpm/post.sh: Touch /boot/do_purge_kernels on package install
    (fate#312018).
--
- Add purge-kernels script to automatically delete old kernel packages
  on boot, based on configuration in /etc/zypp/zypp.conf, variable
  multiversion_kernels (fate#312018).
--
* Tue Jun 21 2011 dmacvicar@suse.de
- Add configuration template for automatic kernel
  purge (feature#312018) to zypp.conf
$ grep ^multiversion /etc/zypp/zypp.conf
multiversion = provides:multiversion(kernel)
multiversion.kernels = latest,running

Happy updating!

]]>

Boo

Fri, 28 Jan 2011 15:34:14 +0000

Arts, buffer, check, clutter, cobbler, colorblind, concurrent, convert, cook, crash, dialog, dump, expect, file, folks, fortune, genius, global, hello, indent, less, links, meanwhile, mirror, screen, sparse, suck, tree, units, words. What do these ordinary English words have in common? They are also names of software projects, which becomes a problem if you want to recognize package names in text. I understand that in the old days, the name of a command or application was only relevant in the context of the computer it ran on, and file names had to be short. Some of these names have allowed for a variety of jokes. But why, in the age of portable programs, WWW and search engines, can’t people come up with less ambiguous names? I mean, it’s not hard to join two words, or, at a minimum, prefix a word with a vowel, like, uhm, a round fruit does.

Oh, and did I mention that we have over 160 packages with a 2-3 letter name? The one mentioned in the title is a programming language, btw.

]]>

Another openSUSE kernel git repo

Tue, 14 Sep 2010 14:53:10 +0000

The mirror of the openSUSE kernel-source repository has been around for several months already, now there is something new: A repository that is actually usable :-). The current kernel-source repository is a series of patches managed in git, which has some upsides, like the ability to easily cherry-pick a patch and port it to a different branch or send it upstream. But it is quite painful if you want to work with the code itself and not with patch files. A task as simple as determining if drivers/…/foo.c in openSUSE-11.3 has or does not have a certain change requires checking out the branch and running the sequence-patch script to be able to look at the file. If you need to know when was the file changed, you have to run ‘quilt patches ’ to find out what patches touched the file and then ask git about the history of these patches. Neither convenient nor efficient. That’s why we have a second repository, that contains the mainline tree with all the suse patches applied. It’s located at http://gitorious.org/opensuse/kernel, the clone url is git://gitorious.org/opensuse/kernel.git. If you already have a clone of the mainline tree, then you can download just the differences with

git remote add suse git://gitorious.org/opensuse/kernel.git
git remote update suse
git checkout suse/master

The above task is then solved by opening the required file in an editor or typing ‘git show branch:file’. And you don’t even need to clone the tree to quickly check something in the source, just use the web viewer. Also, bisecting is much easier, because you avoid the sequence-patch step now. There are some gotchas though:

Not every commit to the kernel-source repository results in a change in the kernel repository. For instance updating config files in the kernel-source repository results in a commit that has no text changes. The gitorious viewer is confused by this and tells you that you are viewing the initial commit. In a local clone, you can exclude such commits with ‘git log .’ (note the dot).
When the patch series does not apply, there isn’t much to show in the kernel repository. In such case, the commit only adds a ‘BROKEN’ file to the toplevel directory and uses the tree from the previous commit. When using a bisect script, you can skip such commits with e.g. ‘test -e BROKEN && exit 125’.
When patches such as xen are temporarily disabled while updating to newer upstream versions and later enabled, it generates huge diffs back and forth. That’s usually not a problem unless you are bisecting something xen-related.

Anyway, I’m sure this will be useful for anyone who needs to debug something in the openSUSE kernel.

]]>

Accessing the Build Service from Eclipse

Wed, 13 Aug 2008 10:50:22 +0000

One of this year’s Google Summer of Code projects is a an Eclipse plugin to access the Build Service, developed by Long Hong from Beijing. If you are interested, read on.

While there are still issues to be solved, I think it’s in a state that everybody can try it out. Grab a package from my home project, launch eclipse and open the Build Service perspective. Please note that the package itself is a bit experimental and was only tested to work on openSUSE 11.0. Enjoy!

]]>

Trick of the Day: Reboot as User

Fri, 18 Jul 2008 13:25:12 +0000

$ reboot -bash: reboot: command not found $ /sbin/reboot reboot: must be superuser.

In KDE / GNOME, you can just click reboot in the menu and your session sends a message to display manager, which runs as root and does the dirty job of rebooting or shutting down your machine. Unfortunately, things are not that easy if you are using a simpler window manager or want to shutdown from a script. Sure, there is sudo, but that has to be configured first to work without password. Luckily, after a couple of hours of googling (only to find helpful advice as “this can be done easily with ConsoleKit or hal”), reading documentation of dbus, {Console,Policy}Kit and hal and clicking in qdbusviewer, I finally found a way with hal+dbus:

$ dbus-send --system --dest=org.freedesktop.Hal \
  --type=method_call --print-reply \
  /org/freedesktop/Hal/devices/computer \
  org.freedesktop.Hal.Device.SystemPowerManagement.Reboot

To shutdown, just replace Reboot with Shutdown. I’m going to add this to the default icewm configuration, so that the logout menu finally works.

]]>

learning ruby…

Mon, 26 May 2008 16:26:23 +0000

Recently, I wanted to show how the buildservice makes packaging easier by creating a specfile template for you (just click the “Create RPM SPEC file templat” checkbox when creating a new package). Unfortunatelly, the template it creates is not really useful for someone not skilled in writing spec files. Also, it’s just a static template, so you have to write the summary and description even though you have just entered both in the web form. Definitely nothing to show off to newbies ;-). But knowing that the buildservice developers have more important stuff to do, and wanting to learn something new, I decided give it a try and fix it myself.

My idea is: The buildservice api asks a set of questions, which are presented by the client (webclient, osc, …) to the user, and creates a specfile based on these questions. Also, the api tries to suggest good defaults where possible. After spending some time learning ruby, rails and the api code, I have an ugly 200 line patch to the api that generates a working specfile for GNU hello ;-).

The user interface part is not yet done, but should be easy. What’s more chalenging is adding heuristics to “do the right thing”: detecting the build system (autotools, cmake, Makefile.PL, etc), detecting build dependencies, and so on. Right now, it only extracts the version number from the tar name.

]]>