A First Attempt with Arch Linux

Having heard great things about Arch Linux, I thought I would give it a try. I’ve enjoyed trying different Linux versions over the years, and have found some good environments.

Unfortunately, Arch Linux is not one of them – at least judging according to my initial installation.

The initial install gives you a text-based environment – no GUI here. This can be almost forgivable – but the installation had some hiccups. If you decide to install Arch Linux, don’t select anything other than the core resource: adding extras will only cause things to break. Stick with your CDROM installation media and forget the rest.

Then, after installation, there are a number of tasks to do. As long as you stick with the Beginner’s Guide, all should work just fine. The problems begin when you get into the extras. Most of these problems have solutions; however, one should not come across one problem after another.

Here are the problems I’ve experienced in just a few hours time after initial installation:

  • xdm spawning too many times; pausing for 5 minutes – this because xdm wasn’t installed but /etc/inittab was trying to start it.
  • package conflict with /etc/mtab
  • package conflict with /etc/profile.d/locale.sh
  • configuration of Window Maker overwrites ~/.xinitrc
  • configuring PAM to use ecryptfs didn’t work
  • encrypting home directory appears to have encrypted ~/Private and not ~
  • ecryptfs documentation is obsolete
  • running XDM loops back to login screen after successful login
  • running GDM fails
  • sudo wasn’t part of the main install
  • a new user wasn’t part of the main install
  • the documentation for adding a new user puts the user in the wheel group if you do it manually – but not if you do it with useradd
  • during installation, old install messages are not removed
  • perl is not part of the base install
  • X installs with a network listener active

The two biggest problems are the following:

  1. Bugs are just documented, not fixed.
  2. Nothing is configured!

When a package is installed, it should be ready to go – it should “just work.” Nothing “just works” on Arch. It is one thing to let us choose which packages we want and how we want; however, there should not be a day’s worth (or more!) of work to get things working. Every package seemed to have bugs and things that didn’t work right – and needed special instructions to configure it.

To do anything with Arch, it requires a huge effort to install a large number of packages – and to hand-configure most. It is a minimalist distribution that is built up to be what someone wants. However, I thought their choice of simplicity quotes was ironic:

Perfection is achieved not when there is nothing more to add, but rather when there is nothing more to take away.

I say ironic because there is nothing that can be taken away from Arch Linux; packages must be added.

This is a big disappointment; I had such high hopes for Arch Linux. I thought it would be an simpler version of Gentoo or Slackware; not so.

    Installing VMware vSphere CLI 4.0 in Ubuntu 10.04 LTS

    Installing the VMware vSphere Command Line Interface (CLI) has the potential for problems. In my case, it generated an error – a three-year old error. Perl returns the error:

    undefined symbol: Perl_Tstack_sp_ptr

    Not only has this error been around for three years, it also has shown up in numerous other instances. Ed Haletky wrestled with the error in VMware vSphere CLI back in June of 2008. The error surfaced in Arch Linux in 2008, both in running their package manager and in running cpan itself. This error also came up (again in 2008) in attempting to build and run Zimbra. (The response from Zimbra support was cold and unwavering: we don’t support that environment and won’t discuss it. How unfortunate.) The error also affected the installation of Bugzilla according to this email thread from 2009.

    On the Perl Porters mailing list, there is an in-depth response as to what causes this error. From reading these messages, it appears that there are two related causes:

    • Using modules compiled for Perl 5.8 with Perl 5.10
    • Using modules compiled against a threaded Perl with an unthreaded Perl

    One recommended solution is to recompile the modules using the cpan utility:

    cpan -r

    That may or may not be enough; it depends on if there were other errors. In attempting to run the vSphere CLI, I get this error:

    IO::Compress::Gzip version 2.02 required--this is only version 2.005

    To fix this, I ran cpan this way:

    cpan IO::Compress::Gzip

    In my case, that loaded IO::Compress::Gzip version 2.033.

    I also loaded the libxml2-dev package; I don’t know if that was necessary or not:

    apt-get install libxml2-dev

    Whenever using cpan, I always wonder how it affects my packaged installations and whether it installs for all users or just me (and how to control that) – but I’ve never had any problems and installs as root seem to go into /usr/local – which makes sense.

    Having done all this, I can now use the vSphere CLI to activate SNMP on the ESXi 4 servers. For the record, this is an integral part of ESXi 4 and supports all SNMP polling and traps – previously, only SNMP traps were supported. Certainly a nice improvement.