Lewis' Blog Tales from the trenches of information technology


Hate KDE Plasma5 on openSUSE Leap 42.1? Me, too.

After severely breaking my well-oiled openSUSE 13.2 installation, and wasting a couple hours trying to fix it (unbootable), I finally bit the bullet and just did an in-place upgrade to Leap 42.1.

Of course, the first thing I noticed was that my display driver was incorrect (max res 1024x768). The second thing was that the desktop was all but unusable.

My first assumption at that point was that it was just the resolution, and that I was indeed missing something which was somewhere off-screen. However, after installing the proper radeon driver, I was left with the same, barely usable desktop. What happened?

Apparently, the openSUSE team decided to switch to KDE's Plasma5 from KDE4 as the default desktop. Not only is Plasma5 unfinished (unfinished=still missing some expected functionality and components common to KDE4), but it seemed (for me) to leak memory badly and do a number of other not-very-nice things when moving windows and such. In addition, the kicker was awkward to use, cluttered to read, and decidedly non-SuSE in appearance.

I tried a few new themes, thinking that perhaps it was just the rather unbranded, default KDE theme which was at fault, but alas, nothing would help.

I stumbled upon this thread in the openSUSE forums, which provided some great links.

Once I got KDE4 back (as well as my old familiar desktop selector menu at login), I discovered that my Apper widget was missing from my panel. I fixed that by downgrading to Apper from plasma5-pk-updater, then uninstalling plasma5-pk-updater and friends (breaking the pattern to satisfy the dep solver), and then marking Apper as locked and plasma5-pk-updater (and friends) as taboo (never install).

Perhaps at some point I'll provide a detailed set of instructions for all of this, but for now, my heartfelt thanks to Wolfgang Bauer (wolfi323) for his wonderful repo and build of plasma5-session (which allows switching back and forth between desktops).


Migrating a bare-metal Windows 2000 install to a VirtualBox guest

A client's sole remaining W2K box started having boot issues the other day. It had been on the slate for about a year (or two or three) for an upgrade, but somehow, it just kept chugging along, so we left it be. Well, after confirming that the drive hardware (80GB Western Digital SATA) was in good shape (I did this from a Parted Magic USB stick boot, running just some rudimentary SMART diagnostics), and yet still unable to get W2K to move beyond the first graphical screen during startup, we decided that the time had come for a change.


Multiple default routes / public gateway IPs under Linux

I recently had the need to configure a server for a client with multiple public IPv4 addresses routing to the internet and the requirement to switch between them at will while browsing (http traffic only).

There are a number of articles available on the net dealing with this type of situation, mainly focused on using iproute2, ToS tagging, and Squid (see references, below). However, I bumped into an issue with openSUSE 12.1 where it would stubbornly refuse to accept certain (otherwise valid) ToS (DSCP) values (see https://bugzilla.novell.com/show_bug.cgi?id=770785 for my bug report). This severely limited the number of possible values I could use, and thus, the number of possible public IP addresses.


Updating Firefox on Linux: the Dreaded “Couldn’t load XPCOM”

I bumped into this annoyance while updating my openSUSE 11.4 workstation tonight.

There are numerous mentions of this issue on the net, and numerous suggestions for addressing it. However, none of them (which I saw) really hits on the underlying problem, which is that somewhere, somehow, XPCOM can't start.

To understand what's going on, it's important to have a basic understanding of what XPCOM is, and how it is involved with Mozilla apps. XPCOM is an acronym for  "Cross Platform Component Object Model," which is Mozilla's equivalent technology to CORBA or Microsoft's COM. Like any other "object model," XPCOM's function is to provide a modular framework vs a monolithic one. This modularization allows XPCOM to be (mostly) platform-neutral, making it possible to run the Gecko rendering engine on a variety of platforms. So, as the Gecko engine is composed of XPCOM components, if XPCOM cannot start, Gecko cannot start. If Gecko cannot start, then there is no rendering engine for the application, essentially stopping whichever Mozilla-based app one might wish to run, before it even gets started.


Resolving remote X sessions via VNC under openSUSE 11

Why isn't anything as easy as it should be?

I just set up a new router for a client on a Sputnik-managed network, and created the proper network rule in the Sputnik Central Control server to direct port 5901 traffic through to the management workstation, which runs openSUSE 11.3. Sounds simple enough, right?

The connection went through with no problem, and I got my familiar login screen. Upon entering my credentials, the session immediately shut down. I tried all sorts of different window manager options, all to no avail.

Finally, I hit on this little gem, mentioning commenting out the IPv6 loopback reference in the hosts file. Luckily, via ssh, I was able to get into the box and make that tweak:


# special IPv6 addresses
::1 localhost ipv6-localhost ipv6-loopback


# special IPv6 addresses
#::1 localhost ipv6-localhost ipv6-loopback


Now, why was that broken in the first place by the presence of the IPv6 loopback reference (IPv6 is turned off in the box), and further, why wasn't that fixed (you mean the original poster of the above forum comment and I are the only two people to have ever seen this, and as neither of us reported it, the bug hasn't been addressed?) between 11.1 and 11.3?

Filed under: openSUSE No Comments

Running remote X sessions against old Linux distros

I had occasion last evening to connect to a Red Hat 5.2 server. No, Not Red Hat Enterprise Linux 5, but Red Hat 5.2, as in, before Fedora.

I built the server for a client when 5.2 was the current release of Red Hat, on a Compaq Proliant 1850R server with dual Pentium II's and 512MB(?) RAM in July of 1999. The only hardware replacements on that machine have been a cooling fan (recently) and one of the redundant power supplies (several months ago). Frankly, it was supposed to have been decommissioned quite a while back, but somehow, we just never got around to it, and as it keeps doing what it needs to do, and the need for the single app which it hosts has been dwindling, it just hasn't been bumped up the list.

At the client's location, we have been plagued recently with some rather nasty power outages, prompting us to increase UPS capacity. We currently have two APC 3000VA XL units in the rack, along with a 2200VA unit. The two 3000's have network management cards in them, and the NetWare cluster and W2K3 Citrix server are configured using APC's Network Shutdown software.

Unfortunately, there is nothing currently available from APC which will run on a 2.4 Linux kernel (please someone, correct me if I am wrong in this regard), and when I attempted to build apcupsd on it, I was thwarted by some outdated libraries (and updating libraries on an 11-year-old Linux distro is a very difficult process). As the machine already had APC's PowerChute 4.5.1 for Linux installed on it (2001), I figured I'd just tweak the settings and cable the server to the UPS via serial.

Naturally, I wanted to have a look-see at the xpowerchute GUI.