Teaching the installer self-update to be a better citizen

As you may know, YaST includes a nice feature which allows the installer to update itself in order to solve bugs in the installation media. This mechanism has been included in SUSE Linux Enterprise 12 SP2, although it’s not enabled by default (you need to pass an extra option selfupdate=1 to make it work).

So after getting some feedback, we’re working toward fixing some usability problems. The first of them is that, in some situations, the self-update mechanism is too intrusive.

Consider the following scenario: you’re installing a system behind a firewall which prevents the machine to connect to the outside network. As the SUSE Customer Center will be unreachable, YaST complains about not being able to get the list of repositories for the self-update. And, after that, you get another complain because the fallback repository is not accessible. Two error messages and 2 timeouts.

And the situation could be even worse if you don’t have access to a DNS server (add another error message).

So after some discussion we’ve decided to show such errors only if the user has specified SMT or a custom self-update repository (which is also possible). In any other case, the error is logged and the self-update is skipped completely.

You can find further information in our Self-Update Use Cases and Error Handling document.

During upcoming sprints, we’ll keep working on making the self-update feature great!

Configuring workers during CaaSP installation

While CaaSP release approaches, our team is still working hard to satisfy the new requirements. Thankfully, YaST is a pretty flexible tool and it allows us to change a lot of things.

For CaaSP installation, YaST features a one-dialog installation screen. During this sprint, configuration of the Worker role has been implemented, including validation of the entered URL and writing the value to the installed system. You can check the animated screenshot for details.

New desktop selection screen in openSUSE installer

The world of Linux desktop environments change relatively quick, with new options popping-up and some projects being abandoned. Thanks to the openSUSE’s community of packagers we have a lot of these new desktop environments available on the openSUSE distributions. But the status of those packages for openSUSE is also subject to changes: some desktop environments are poorly maintained while others have a strong and active group of packagers and maintainer behind.

The YaST Team does not have enough overview and time to watch all these desktop environment and evaluate which one is ready or not for being in the installer’s desktop selection screen. So the openSUSE Release Team decided to replace this dialog with something a bit more generic but still useful for newcomers.

They asked the YaST Team to come up with a new dialog featuring the two openSUSE main desktops (KDE Plasma and GNOME) and allowing the easy selection of other environments without reworking the dialog in the future. The goal of that new dialog was to replace the existing one you can see in the following screenshot.

We decided the new dialog should rely on patterns for several reasons. The main one is that the set of patterns is under the close control of the openSUSE community, which looks more closely than us to the desktop environments and their integration into the distribution. Moreover, each pattern specifies its own icon and description that can be somehow re-used by the installer.

We also took the opportunity to merge this almost empty and outdated dialog with the new one.

Addons are no longer produced for openSUSE, so only the second checkbox made any sense nowadays. Moreover, the functionality of that second checkbox directly influence the available selection of patterns, so it made more sense to merge everything in a single screen that keeping an extra step in the installation just to accommodate a checkbox.

So we sent a proposal for the new dialog to the opensuse-factory mailing list and, after implementing many of the ideas discussed there (like better wording or using a button instead of a checkbox for the online repositories), this is the new dialog that replaces the two ones mentioned above.

Selecting “custom” will take the users to the already existing patterns selection screen. Just in case you don’t remember how that screen looks like, you can check this image.

If these screenshots are not enough to make your mind about the change, you can check the following animation, in which KDE Plasma is initially chosen to be changed at a later point (going back in the workflow) to LXQt.

It will take some time before the changes hit the Tumbleweed installer, since they obviously have a non-trivial impact on the openQA tests, that will need some adaptation.

We would like to thank everybody that contributed to this new feature by providing feedback and suggestions through the mailing list. Once again, the openSUSE community has proved to be simply awesome!

Storage reimplementation: improved handling of logical partitions

Our reimplementation of the storage layer keeps getting improvements here and there. With the base x86 case working, we are now implementing the tricky parts, like the partitions renumbering that takes place when dealing with logical partitions in a MBR style partition table.

With GPT partition tables or with primary partitions in a MBR partition table, the partition gets a number (like sda1) when it’s created and keeps that number for its whole lifetime. But logical partition gets constantly renumbered when other partitions are created and destroyed. We need to know in advance what device name every partition will get in order to configure everything beforehand and only commit the changes to the disk when the user clicks in the “install” (during the installation process) or “commit” (if running the expert partitioner).

Now, libstorage-ng is able to simulate in memory the re-numbering process, so we can calculate all the settings related to partitioning (like the configuration of the bootloader) before really touching the disk.

Making kdump work in CaaSP

When you enable the Kernel Crash Dump (kdump), you probably expect that you will get a kind of core dump, like you do for regular processes. What you might not expect is an automatic reboot. That is a nice bonus. If you are tired of waiting for an actual kernel crash, you can test your kdump setup by triggering a crash yourself. Just run this as root:

echo c > /proc/sysrq-trigger

The way kdump works is by allocating some extra memory at boot time and putting a second kernel+initrd there. When the main kernel realizes it is crashing, it transfers control (by kexec) to the other one, which has only one purpose, to dump the memory of the crashed kernel.

In the upcoming Containers as a Service Platform, kdump was not working because the root filesystem is read-only there and we were not able to create the kdump initrd. We fixed it by creating it just after the RPMs are installed, when the FS is still read-write.

Fixes for Snapper in CaaSP

Kdump was not the only component affected by the fact of having a read-only filesystem in CaaSP. Snapper was also running into problems when trying to execute the rollback and cleanup operations. Now the problems are fixed. While working on that we did enough interesting findings to deserve a separate blog entry. So you can expect a new entry in the Snapper.io blog soon.

Snapshot-related improvements in the expert partitioner

While we work on the new storage system, we are still taking care and improving the current one that will continue to be shipped with SLE12-SP3, SUSE CaaSP and openSUSE Leap 42.3. During this sprint we introduced a couple of usability improvements in the expert partitioner related to Btrfs subvolumes.

First of all, we moved the “Enable Snapshots” checkbox that was pretty much hidden in the “Subvolume Handling” dialog to the place where it really belongs – below the selector of the file-system type.

In addition, we added the warning you can see in the screenshot below for users enabling snapshots in a potentially problematic setup.

Bring back the beta warning on CaaSP

And talking about warnings, we improved the CaaSP installation dialog to show the Alpha/Beta product warning at the beginning. After changing the CaaSP installation to use the all-in-one dialog described in our previous post, this feature was lost as it is part of the initial EULA dialog. Now it is back and the users should now properly see the current product status.

Storage reimplementation: encrypted LVM proposal

Back to our storage layer reimplementation, the new system is now able to propose a setup with encrypted LVM. Since some sprints ago, we were already able to propose a partition-based and a LVM setup. That means the new proposal is now feature-pair with the old one, with the only exceptions of Btrfs sub-volumes (that shouldn’t be a big challenge) and s/390 storage (that is still not properly managed by the underlying libstorage-ng).

The bright part is that the new code is written with re-usability in mind, which means implementing an encrypted partition-based proposal (with no LVM) would be trivial. The new code is 100% covered by automatic unit tests and scores to the top in all the automatic quality checkers we have run (like Rubycritics, CodeClimate, and Rubocop).

So now we are prepared for whatever the future brings, having lost no single feature in the way.

Storage reimplementation: prototype if the UI for the proposal settings

The next challenge is to make the power of that new storage proposal available to the users through the user interface. In the previous post we presented the document describing the general ideas we wanted to discuss with UX experts.

It’s our pleasure to announce we met the experts and we very easily reached an agreement on how the user interaction should be. During this sprint we already implemented a prototype of the future proposal settings wizard that is, as usual, included in our testing ISO.

Now that we have solid foundations, it’s very likely that the following sprint will result in the fully working wizard, with almost-final wording and design.

Support for CaaSP added to the AutoYaST integration tests

While fixing a problem with AutoYaST and CaaSP, we decided to extend our AutoYaST integration testing tool to support CaaSP. But, as a side effect, we also made some additional improvements that were long overdue (like improving the procedure to download ISOs, reducing timeouts, etc.).

Now, our internal Jenkins instance takes care of running AutoYaST integration tests for the development version of CaaSP (as it already does for SLE 12 SP2).

Services manager moved to first auto-installation stage

AutoYaST allows to define a set of services to be enabled/disabled in the installed system, applying this configuration during the 2nd stage (after the first reboot).

Unfortunately, this approach won’t work for CaaSP because, in that case, the 2nd stage won’t be available. For that reason, during this sprint, we have adapted AutoYaST to write services configuration during 1st stage.

As usual, not only CaaSP, but other future (open)SUSE versions will benefit of this change.

Faster YaST installation when the release notes cannot be downloaded

Sometimes a very small simple change in a program makes a very noticeable impact in its everyday use. That’s the case of a fix implemented during this sprint. YaST usually re-tries to download the distribution release notes several times if the first attempt was unsuccessful. Although that’s correct from a general point of view, there are cases in which retrying makes no sense and only delays the installation. We have now added failed DNS resolution to that list of cases, which should result in a noticeable faster installation in many scenarios.

Moreover, in the case of AutoYaST we now skip downloading the release notes completely. Downloading them don’t make us much sense in the kind of unattended scenarios handled by AutoYaST and skipping this step and all the possible associated problems result in a more robust process.

Better continuous integration for Libyui

In the previous sprint we switched to Docker at Travis so we could build and test our packages in the native openSUSE system instead of the default Ubuntu. This sprint we did the same change also for the Libyui library which implements the UI part of YaST.

Originally we could not build the Libyui packages at Travis as either the required build dependencies were missing or were present at a very old unusable version. With this switch we can easily use the latest packages from openSUSE Tumbleweed and thus enable Travis builds for all Libyui packages.

See you after Hack Week!

As already mentioned, this week is Hack Week 15! So our Scrum process will be on hold for some days. That doesn’t necessarily mean the YaST development will stall. Since there are quite some YaST-related projects in the Hack Week page, you can expect YaST to simply go in unexpected directions.

And remember Hack Week is not a SUSE internal initiative, we are open to collaboration from anybody within or outside the company. So jump in and have fun with us!

Tumbleweed beware : broken Xorg

It seems since the release, that a number of report of broken xorg with gdm, ssdm and so… segfaulting

You can still use the previous version hanging on the server. But I doubt it would work better

As soon, with Sebastian Siebert we have a patch for, I will republish a new build

Informations & bugreport Sebastian’s blog or lizards.o.o

The proposed drivers support kernel up to version 4.4

AMD release note available

Sebastian Siebert posts about fglrx

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)

Debugging troubles

I recommend in case of trouble the use of his script which can collect the whole informations needed to help you. then you just have to issue a simple commande in console to collect all informations, you can review them, and finally transmit them.
Check the website to get the latest.

su -c 'sh makerpm-amd-15.11.sh -ur'
The system report 'amd-report.txt' was generated.                                                                                                          [ OK ]
Do you want to read the system report 'amd-report.txt' now? yes/no [y/n]: y
Are you sure to upload the above-named system report to sprunge.us? yes/no [y/n]: y

The report was uploaded to sprunge.us.
   The link is:  http://sprunge.us/eMEB

Copy paste the link in the comment zone of Sebastian post

All proudly distributed by openSUSE powered server and sponsored by Ioda-Net Sàrl

Here is how you can get openSUSE running on Banana Pi M2.

* Download the image

* Extract the archive to get openSUSE-Tumbleweed-Bpi-M2-Xfce.img

* Dump openSUSE-Tumbleweed-Bpi-M2-Xfce.img on to a SD card
(dd if=/path/to/openSUSE-Tumbleweed-Bpi-M2-Xfce.img of=/dev/sdX bs=4M; sync #replace /dev/sdX with your actual SD card device)

*  In case you have a bigger SD card, use yast2 disk(partitioner) to “expand” the second partition. You can use yast’s package manager to install more software. The default password for root is linux, you may want to change that first thing after booting.

I am unable to get sound on this hardware, probably their kernel is missing sound related modules, if you figure out how to get sound working drop me a line so I can include it in next release.Everything else(wifi, hdmi out, USB ports etc) works well enough.

Unfortunately there is no release notes from AMD. This update can solve the issue with PowerXpress but I can not really verified this because lack of such hardware.

Another side note I have implemented a workaround in the script to get the driver works with the GNOME Displaymanager + GNOME. It is a little cruel hack but it works for the moment. Thanks to the user that they posted the article in my blog.

For GNOME user with gdm: Execute the following command as root after the installation of the AMD driver and before restart the machine:
sh makerpm-amd-15.3-beta.sh --install-gdm-fix
If you update the AMD driver, so the workaround does not work anymore. It is important that you do not delete the file /amd_xversion and is needed for the workaround.

To revert the changes:
sh makerpm-amd-15.3-beta.sh --uninstall-gdm-fix

Before I forget it: All user from openSUSE Tumbleweed can also install the driver. But remember, Tumbleweed is under heavy development. I can not guarantee that the driver works in the future yet.

Downloads:

• Script: makerpm-amd-15.3-beta.sh
• SHA1: makerpm-amd-15.3-beta.sh.sha1

Installation guide (English):
http://en.opensuse.org/SDB:AMD_fglrx#Building_the_rpm_yourself

The above named installation guide is only for the stable driver but you can adapt it for the beta driver.

Bruno Friedmann will build the new RPM packages in the fglrx repository. Stay tune!

If you find any issue with the driver. Don’t hesitate to contact me. I am in contact with AMD and can forward your issue to the right place. Feedback are welcome.

A report of your system is very helpful beside your feedback. You can generate it with the script:
su -c 'sh makerpm-amd-15.3-beta.sh -ur'

Have a lot of fun!

Sebastian
openSUSE member / Official AMD Packaging Script Maintainer for openSUSE

German Blog: openSUSE – proprietären Grafik-Treiber AMD Catalyst 15.3 Beta als RPM installieren

I hope this release will give better results for all of you who own an apu (especially the recent one), and also fix a number of issue with the hybrid chipset intel cpu/amd gpu embedded.

See below how to report issue on Sebastian blog.

It will be the last build for all openSUSE version below 13.1 (except if patches are needed).
In January 12.3 support will definitively end. But I will let the drivers as is so you can still use them in case of.

Installation / update

Please refer to the wiki page SDB:AMD_fgrlx

New packaging schema

The driver is now splitted into different rpm that all need to be installed. Normally the necessary Require field is there and should happen automatically.

My advise is to check if you have them all installed.

for 32 bits

zypper install fglrx_xpic fglrx_core fglrx_graphics fglrx_amdcccle fglrx_opencl

for 64 bits

zypper install fglrx64_xpic fglrx64_core fglrx64_graphics fglrx64_amdcccle fglrx64_opencl

A notice for Tumbleweed users

The new release has now its package correctly named, previously they were called SUSEFACTORY, with the new version the package will contain SUSETUMBLEWEED in their name

Release note about 14.12

AMD Catalyst Full release note

New Features:
The following section provides a summary of new features in this driver version.

    OpenCL 2.0 support (requires 64-bit OS and compatible AMD Radeon™ R Series GPU)
    VAAPI decoding support (H264, VC1, MPEG2, MPEG4)
    Distribution specific package support for Ubuntu and Red Hat

Resolved Issues:
This section provides information on resolved known issues in this release of the AMD Catalyst Linux Software Suite.

    [402835]: Unexpected pixmap's time stamp change on Ubuntu with composite enabled causes Linux Khronos CTS to randomly fail
    [403420]: Driver install can sometimes have an error in Ubuntu 14.10 using GPL symbol before Kernel 3.16
    [405011]: Driver installation may intermittently fail on Kernel 3.9.0
    [409856]: Generate Distribution Specific Package' mode of Catalyst install does not create symbolic links for libGL
    [407550]: Driver upgrade failed in Ubuntu with specific drivers

Known Issues:
The following section provides a summary of open issues that may be experienced with the AMD Catalyst Linux Software Suite.

  [404829]: Horizontal flashing lines on second screen in a clone mode with V-Sync on using AMD Mobility Graphics with Switchable Intel Graphics
  [404508]: Display takes a long time to redraw the screen after an S4 cycle

This Catalyst fglrx version support openSUSE version from 11.4 to 13.2 plus Tumbleweed (thus covering kernel to 3.18 series).
Again a special thanks to Sebastian Siebert for his effort on making this driver working under openSUSE and latest kernel.
Want to help, use the donate button on his blog page

Sebastien Siebert making script

Sebastian Siebert post about 14.12

Damn I’m impressed by the number of steam games tested there, I should try some of them during hollidays

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.

Debugging and reporting troubles

I recommend in case of trouble the use of his script which can collect the whole informations needed to help you. then you just have to issue a simple commande in console to collect all informations, you can review them, and finally transmit them.
Check the website to get the latest.

su -c 'sh makerpm-amd-14.12.sh -ur'
The system report 'amd-report.txt' was generated.                                                                                                          [ OK ]
Do you want to read the system report 'amd-report.txt' now? yes/no [y/n]: y
Are you sure to upload the above-named system report to sprunge.us? yes/no [y/n]: y

The report was uploaded to sprunge.us.
   The link is:  http://sprunge.us/eMEB

Copy paste the link in the comment zone of Sebastian post

Reminder this drivers is only for radeon HD5xxx

This release concern only owners of radeon HD5xxx or above.
For older gpu, the fglrx-legacy is still there see wiki page atSDB:AMD_fgrlx_legacy.
Beware of it obsolete status, and prefer the free open-source radeon driver which came out of the box from your openSUSE distribution.
For 12.3, and more true with 13.1+ the free radeon often offer a better experience than the old fglrx-legacy, especially for HD2xxx-HD4xxx range.

Humor : the never ending links

In 2014 April, I’ve decided to close the automatic redirection of http://geeko.ioda.net/mirror/ati after being obsolete for more than one year.
The reason was that there’s no safe way to drive people having a older Radeon HD card (series 2xxx to 4xxxx) to not use newer fglrx build.

Guess what? I’m still seeing more than quarter billion hit on those address (for 12.1 to 13.1)

If you click on such link referring to this url, please do your best to fix thoses and check your or friends computer configurations

Mirror total Statistics

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

After exiting the chroot terminal, openSUSE services will be stopped, no changes to your android system is made.

Have a lot of fun…

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!

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

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

Quick overview

For openSUSE version 11.3 and above

Have a radeon hd5xxx and above
1. You have to use the standard fglrx
2. Use the new repository http://geeko.ioda.net/mirror/amd-fglrx/openSUSE_VERSION
3. SDB:AMD_fgrlx

Have a radeon between hd2xxx and hd4xxx
1. You have to use the legacy fglrx version
2. Use the new repository http://geeko.ioda.net/mirror/amd-fglrx-legacy//openSUSE_VERSION
3. SDB:AMD_fgrlx_legacy

Note that legacy has not yet been updated, and so can’t be use on kernel 3.6+ (Tumbleweed, 12.3 or kotd)

or have a look at the previous article which describe also step by step the procedure
lizards.opensuse.org/?p=8888

fglrx & 3d effects kde 4.9.5 on openSUSE 12.2

Debugging troubles

I recommend in case of trouble the use of his script which can collect the whole informations needed to help you. then you just have to issue a simple commande in console to collect all informations, you can review them, and finally transmit them.
Check the website to get the latest.

su -c 'sh makerpm-amd-13.1.sh -ur'
The system report 'amd-report.txt' was generated.                                                                                                          [ OK ]
Do you want to read the system report 'amd-report.txt' now? yes/no [y/n]: y
Are you sure to upload the above-named system report to sprunge.us? yes/no [y/n]: y

The report was uploaded to sprunge.us.
   The link is:  http://sprunge.us/eMEB

Copy paste the link in the comment zone of Sebastian post

flash film ( osc13 Thessaloniki teasing )

Mirror Statistics

December 2011 as shown a big bump on the server : 50,212 unique visitor for a roughly 320GB traffic for the rpm

1582GB has been distributed during 2011.

2012

That’s all folks! Have fun!

AMD/ATI Catalyst 12.3 / fglrx 8.951 rpms are available

Quick Résumé about 12.3

AMD rename their installer, So Sebastian did the same for his script.

I will just copy/google translate/paste here the comment made by Sebastian Siebert on his blog :

amd ccc and fgl_glgears running

The packaging script was updated because I have a compile error when building a kernel module fglrx in the kernel 3.2.8+ and 3.3+. Due to the very tight time window, the patches could no longer be incorporated into AMD Catalyst 12.3. Only in the upcoming AMD Catalyst 12.4, the patches from me for openSUSE will be available. AMD Catalyst 12.5 they will be officially included for all other distributions. Yes, with the makerpm-amd script made for you, I can despatch on very simple, convenient and quick patches or missing useful extensions via the script packaging update. Who need to wait months.
Driver support now AMD Radeon HD 7950, HD 7970, HD 7990

See more at Sebastian’s blog.
Don’t be shy, you can leave there the result of test in english too
or ask in forums, irc and ping freespacer.
See below what to do in case of troubles.

The rpms version 8.951 are available from Friday March 30th.

My advise is to firstly remove any existing version with zypper rm, then just zypper in the new version,
even if 8.930 was the first version I’ve seen able to upgrade correctly.
The 8.950 leave a file that need to be manually removed /etc/ati/amdpcsdb. The 8.951 fix that now.

As usual, I let the previous versions in the repository, just in case you need it.

Tested on a fresh 12.1 + updates and kde 4.8.1

12.2 Factory rpms are presently available, use at your own risk, and report bugs in forums and Sebastian blogs.
Anyways, factory and 12.2 should keep their effort on debuging and testing widely the free radeon driver.

One-click-installer

Two one-click-installer are available here :
For 32bits system :

For 64bits system :

(*) To know which kind of system you have, open a console, then run uname -a and look the output if you see x86_64 on the line you are running a 64bits, otherwise a 32bits.

Installation, Caution, Troubles

Installation

Please refer to my previous article where all the installation procedure was explained.

For a first installation, if you don’t remove radeon from the initrd, you will certainly get in trouble. Don’t thanks who removed that from the wiki.

Caution

• Wrong (to my point of view) create an xorg.conf file which is unneeded if you work with /etc/xorg.conf.d/50-device.conf and have driver “fglrx” inside
• AMD CCLE didn’t get correctly upgraded if xorg is running during the upgrade. My advise, let’s go to console and as root do the following :

  init 3
  rcatievenstd stop
  zypper ref
  zypper up
  init 6
  

  Let the package rebuild the kernel driver. And for me I always remove the newly xorg.conf file created.
  reboot is mandatory!

Debuging troubles

I recommend in case of trouble the use of his script which can collect the whole informations needed to help you. then you just have to issue a simple commande in console to collect all informations, you can review them, and finally transmit them

su -c 'sh makerpm-amd-12.2.sh -ur'
The sytem report 'amd-report.txt' was generated.                                                                                                                    [ OK ]
Do you want to read the system report 'amd-report.txt' now? yes/no [y/n]: y
Are you sure to upload the above-named system report to sprunge.to? yes/no [y/n]: y

The report was uploaded to sprunge.us.
   The link is:  http://sprunge.us/ZVRP

Copy paste the link in the comment zone of Sebatian post

Statistiques

December 2011 as shown a big bump on the server : 50,212 unique visitor for a roughly 320GB traffic for the rpm

1582GB has been distributed during 2011.

2012

That’s all folks! Have fun!

Have a lot of fun!
My month wishes : Now we get a G+ button spread!