Archive for the 'Korora' Category

Decorating (a)kmod packages with modalias info for use with RPM

Originally posted by firnsy at Korora Project news.

Whilst developing Pharlap, our utility for easing the installation and removal of drivers, we came across a big hurdle that other distributions had seemingly solved. The hurdle was being able to identify packages that provide support for a particular piece of hardware. Our initial workarounds used a dedicated map and for a while it was sufficient but it wasn’t ideal. Over time, the frustration of it’s inelegance grew and thus began our journey to investigate a more elegant solution.

Before developing Pharlap, there was Jockey, originally ported over from Ubuntu land by Hedayat Vatankhah for his Parsidora Fedora Remix. We started to contribute to and incorporate Hedayat’s work around version 16. At this time Hedayat, proposed the integration of Jockey into the RPM Fusion repositories which was met with a level of positivity. Could this already be implemented and we just don’t know? Darn, doesn’t look like it. Let’s continue.

So I mentioned earlier that other distributions had already solved this problem and indeed they had Debian/Ubuntu decorate their kernel module packages with the modaliases that the modules provide support for. Awesome? Yes it is! That allows the higher level package utilities to query the “provides” information using a device ID of interest.

So with that in mind, we set out to identify how we could adequately decorate kmod and akmod packages with appropriate modalias information.

kmod Packages

Starting with kmod packages (more specifically those rpm packages which contain pre-compiled kernel *.ko modules) it turns out that is reasonably trivial to decorate them using the builtin pluggable fileattr decorators of RPM with some post-processed information derived from ‘modinfo’.

To achieve this first build an appropriate “what provides” decorator that can interpret our kernel module files (*.ko). Fortunately this already exists in a standard installation but for reasons I’m not entirely sure of, is not enabled. So we just copy the modalias.prov out of the /usr/lib/rpm/redhat directory as a new file /usr/lib/rpm/kmod.prov.

Here’s the file for reference.


$ cat /usr/lib/rpm/kmod.prov
#! /bin/sh
 
# heavily based upon find-suggests.ksyms by Andreas Gruenbacher .
# with modifications by Michael Brown
#
# -- added module versioning info to modalias() symbols
# -- removed code which inspects spec files.
 
IFS=$'\n'
 
#
# Initially, dont generate modalias() lines for kernel package. This needs
# additional discussion. Would like to eventually add them for
# completeness, so that we can determine when drivers are folded into
# mainline kernel.
#
case "$1" in
kernel-module-*) ;; # Fedora kernel module package names start with
# kernel-module.
kernel*) is_kernel_package=1 ;;
esac
 
if ! [ -z "$is_kernel_package" ]; then
cat > /dev/null
exit 0
fi
 
print_modaliases() {
declare class=$1 variants=$2 pos=$3
if [ -n "$variants" ]; then
echo "${class:0:pos}[$variants]${class:pos+1}"
else
[ -z "$class" ] || echo "$class"
fi
}
 
combine_modaliases() {
declare tag class variants pos n
read class
while read tag; do
for ((n=0; n<${#class}; n++)); do
if [ "*" != "${class:n:1}" -a \
"${class:0:n}" = "${tag:0:n}" -a \
"${class:n+1}" = "${tag:n+1}" ] &&
( [ -z "$pos" ] || [ $n = $pos ] ); then
variants="${variants:-${class:n:1}}${tag:n:1}"
pos=$n
break
fi
done
if [ $n -eq ${#class} ]; then
print_modaliases "$class" "$variants" "$pos"
variants=
pos=
class=$tag
fi
done
print_modaliases "$class" "$variants" "$pos"
}
 
for module in $(grep -E '/lib/modules/.+\.ko$') $*; do
# | head -n1 because some modules have *two* version tags. *cough*b44*cough*
modver=$(/sbin/modinfo -F version "$module"| head -n1)
modver=${modver// /_}
 
# only add version tag if it has a version
if [ -n "$modver" ]; then
/sbin/modinfo -F alias "$module" \
| sed -nre "s,(.+),modalias(\\1) = $modver,p"
else
/sbin/modinfo -F alias "$module" \
| sed -nre "s,(.+),modalias(\\1),p"
fi
done \
| sort -u \
| combine_modaliases

We need to plug in our new provider by adding an attribute file in the /usr/lib/rpm/fileattrs directory. To follow suit, we'll call it kmod.attr which looks like this:


$ cat /usr/lib/rpm/fileattrs/kmod.attr
%__kmod_provides %{_rpmconfigdir}/kmod.prov
%__kmod_path ^/usr/lib/modules.*\\.ko$

The two lines indicate that any kernel module captured by %__kmod_path is to be passed onto the kmod.prov decorator.

So how does it look? Here's a listing of the provides for a kmod package built with the above changes:


$ rpm -qp --provides ./kmod-wl-3.13.10-200.fc20.x86_64-6.30.223.142-5.fc20.x86_64.rpm
kernel-modules-for-kernel = 3.13.10-200.fc20.x86_64
kmod-wl-3.13.10-200.fc20.x86_64 = 6.30.223.142-5.fc20
kmod-wl-3.13.10-200.fc20.x86_64(x86-64) = 6.30.223.142-5.fc20
modalias(pci:v*d*sv*sd*bc02sc80i*)
wl-kmod = 6.30.223.142-5.fc20

Sweet, that looks exactly like what we want. So that takes care of kmods, what about akmods?

akmod Packages

Unfortunately the above method won't satisfy our initial requirement for akmods to also provide modalias information. The main reason is that akmod packages don't contain any pre-built kernel modules, they contain the source RPM from which a suitable kmod package can be built from.

Damn! Ideally, doing a "provides" search via dnf or yum should return both kmod and akmod packages.

We mentioned that an akmod package actually contains the source code and thus no directly suitable files (such as *.ko files) that can be interrogated by the fileattrs. Fortunately, akmod packages are produced by the same spec that is used to create the kmod packages and thus we have the ability to leverage some information to generate a dedicated file with sufficient information that can be interrogated for decoration at a later stage.

So looking at the typical structure of an akmod package it contains normally two files, the source RPM and a symlink to the latest source RPM (normally itself). Our proposal involves the addition of another file using similar unique naming to the source RPM (e.g. kmod-$name-$version-$release.modalias) that contains the associated modaliases that will be present when the kmod is built.

With the file in place, we can then perform a similar process to what we used for the kmod packages and ensure the decorator can process our new modalias file.

So in order to build this file, we need to unravel the complexities of how akmods are produced. I won't go into the nitty gritty but suffice to say there's a reasonable amount of magic provided by the kmodtool which does some dynamic macro creation for the kmod spec files. The final stages of these spec files, throws a call to %{?akmod_install}. It's this macro that we need to extend to create our modalias file. The following small diff is all that is needed to generate the .modalias file which we can then have picked up by an appropriate decorator.


$ diff -Nurd /usr/bin/kmodtool /tmp/kmodtool
--- /usr/bin/kmodtool 2013-12-08 04:17:24.000000000 +1100
+++ /tmp/kmodtool 2014-04-22 16:35:50.564309505 +1000
@@ -66,7 +66,14 @@
rpmbuild --define "_sourcedir %{_sourcedir}" \\\
--define "_srcrpmdir \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/" \\\
-bs --nodeps %{_specdir}/%{name}.spec ; \\\
-ln -s \$(ls \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/) \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/${kmodname}-kmod.latest
+ln -s \$(ls \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/) \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/${kmodname}-kmod.latest ; \\\
+for kernel_version in %%{?kernel_versions}; do pushd _kmod_build_\${kernel_version%%___*} ; \\\
+for module in *.ko; do \\\
+ modver=\$(modinfo -F version "\$module"| head -n1) \\\
+ modver=\${modver// /_} \\\
+ [ -n "\$modver" ] && modinfo -F alias "\$module" | sed -nre "s,(.+),modalias(\\\\1) = \$modver,p" || modinfo -F alias "\$module" | sed -nre "s,(.+),modalias(\\\\1),p" ; \\\
+done >> \$RPM_BUILD_ROOT/%{_usrsrc}/akmods/${kmodname}-kmod-%{version}-%{release}.modalias ; \\\
+popd ; done
 
%package -n akmod-${kmodname}
Summary: Akmod package for ${kmodname} kernel module(s)

With our modalias file now being created, we need to build an appropriate decorator. The astute will notice that a portion of our original decorator has made it's way into the macro diff above. This in turn allows us to simplify the final decorator which in this case we call modalias.prov and place it in the /usr/lib/rpm directory.


$ cat /usr/lib/rpm/modalias.prov
#! /bin/sh
#
# heavily based upon find-suggests.ksyms by Andreas Gruenbacher .
# with modifications by Michael Brown
#
# -- modalias file already contains modalias information and just needs to
# be sorted and combined
 
print_modaliases() {
declare class=$1 variants=$2 pos=$3
if [ -n "$variants" ]; then
echo "${class:0:pos}[$variants]${class:pos+1}"
else
[ -z "$class" ] || echo "$class"
fi
}
 
combine_modaliases() {
declare tag class variants pos n
read class
while read tag; do
for ((n=0; n<${#class}; n++)); do
if [ "*" != "${class:n:1}" -a \
"${class:0:n}" = "${tag:0:n}" -a \
"${class:n+1}" = "${tag:n+1}" ] &&
( [ -z "$pos" ] || [ $n = $pos ] ); then
variants="${variants:-${class:n:1}}${tag:n:1}"
pos=$n
break
fi
done
if [ $n -eq ${#class} ]; then
print_modaliases "$class" "$variants" "$pos"
variants=
pos=
class=$tag
fi
done
print_modaliases "$class" "$variants" "$pos"
}
 
while read FILE; do
cat $FILE
done | sort -u | combine_modaliases

We hook up the modalias decorator by adding a modalias.attr attribute file in the /usr/lib/rpm/fileattrs directory, which looks like the following:


$ cat /usr/lib/rpm/fileattrs/modalias.attr
%__modalias_provides %{_rpmconfigdir}/modalias.prov
%__modalias_path ^/usr/src/akmods/.*\\.modalias$

And the final result yields:


$ rpm -qp --provides ./akmod-wl-6.30.223.142-5.fc20.x86_64.rpm
akmod-wl = 6.30.223.142-5.fc20
akmod-wl(x86-64) = 6.30.223.142-5.fc20
modalias(pci:v*d*sv*sd*bc02sc80i*)
wl-kmod = 6.30.223.142-5.fc20

Beautiful!

OK, so what now? Well this is just the results of us investigating if it was possible and how it could be done. The above mechanism would require a diff to the kmodtool and rpm-build packages to provide the auto-decorating of modalias information on kmod and akmod packages.

Knowing that this can work, we think it might be a good time to revisit the possibilities with the RPMFusion team and see if we can make this a reality that all users of RPMFusion packages can benefit from.

Stay tuned!

Fix problem updating packages in Fedora/Korora due to broken SELinux update

Unfortunately an update to the SELinux policy package in Fedora 20 (and therefore Korora 20) caused RPM scriptlets to fail when updating packages.

This bug only affects systems that have SELinux mode set to enforcing (which is the default) and were updated to version 3.12.1-116 of the selinux-policy package. If you have seen the following sort of error when updating packages, then this bug may affect you:

warning: %post(libkcompactdisc-4.12.1-1.fc20.x86_64) scriptlet failed, exit status 127
Non-fatal POSTIN scriptlet failure in rpm package libkcompactdisc-4.12.1-1.fc20.x86_64

Below are the commands to resolve this issue (which has been fixed in an updated 3.12.1-117 version of selinux-policy).

sudo setenforce 0
sudo yum clean expire-cache
sudo yum update selinux-policy\*
sudo setenforce 1

The first command disables SELinux enforcement for the current session and the subsequent commands expire the yum cache and install the SELinux policy update which fixes this issue. The last command re-enables SELinux enforcement.

If you previously installed any packages which failed with scriptlet errors like above, you can reinstall them using the following command:

sudo yum reinstall

You can find out what packages were installed after the broken update using a command like this:

sudo sed '1,/selinux-policy-3.12.1-116/d' /var/log/yum.log

If you require any assistance please don’t hesitate to ask for help using Engage or jump onto the #korora channel in IRC freenode.net servers.

Force rsync to use delta transfer to fix corrupt remote file

We host our Korora Project ISO images on SourceForge and I (naturally) use rsync to move them there (slowly, at 100kb/sec). Sometimes though the connection drops off and that’s OK because rsync picks up where it left off.

However occasionally the ISO ends up with the wrong checksum, so something went wrong in the transfer. No amount of re-rsyncing seems to fix this up because by default it uses file size and timestamps to check whether it should skip existing files.

Fortunately, I don’t need to re-send the whole file again as rsync can perform a delta transfer instead and only send the small difference. Yay!

The way I do this is by telling rsync to use checksum. I also need to do the transfer in-place (rsync normally writes a temporary file, then moves) and not to copy the whole file (the whole-file option disables deltas), something like:
rsync -Pa --checksum --inplace --no-whole-file local.file remote.server:

Here’s a real example:
chris@x220 ~ $ rsync -Pa --checksum --inplace --no-whole-file -e ssh korora-20-i386-cinnamon-live.iso csmart,kororaproject@frs.sourceforge.net:/home/frs/project/k/ko/kororaproject/20/
 
sending incremental file list
korora-20-i386-cinnamon-live.iso
  1,715,470,336 100% 220.87MB/s 0:00:07 (xfr#1, to-chk=0/1)

So rsync just saved me 4 hours of uploading the ISO again. Thanks rsync.

Korora 20 (Peach) released

Today we released the final images for Korora Project (Fedora1 Remix) version 20 with Cinnamon, GNOME, KDE, MATE and Xfce desktops (in 32 and 64 bit).

The release was a little delayed because we were waiting for a few bug fixes to land, as well as Christmas and New Year holidays which got in the way.

We have also been hard at work building our new open source web platform which includes a replacement for our forums which is called Engage. Anyone who had an account with our old forums can log in to the new site, you will just get an email to activate your account first. Bug reports welcome!

1 Korora is not provided or supported by the Fedora Project. Official, unmodified Fedora software is available through the Fedora Project website.

Introducing Pharlap, our new driver manager replacement for Jockey

Previous versions of Korora have shipped with Ubuntu’s Jockey for installing drivers like NVIDIA and Catalyst but now we have Pharlap. Jockey has been deprecated upstream in favour of ubuntu-drivers-common, so we thought we’d see if we could make some use of that code base and create a version for Korora/Fedora+RPMFusion.

It seemed to work out well and so it’s included by default in the Korora 20 beta release, although Jockey is still available to install if you so desire. It’s much more lightweight and uses yum-daemon for package management. The packages are pharlap and pharlap-modaliases, both of which are available for Fedora 20 from the Korora repo (including source RPMs).

Pharlap, driver manager

Pharlap, driver manager

We need lots of testing on Pharlap so if you’re keen to help, we would appreciate any feedback. Hopefully at some point we can get it into RPMFusion.

Where did the name come from?

Phar Lap, great racehorse

Phar Lap, great racehorse

Well since we were replacing Jockey, we thought we’d go with a horse theme. Born in 1926, Phar Lap was a New Zealand foaled, Australian-trained thoroughbred racehorse, one of the greatest of all time. Although Phar Lap came last in his first ever race, towards the end of his career he won 32 of 35 races (coming second in two of the others he lost).

In 1932 Phar Lap raced in the Agua Caliente Handicap at Tijuana, Mexico, which was North America’s then richest race. It was his first time racing in America, his first race on dirt tracks and his first start from barrier stalls. He was last out of the gate and started ten lengths behind the leaders, but by the half-mile he was in front and then won the race by three lengths, setting a new track record.

Two weeks later Phar Lap was dead after someone poisoned him with arsenic.

So to honour this great horse, we’ve named the project Pharlap.

Korora 20 (Peach) beta released

The Korora Project is pleased to announce the first beta release of version 20 (codename “Peach”) which is now available for download.

Note: This beta release of Korora is derived from a beta release of Fedora1 and as such there will likely be a larger number of bugs and many software updates.

For the first time we are introducing an Xfce desktop, which was made possible thanks to Maik Adamietz (AKA DarkEra) and others in the community. We would also like to thank Jeremiah Summers (AKA JMiahMan) for his assistance in updating the KDE version as well as Dan Marshall (AKA dan408) for his help with the MATE release. Thank you!

Features

GNOME 3.10

GNOME 3.10 will have a number of new applications and new features that will please GNOME-lovers. This release includes a new music application (gnome-music), a new maps application (gnome-maps), a revamp for the system status menu, and Zimbra support in Evolution. A preview of GNOME on Wayland compositor is also finally available. Refer to the GNOME 3.10 announcement for more details.

KDE Plasma Workspaces 4.11

A modern, stable desktop environment, this release includes faster Nepomuk indexing, improvements to Kontact, KScreen integration in KWin, Metalink/HTTP support for KGet, and much more. Refer to the KDE Plasma Workspaces 4.11 announcement for more details.

But wait, there’s more …

Derived from Fedora 201 beta, Korora benefits from Fedora’s long tradition of bringing the latest technologies to open source software users.

A complete list with details of each new inherited feature is available at the Fedora 20 Accepted Proposals List

  • Application Installer brings a new interface for installing packages in GNOME.
  • NetworkManager should be able to configure bond master and bridge interfaces with commonly used options and recognise their existing configuration on startup without disrupting their operation.
  • Ruby on Rails 4.0, which is the latest version of well know web framework written in Ruby.
  • LVM has introduced thin provisioning technology, which provides greatly improved snapshot functionality in addition to thin provisioning capability. This change will make it possible to configure thin provisioning during OS installation.
  • Plasma-nm replaces the current network applet in KDE with a new one and bring the latest features in NetworkManager to KDE.
  • SSD Cache is updated thanks to the recent kernel to support (fast) SSD caching of (slow) ordinary hard disks.
  • VirtManager user interface for managing virtual machines has the ability to easily manage snapshots.

Contributing

We don’t build Korora inside a box. We need your help! Bug reports are especially helpful – if you encounter any issues, please report them!

Korora is a fantastic, friendly community, and we have many ways in which you can contribute. Please send us feedback in the forums or log a bug report if you have any issues. Of course you can find us on social media like Identi.ca, Twitter, Google+ and Facebook.

What is the Beta release?

The Beta release is the last important milestone before the release of Korora 20. Join us in making this a solid release by downloading, testing, and providing your valuable feedback.

Of course, this is a beta release, meaning that some problems may still be lurking. A list of the problems already known can be found at the Common F20 bugs page.

1 Korora is not provided or supported by the Fedora Project. Official, unmodified Fedora software is available through the Fedora Project website.

Korora 19.1 released

Yesterday we released Korora 19.1 which is a 3 month update to the original 19 release. Anyone already running Korora doesn’t need this, however if you are planning do any more installs we highly recommend downloading this new release as it includes all updates, a few tweaks and fixes a number of bugs. This release also includes versions of the MATE and Cinnamon desktops which we’ve created to gauge community interest.

The 19.1 release features:

  • All updates at time of release, including; KDE 4.11, kernel 3.11.2 and Firefox 24
  • Introduces support for MATE and Cinnamon desktops
  • Replaces rawtherapee raw image editor with darktable
  • Includes lzma compression, fonts-tweak-tool and gnome-documents
  • Fixes a systemd bug where the installer sometimes won’t start

MATE is a fork of GNOME 2, so if you’re pining for the old days and GNOME 3 isn’t your cup of tea, this may be for you.

Cinnamon is a fork of GNOME Shell and implements a more traditional layout with modern technology on top of GNOME 3.

MATE

korora-19.1-mate

CINNAMON

korora-19.1-cinnamon

Thank you to our community members who have helped to make this release possible.

Enjoy!

Fixing GNOME 3 freezes on SandyBridge and later Intel graphics

I had this problem in Korora/Fedora 19 and the fix appears to be enabling SNA (Sandybridge’s New Acceleration) acceleration for the card instead of the older UXA (Unified Acceleration Architecture).

It’s simple to do, just add the following contents to /etc/X11/xorg.conf.d/10-intel.conf file then restart X or reboot.
Section "Device"
  Identifier "Intel Graphics"
  Driver "intel"
  Option "AccelMethod" "sna"
EndSection

ZDNet on Korora 19, “If you make the effort to try it, you are likely to love it.”

After reviewing Fedora 19, J.A. Watson does a hands on with Korora 19.

Once installed, Korora has worked flawlessly for me. Every system, every bit of hardware, every driver — they have all worked straight out of the box. If you’re not into reading release announcements and such to find out what the differences [between Fedora and Korora] are, just install it and then browse around in the menus a bit. It includes a truly impressive array of pre-installed software, in every category. If you make the effort to try it, you are likely to love it.

Korora 19 (Bruce) released

Well, the cat’s out of the bag! Korora 19 (Bruce) is now available for download, which for the first time ever coincides with the same release of Fedora :-)

See the official Korora Release announcement for more details.