OpenSUSE 12.3 KDE - I like it

[dmeyer]

Funny -- I just took OpenSUSE 12.3 for a spin myself. The installer is absolutely incredible. You can very much fine tune the package collection before anything gets written to the hard drive. Quite an accomplishment. It is the most sophisticated installer I've ever seen.

If you want something that'll stay up-to-date, convert your installation to a Tumbleweed rolling release. I suspect it'll provide you with a similar fresh-from-the-compiler experience that we get with the Kubuntu backports PPA.

Not really needed. Just adding the KR410 repos is all he really needs. Enable the update repos and a couple others and you have a very up to date and great install. Tumbleweed breaks nvidia/catalyst repeatedly so its not newbie friendly.

General warning with people using openSUSE, untick stay subscribed to repositories when using one click install. Also, be patient, its a different way of doing things and zypper is very powerful but its also a little scary. It often gives unnecessarily scary warnings etc.

[67GTA]

Package management was always my thorn with openSUSE. I have been spoiled with apt always choosing the highest version, while zypper and yast are always fighting with each other. They install updates according to the repo priorities. You can actually downgrade/upgrade at the same time, and end up with a horrible mismatch of package versions. Adding repos to openSUSE WILL bork your system unless you pay attention to package versions and repo priorities. Of course this is before you get into "changing vendors" as they call it. The extra (community) repos/packages aren't always compatible with the openSUSE repos either. Package management in openSUSE is a nightmare which is sad because zypper is a nice tool.

[SteveRiley]

Well, I decided to give openSUSE another go. This time, on bare metal, not in a VM. And just to make it as challenging as possible, I decided to see how far I could get with the following goals:

• Dual-boot, keeping Kubuntu in place
• Integrate both Kubuntu and openSUSE with rEFInd
• Enable Tumbleweed
• Install the nVidia binary driver

This, of course, requires doing it on my T520 -- my main work machine. Woo hoo!


rEFInd

A few weeks ago, I decided to move away from directly booting the kernel via UEFI. The bug in kernel 3.8 that prevents adding new NVRAM variables was becoming a real pain. Plus, having to copy the kernel image to the EFI partition after every upgrade turned out to be a chore. So I've switched to using rEFInd, a beautifully simplistic UEFI boot manager. No longer do I need to have NVRAM variables for each kernel I want to boot, but instead just a single variable pointing to the rEFInd boot loader.

At a high level, rEFInd scans known locations for bootable EFI images (kernels, shells) and presents them in a menu. It knows how to work around various distro quirks. It can find all the kernels in /boot so long as I load the provided EXT4 driver. While the EFI partition is still mounted on /boot/efi, I no longer need to copy kernel images there. rEFInd is remarkably maintenance-free.


Partition setup

Originally, my partition table looked like this:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40         1048615   512.0 MiB   EF00  
   2         1048616       481296423   229.0 GiB   8300  
   3       481296424       500118151   9.0 GiB     8200

I needed to shrink #2 to allow space for the openSUSE partition. Being the annoyingly detailed person that I am, I wanted this new partition to become #3, and change swap to #4. Booting with a Gparted Live USB allowed me to change the size of #2 from 229.0 GiB to 120.0 GiB.

Then I rebooted back into Kubuntu. Using gdisk, I deleted the swap partition. I created a new /dev/sda3 partition of size 109.0 GiB, and a new /dev/sda4 swap partition of size 9.0 GiB. I formatted /dev/sda3 in my usual manner:

sudo mkfs.ext4 /dev/sda3
sudo tune2fs -o discard,journal_data_writeback /dev/sda3

I've grown to hate typing UUIDs for partitions, so I've reverted to using device names. Recalling that changing the swap device name can cause initramfs startup delays, I edited /etc/initramfs-tools/conf.d/resume to reflect the correct device name:

RESUME=/dev/sda4

I want each OS's partition to be available to the other, so I created a subdirectory in /mnt, and then made the necessary changes to /etc/fstab:

# <file system> <mount point> <type> <options>                      <dump> <pass>
/dev/sda1       /boot/efi     vfat   defaults                       0      1
/dev/sda2       /             ext4   noatime,discard,data=writeback 0      1
/dev/sda3       /mnt/openSUSE ext4   noatime,discard,data=writeback 0      1
/dev/sda4       none          swap   sw                             0      0
tmpfs           /tmp          tmpfs  noatime,mode=1777              0      0

Finally I updated Kubuntu's initramfs to read the new device configuration:

sudo update-initramfs -u -k all

The final result is this:

Number  Start (sector)    End (sector)  Size       Code  Name
   1              40         1048615   512.0 MiB   EF00  
   2         1048616       252708863   120.0 GiB   8300  
   3       252708864       481296423   109.0 GiB   8300  
   4       481296424       500118151   9.0 GiB     8200

Kubuntu took all this in stride...none of these changes affected the existing operating system at all.


Installing openSUSE

Just for the sheer difference, I downloaded the GNOME-based ISO. I knew that GNOME 3.8.1 is in Tumblweed, and I was curious to see what's new. Following the openSUSE wiki's directions, I dded the ISO onto a USB and tried to boot. After a few seconds of scrolling text, the boot froze. I know why: this T520 ThinkPad is one of a batch of nVidia-equipped machines that require a certain boot parameter, namely nox2apic.

For some reason, when booted in UEFI mode, the openSUSE installer menu lacks the option to specify kernel boot parameters. What to do? Somehow, I have to edit the grub.cfg on the USB. But it's an ISO9660 file system, which always mounts read-only! I reformatted the USB to have a single FAT32 partition, marked it active, and extracted the openSUSE ISO to the USB using Ark. Then I edited grub.cfg to add the kernel parameter. This got me farther in the boot process, but then another weird error, something about a mismatched MBR ID (?). So I dded the ISO again, and took a closer look. The result of that procedure actually creates two partitions on the USB. The first is, yes, a small FAT32 EFI partition, which is read-write! This partition contains an editable grub.cfg in which I added the nox2apic parameter. The other, much larger, partition is the ISO9660 file system containing the live image.

Finally, a bootable USB. Working my way through the installer, I specified the following:

• Keep /dev/sda1 as the EFI partition, and mount it to /boot/efi
• Don't format /dev/sda3 (since I already did that), but do mount it to /
• Don't install GRUB2 or any other boot loader -- very important, since I'm managing that with rEFInd now

The installer chugged along, performing everything exactly as it said it would. When I rebooted, rEFInd discovered the additional kernel in the /boot subdirectory of /dev/sda3! Yes, I love these little successes. I chose openSUSE's kernel (version 3.7 currently), boot text flew by, and GDM gracefully appeared. I logged in, and voila, GNOME Shell.

Similar to what I did in Kubuntu to see the openSUSE partition, I want to see the Kubuntu partition when booted to openSUSE. Like before, I created a subdirectory in /mnt, and then made the necessary changes to /etc/fstab:

# <file system> <mount point> <type> <options>                      <dump> <pass>
/dev/sda1       /boot/efi     vfat   defaults                       0      1
/dev/sda2       /mnt/Kubuntu  ext4   noatime,discard,data=writeback 0      1
/dev/sda3       /             ext4   noatime,discard,data=writeback 0      1
/dev/sda4       none          swap   sw                             0      0
tmpfs           /tmp          tmpfs  noatime,mode=1777              0      0

Tumbleweed

My main reason for performing this experiment at all is because I want to see what it's like to work with a rolling distribution. I know Arch would be another choice for that, but I feel that having some experience with an RPM-based distribution would be more valuable.

First I updated the installation:

sudo zypper refresh
sudo zypper dist-upgrade

Then I followed the instructions on the wiki page to convert to Tumbleweed. This brought along a new 3.9.1 kernel, which rEFInd dutifully placed in its menu. I really like this tool -- quite simple, and none of the brittleness that we all know plagues GRUB.


nVidia driver

The wiki warns that, with Tumbleweed, you have to go "the hard way." I downloaded the driver from nVidia's web site and followed the instructions on the wiki. But the installer script failed, throwing up an error about a missing version.h file. Turns out another package is required in addition to the three listed on the wiki: kernel-desktop-devel.

After I installed that, the script got a little farther, but complained about a version mismatch. For some reason, the linux symlink in /usr/src was pointing to the subdirectory for the 3.7 kernel source files. So I removed all versions of all kernel-devel and kernel-desktop-devel packages, then installed only the ones for the 3.9.1 kernel. With the symlink now correctly set, I could continue.

The script doesn't like having the Nouveau drivers loaded. It offered to blacklist them for me, which I permitted. You also need to recreate the initramfs, too, which the script won't do. The openSUSE command for that is mkinitrd.

After rebooting once more, and adding the kernel boot parameter "3" to force the system to boot to runlevel 3 (no X), the script seemed to have everything it needed. All the modules compiled. Then I received quite a number of prompts telling me that "(null) could not be symlinked to {something}, is that OK?" I simply OK-ed my way through every one of them. Apparently these aren't important, because after running nvidia-xconfig and one more reboot, the nVidia binary driver loaded without a hitch.


Cleaning up

I'm not really a fan of distro-specific branding. Fortunately, openSUSE makes this relatively painless to fix. Using the GUI version of YaST, I searched for every installed -branding-openSUSE package. As I marked each one for removal, YaST automatically marked the corresponding -branding-upstream package for installation. The only one that I had to keep was systemd-presets-branding-openSUSE -- removing that one would have removed most of the operating system.

Other elements were similarly easy to remove: nothing depends on Plymouth, so I could get rid of that without having to resort to the dummy package procedure Ubuntu requires. I had to use hostnamectl to change the computer's name, and manually add myself to the wheel group and edit visudo so that I can elevate without typing my password. I deleted a bunch of input method modules for languages I don't speak. I removed left-over GRUB packages and bits (even though the bootloader itself wasn't installed), got rid of Mono, and deleted firmware packages for hardware not present on my T520.


Overall first impressions

UEFI and rEFInd are, I think, critical elements that made this little project possible. I love not having to worry about MBR clobbering and repair, or dealing with conflicting boot managers.

Understanding Zypper and RPM-based package management is going to be time-consuming. I am so intimately familiar with APT and DEB that I feel somewhat lost here. For example, I haven't yet found an equivalent to apt-cache or apt-rdepends, both of which I use a lot. There appears to be no simple way to do "show me a list of all packages that depend on foo." I don't know what I'd need to pull out when it's time for the RPM equivalent of my favorite DEB surgical tool, dpkg. Perhaps the rpm utility? I'm not sure.

openSUSE switched to the systemd init system. Regardless of the arguments pro and con, this appears to be the trend; everyone but you-know-who has either made the switch or will soon. From my limited experience so far with systemd, I must say I like what I see.

GNOME Shell is...weird. 3.8.1 has a few more knobs and dials to twiddle. But it still has nowhere near the configurability of KDE. GNOME's browser, Epiphany (now simply called Web) is jokingly basic; Rekonq and even Konqueror are feature-rich in comparison.

Nevertheless, I enjoyed this adventure. All told, it took about four hours last night, from start to finish. Learning is good!

[SteveRiley]

Oh man, there is a major bug in GNOME 3.8.1. Many windows open up very tiny...as in 500 x 400 pixels or something. Seems like I'm constantly resizing almost everything. If an application uses multiple panes switching panes causes a revert-to-small event -- something as simple as changing Evolution's view from mail to calendar!

I do rather like GNOME's dynamic workspace thing, though. More than I thought I would. I have never investigated KDE's Activities much; wonder if there's a way to achieve something similar?

[dmeyer]

Package management was always my thorn with openSUSE. I have been spoiled with apt always choosing the highest version, while zypper and yast are always fighting with each other. They install updates according to the repo priorities. You can actually downgrade/upgrade at the same time, and end up with a horrible mismatch of package versions. Adding repos to openSUSE WILL bork your system unless you pay attention to package versions and repo priorities. Of course this is before you get into "changing vendors" as they call it. The extra (community) repos/packages aren't always compatible with the openSUSE repos either. Package management in openSUSE is a nightmare which is sad because zypper is a nice tool.

What? Zypper is light years ahead of apt. Also adding repos won't bork your system. The thing with openSUSE is that their default is to add a repo for each third party app which is silly. Many ppa's bork an *buntu distribution as well. The default in openSUSE might be poor but that's about it.

Also you shouldn't use "dist-upgrade" as the default updating method. Its a very different way of managing packages but it most certainly is not bad. On a technical level and for fine tuning one's system openSUSE is leap years ahead of Kubuntu. Its a different way of working and its not always as simple as it could be but it is most definitely not bad. Different is different, once your learn the system you come to love it.

[Snowhog]

Also you shouldn't use "dist-upgrade" as the default updating method.

Huh? It's the preferred method over upgrade -- IMO. It's the only method I use.

[dmeyer]

Huh? It's the preferred method over upgrade -- IMO. It's the only method I use.

"dist-upgrade" changes repos for packages on openSUSE. Essentially a set of packages is locked to a repo unless you tell it to change. This has pros and cons but I prefer it this way. So to avoid third party repos wrecking an openSUSE install just dont run "sudo zypper dup" unless you want the packages to change repos. For example lets say I want to upgrade from KDE 4.9 to KDE 4.10 on 12.3 I would run

sudo zypper ar -f <repo name> <repo alias>
sudo zypper refresh
sudo zypper dup --from <repo alias>

.

"dist-upgrade" on openSUSE is designed for moving from major release to major release more like "do-release-upgrade" except you need to manually change repo locations etc. Zypper's update is very intelligent and is pretty much analogous to "dist-upgrade" in terms of behaviour i.e. intelligent package adding/removing etc. Also you don't need too use "dup" to chage the repo of a set of packages, it just happens to be the best/fastest/easiest way to get all your packages set to a certain repo. Zypper is very different to apt but once you get used to it you'll love it.

P.S. I hope I didn't make this sound super complicated because it isn't. I'm just terrible at explaining and the fundamentally different way of managing packages can make things confusing at first. Zypper is different and is used differently.

[SteveRiley]

Huh? It's the preferred method over upgrade -- IMO. It's the only method I use.

dist-upgrade for APT/DEB is not equivalent to dist-upgrade for Zypper/RPM.

man pages for zypper up:

Update installed packages with newer versions, where possible. This command will not update packages which would require change of package vendor unless the vendor is specified in /etc/zypp/vendors.d, or which would require manual resolution of problems with dependencies. Such non-installable updates will then be listed in separate section of the summary as "The following package updates will NOT be installed:". To update individual packages, specify one or more package names. You can use the '*' and '?' wildcard characters in the package names to specify multiple packages matching the pattern.

man pages for zypper dup:

Perform a distribution upgrade. This command applies the state of (specified) repositories onto the system; upgrades (or even downgrades) installed packages to versions found in repositories, removes packages that are no longer in the repositories and pose a dependency problem for the upgrade, handles package splits and renames, etc. If no repositories are specified via --from or --repo options, zypper will do the upgrade with all defined repositories. This can be a problem if the system contains conflicting repositories, like repositories for two different distribution releases. This often happens if one forgets to remove older release repository after adding a new one, say openSUSE 11.1 and openSUSE 11.2. To avoid the above trouble, you can specify the repositories from which to do the upgrade using the --from or --repo options. The difference between these two is that when --repo is used, zypper acts as if it knew only the specified repositories, while with --from zypper can eventually use also the rest of enabled repositories to satisfy package dependencies.


NOTE: Differences between zypper update and zypper dist-upgrade

Choose zypper update to update packages to newer versions available for your product version while maintaining system integrity. zypper update will honor the following rules:

* no vendor changes
* no architecture changes
* no downgrades
* keep installed packages

When executing zypper dist-upgrade, all packages will be installed from the repositories currently enabled. This rule is enforced, so packages might change vendor or architecture or even might get downgraded. All packages that have unfulfilled dependencies after the upgrade will be uninstalled.

Unlike apt-get dist-upgrade, zypper dup can be used to perform an actual distribution upgrade. For this reason, it's more aggressive. It's also, according to the wiki, the only supported method for keeping Tumbleweed updated. This is likely because dup strives to keep an installation exactly aligned with the repositories.

[SteveRiley]

Zypper is very different to apt but once you get used to it you'll love it.

@dmeyer,

Using Zypper, how do I do this: "show me a list of all packages that depend on foo" ... I can't figure this out.

[dmeyer]

@dmeyer,

Using Zypper, how do I do this: "show me a list of all packages that depend on foo" ... I can't figure this out.

rpm -q --whatrequires <packagename>

It's really silly that there is no zypper command for it but it is planned.

[sumski]

@dmeyer, Steve, that feature has been added in latest libzypp/zypper (which is not yet in factory afaik, it's only in devel project for now):

zypper se --help
search (se) [options] [querystring] ...


Search for packages matching any of the given search strings.


  Command options:

    --match-substrings     Search for a match to partial words (default).
    --match-words          Search for a match to whole words only.
    --match-exact          Searches for an exact match of the search strings.
    --provides             Search for packages which provide the search strings.
    --recommends           Search for packages which recommend the search strings.
    --requires             Search for packages which require the search strings.
    --suggests             Search what packages are suggested by the search strings.
    --conflicts            Search packages conflicting with search strings.
    --obsoletes            Search for packages which obsolete the search strings.
-n, --name                 Useful together with dependency options, otherwise
                           searching in package name is default.
-f, --file-list            Search for a match in the file list of packages.
-d, --search-descriptions  Search also in package summaries and descriptions.
-C, --case-sensitive       Perform case-sensitive search.
-i, --installed-only       Show only packages that are already installed.
-u, --uninstalled-only     Show only packages that are not currently installed.
-t, --type <type>          Search only for packages of the specified type.
-r, --repo <alias|#|URI>   Search only in the specified repository.
    --sort-by-name         Sort packages by name (default).
    --sort-by-repo         Sort packages by repository.
-s, --details              Show each available version in each repository
                           on a separate line.
-v, --verbose              Like --details, with additional information where the
                           search has matched (useful for search in dependencies).

[NickStone]

I tried OpenSUSE 12.3 (KDE edition) after I had a problem with upgrading Manjaro. For me installation went without any issues except when it came to login it wouldn't allow me in. Upon reading their wiki pages I discovered that passwords needed to consist of alpha numerical characters and use both upper and lower case letters. So once I discovered that I re-installed set up the password to that format and was able to log in without issues.

I tried OpenSUSE 12.3 for about a week and in general everything was working fine. I wanted to remove Firefox so I attempted to use the software management tool in YaST however, when I selected firefox it wanted to replace it with Thunderbird along with a couple of other packages. I then looked at using the command line tool zypper to remove Firefox which it did without wanting to replace it with Thunderbird.

I have since replaced OpenSUSE 12.3 with Manjaro but would not hesitate to use OpenSUSE in the future.

[dmeyer]

I tried OpenSUSE 12.3 (KDE edition) after I had a problem with upgrading Manjaro. For me installation went without any issues except when it came to login it wouldn't allow me in. Upon reading their wiki pages I discovered that passwords needed to consist of alpha numerical characters and use both upper and lower case letters. So once I discovered that I re-installed set up the password to that format and was able to log in without issues.

I tried OpenSUSE 12.3 for about a week and in general everything was working fine. I wanted to remove Firefox so I attempted to use the software management tool in YaST however, when I selected firefox it wanted to replace it with Thunderbird along with a couple of other packages. I then looked at using the command line tool zypper to remove Firefox which it did without wanting to replace it with Thunderbird.

I have since replaced OpenSUSE 12.3 with Manjaro but would not hesitate to use OpenSUSE in the future.

By default any install from a live disc wants to install a huge amount of "recommended" packages. To fix it all you have to do is Software > Options > Ignore Recommended Packages for Already Installed Packages. That should fix the issue of it trying to install a billion packages after a fresh install. Else you end up with a very bloated system.

[Rich Oliver]

I've been on 12.3 for several months now. I've managed to lose my sound when upgrading to KDE 4.11, so I need to reinstall as fixing it seems to be beyond my capabilities. My main use is Scala development. I have all my eclipse installs, eclipse workspaces, java run times, scala tools, projects, fire fox profile and general office files organised within one /sdat folder, so its fairly easy for me to reinstall my working working environment, keep it backed up, or even use it on another machine. In future I'm going to put it all on its own partition and mount it as /sdat. Big stuff like films and distro images can go somewhere else. There's no need for them to be on an SSD. I don't really use the /home directory.

There's definitely some advantages to Kubuntu and Mint KDE for newish Linux users. I'm sure Kubuntu, Mint KDE and Fedora KDE could all work well for me. I don't really need to get KDE 4.11 straight away or officelibre 4. But, I'm looking for a distro that I can recommend other users to use. That's friendly to beginners. That could be the default Linux distro. It seems that Ubuntu was that default newbie friendly distro, but it is no longer. They fragmented the Linux desktop by leading everyone up the Gnome's garden path and then foisted Unity (is that a joke, I think we should refer to it as the Schism desktop, Upstart was well named along with the Mire display server) on us. I don't want any dependency on Mark Shuttleworth in my system. I could have stuck with Steve, developers, developers, developers, Balmer.

I like the fact that KDE is the Opensuse default. Kwin, plasma desktop and Dolphin seem like sensible linux defaults. They do a lot of Upsteam support, although not as much as Redhat. Although I haven't used it I really like the idea of Suse studio: the exact opposite of Canonical's recent attitude. Opensuse is also a pretty stable distro. I don't think new users need cutting edge. Its not as stable as Debian, but Debian vanilla does not strike me as accessible for newbies and its so behind the curve that it encourages people to build unstable distros on top of it. It strikes me that inexperienced people shouldn't be directed to unstable or rolling distros.

[kernelbasher]

Funny -- I just took OpenSUSE 12.3 for a spin myself. The installer is absolutely incredible. You can very much fine tune the package collection before anything gets written to the hard drive. Quite an accomplishment. It is the most sophisticated installer I've ever seen.

If you want something that'll stay up-to-date, convert your installation to a Tumbleweed rolling release. I suspect it'll provide you with a similar fresh-from-the-compiler experience that we get with the Kubuntu backports PPA.

Typically Steve
Tumbleweed is slower to update kde than if you use the OBS repos on a standard setup
You will of course get kernel updates that you wouldn't on a standard install (though this requires you manually install graphics drivers with every new kernel update)
Tumbleweed is not for the noobs, that's for sure.