Preparing For The Big Update
I am a tad late for the party. Slackware 14.2 was released June 30, 2016. While I have wanted for some time to update all of my 14.1 32-bit systems to 64-bit, getting there was a matter of waiting for life to provide me the time. Other responsibilities and requirements prevailed.
I have been tinkering with Slackware 14.2 64-bit on my Thinkpad T400 laptop.
Time for me to pause with updating all of my computers. I foresee some challenges ahead. I need to coordinate updating all systems.
I have written many shell scripts. Through my experiences the past two and half years of using some non Slackware distros alongside Slackware, the scripts have been tweaked to accommodate pre-systemd Debian and systemd. I am grateful for that experience and exposure. I learned a lot. Yet something always breaks when updating or changing operating systems.
One concern is coordinating package management with my Slackware server. There will be a transition period with mixed 14.1 32-bit and 14.2 64-bit systems. Previously, keeping Slackware systems synchronized was straightforward.
I searched for ways to distinguish between a 32-bit and 64-bit system. Oddly, I found no differences in /etc/slackware-version. One way is the uname command. Another is the 32-bit version does not contain a /usr/lib64 directory. Another method is the slackpkg mirror selection. Other methods include file /sbin/init | grep 32[64]-bit and getconf LONG_BIT.
Another concern is for years I have maintained a local mirror of the stock Slackware repositories. This helps me control bandwidth usage by downloading updated packages only once for all systems. I plan to continue that local support because my LAN server will remain Slackware. I anticipated this move a long time ago and already have both 32-bit and 64-bit 14.1 and 14.2 local mirrors.
Another related challenge is synchronizing multiple mixed Slackware systems. For me that includes /home and /usr/local, which I install on separate partitions. For Slackware systems I like to keep most of /etc synchronized too. I use an rsync wrapper script along with an exclusions file. For years I have modified /etc/rc.d scripts in Slackware.
Despite the lack of a large binary repository system in Slackware, through the years I have been able to find most of the packages I want. In that respect I have been able to keep Slackware and other distros I have used synchronized with respect to work flows.
Another component that might be different when updating from 32-bit to 64-bit is VirtualBox. I compile my own package.
A popular belief and practice is VirtualBox does not compile on 64-bit without first installing multilib 32-bit support. The stock Slackware does not include multilib. There is only one way to obtain multilib support and that is through a third-party repository maintained by one of the trusted Slackware developers. VirtualBox does not need multilib at run-time, only during compiling.
Many Slackers using 64-bit use the Oracle generic *.run script to install the 64-bit version of VirtualBox. I prefer a package approach. Odd that none of the Slackware gurus have created a package script wrapper for the *.run script. That said, I discovered some valuable information that compiling VirtualBox on 64-bit is possible. Just do not compile the Guest Additions ISO image. This will be one of my first tests as soon as I have a 64-bit Slackware system running.
Another grit test is compiling a preferred older version of XBMC.
Posted: Category: Usability Tagged: Slackware
Next: The Big Update
Previous: Updating Slackware