Home Home > Base-system
Sign up | Login

Archive for the ‘Base System’ Category

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

Proprietary AMD/ATI fglrx 12.104 Catalyst 13.4 rpm released

April 29th, 2013 by

Proprietary AMD/ATI Catalyst fglrx 13.4 (12.104-1) rpm released

Notice

This release concern only owners of radeon HD5xxx or above.
For older gpu, the fglrx-legacy is still 13.1, and thus didn’t work with Kernel 3.6, 3.7, 3.8 nor openSUSE 12.3 and xorg 1.13
SDB:AMD_fgrlx_legacy
Beware of that, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.

Release note about 13.4

This Catalyst fglrx version support openSUSE version from 11.4 to 12.3 (new repository) and also Tumbleweed (thus also kernel 3.8x series).

Release Note

A release note is available on AMD website

Fixed issues

    [370253]: Serious Sam 3 - Color of Objects turning into be red when enabling separate shader object
    [371937]: Team Fortress 2 - Screen black issue while entering the game screen under cinnamon desktop environment
    [371374]: Team Fortress 2 - Screen random flickering and corruptions in Lakeside Map
    [354777]: Maya 2012 Benchmark - Benchmark falling out of TIMMO
    [372137]: NX8.0 - Severe flickering is observed while playing animation in manufacturing mode
    [373561]: Mari crashes at startup on Ubuntu only
    [374371]: Severe corruption occurs in Unigine Heaven 4.0 on Saturn XT when running at extremely high settings
    [373787]: Softimage fails to refresh properly
    [372918]: Maxon - Wrong shading when UBOs are used to store light parameters

 Known Bugs

    [373836]: Vsync application shows corruption filed
    [373772]: Team Fortress 2 – Game could not be loaded in “High Performance GPU” mode
    [373909]: Driver install via .deb package will cause OS desktop corruption
    [371372]: SCQA - Anti-Aliasing does not work

Sebastien Siebert making script

Sebastian Siebert post about 13.4

If you have any problems with the driver, don’t be afraid to report to Sebastian (German and English bugreports are gladly accepted).
he will try, as far as I am able to reproduce the bug. Together with the necessary system information, he will go directly to the right place at AMD to have the bug fixed in the next driver release.
Thank you very much, Sebastian.

See below what to do in case of troubles.

Or you can also ping him on irc (freespacer)

(more…)

One that got away – 12.3 Networking

March 13th, 2013 by

Well openSUSE 12.3 is about to go live  and we are all pretty excited. It is, as far as I can tell a rock solid release and we have outdone ourselves. Considering the short release cycle makes this even more impressive.

One can only thank everyone in the community for pulling together, getting a lot of stuff done and delivering a great release.

Yet, there’s one sprinkle that rains on our parade. While we completed the switch to systemd we somewhere along the lines forgot to check the status of NetworkManager on an installed system. Thus, when you upgrade from a previous release and NetworkManager is disabled, it will be enabled and running after the upgrade is complete, sorry. If you happen to be running a network bridge your bridge will not be working and you’ll end up in some weird network state where ifconfig will tell you that both your bridge and your Ethernet card have an IP address. Your routing table will also be messed up. Addressing the issue is easy.

Login as root, which you will have to do at the login manager if you happen to run NIS, disable NetworkManager, stop the NetworkManager service, and restart your network. You are now back to your original configuration, no sweat ;) . Below is a list of commands you want to run as the root user to make this happen:

# systemctl –force disable NetworkManager.service

# systemctl stop NetworkManager.service

# rcnetwork restart

openSUSE 12.3 Image available for ARM64 (AArch64)

March 5th, 2013 by

Howdy,

the openSUSE on ARM team was quite busy the last few weeks with getting openSUSE 12.3 for AArch64 (ARM64, also called ARMv8) ready. At the time of this post, we have finished around 4100 packages (out of ~ 6000) of openSUSE 12.3 built for AArch64, the ARM 64bit platform. With those successfully built packages, we’re also able to build a regular openSUSE image for you to try and run in the ARMv8 System emulator (ARMv8 Foundation Model).

This is a huge achievement and milestone for us, thanks to lots of helpful hands within openSUSE. Just to put this into perspective: This is not a minimal system with a couple of toolchain packages. It is also not an embedded variant of a Linux environment. No, this is the full featured, standard openSUSE distribution as you’re used to, ported to AArch64, up and running. We have built it based on (slightly newer versions of) standard openSUSE 12.3 packages, and the changes are mostly already merged back into openSUSE Factory. For all we know it’s also more successful package builds than any other Linux distribution has on AArch64! If you’d like to see the status yourself, please check out the OBS repository we created for this.

As an open distribution, it is important to make contributions easy and we worked hard to enable others to participate in our effort. We extended OBS to automatically spawn a Foundation Model virtual machine when you want to build for aarch64. This works remotely on the OBS server as well as locally using osc build. More information on this is available on the respective wiki page.

So, dive right into it:  Get the image and start with openSUSE on AArch64 by following our wiki page: https://en.opensuse.org/Portal:ARM/AArch64.

AMD fglrx, fgrlx-legacy : news, cleanup & important informations

March 3rd, 2013 by

Status of fgrlx & fglrx-legacy regarding next coming 12.3

fglrx

fglrx (Catalyst 13.1) drivers has been refreshed and published for 12.3 with the RC2 build.
During the first few days after the release, and fresh new build will be made with the final version, and first updates.

fglrx-legacy

fglrx-legacy (Catalyst 13.1) will never support (actually) xorg 1.13 which is the version that come in openSUSE 12.3. Even if it can handle kernel 3.8
So the previous build has been removed from the server. To insure end-users no trouble or hassle trying to get it working.
If you still have a radeon from hd2xxx to hd4xxx you’re welcomed to use the free radeon. It made progress and could eventually be as efficient as the proprietary drivers.
The bonus you get, you can report bug, and they will be fixable.

Status of mirrors

One year ago I announced the move to the new host for the package mirror. During that time, I’ve kept a redirection active, and also a symlink from ati to amd-fglrx

This time is over now, so please update your repositories

Repositories available

FLGRX
http://geeko.ioda.net/mirror/amd-fglrx/ add openSUSE_(you version) from 11.2 to 12.3
FLGRX-LEGACY
http://geeko.ioda.net/mirror/amd-fglrx-legacy/ add openSUSE_(you version) from 11.2 to 12.2

Spread the word

If I already updated the en.opensuse.org wiki page (even if the reviewing process is stuck actually), I need your help to spread the word, to reach any end-users that need those informations.

Notice about tumbleweed, evergreen

I saw several users, trying to use the one-click-installer with tumbleweed. Sorry this can’t work due to the lack of perfect recognition of tumbleweed. etc/SuSE-release is 12.2 actually.

So if you use tumbleweed you just have to install the tumbleweed repository (again one for fglrx, one for fgrlx-legacy depending on your gpu)

But beware, tumbleweed is a moving target, and the proprio drivers could stop working at any update, kernel or xorg

Evergreen : some users successfully use fglrx-legacy 13.1 with the kernel 3.0.58

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).
(more…)

ATI/AMD catalyst fglrx legacy updated to new 13.1 version

January 24th, 2013 by

Proprietary AMD/ATI Catalyst fglrx legacy 13.1 (8.97.100.7-1) rpm released

Notice

This release concern only radeon HD2xxx to HD4xxx owners

The published Catalyst fglrx rpm version support openSUSE version from 11.4 to 12.3 (new repository) and also Tumbleweed (thus also kernel 3.8x series).
For testing with the next openSUSE 12.3 just use the new openSUSE_12.3 repo

The release note

Feedback

Sebastian Siebert will publish an article today, and he’s looking for feedback about the patches included to make it working on 12.3, so don’t hesitate to get in touch with him

Comments:

As I didn’t have a gpu card of this series, I can’t test it before publishing the rpm like for normal fglrx. If someone has a spare hd2xxx or hd4xxx, Could he(she) contact me?

Have fun!

Proprietary AMD/ATI Catalyst fglrx 13.1 (9.012-1) rpm released

January 21st, 2013 by

Proprietary AMD/ATI Catalyst fglrx 13.1 (9.012-1) rpm released

Sorry this article should have been published Saturday, but some trouble (error in a updated module) locked me outside of lizards), Thanks to Matthew to have fix it in the meantime

fglrx 13.1 amd-ccc & fgl_glxgears

fglrx 13.1 amd-ccc & fgl_glxgears

Notice

This release concern only owners of radeon HD5xxx or above.
For older gpu, the fglrx-legacy is still 12.6, and thus didn’t work with Kernel 3.6, 3.7, 3.8
SDB:AMD_fgrlx_legacy
Beware of that fact, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.

Release note about 13.1

This Catalyst fglrx version support openSUSE version from 11.4 to 12.3 (new repository) and also Tumbleweed (thus also kernel 3.8x series).
For testing with the next openSUSE 12.3 just use the new openSUSE_12.3 repo

Release Note

A release note is available on AMD website

Fixed issues

    [368958]: Driver release version is added to GL_VERSION
    [367282]: Bblank VGA display after resume from suspend
    [367245]: X crash for AMD PowerXpress™ A+I High-Performance mode on Ubuntu 12.10
    [366820] Performance of Valve Linux games
    [366805]: Segmentation fault when exit QtOpenGL applications such as AMD CodeXL
    [366425]: Xserver getting exit upon resume from suspend on RHEL 5.8
    [364107]: VariBright not working when change AMD PowerPlay™ settings in AMD Catalust Control Center:LE
    [363638]: VariBright doesn’t work after resume from suspend on “Trinity” platform
    [350759]: Flickering cursor when run some full-screen OpenGL games with CrossFire enabled
    [347895]: OpenGL performance on “Southern Islands” ASICs
    [344996]: 16 re-frames doesn’t work for H.264 @Level 5.1
    [337240]: Corruption when resize the Konsole window
    [304016]: One display goes black after changing from multi-display desktop from single independent

Sebastien Siebert making script

Sebastian Siebert post about 13.1

If you have any problems with the driver, don’t be afraid to report to Sebastian (German and English bugreports are gladly accepted).
he will try, as far as I am able to reproduce the bug. Together with the necessary system information, he will go directly to the right place at AMD to have the bug fixed in the next driver release.
Thank you very much, Sebastian.

See below what to do in case of troubles.

Or you can also ping him on irc (freespacer)

fglrx & 3d effects kde 4.9.5 on openSUSE 12.2

fglrx & 3d effects kde 4.9.5 on openSUSE 12.2


(more…)

Making different openSUSE liveCDs

December 29th, 2012 by

In my last post I explored the various liveCD creation methods out there, and I really wanted to try one of the others for openSUSE.
Thus I did so today in less than two hours.
I used Debian’s liveCD as basis and replaced the userspace with an openSUSE-11.4-GNOME-liveCD one (later ones likely do not work as systemd is not compatible with old 2.6.32 kernels).
And it worked like a charm. If you want to try it yourself, you need openSUSE and an empty directory with 5GB free space. Then you do as root:

zypper -n in clicfs squashfs cdrkit-cdrtools-compat
wget -O Makefile http://lsmod.de/bootcd/Makefile.aufslive.11.4
make

This will take a while to download the two isos and then at least another 3 minutes for the processing.
If that seems too hard for you, you can just download the finished iso and try it with qemu-kvm -m 1000 -cdrom xxx.iso

Do not let the debian logo in the bootloader confuse you. Just press enter there.
When running in KVM from RAM, this boots up in 18 seconds, while the original iso took 33 (measured from pressing enter in bootloader to the time the CPU load goes down). However, with physical media the difference will be less pronounced. Some of the difference comes from the faster gzip decompression. Unfortunately debian’s kernel does not support squashfs-xz, so I could not try that.

I hope in the future, we will have aufs patches in our normal openSUSE kernels and add an aufs-live mode to kiwi. That would help with the problems we hit with clicfs when memory runs out (and it can not be freed by deleting files either).

LiveCDs

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.