Home Home > Base-system
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for the ‘Base System’ Category

Is my server alive and how good is my connection

March 10th, 2014 by

If you have time to setup real solution and need something reliable test Zabbix (http://zabbix.com). Zabbix is wonderful all in one solutions for monitoring network and your hosts (servers). If you are in need of knowing how good you Internet/(W)LAN connections is then things are getting complicated. (more…)

Network boot live ISO

January 29th, 2014 by

The x86_64 edition of openSUSE Education’s Li-f-e live DVD supports PXE booting the iso over the network, here is how to do it:

* Install Li-f-e on a server from which other machines will PXE boot, make sure you have plenty of space assigned to / partition(about 20G)
* Set up LTSP by following this quick start guide
* Create /srv/nfs folder and copy Li-f-e iso there
* Run the following as root in terminal:

mount /srv/nfs/openSUSE-Edu-li-f-e.x86_64-42.1.1.iso /mnt
cp /mnt/boot/x86_64/loader/linux /srv/tftpboot/boot/linux-life64
cp /mnt/boot/x86_64/loader/initrd /srv/tftpboot/boot/initrd-life64
echo "/srv/nfs *(ro,no_root_squash,async,no_subtree_check)" >> /etc/exports
cat <<EOF>> /srv/tftpboot/pxelinux.cfg/default
LABEL Li-f-e
kernel boot/linux-life64
append initrd=boot/initrd-life64 isofrom_device=nfs:10.0.0.254:/srv/nfs/ isofrom_system=/openSUSE-Edu-li-f-e.x86_64-42.1.1.iso
IPAPPEND 2
EOF
chkconfig rpcbind on && service rpcbind restart
chkconfig nfsserver on && service nfsserver restart

Now you can PXE boot any machine over the network, select Li-f-e from the end of the boot menu to boot live DVD iso instead of normal LTSP session.

Use “yast2 live-installer” to install Li-f-e on the client machine.

Proprietary AMD/ATI Catalyst fglrx 13.12 (13.251-3) rpm get a new build release

January 27th, 2014 by

Just a small note about a new build (-3) of the 13.251 fglrx version.

Changelog

AMD has changed /etc/ati/amdpcsdb.default database in its tarball

The packages have just been published on geeko.ioda.net, so next time you zypper up the new build should appear as a proposed update

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 openSUSE 12.3 or above.
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.
For 12.3 and especially 13.1 the free radeon often offer a better experience than the old fglrx-legacy.

Have fun!

Beta Proprietary AMD/ATI fglrx 13.11 betaV9.95 Catalyst 13.25.18-3 rpm released

January 27th, 2014 by

Beta Proprietary AMD/ATI Catalyst fglrx 13.11 (13.25.18-3) rpm get a new release

Just a small note about a new build (-3) of the 13.251 fglrx version.

Changelog

On AMD website : Release note

Adds support for Steam OS

The packages will be published in a few minutes on geeko.ioda.net/mirror/amd-fglrx-beta, so next time you zypper up the new build should appear as a proposed update, if you use the beta repository (not recommended).

Notice

This release concern only owners of radeon HD5xxx or above. And is BETA.
For older gpu, the fglrx-legacy is still 13.1, and thus didn’t work with openSUSE 12.3 or above.
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.
For 12.3 and especially 13.1 the free radeon often offer a better experience than the old fglrx-legacy.

Have fun!

How to destroy your data from harddisk permamently?

January 24th, 2014 by

First warning and please read it: If you wipe your harddisk, USB-stick or Flash with any of these tips. Your data won’t magically come back! After correct ‘secure rm’ or ‘NWipe’ there way is no way to bring your valuable data back. Make backups and happy wiping!

Destroying data permanently from hard disk is not as easy as you think. Sometime hard disks just self destructs without notice but when there is police behind you door knocking and you have destroy as much data as you can it’s little bit trickier. Even normal cases when there ain’t police at door and you just want to make sure that your old hard disk is clean and it doesn’t contain your personal data it’s a bit of a problem. (more…)

Unterstanding the nvidia driver process

January 15th, 2014 by

Nvidia pic from Muktware
The NVIDIA drivers for openSUSE 13.1 took a while to appear. Many users have asked why this was and we’d like to explain what happened and what we plan to do to prevent this in the future. This post was written with input from the openSUSE developers who maintain these drivers at SUSE and work with NVIDIA to make them available for our users.

How it should work

Legally, the Linux kernel GPLv2 license leaves proprietary binary drivers in a bit of a tangle. While some claim it should be OK, others say not – and that is what most distributions currently assume: one can not ship a Linux distribution with proprietary, binary drivers. NVIDIA has agreed that our users can grab their drivers from the official NVIDIA servers. They are packaged by SUSE engineers however. They take care of both SLE and openSUSE proprietary driver packaging for NVIDIA hardware, and have contacts at NVIDIA who get the drivers up on their ftp mirrors.
Nvidia-1click
The packages are build on a dedicated system, but the package spec (skeleton for building) is in OBS – for example, G03 is here. Anybody could use these to build the nvidia driver locally (the nvidia binary driver is grabbed from the nvidia driver during building). The command sequence for local building can be found in the README.

Once the packages are build, they are send to NVIDIA, which signs the packages with their key and generates and signs repositories, making them available to the public.

To note is the fact that this is all manual and takes a while on NVIDIA’s side (and ours). This of course is part of the reason why we don’t offer NVIDIA packages for Factory, our fast-rolling development repository.

What happened

What occurred for 13.1 is a typical case of “everything went wrong”.

Up until a few weeks before the release, the driver did not build against the Linux Kernel version 3.11. NVIDIA warned against the use of a patch for this problem created by third parties so the driver team did not have a running build. Due to a holiday, it took a while to get the packages build and pushed to NVIDIA. Unfortunately, by the time this was done, the holiday period at NVIDIA blocked progress for another week. Once the package was signed, it took the webteam at NVIDIA another week to get the repository published. It all added up to almost a month and brought quite some inconvenience for users eager to use their latest NVIDIA cards with the latest openSUSE.

About a week later, the openSUSE 13.1 NVIDIA drivers disappeared again from the nvidia servers for a day or so. We don’t know exactly what happened there, it might have simply been a server issue.

What we will do

The first and most obvious thing to change would be to improve coordination. The developers taking care of the NVIDIA packages should be made aware as early as possible about the release planning and a replacement in case for holidays should be available. We noted this in our 13.1 release report and will make sure that there will be a task in our task tracker for this for the next release. We also need to talk to NVIDIA about this to make sure that there, too, somebody can fill in for SUSE’s contacts.

But there are also thoughts on how to improve further. Some of the current ideas:

  • To get drivers for Factory the process needs more automation as the driver may break on kernel or X changes
  • We could try to open the process and work with community members to secure the process in case the SUSE folks are unavailalbe
  • It would be nice if we could make NVidia to see benefit of working more on the driver in openSUSE, e.g. by doing some testing
  • We could write some scripts that check regularly whether repo and packages are still available and in a valid state (meta data matches available RPMs)

We’ll have to see which of these we can implement, when and how. But rest assured that we will do what we can to prevent this in the future!

statistics with Geeko inside

And the stats!

After a bit of a hiatus, we’re back with the numbers. Development has slowed down around new year and isn’t back to speed yet so the 10th spot is shared by quite a big group of people…

Spot Name
1 Stephan Kulow
2 Denisart Benjamin
3 Tomáš Chvátal, Dirk Mueller, Michal Vyskocil
4 Hrvoje Senjan
5 Ciaran Farrell
6 Petr Gajdos
7 Lars Vogdt, Pascal Bleser
8 Jan Engelhardt, Charles Arnold
9 Andreas Stieger, Michal Marek, Niels Abspoel, Kyrill Detinov
10 Dinar Valeev, Bjørn Lie, Ulrich Weigand, Tobias Klausmann, Marcus Meissner, Alexander Graf, Robert Schweikert, Martin Vidner

Proprietary AMD/ATI fglrx 13.251-1 Catalyst 13.12 rpm finally released

December 21st, 2013 by

Proprietary AMD/ATI Catalyst fglrx 13.12 (13.251-1) rpm released

Geeko Santa Claus - Crédits Carlos Ribeiro

Geeko Santa Claus – Crédits Carlos Ribeiro

Patience is a virtue, months of it and finally we got a proof that Santa Claus exist 🙂
This release allow me to wish you a Merry Christmas!

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 openSUSE 12.3 or above.
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.
For 12.3 and especially 13.1 the free radeon often offer a better experience than the old fglrx-legacy.

Changing the signer of package

I’ve done a change with which key used for signing the package and repository. So you will need to trust the new key for the repository

zypper ref -f -r amd-fglrx
Forcing raw metadata refresh
Retrieving repository 'amd-fglrx' metadata ---------------------------------------------------------------------------------------------------------------------------------------------[\]

New repository or package signing key received:
Key ID: 484F703065BE584C
Key Name: builder Ioda-Net (Building and signing packages build at Ioda-Net) 
Key Fingerprint: 80D079EBFB1AB0FEE3CA41E6484F703065BE584C
Key Created: lun 30 jui 2012 15:27:35 CEST
Key Expires: sam 29 jui 2017 15:27:35 CEST
Repository: amd-fglrx

Do you want to reject the key, trust temporarily, or trust always? [r/t/a/? shows all options] (r): a

fglrx-13.12-capture01

Help for spreading the word

Dear fellow I’m counting on you to spread the word, in the different social media you’re subscribed, and also on Mailing list, forums.
Feel free also to translate it into your native language

Release note about 13.12

This Catalyst fglrx version support openSUSE version from 11.4 to 13.1 and also Tumbleweed (thus also kernel 3.12/13 series).
A special thanks to Sebastian Siebert for his effort on making this driver working under openSUSE.

If a kind German geeko can take the time to translate his article, put the result in comments below, you will understand that getting it working,
is not just Fun.

Notice for users of the -beta repository

If you previously used the fglrx drivers using the -beta created for fglrx 13.11, you could not switch back the url of the repository to the standard one.
The beta will contain now outdated driver until AMD release a new one.
If you were using the normal repository the update should appear directly

To change the url if your repository is called FGLRX
zypper mr -n FLGRX http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_13.1

Tumbleweed

For tumbleweed due to the change of openSUSE version from 12.3 to 13.1, you will certainly have remove the old package and install the new one.

zypper rm fglrx64_xpic_SUSE123

zypper in fglrx64_xpic_SUSE131
[snipped par of installation]
Calling 'depmod -a 3.12.5-3.g48b587a-desktop' this may take a while...

Summary report:
================================================================================

   Kernel     => 3.12.5-3.g48b587a-desktop
   Detected   => RPM package
   Build      => [ OK ]
   Install    => [ OK ]

*************************************************************
Please read "/usr/share/doc/packages/fglrx/README.SuSE" for
configuration details when using SaX2.
*************************************************************
...

Release Note

A release note is available on AMD website

Fixed issues

    [384861]: Ultra slow dota2 fps
    [383176]: System hang when startx after enable Eyefinity
    [383109]: System hang when run Unigine Heaven 4.0
    [382494]: Screen corruption when run C4Engine with GL_ARB_texture_array enabled
    [384193]: Fix the procfs permission issue on kernel 3.10 and later
    [373812]: System hang when run some OpenGL stress test
    [383430]: Glxtest failed with force AA
    [383372]: Fail to launch cairo-dock
    [384509]: glClientWaitSync is waiting even when timeout is 0
    [383573]: AC/DC switching is broken
    [384194]: Tear-Free Desktop sets V-Sync to 30Hz instead of 60Hz
    [385123]: CrossFire aspect observed in CCCLE where it should not
    [385414]: Steam crashes and games hang on a black screen when Force AA is on
    [387027]: Glxtest failed on SLED11 SP3
    [382079]: MARI crash with weird stack
    [387797]: X crash when kill X with Xserver 1.13 and 1.14
    [389431]: Screens are distorted when connecting an external monitor on some PowerXpress platform with Intel Haswell
    [389728]: Segfault after disabling display on re-launch of CCCLE
    [387573]: Soft hang and error observed on BasicDebug sample for OpenCL when run on x86
    [385704]: Black window when run glxgears with TWM
    [376115]: Display corruption when using rotation

 Known Bugs
	

(more…)

Owners of FGLRX card using openSUSE 12.1 – cleanup your repositories

December 21st, 2013 by

Important
If you’re still using openSUSE 12.1 and you have one day installed the AMD/ATI FGLRX long time ago, you certainly forget to adjust the new location of the repository.

My server indicate that still around 154 Geekos have their FGLRX repository pointing to the old urls :
http://geeko.ioda.net/mirror/ati/openSUSE_12.1/

The location changed long time ago, when AMD decide to split the drivers in two part (legacy HD2xxx-HD4xxx and normal HD5xxx or above).
The worst things, is that those are trying to refresh almost every half hour, generating 404 errors on my server, without help them to get the right driver.

I’ve made a call at that time to help to spread the information. Would be nice, if any of you could spread this reminder to your fellows.
Cause I can decide by a redirection, which gpu you have 🙂

The new location for 12.1 was setup as following :
For HD2xxx-HD4xxxx legacy :http://geeko.ioda.net/mirror/amd-fglrx-legacy/openSUSE_12.1/

For HD5xxx or above : http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_12.1/

AMD FGLRX ymp (One Click install) and stable repository

November 28th, 2013 by

A Quick notice

Due to some requests, I’ve finally decide to do something I wouldn’t have.

The stable repository of FGLRX for openSUSE 13.1 and Tumbleweed have been linked to the FGLRX-BETA repository, the time we got a stable functional FGLRX driver which should happen in December

I’ve also updated the ymp file, so people trying the one-click-install will be deserve correctly with the new openSUSE version

Thanks to any feedback, good or bad to improve the situation.

Yippee Yeah Another Proprietary AMD/ATI Catalyst fglrx 13.11 BETA v9.4 (13.25.18-2) rpm are released for any openSUSE version

November 23rd, 2013 by

Yippee Yeah Another Proprietary AMD/ATI Catalyst fglrx 13.11 BETA v9.4 (13.25.18-2) rpm are released for any openSUSE version

amd logo

Welcome in paradise II … 🙂

A fresh new version of the FGLRX driver has been released by AMD, and thus packaged and available for all of you.

Next month, AMD promise to release a stable version.

Notice

This release concern only owners of radeon HD5xxx or above. All owner of HD2xx and HD4xx are really encouraged to use the free radeon driver (which received a lot of improvement in 3.11)

There’s 13 and thirteen 🙂 When I speak about 13.1 it’s openSUSE version, 13.11 is FGLRX version, don’t get confused! Oh and 3.11 is the kernel version 🙂

This is experimental & BETA software, it could fix issues you encountered (FGLRX not working for openSUSE 13.1),
But good reports have been collected around (people having used Sebastian’s script directly)

I would like to thanks again Sebastian Siebert for his effort to kept FGLRX in a good shape for all of us.

Beta Repository

To make things clear about the status of the drivers, it will not be published under the normal stable repository http://geeko.ioda.net/mirror/amd-fglrx.
I’ve created some times ago a beta repository located at http://geeko.ioda.net/mirror/amd-fglrx-beta.
The FGLRX 13.11 beta6 and beta 9.4 rpm are released for any openSUSE version from 11.4(Evergreen) to latest 13.1 + Tumbleweed

Also the signer of package have change and use now the generic builder gpg key at Ioda-Net. (gpg key id 65BE584C)

Installing the new repository

Admitting you’ve the normal repository named FGLRX, (use zypper lr -d to find the number or name you give it). You have to start by disabling it
so you could fallback to it quickly when new stable version will be published. Open a root console or add sudo at your convenience and issue the following command:

zypper mr -dR FGLRX

amd-fglrx-beta

To add another repository in the same console as root issue the following command which will install normally the right repository for your distribution

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_`lsb-release -r | awk '{print $2}'` FGLRX-BETA

If you are using Tumbleweed use this one

zypper ar -n FGLRX-BETA -cgf http://geeko.ioda.net/mirror/amd-fglrx-beta/openSUSE_Tumbleweed FGLRX-BETA

Now the update/upgrade process

zypper dup -r FGLRX-BETA

Let the system upgrade the package, and try to enjoy the new beta.

(more…)