The Big Update
I stopped my big update to Slackware 14.2 64-bit. A few events in the process of moving from 14.1 32-bit to 14.2 64-bit motivated me to update in two separate steps rather than a big single step.
I am running a dedicated LAN server in my home LAN. Taking down a workstation disrupts little on the network. Taking down a home LAN server for maintenance and testing is doable and livable and not the same as an enterprise server. Yet I prefer an enterprise approach to performing administration and support. While I want to update my LAN server from Slackware 14.1 32-bit to 14.2 64-bit, the time involved is hefty. I want as little down time as possible. The obvious plan is do what most professionals do.
Test as much as possible on a separate system.
I had room for another partition on my Thinkpad T400 hard drive. I used that as my testing platform. There are limits, such as the laptop not actually being the server, but a significant amount of interoperability and script testing is possible in this manner, especially from the workstation perspective.
Reviewing the release documentation is the traditional first place to start. I found nothing dramatic in those notes.
I did not perform a full install. Notably not installing the KDE or BSD games packages.
I was unable to copy the ISO image to a USB flash drive. I tried two different brands. Neither would boot. I resorted to that ancient technology known as a DVD. Not as fast as USB but not painfully slow either. Curiously, I used one of the sticks to create a Slackware bootdisk and the stick worked fine. Some post-install sleuthing revealed a solution — using the isohybrid command. I use the mkisofs command to create my local Slackware ISO images, hence the original problem.
Installing 14.2 on the laptop looks much the same as past releases. Nothing earth shocking. I had a decent check list to get me through initial testing. Critical are a handful of apps that need to be recompiled and tested.
Compiling and testing 64-bit Firefox was fine. Likewise with VirtualBox. This is where the grand update stumbled.
I prefer to run an older version of XBMC. My short list of reasons are 1) I like organizing videos based on a simple directory structure rather than a database library and 2) I do not care for all of the 24/7 “phone home” connections newer versions of XBMC and now Kodi create. Newer versions have become too complex. Sometimes the older versions are simpler and work great. Sadly I could not compile this older version of XBMC 14.2 64-bit.
After a night’s rest I decided to avoid updating from 14.1 32-bit to 14.2 64-bit in one fell swoop. I would first update from Slackware 14.1 32-bit to 14.1 64-bit. Ensure everything compiles and runs. This would provide me a known starting point because I know the everything works in 14.1 32-bit. This approach would introduce me to 64-bit nuances without the changes of one system release to another.
Thereafter I could update directly to 14.2 64-bit rather than perform a fresh install of 14.2. Often packages compiled under a previous release continue to work fine in the new release without recompiling. If I could avoid compiling XBMC in 14.2 64-bit then hopefully the package compiled for 14.1 64-bit would still function.
This approach made more sense for stability and minimizing down time too. Getting 14.1 64-bit stabilized is an easier first step.
After compiling 64-bit versions of most of the packages I use in 32-bit, I again started testing. Again 64-bit Firefox and VirtualBox worked fine. XBMC compiled fine but refused to run with the infamous XBMC needs hardware accelerated OpenGL rendering error message.
Oops. I was still using the nouveau drivers. A reminder that my next main board purchase for my office system will use Intel video.
I needed to compile and install the NVidia proprietary drivers. On my 14.1 32-bit system I was running the 304.131 drivers. I visited the NVidia web site to grab 64-bit versions of the sources. I noticed 304.132 was available. I downloaded and compiled the newer version.
I discovered root had direct rendering but non-root users did not. The glxgears test utility barely ran. I searched the web for possible discussions. Nothing. I then restored the nouveau drivers. No direct rendering but glxgears ran without stuttering. Something was awry then with the proprietary drivers.
Back to the NVidia web site to grab the 64-bit versions of 304.131. I compiled, installed, and for good measure, rebooted. Everything worked. My conclusion is the 304.132 drivers are hosed. A fine way to waste several hours. With the video drivers out of the way, XBMC offered no complaints and ran as expected. Testing LIRC and the remote control went well too.
Try as I might, I could not get Remmina to function. The only clue was through the debug window that there was a VNC authentication problem. Rebooting back into my 32-bit system verified Remmina worked fine. I found a compiled package in the Microlinux repositories that worked.
There were more user tests. Yet much more quickly than I had anticipated, I had a 14.1 64-bit system that was almost identical to my 32-bit system.
This was on my office desktop. I am leaving things remain like this for a while. Watch for bugs and unseen and unanticipated bumps. Then update the remaining workstations. I will update the server last. Then sit again in another holding pattern for a while waiting for unexpected corner case issues to arise. I will let everything remain that ways to verify quiet operations, then restart again with updating to 14.2.
Posted: Category: Usability Tagged: Slackware
Next: Moving vnstat from 32-bit to 64-bit
Previous: Preparing For The Big Update