For openSUSE Leap 42.1, my plan was to install it on 3 very different computers before posting my experiences:
I had openSUSE 13.2 working on each machine, but decided in each to do a fresh install rather than upgrade. You probably
already have an idea about my experiences given this post is in Soapbox rather than General Chit-Chat.
The decision by the Developers not to support 32-bit I welcome, but the decision not to provide live media ISOs I do
not. Without Live boots, there’s no option to try openSUSE before commiting to hard drive (although I would still
install from DVD). Apparently the reason given is that live installers are limited by the capacity of CDs. Seriously? Do
the Developers really think that people burn actually live media to CDs to try out a GNU/Linux distribution? For those
who do, they should know there are these things called `USB-pens’ that modern motherboards can happily boot from and
nowadays their capacities are well in excess of DVDs. If I actually burned a CD every time I tried out a GNU/Linux
distribution, I would have a lot of coasters for my morning coffee!
I downloaded the DVD ISO from the nearest UK mirror. The sha256 checksum didn’t match the expected. I tried again.
Again it didn’t match and gave the same erroneous value. It appears the ISO image from the Warwick and Oxford mirrors
don’t match. One of them was correct and one was wrong. So I burned the correct ISO to DVD and using YaST (in 13.2) that
the media check was successful. So I was now ready to install.
Hardware: Intel Core i7-4500U with Intel HD integrated graphics.
Software: New install openSUSE_Leap_42.1_x86_64_KDE dual-boot (alongside Win64 10)
I like the openSUSE installer and it was very familiar since the experience hasn’t changed much in the last 200 years.
Since 13.2, the ridiculous BTRFS subvolume proposal arrived and seems now to be even more ridiculous in Leap. Perhaps
the Developers are trying to instill fear into GNU/Linux newcomers and scare them from clicking the `Expert partitioner’
options in order to implement a much more sensible partition arrangement.
The installer obviously picked up that I booted from EFI with the GRUB2-EFI installer selected as the default
bootloader. I remember previously on this laptop openSUSE 13.2 played very nicely with Win64 8 and Win64 10 with UEFI
Secure Boot enabled so I had no specific concerns. When installation was finished, there sensibly was no kexec and the
laptop booted. I could see that Win64 10 was detected (presumably by the os-prober) and booted into openSUSE Leap KDE
for the first time.
So after logging in and familiarising myself with KDE5, I noticed a few similarities and differences with 13.2 KDE. An
ever-present initial irritation of KWallet was cast aside as quickly as it invoked its wrath. The default desktop
wallpaper was even more gorgeous than 12.3’s and wifi connection using KDE’s network manager was flawless, although I do
hope it one day grows up and autodetects the WPA/PSK configuration of the host router like most mature wifi connectors.
I saw some differences from previous openSUSE_KDE experiences. The first I noticed was there was no welcome window on
first boot - good riddance! Another thing I noticed is that apart from the wallpaper, KDE5 looked horrible: think of a
Frankenstein cross between Apple MacOS, MATE, and XFCE except for partially-sighted children. After restoring the
Breeze' settings to Oxygen’/
Raliegh' however, KDE looked a lot better. Subsequently, I performed a zypper
up’, rebooted and ran my scripts for adding my preferred repositories and packages which went extremely smoothly. Joy.
Then I rebooted. I tried to boot into Windows 10. I failed. The error message
Not supported image'. After posting to the openSUSE thread ( https://forums.opensuse.org/showthread.php/510685-openSUSE-Leap-42-1-Windows-10-and-secure-boot/page3 ), I discovered this was a bug resulting from the Leap's lineage from the SLES dynasty rather than openSUSE 13.x, where the bug was already resolved. After some very helpful posts from a couple of forum regulars (Thanks nrickert and arvidjaar!), I find a GRUB update in a test’ repo. On a positive note, the new GRUB worked, and I could happily boot to both operating
systems. I expressed dismay that such an essential fix has not been implemented in the official update repos over two
months after Leap went gold, but a response (from OrsoBruno) has since indicated that this update has now been applied
to the official repo.
Not a promising start, but I was sufficiently content with openSUSE Leap to install it on my home desktop.
Hardware: Intel Core i7-975 with AMD Radeon graphics card (Radeon 79xx).
Software: openSUSE_Leap_42.1_x86_64_KDE quad-boot (alongside Win7, Linux Mint 17, and Gentoo)
There was absolutely no reason to replace my 13.2 with Leap especially since 13.2 played very nicely with the fglrx
driver, which was certainly not the case with 13.1! Now I wish I didn’t.
Once again installation went fine, apart from BTRFS subvolume nonsense. Since this was not a EFI system, GRUB2 happily
picked up the other OSs and successfully booted to all of them albeit with the inevitable corruption of monitor
resolutions in the virtual terminals. Again KDE5 booted up fine, only requiring removal of the disgusting
Breeze' themes to look respectable. DHCP networking was fine, I zypped up’, rebooted, and ready to install my preferred
I started with fglrx. Installation was successful. I rebooted, and after leaving the GRUB2 screen I was met with a blank
screen with a hard crash. Even going through Advanced options and including
nomodeset' did not avert the hard crash. At this point I was cursing the Leap didn't have Live media through which I could have chrooted. Of course there are other options (e.g. Rescue system’ or other Live/Recovery GNU/Linux media etc…), but the time it takes to reboot, network,
mount, chroot, and zypper rm fglrx, which is openSUSE’s official `fix’ to this problem is actually slightly longer then
just performing another reinstall. So there was no point.
Rant ahead caution. According to
https://lizards.opensuse.org/2015/10/31/proprietary-amdati-catalyst-fglrx-rpms-released-for-leap-42-1/ , the official
Leap take on the fglrx driver is:
There’s really no warranties the drivers will work, for you!
If you are satisfied with the open-source radeon drivers, don’t risk to break your computer.
Seriously? Look, I do openGL coding; so the open-source drivers aren’t an option. AMD are official openSUSE sponsors!
Honestly? Why is openSUSE accepting any money from AMD when the distribution can’t even run with their offical
proprietary driver? And why is the fglrx driver never a problem in any other GNU/Linux distribution I’ve try it on
(including Arch, Gentoo, Debian, *buntu, Fedora, Mint)? Does AMD sponsorship mean that openSUSE’s compatibility with the
proprietary driver must therefore be exclusively flaky?
From what I can see, openSUSE implementation of the fglrx driver appears to be maintained by the heroic efforts of a
a single volunteer called Sebastian Siebert, to whom openSUSE users should be eternally grateful. But this is
scandalous! If Developers have no interest in simply ascertaining whether the openSUSE configuration properly supports
AMD hardware, then users who want to use AMD hardware properly should simply have no interest in openSUSE. I would find
this easier to swallow were not the case that a) AMD sponsor openSUSE and b) I’ve had zero problems with the fglrx
driver on every other GNU/Linux distribution I’ve tried.
This isn’t rocket science. One of the things people want to do using an operating system is to look at the display. The
open-source driver doesn’t allow everything rendered to be displayed hence the necessity of using the fully featured
driver. It’s just a graphics driver. It’s 2016 and we’re still having problems at openSUSE. Don’t blame GNU or the Linux
kernel because it’s not a problem on other GNU/Linux distributions.
So I expect I will be reinstalling 13.2 rather Leap 42.1 on this desktop.
Hardware: Intel Xeon E5-2640-v3 X2 with Nvidia Quadro graphics card
Software: openSUSE_13.2_x86_64_KDE treble-boot (alongside Win7 and Gentoo)
Since I have a working openSUSE_13.2 install as a backup on this machine (for which Gentoo is the primary distribution),
and in the light of my experiences of Leap 42.1, there’s no way Leap 42.1 is coming anywhere near this machine, or
indeed of the other mission-critical machines I am in control of. In particular for this workstation, I was considering
purchasing SLES/SLED but I’m absolutely relieved that I did not given the problems I’ve had with Leap.
This is the first time since S.u.S.E. 5, I’ve decided not to install SUSE/openSUSE because it was not fit-for-purpose.
Of course this is a disappointment. I now find myself in the rare position of agreeing with something Dedoimedo has said
Leap? More of plunge.' For now I might keep Leap on my laptop, but otherwise I'll give Leap a skip’, and
recommend others do likewise. I hope this is not the case for the next version.