Technology Tales

Trying out OpenSolaris

Having been programming (mostly in SAS as it happens) on Sun’s venerable Solaris operating system platform at work since the start of this year, the chance to try OpenSolaris x86 edition in a VMware virtual machine seemed a good opportunity for advancing my skills.

Prior to this, my exposure to Solaris was when I was at university and things have moved on a bit since then, not least on the technology side but also in terms of my own skills. In those days, my mindset was fixed by exposure to macOS and Windows with their point-and-click functionality; the fact that the terminals that we were using were ancient didn’t make for a positive impression. You can see below what I mean. And the concept of tackling a command line, even one as powerful as that in UNIX, armed with a good book was somehow foreign to me.

Mind you, in those pre-Safari days, getting your hands on books not in the university library was an expensive outing for the student finances. Armed with years of programming and web development experience, the UNIX command line now looks like a powerful tool to be used to the greatest advantage. Years of exposure to Perl and Linux have made the tool a less daunting one for me. Also, the availability of shell scripting makes the Windows batch file language look positively archaic. The default ksh shell (I believe that it is ksh88) in Solaris is not as friendly as it could be, but bash is available on demand, so life isn’t that uncomfortable on the command line.

To date, my experience of OpenSolaris has been brief because I wrecked the installation while trying to sort out an annoying graphics issue that appeared after installing VMware Tools (drivers for various pseudo-devices) on OpenSolaris; I have yet to put things back. The installation procedure is pretty painless for what is a technical operating system. The Community: Tools section of the OpenSolaris website has articles on installation and installation under VMware is discussed on Developer’s Quarterdeck Log.

As regards a desktop environment, you have a choice between the ubiquitous Gnome and Sun’s own CDE, of which I have seen plenty at work. As it happened, I installed the developer edition, but there are the usual Linux mainstays on the desktop: StarOffice (in place of OpenOffice), GIMP, Mozilla Firefox, etc. One thing that I wasn’t able to sort out was the internet connection, and that may be because ZoneAlarm was blacklisting VMware at the time of installation. All in all, it looked like a far friendlier environment for users than that which I encountered during my early years on UNIX. I must get it back in action and take things on from here…

Installing Nightingale music player on Ubuntu 13.04

Ever since the Songbird project concentrated its efforts to support only Windows and OS X, the Firefox-based music player has been absent from a Linux user’s world. However, the project is open source and a fork called Nightingale now fulfils the same needs. Intriguingly, it too is available for Windows for OS X users so I am left wondering why that overlap has happened. However, Songbird also is available as a web app and as an app on both Android and iOS while Nightingale sticks to being a desktop application.

To add it to Ubuntu, you need to set up a new repository. That can be done using the Software Centre but issuing a command in a terminal can be so much quicker and cleaner so here it is:

sudo add-apt-repository ppa:nightingaleteam/nightingale-release

Apart from entering your password, there will be prompt to continue by pressing the carriage return key or cancelling with CTRL + C. For our purposes, it is the first action that’s needed and once that’s done the needful, you can execute the following command:

sudo apt-get update && sudo apt-get install nightingale

This is in two parts: the first updates the repositories on your system and second actually installs the software. When that is complete, you are ready run Nightingale and, with the repository, staying up to date is not chore either. In fact, using the above commands brings another advantage and it is that they should in any Ubuntu derivatives such as Linux Mint.

Getting VirtualBox working on Ubuntu after a kernel upgrade

In previous posts, I have talked about getting VMware Workstation back on its feet again after a kernel upgrade. It also seems that VirtualBox is prone to the same sort of affliction. However, while VMware Workstation fails to start at all, VirtualBox at least starts itself even if it cannot get a virtual machine going and generates errors instead.

My usual course of action is to fire up Synaptic and install the drivers for the relevant kernel. Looking for virtualbox-ose-modules-[kernel version and type] and installing that usually resolves the problem. For example, at the time of writing, the latest file available for my system would be virtualbox-ose-modules-2.6.24-19-generic.  If you are a command line fan, the command for this would be:

sudo apt-get install virtualbox-ose-modules-2.6.24-19-generic

The next thing to do would be to issue the command to start the vboxdrv service and you’d be all set:

sudo /etc/init.d/vboxdrv start

There is one point of weakness (an Achilles heal, if you like) with all of this: the relevant modules need to be available in the first place and I hit a glitch after updating the kernel to 2.6.24-20 when they weren’t; I do wonder why Canonical fail to keep both in step with one another and why the new kernel modules don’t come through the updates automatically either. However, there is a way around this too. That means installing virtualbox-ose-source via either Synaptic or the command line:

sudo apt-get install virtualbox-ose-source

The subsequent steps involve issuing more commands to perform a reinstallation from the source code:

sudo m-a prepare

sudo m-a auto-install virtualbox-ose

Once these are complete, the next is to start the vbox drv as described earlier and to add yourself to vboxusers group if you’re still having trouble:

sudo adduser [your username] vboxusers

The source code installation option certainly got me up and running again and I’ll be keeping it on hand for use should the situation raise its head again.

An in situ upgrade to Linux Mint 12

Though it isn’t the recommended approach, I have ended up upgrading to Linux Mint 12 from Linux Mint 11 using an in situ route. Having attempted this before with a VirtualBox hosted installation, I am well aware of the possibility of things going wrong. Then, a full re-installation was needed to remedy the situation. With that in mind, I made a number of backups in the case of an emergency fresh installation of the latest release of Linux Mint. Apache and VirtualBox configuration files together with MySQL backups were put where they could be retrieved should that be required. The same applied to the list of installed packages on my system. So far, I haven’t needed to use these, but there is no point in taking too many chances.

The first step in an in-situ Linux Mint upgrade is to edit /etc/apt/sources.list. In the repository location definitions, any reference to katya (11) was changed to lisa (for 12) and the same applied to any appearance of natty (Ubuntu 11.04) which needed to become oneiric (Ubuntu 11.10). With that done, it was time to issue the following command (all one line even if it is broken here):

sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

Once that had completed, it was time to add the new additions that come with Linux Mint 12 to my system using a combination of apt-get, aptitude and Synaptic; the process took a few cycles. GNOME already was in place from prior experimentation, so there was no need to add this anew. However, I need to instate MGSE to gain the default Linux Mint customisations of GNOME 3. Along with that, I decided to add MATE, the fork of GNOME 2. That necessitated the removal of two old libraries (libgcr0 and libgpp11, if I recall correctly but it will tell you what is causing any conflict) using Synaptic. With MGSE and MATE in place, it was time to install LightDM and its Unity greeter to get the Linux Mint login screen. Using GDM wasn’t giving a very smooth visual experience and Ubuntu, the basis of Linux Mint, uses LightDM anyway. Even using the GTK greeter with LightDM produced a clunky login box in front of a garish screen. Configuration tweaks could have improved on this but it seems that using LightDM and Unity greeter is what gives the intended setup and experience.

With all of this complete, the system seemed to be running fine until the occasional desktop freeze occurred with Banshee running. Blaming that, I changed to Rhythmbox instead, though that helped only marginally. While this might be blamed on how I upgraded my system, things seemed to have steadied themselves in the week since then. As a test, I had the music player going for a few hours and there was no problem. With the call for testing of an update to MATE a few days ago, it now looks as if there may have been bugs in the original release of Linux Mint 12. Daily updates have added new versions of MGSE and MATE so that may have something to do with the increase in stability. Even so, I haven’t discounted the possibility of needing to do a fresh installation of Linux Mint 12 just yet. However, if things continue as they are, then it won’t be needed and that’s an upheaval avoided should things go that way. That’s why in situ upgrades are attractive though rolling distros like Arch Linux (these words are being written on a system running this) and LMDE are more so.

Getting Fedora working in VirtualBox

After a hiatus induced by disk errors seen on start up, I have gone having a go with Fedora again. In the world of real PC’s, its place has been taken by Debian so virtualisation was brought into play for my most recent explorations. I could have gone with 10, the current stable version, but curiosity got the better of me and I downloaded a pre-release version of 11 instead.

On my way to getting that instated, I encountered two issues. The first of these was boot failure with the message like this:

FATAL: INT18: BOOT FAILURE

As it turned out, that was easily sorted. I was performing the installation from a DVD image mounted as if it were a real DVD and laziness or some other similar reason had me rebooting with still mounted. There is an option to load the hard disk variant but it wasn’t happening, resulting in the message that’s above. A complete shut down and replacement of the virtual DVD with a real one set matters to rights.

The next trick was to get Guest Additions added but Fedora’s 2.6.29 was not what VirtualBox was expecting and it demanded the same ransom as Debian: gcc, make and kernel header files. Unfamiliarity had me firing up Fedora’s software installation software only to find that Synaptic seems to  beat it hands down in the search department. Turning to Google dredged up the following command to be executed and that got me further:

yum install binutils gcc make patch libgomp glibc-headers glibc-devel kernel-headers kernel-devel

However, the installed kernel headers didn’t match the kernel but a reboot fixed that once the kernel was updated. Then, the Guest Additions installed themselves as intended with necessary compilations to match the installed kernel.

The procedures that I have described here would, it seems, work for Fedora 10 and they certainly have bequeathed me  a working system. I have had a little poke and a beta of Firefox 3.5 is included and I saw sign of OpenOffice 3.1 too. So, it looks very cutting edge, easily so in comparison with Ubuntu and Debian. Apart from one or niggles, it seems to run smoothly too. Firstly, don’t use the command shutdown -h now to close the thing down or you’ll cause VirtualBox to choke. Using the usual means ensures that all goes well, though. The other irritation is that it doesn’t connect to the network without a poke from me. Whether SELinux is to blame for this or not, I cannot tell but it might be something for consideration by the powers than be. That these are the sorts of things that I have noticed should itself be telling you that I have no major cause for complaint. I have mulled over a move to Fedora in the past and that option remains as strong as ever but Ubuntu is not forcing me to look at an alternative and the fact that I know how to achieve what I need is resulting in inertia anyway.

A little look at Debian 7.0

Having a virtual machine with Debian 6 on there, I was interested to hear that Debian 7.0 is out. In another VM, I decided to give it a go. Installing it on there using the Net Install CD image took a little while but proved fairly standard with my choice of the GUI-based option. GNOME was the desktop environment with which I went and all started up without any real fuss after the installation was complete; it even disconnnected the CD image from the VM before rebooting, a common failing in many Linux operating installations that lands into the installation cycle again unless you kill the virtual machine.

Though the GNOME desktop looked familiar, a certain amount of conservatism reigned too since the version was 3.4.2. That was no bad thing since raiding the GNOME Extension site for a set of mature extensions was made all the more easy. In fact, a certain number of these was included in the standard installation anyway and the omission of a power off entry on the user menu was corrected as a matter of course without needing any intervention from this user. Adding to what already was there made for a more friendly desktop experience in a short period of time.

Debian’s variant of Firefox , Iceweasel, is version 10 so a bit of tweaking is needed to get the latest version. LibreOffice is there now too and it’s version 3.5 rather than 4. Shotwell too is the older 0.12 and not the 0.14 that is found in the likes of Ubuntu 13.04. As it happens, GIMP is about the only software with a current version and that is 2.8; a slower release cycle may be the cause of that though. All in all, the general sense is that older versions of current software are being included for the sake of stability and that is sensible too so I am not complaining very much about this at all.

The reason for not complaining is that the very reason for having a virtual machine with Debian 6 on there is to have Zinio and Dropbox available too. Adobe’s curtailment of support for Linux means that any application needing Adobe Air may not work on a more current Linux distribution. That affects Zinio so I’ll be retaining a Debian 6 instance for a while yet unless a bout of testing reveals that a move to the newer version is possible. As for Dropbox, I am sure that I can recall why I moved it onto Debian but it’s working well on there so I am in no hurry to move it over either. There are times when slower software development cycles are better…

A need to update graphics hardware

Not being a gaming enthusiast, having to upgrade graphics cards in PC’s is not something that I do very often or even rate as a priority. However, two PC’s in my possession have had that very piece of hardware upgraded on them and it’s not because anything was broken either. My backup machine has seen quite a few Linux distros on there since I built it nearly four years ago. The motherboard is an ASRock K10N78 that sourced from MicroDirect and it has onboard an NVIDIA graphics chip that has performed well if not spectacularly. One glitch that always existed was a less than optimal text rendering in web browsers but that never was enough to get me to add a graphics card to the machine.

More recently, I ran into trouble with Sabayon 13.04 with only the 2D variant of the Cinnamon desktop environment working on it and things getting totally non-functional when a full re-installation of the GNOME edition was attempted. Everything went fine until I added the latest updates to the system when a reboot revealed that it was impossible to boot into a desktop environment. Some will relish this as a challenge but I need to admit that I am not one of those. In fact, I tried out two Arch-based distros on the same PC and got the same results following a system update on each. So, my explorations of Antergos and Manjaro have to continue in virtual machines instead.

To get a working system, I gave Linux Mint 15 Cinnamon a go and that worked a treat. However, I couldn’t ignore that the cutting edge distros that I tried before it all took exception to the onboard NVIDIA graphics. systemd has been implemented in all of these and it seems reasonable to think that it is coming to Linux Mint at some stage in the future so I went about getting a graphics card to add into the machine. Having had good experiences with ATi’s Radeon in the past, I stuck with it even though it now is in the hands of AMD. Not being that fussed so long there was Linux driver support, I picked up a Radeon HD 6450 card from PC World. Adding it into the PC was a simpler of switching off the machine, slotting in the card, closing it up and powering it on again. Only later on did I set the BIOS to look for PCI Express graphics before anything else and I could have got away without doing that. Then, I made use of the Linux Mint Additional Driver applet in its setting panel to add in the proprietary driver before restarting the machine to see if there were any visual benefits. To sort out the web browser font rendering, I used the Fonts applet in the same settings panel and selected full RGBA hinting. The improvement was unmissable if not still like the appearance of fonts on my main machine. Overall, there had been an improvement and a spot of future proofing too.

That tinkering with the standby machine got me wondering about what I had on my main PC. As well as onboard Radeon graphics, it also gained a Radeon 4650 card for which 3D support wasn’t being made available by Ubuntu GNOME 12.10 or 13.04 to VMware Player and it wasn’t happy about this when a virtual machine was set to have 3D support. Adding the latest fglrx driver only ensured that I got a command line instead of a graphical interface. Issuing one of the following commands and rebooting was the only remedy:

sudo apt-get remove fglrx

sudo apt-get remove fglrx-updates

Looking at the AMD website revealed that they no longer support 2000, 3000 or 4000 series Radeon cards with their latest Catalyst driver the last version that did not install on my machine since it was built for version 3.4.x of the Linux kernel. A new graphics card then was in order if I wanted 3D graphics in VWware VM’s and both GNOME and Cinnamon appear to need this capability. Another ASUS card, a Radeon HD 6670, duly was acquired and installed in a manner similar to the Radeon HD 6450 on the standby PC. Apart from not needing to alter the font rendering (there is a Font tab on Gnome Tweak Tool where this can be set), the only real exception was to add the Jockey software to my main PC for installation of the proprietary Radeon driver. The following command does this:

sudo apt-get install jockey-kde

When that was done I issue the jockey-kde command and selected the first entry on the list. The machine worked as it should on restarting apart from an AMD message at the bottom right hand corner bemoaning unrecognised hardware. There had been two entries on that Jockey list with exactly the same name so it was time to select the second of these and see how it went. On restarting, the incompatibility message had gone and all was well. VMware even started virtual machines with 3D support without any messages so the upgrade did the needful there.

Hearing of someone doing two PC graphics card upgrades in a weekend may make you see them as an enthusiast but my disinterest in computer gaming belies this. Maybe it highlights that Linux operating systems need 3D more than might be expected. The Cinnamon desktop environment now issues messages if it is operating in 2D mode with software 3D rendering and GNOME always had the tendency to fall back to classic mode, as it had been doing when Sabayon was installed on my standby PC. However, there remain cases where Linux can rejuvenate older hardware and I installed Lubuntu onto a machine with 10 year old technology on there (an 1100 MHz Athlon CPU, 1GB of RAM and 60GB of hard drive space in case dating from 1998) and it works surprisingly well too.

It seems that having fancier desktop environments like GNOME Shell and Cinnamon means having the hardware on which it could run. For a while, I have been tempted by the possibility of a new PC since even my main machine is not far from four years old either. However, I also spied a CPU, motherboard and RAM bundle featuring an Intel Core i5-4670 CPU, 8GB of Corsair Vengence Pro Blue memory and a Gigabyte Z87-HD3 ATX motherboard included as part of a pre-built bundle (with a heatsink and fan for the CPU) for around £420. Even for someone who has used AMD CPU’s since 1998, that does look tempting but I’ll hold off before making any such upgrade decisions. Apart from exercising sensible spending restraint, waiting for Linux UEFI support to mature a little more may be no bad idea either.

Update 2013-06-23: The new graphics card in my main machine is working as it should and has reduced the number of system error report messages turning up too; maybe Ubuntu GNOME 13.04 didn’t fancy the old graphics card all that much. A rogue .fonts.conf file was found in my home area on the standby machine and removing it has improved how fonts are displayed on there immeasurably. If you find one on your system, it’s worth doing the same or renaming it to see if it helps. Otherwise, tinkering with the font rendering settings is another beneficial act and it even helps on Debian 6 too and that uses GNOME 2! Seeing what happens on Debian 7.1 could be something that I go testing sometime.

ERROR: Can’t find the archive-keyring

When I recently did my usual system update for the stable version Ubuntu GNOME, there were some updates pertaining to apt and the process failed when I executed the following command:

sudo apt-get upgrade

Usefully, some messages were issued and here’s a flavour:

Setting up apt (0.9.9.1~ubuntu3.1) …
ERROR: Can’t find the archive-keyring
Is the ubuntu-keyring package installed?
dpkg: error processing apt (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
apt
E: Sub-process /usr/bin/dpkg returned an error code (1)

Some searching on the web revealed that the problem was that there were no files in /usr/share/keyring when there should have been and I had not removed them myself so I have no idea how they disappeared. Various remedies were tried and any that needed software installed were non-starters because apt was disabled by the lack of keyring files. The workaround that restored things for me was to take a copy of the files in /usr/share/keyring from an Ubuntu GNOME 14.04 installation in a VirtualBox VM and copy them in to the same location in its Ubuntu GNOME 13.10 host. For those without such resources, I have packaged them in a zip file below. Other remedies like Y PPA also were suggested where I was reading but that software package needed installing beforehand so it was little use to me when the likes of Synaptic were disabled. If there are other remedies that do not involve an operating system re-installation, I would like to know about them too as well as possible causes for the file loss in the first place and how to avoid these.

Ubuntu Keyrings

Interrogating Solaris hardware for installed CPU and memory resources

There are times when working with a Solaris server that you need to know a little more about the hardware configuration. Knowing how much memory that you have and how many processors there are can be very useful to know if you are not to hog such resources.

The command for revealing how much memory has been installed is:

prtconf -v

Since memory is often allocated to individual CPU’s, then knowing how many are on the system is a must. This command will give you the bare number:

psrinfo -p

The following variant provides the full detail that you see below it:

psrinfo -v

Output:

Status of virtual processor 0 as of: 10/06/2008 16:47:54
  on-line since 09/13/2008 14:47:52.
  The sparcv9 processor operates at 1503 MHz,
        and has a sparcv9 floating point processor.
Status of virtual processor 1 as of: 10/06/2008 16:47:54
  on-line since 09/13/2008 14:47:49.
  The sparcv9 processor operates at 1503 MHz,
        and has a sparcv9 floating point processor. 

For a level intermediate between both extremes, try this to get what you see below it:

psrinfo -vp

Output:

The physical processor has 1 virtual processor (0)
  UltraSPARC-IIIi (portid 0 impl 0x16 ver 0x34 clock 1503 MHz)
The physical processor has 1 virtual processor (1)
  UltraSPARC-IIIi (portid 1 impl 0x16 ver 0x34 clock 1503 MHz)

Changing from to Nvidia Graphics Drivers on Linux Mint Debian Edition 64-bit

One way of doing this is to go to the Nvidia website and download the latest file from the relevant page on there. Then, the next stage is to restart your PC and choose rescue mode instead of the more usual graphical option. This drops you onto a command shell that is requesting your root password. Once this is done, you can move onto the next stage of the exercise. Migrate to the directory where the *.run file is located and issuing a command similar to the following:

bash NVIDIA-Linux-x86_64-295.40.run

The above was the latest file available at the time of writing so the name may have changed by the time that you read this. If the executable asks to modify your X configuration file, I believe that the best course is to let it do that. Editing it yourself or running nvidia-xconfig are alternative approaches if you so prefer.

Proprietary Nvidia drivers are included the repositories for Linux Mint Debian Edition so that may be a better course of action since you will get updates through normal system update channels. Then, the course of action is to start by issuing the following installation comands:

sudo apt-get install module-assistant
sudo apt-get install nvidia-kernel-common
sudo apt-get install nvidia-glx
sudo apt-get install kernel-source-NVIDIA
sudo apt-get install nvidia-xconfig

Once those have completed, issuing the following in turn will complete the job ahead of a reboot:

sudo m-a a-i nvidia
sudo modprobe nvidia
sudo nvidia-xconfig

If you reboot before running the above like I did, you will get a black screen with a flashing cursor instead of a full desktop because X failed to load. Then, the remedy is to reboot the machine and choose the rescue mode option, provide the root password and issue the three commands (at this point, the sudo prefix can be dropped because it’s unneeded) then. Another reboot will see order restored and the new driver in place. Running the following at that point will do a check on things as will be the general appearance of everything:

glxinfo | grep render