Home Home > Base-system > Architectures
Sign up | Login

Archive for the ‘Architectures’ Category

How I ran openSUSE on a Nexus 7

September 22nd, 2013 by

The Nexus 7 (2012 version) is a 7 inch tablet by Google+Asus.
The nice thing about it is, that it has an unlockable bootloader. Also it has an armv7 CPU and we built openSUSE for this CPU for some years. I had one such device with a broken display, so doing some more risky things with it seemed to be appropriate.
I wanted to run my own software on it. Running openSUSE in a chroot (change-root) environment is usually a lot easier than replacing the whole system, so this is where I went.

First, I needed two tools. One is the “adb” – Android DeBug tool from the official sdk and the other is “fastboot” which was hard to find, so I mirror it here.
I got me the stable ROM from http://wiki.cyanogenmod.org/w/Grouper_Info and followed their installation instructions. adb shell only seemed to work while in bootloader (which you reach by holding Volume-Down+Power during boot)
The hardest part was to re-enable USB-debugging by going into Settings/About tablet and tapping Build-Number seven times.

Also before zapping everything that was there, I did in adb shell : cp -a /system/app /sdcard/
and back later.
So after following all the other installation steps, I had cyanogenmod booting. I attached a bluetooth keyboard so that I can better type. The ROM comes with a terminal app, which I opened. type su - to become root after a security popup.
Now, I downloaded my lastest Raspberry-Pi image from http://www.zq1.de/bernhard/linux/opensuse/. This is under /sdcard/Download where I unpacked it with xz -d
Then comes the tricky part. The image has a partition table, but here we just need the root filesystem. With fdisk -lu we can see that it starts at sector 309248. One could copy out that part with dd or use a loop device with offset like this:
mknod /dev/loop0 b 7 0
losetup -d /dev/loop0 # cleanup of previous try
losetup -o `expr 512 \* 309248` /dev/loop0 rasp*img
mkdir -p mnt
mount -t ext2 /dev/loop0 mnt

Now we have access to the openSUSE files under mnt.
In there I created me a chroot.sh:
for m in proc sys dev ; do mount -o bind /$m $m ; done
HOME=/root PATH=/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/X11R6/bin /system/xbin/chroot . bin/bash
for m in proc sys dev ; do umount $m ; done

With that, the only remaining thing to do was to add a nameserver line to /etc/resolv.conf before I could use zypper to install software e.g. zypper install yast2-network yast2-ncurses.
Running yast lan on the Nexus 7 gives nice sight.

I guess one could also use the armv7 rootfs to have software built for armv7 instead of the compatible armv6. But for me it does not matter much.

New Raspberry Pi Image

September 7th, 2013 by

update: new image with kernel-3.6 and minimal X11/icewm http://www.zq1.de/~bernhard/linux/opensuse/raspberrypi-opensuse-20130911x.img.xz (103MB)

We got a new armv6 based image for the Raspberry Pi.
This one is only 82MB compressed, so pretty minimalistic.


The exciting new thing is that this was created using an alternative image building automatism which I wrote from scratch in three hours this morning.
The scripts can be found at


and are also embedded within the image under /home/abuild/rpmbuild/SOURCES/

This means that everyone can now easily build his own images the way he likes and even branch and do submit requests for changes that are useful for others.
The way to use this is simple.
If you have 6GB RAM, you can speed things up with export OSC_BUILD_ROOT=/dev/shm/arm before you do
osc co devel:ARM:Factory:Contrib:RaspberryPi altimagebuild
cd devel:ARM:Factory:Contrib:RaspberryPi/altimagebuild
bash -x main.sh

This pseudo-package does not easily build within OBS or osc alone because it needs root permissions for some of the steps (chroot, mknod, mount), which could only be workarounded with User-Mode-Linux or patching osc.
The build consists of three steps that can be seen in main.sh:

  1. First, osc build is used to pull in required packages and setup the armv6 rootfs.
  2. Second, mkrootfs.sh modifies a copy of the rootfs under .root to contain all required configs
  3. And finally, mkimage.sh takes the .root dir and creates a .img from it that can be booted

This can build an image from scatch in three minutes. And my Raspberry Pi booted successfully with it within 55 seconds.

There are some remaining open issues:

  • the repo key is initially untrusted
  • still uses old 3.1 kernel – solved
  • build scripts have no error handling

Compared to the old image, this one has some advantages:

  • It is easier to resize because the root partition is the last one
  • Compressed image is much smaller
  • Reproducible image build, so easy to customize
  • It is armv6 with floating point support, so could be faster
  • We have over 5200 successfully built packages from openSUSE:Factory:ARM
    so for example you can install a minimalistic graphical environment with zypper install xauth twm xorg-x11-server xinit and start it with startx

So if you wanted to play with openSUSE on RPi, you can do so right now and have a lot of fun.

openSUSE 12.3 on Android

May 9th, 2013 by

Here is a new image for your armv7l powered phone or tablet(any recent dual core device should work), you can get openSUSE 12.3 XFCE running on it without the need for repartition, formats, bootloader hacks or sacrificing your nicely running latest android on it. What you need is rooted device with busybox, Android VNC and terminal app installed and 4GB free space on sdcard(internal or external).

Instructions to run it are same as mentioned earlier. In addition to those you can also use LinuxonAndroid app with patched bootscript.sh. Replace /data/data/com.zpwebsites.linuxonandroid/files/bootscript.sh on your device with the patched one and follow the directions shown here(last 3 images):

openSUSE on android

openSUSE on phones/tablets

February 20th, 2013 by

Thanks to the fantastic work by openSUSE Arm team, you can get full desktop on your armv7l powered phone or tablet(any recent dual core devices should work), without the need for repartition, formats, bootloader hacks or sacrificing your nicely running latest android on it. What you need is rooted device with busybox, Android VNC and terminal app installed and 4GB free space on sdcard(internal or external).


December 27th, 2012 by

As few of you might know, I made my own SUSE-based LiveCDs a while ago, using (like Knoppix) cloop compression with iso9660 and my own kernel code for file-based overlay to make it writeable. You might be amazed at how fast it runs in KVM. However, the kernel part has bit-rotten and there are other techniques out there today, so I took a look around at how others do their LiveCDs.

But first some broader overview. To make a LiveCD, the biggest problem is that CDs are not writeable (and even modern Flash devices do not want to be written too much). Embedded devices using flash had the same problem. Various approaches have been used in the past to solve this:

  • adapt all software to write into ram-disks e.g. by having symlinks (hard to create and maintain)
  • load all software into RAM (only for small distributions)
  • use file-based overlaying such as unionfs or aufs to have software write into RAM (lsof, pwd, and hardlinks can be tricky)
  • use block-based overlaying (problem: can not easily free disk space again)

Also compression is used to fit more onto a CD. And interestingly, this usually also speeds up booting because it is faster to read 10MB off a CD and decompress it into the original 30MB than to read 30MB from such a slow medium.

Now, to the distributions.

  • openSUSE has the classic DVD installs that use special installation-images and run in RAM and then there are the real LiveCDs that are created by our kiwi tool, use block-based overlaying and LZMA compression of a ext3 by means of our FUSE-based clicfs.
  • All of the other distributions use squashfs for compression. Mageia employs dracut for initrd and unionfs for file-based overlaying
  • Debian uses aufs for file-based overlaying
  • Ubuntu uses overlayfs for file-based overlaying
  • Fedora uses an ext4 filesystem image contained in a squashfs with dm-snapshot for block-based overlaying, thus being most similar to openSUSE

I also spent some time benchmarking (on my AMD A10-5800K) the various technologies with a simple script using Debians uncompressed rootfs of 495132 KiB as data.
squashfs supports three different compression methods: lzo, gzip and xz (aka LZMA).

  • squashfs-lzo: size:220992 compression:11.1MB/s decompression:134.4MB/s
  • squashfs-gzip: size:203328 compression:15.5MB/s decompression:88.9MB/s
  • squashfs-xz: size:176064 compression:6.5MB/s decompression:22.5MB/s
  • cloop(gzip): size:213348 compression:16.2MB/s decompression:49.6MB/s
  • clicfs(xz): size:185300 compression:16.7MB/s decompression:18.2MB/s

This has some surprises: even when using the same compression method, sizes can differ by 5% and speed can differ even more.

If you want to compare numbers on your system, memory throughput is also interesting:
# dd if=/dev/zero of=/dev/null bs=1M count=100000
104857600000 bytes (105 GB) copied, 12.4499 s, 8.4 GB/s

Overall, clicfs is performing OK, considering that it already takes care of the overlaying, but for my own LiveCD I would prefer Debian’s method and I am wondering how it would work.

Linux Kernel built with clang boots into openSUSE

July 14th, 2012 by

Whatch this:  http://youtu.be/Jp04DMXH2Rg

The kernel was compiled with Clang (C frontend of LLVM)  and boots into a running openSUSE desktop!


openSUSE ARM image

January 21st, 2012 by

When I wrote this week, how I ran openSUSE on my genesi smarttop some people asked for a ready-to-use image. After spending less than 8 hours fiddling with u-boot-scripts, partition tables, tuning ext3 and initrds, it was done… and is now so easy:

wget http://www.zq1.de/efika.img.xz # 83MB
xz -cd efika.img.xz | dd of=/dev/sdX bs=1M

with sdX being the device name of your SD-card (e.g. “mmcblk0″ on the smarttop itself) with at least 1GB (actually 1024000000 bytes) of free space.

When inserted at boot, it should just boot up within 23 seconds and let you login as root with password “linux” on SSH, serial and with a USB-keyboard on HDMI. I spent some effort on putting as few packages as possible into it. Still, you have zypper to install packages and nano to edit files.

There is still a known hangup when you try to reboot. Workaround is: init 2 ; sleep 12 ; killall rsyslogd ; umount /boot/ ; mount -o remount,ro / ; reboot

As it still uses the original linux-2.6.31 kernel, it has another bug that also happens with pre-installed Ubuntu: sometimes (in ~40% of cases), boot stopps early, before graphics is initialized, when the last line on serial is “console handover: boot [ttymxc0] -> real [tty1]“. Try turning it off and on again.

This should allow you to have a whole lot of fun…

running openSUSE on ARM

January 19th, 2012 by

This week I finally got my genesi efika MX box. By default it has on old Ubuntu version installed on its internal IDE-attached 8GB SSD. It features 512 MB RAM and a 800 MHz ARMv7 CPU.

Using a HDMI-cable and an HDMI-DVI-Adaptor I got it connected to a monitor, plugged in a USB keyboard+mouse and it pretty much worked out of the box with WLAN,Ethernet,X11 (except for a bug that causes it to force you to change PW on every console login). How boring.

Having read about recent progress with openSUSE on ARM I wanted the excitement of running it on this box.

Michal’s image and script (now in alpha) was very helpful to get me started within 15 minutes.

If you have any (e.g. x86) openSUSE system running, there is another easy way to create a working ARM chroot-environment:

zypper ar http://download.opensuse.org/repositories/openSUSE:/Tools:/Unstable/openSUSE_12.1/openSUSE:Tools:Unstable.repo
zypper install qemu osc
osc co openSUSE:Factory:ARM bash
cd openSUSE:Factory:ARM/bash
edit bash.spec # add lines with your packages like BuildRequires: zypper,vim
osc build –no-verify –clean standard armv7l

If it worked well, /var/tmp/build-root/ should contain a chroot environment. E.g. you can run

file /var/tmp/build-root/bin/bash
/var/tmp/build-root/bin/bash: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, BuildID[sha1]=0xed9ca12f44c8591560d780cf807b6b6cf8ca8873, stripped

I partitioned my SD-card into two partitions. The first one for /boot with ext2 (needs only 150MB) and the second one for / to contain the rootfs. Be sure to have barrier=0 in your fstab for all ext[34] partitions so that writing to SD will not be as slow. The default U-Boot configuration first checks on the first partition of an SD-card for boot.scr which is a uImage-formatted version of a U-boot script. I copied all of Ubuntu’s /boot and /lib/modules/, slightly adapted their boot.script file to have root=/dev/mmcblk0p2 and uImage/uInitrd- as kernel/initrd, dropped “quiet splash” and added “console=ttymxc0,115200″ to see more of the boot and ran a line from another helpful site:

mkimage -A arm -O linux -T script -C none -a 0 -e 0 -n “my boot script” -d boot.script boot.scr
echo mxc0:S12345:respawn:/sbin/agetty -L 115200 ttymxc0 vt102 >> /etc/inittab # for serial console

However, this failed to boot. Using the serial debug console, I could see U-boot trying to load the boot.scr but it was thinking it was zero bytes for some strange reason. Re-creating my /boot partition as a raw copy of /dev/sda1 with my adaptions ontop finally gave me an SD-card that just boots openSUSE Factory on ARM with framebuffer console on HDMI/DVI.

Find more ARM-related info on our openSUSE ARM Portal

fuk the kit you will love

January 19th, 2012 by

Dear fellows, in our moving free world, it’s not always bienvenue to talk about one of the *kit* software around.
Most of them have bad reputation, (with good or bad reasons) this is the debate of this post.

But in the uni-kit-verse there’s one you must known, especially if you are the proud owner of a laptop or one of this computer the manufacter deliver its firmware only in DOS exe format.
FirmwareUpdateKit (was introduced in 2008 in openSUSE by Steffen Winterfeldt

How that works?

As the title of the post give you the right command, open a console, then use the cnf (command-not-found) tool to learn what to do

Install the package

cnf fuk

The program 'fuk' can be found in the following package:
  * FirmwareUpdateKit [ path: /usr/bin/fuk, repository: zypp (repo-oss) ]

Try installing with:
    zypper install FirmwareUpdateKit

Pretty clear and cool, let’s install that stuff!

sudo zypper install FirmwareUpdateKit
root's password:
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW packages are going to be installed:
  FirmwareUpdateKit syslinux 

2 new packages to install.
Overall download size: 758.0 KiB. After the operation, additional 2.1 MiB will be used.
Continue? [y/n/?] (y): y
Retrieving package syslinux-4.04-12.1.3.x86_64 (1/2), 642.0 KiB (1.9 MiB unpacked)
Retrieving: syslinux-4.04-12.1.3.x86_64.rpm [done]
Retrieving package FirmwareUpdateKit-1.1-14.1.1.x86_64 (2/2), 116.0 KiB (178.0 KiB unpacked)
Retrieving: FirmwareUpdateKit-1.1-14.1.1.x86_64.rpm [done]
Installing: syslinux-4.04-12.1.3 [done]
Installing: FirmwareUpdateKit-1.1-14.1.1 [done]

Firmware Update

Get your bios

Nothing easy for that, you will have to surf on boring mfg website, and find an appropriate bios for your computer.

Be serious during that selection, you can screw up totally your computer

Time to fuk

As always before running a program, it’s always good to check if there’s the fine manual (not the case here) or try a -h –help

fuk --help
Usage: fuk [OPTIONS] FILES
FirmwareUpdateKit version 1.1.

Create bootable DOS system and add FILES to it.
The main purpose is to assist with DOS-based firmware updates.

  --grub                        Add boot entry to /boot/grub/menu.lst.
  --lilo                        Add boot entry to /etc/lilo.conf.
  --title TITLE                 Use TITLE as label for boot menu entry.
  --iso FILE                    Create bootable CD.
  --floppy FILE                 Create bootable (1440 kB) floppy disk.
  --image FILE                  Create bootable harddisk.
  --run COMMAND                 Run COMMAND after booting DOS.
  --verbose                     Be more verbose.

Nothing complicated as a nuclear plan here, everything seems to be self explicit.
Let try it, and install a new grub entry for the new A8 version for my lappy.

fuk --verbose --grub --run M4600A08.exe /home/bruno/src_tmp/HARDWARE/DELL_M4600/M4600A08.exe 
/tmp/fuk.lSVIgS0cMt/fwupdate.img: chs = 186/4/16, size = 11904 blocks
- writing mbr
- writing fat12 boot block
- copying:
c-3po:~ # 

That’s all I’ve now a new entry in my grub list

title Firmware Update
    kernel /boot/memdisk
    initrd /boot/fwupdate.img


Now just reboot and use the grub entry, then upgrade your bios, like you will normally have done with you old complicated build iso, or diskette (I’m joking)

Road to 11.3 : when pattern are not your friend, pre selection can be a trap

June 10th, 2010 by

So it’s time to take some hours to test our future version.

Today I start a fresh M7/Factory install : booting from pxe. The test case is build quickly a minimal server text mode.

Just uncheck the auto configuration, we are after all linux admin. Choose your partition keyboard, language (en recommanded for server) etc … normal.

Just before starting the install check software :  click on installation resume . You will discover that base-system-pattern would like to install a kernel-desktop, wtf why we want a server !

So there’s a new ticket about that : https://bugzilla.novell.com/show_bug.cgi?id=613216

I express the fact that it would be nice to have a new pattern selected when we choose minimal install server text mode.

And you what about your opinion about pre-selection or having a base-system-server pattern … Please comment, & vote on bugzilla

A pattern guru wanted to build a patch for that.