A Few Days in the Slack 64-bit World
Author: Grant Coady
Published: March 27, 2007
Hardware: Intel DP965LT mobo with Intel Core 2 Duo CPU and 1GB main memory, 120GB + 160GB SATA hard drives and DVD burner + CDROM optical drives, a GeForce 6200 Graphics Accelerator.
Check here for more information and gotchas.
Day 1: Bluewhite64
I type this as I go, bluewhite second download:
ftp://mirror.inode.at/bluewhite64/bluewhite64-11.0-dvd-iso/bluewhite64-11.0-install-dvd.iso
also failed md5 checksum, but I give it a go anyway.
First boot failed to see the SATA disks, booted 'test26' and the SATA drives are visible—this is a good start!
Installer startup looks just like slackware :o)
I'm installing to /dev/sdb2 (8GB) and will boot via existing slack install, so lilo will be boot /dev/sdb2, root /dev/sdb2.
Hit setup... Bad news, it cannot see the CDROM, plan B? Install from hard drive.
Reboot to slackware and copy the DVD to /dev/sda6—cannot get slackware to see the DVD, reboot to openSUSE and copy the DVD to a local partition.
OpenSUSE has working hald and udev ;) Using the GUI to copy the DVD is a no-brainer... Except I forgot to mount /dev/sda6 and I'm copying to the freakin' mountpoint! Luckily there's enough room for it :)
Okay, copy install source to /dev/sda6 -> bw64, I'm doing this in an ssh session, underneath the GUI. For me, this is familiar territory.
Note: the 'slackware' directory is renamed to 'bluewhite64', so the install path will be /dev/sda6 -> /bw64/bluewhite64.
Here goes. The example for HDD install is labelled /stuff/bluewhite64!
Hah! Can see the install source :o))
Take the defaults from a 'menu' install—linuxdoc is corrupt, that's a relief 'cos I don't use it ;) Oops, qt is corrupt too :( That's bad.
Now I hit the install kernel from HDD cannot find kernels. Bug, copy /cdrom/bw64/kernels/test26.s/bzImage to /mnt/boot, as well as its config.
Reboot to slackware to make a main lilo boot stanza for the new OS.
Kernel panic :( cannot mount the root —> Reboot to slackware—let's fix this? Kernel is /boot/bzImage, not vmlinuz!!
Well here I am, at a bw64 login: prompt . . . bluewhite64 is running, it includes the expected slackware installer quirks and recovery methods.
Familiar territory for a slacker lucky enough to upgrade to modern 64bit hardware :)
Beware—I need to install the kernel modules from /testing to suit the boot kernel—reboot...
Install missing nfs-utils, we have NFS!
Okay, add 'grant' user and edit /etc/fstab to include the kernel source partition, compile a new 2.6.19.7 kernel to suit the hardware.
Reboot to new kernel, so now we have sound :)
KDE can't start due to the missing libqt...
Okay, we're on the familiar territory of finding and fixing the minor glitches, I'm disappointed at the mirror holding an apparently faulty .iso image—but the thing installed with only the usual minor hiccups.
Compiling 2.6.19.7 took 2 minutes for 'time make -j4' :)
Now I need to grab the faulty packages and get KDE going.
Day 2: Slamd64
Install was straightforward, as expected the installer couldn't find the cdrom so I installed from hard drive. Slamd64 comes with a 2.6.16.29 kernel which is a bit old.
Slamd64 had no problems installing vmware 5.5.3, it even works :)
NFS not behaving—unsure what the problem is as yet. NFS worked as expected with BW64.
Some screens in grey rather than the expected colours—me not sort out why yet—minor niggle.
KDE runs okay. Basically, Slamd64 works out of the 'box', apart from NFS.
Day 3: Updates
I've now got the local mirror of slamd64 install tree up-to-date with the source and will add at least one more installment after applying the patches since NFS gets a couple mentions in the Changelog. Here's the update story.
Both BW64 and slamd64 have active rsync mirrors which allows me to maintain a local install tree mirror—updating is then a simple 'updatepkg /home/mirror/<distro>/patches/packages/*tgz', except the initial slamd64 will be via local hard drive as I rsync the install tree over while booted into BW64.
Updating slamd64
Syncing up the local install tree with the mirror is an rsync one liner:
rsync -avPH --delete --progress \
rsync://mirror.vbfx.com/slamd64/slamd64-11.0/ \
/home/mirror/slamd64-11.0
Refresh the hard drive install source from the local server with:
rsync -avPH --delete --progress /home/mirror/slamd64-11.0/ slamd64-11.0reboot to slamd64 and run the update:
upgradepkg /home/grant/vmware/slamd64-11.0/patches/packages/*tgz
(/home/grant/vmware is the temporary home of the install source).
Restart the NFS by issuing '/etc/rc.d/rc.nfsd restart' and '/etc/rc.d/rc.rpc restart' and NFS mounts now work without locking up.
Now I modify /etc/fstab to mount the /home/common NFS export on boot and reboot to check there is no longer a bootup warning. No, slamd64 still stalls on boot with an NFS error :( For me, this is a showstopper. I've applied the patches and slamd64 still stalls on boot, unusable.
Read through the slamd64 forum but see no mention of NFS problems, cannot register to report the issue as the registration page looped on submit then kicked me out after five tries :( I had no such problem registering on the bluewhite64 site.
Current status: Slamd64 is a no go due to the NFS issue, while BW64 cannot run vmware at the moment, Arny (the maintainer of BW64) is going to try it and report back.
Note: openSUSE 64bit is working fine, and YaST on a fast box is almost bearable. At the moment openSUSE works, and bluewhite64 is a promising slackware port. Slamd64 is depressing since it has the showstopper no NFS plus is dreary grey on screens (vim and make menuconfig) that are usually coloured.
Day 4: Slamd64-current
Using the slamd64 DVD install tree as a base, I rsync'd it to get a slamd64-current install tree. Then rsync across to new box preparing for a hard drive install.
Install from boot to slamd64 DVD to reboot into the new system took 14 minutes! This was an install from hard drive. Slamd64-current uses the 2.6.18 kernel and I'm pleased to report mounted the localnet system-wide NFS export without a hitch.
I'm also pleased to report that the colour is back to 'normal', compared with the earlier slamd64 install. Let me explain, the first file I copy to a new install is a .vimrc for the root account, then when I edit the /etc/fstab I expect a known colour scheme. The first file I create is .ssh/authorized_keys to allow password-less login from localnet machines.
Then I add the NFS mounts to the /etc/fstab file and create a user account.
Day 5: The Two plus Sflack
State of play:
Bluewhite64-11.0, bluewhite64-current: waiting for Arny to try installing vmware and fix the library issue.
Slamd64-11.0: no NFS—fixed in -current. Slamd64-current works on the few tests I've used: NFS, sound in KDE, install vmware okay.
Sflack-11.0 library issue prevents install of vmware, has sound in KDE, for some reason is about 12% slower in the kernel compile benchmark.
Sflack-current not sufficiently different (only two packages) to bother installing for test.
Conclusions? At this early stage I'm likely to drop Sflack and track BW64-current as well as slamd64-current.
I'm also running openSUSE-10.2 and WinXP on the new box. At present the openSUSE grub boot loader owns the MBR and can reach any of the eight installed OS. This is too many OS to support in the one box but hey, this is for fun, right?
No confirmation email for joining slamd64 forum yet :( I need to wait for the world to catch up.
Day 6: More on Vmware
I'm disliking sflack 'cos it's hard to pronounce, besides it infringes on Patrick's "don't use slackware or anything sounding like slack" (paraphrased) request for slackware clones. Sflack is the least developed of the three, going by the -current offering.
I installed nVidia 64bit video driver to slamd64-current without a problem. Also successfully installed 64-bit vmware 6.0beta to BW64 but it failed to load a guest OS, again due to the missing library—I assume this 'cos if I symlink ld-linux.so.2 in I get a 'corrupted shared...' error, same as I had with vmware 5.5.3.
The 64bit vmware 6.0beta works in slamd64-current. As far as a 64-bit slackware clone goes, slamd64-current is the one that fails to fail ;)
Day 7: Why 64?
Another comparison: why go 64-bit? Consider that the best kernel compile time for 64bit mode was just under two minutes, and with slackware the same test returns 2m13 for a 'make clean; time make -j4'. Running 64-bit mode would appear to be 10% faster than running 32bit mode on the same hardware. For comparison, on a 2.4GHz P4 HT box the result is 6m25.
The vmware 6.0beta comes in 32 or 64-bit versions for linux. Likewise the nVidia display driver.
Another comparison between 32 and 64-bit modes, both with latest nVidia drivers and kernel 2.6.20.3: glxgears on slackware yields 1638fps, on slamd64-current 1760fps which is a 7.5% improvement.
Day 8: YaST (abbr.)
Bluewhite64 ask EUR39 (USD51) for a DVD. Slamd64 asks for an 'appropriate' donation. Sflack don't ask for anything.
All offer a free download.
Last night I sucked slamd64-current and sflack out of the logical partitions and into the primaries. Overwriting the BW64 and Slamd64 installations. Why? So I can use lilo as boot loader—even the latest version of lilo cannot see the second drive logical partitions.
Done this because YaST -> system -> boot loader locked up again, the thing was respawning a file parser looping forever, I hate YaST—Yet another Stupid Thing ;)
Day 9
Sflack also seems slow. It is going from my list, leaving slamd64-current in top place with BW64-current in second. I'm yet to hear from Fred (the maintainer of Slamd64). Installation of 64-bit nVidia graphics driver to BW64 failed due to library issues :( This promotes slamd64-current to being the only useful 64bit variant of slackware, no? The nVidia install also fails for sflack, very early 'file not found' (unspecified).
Conclusions
Other users do not have the same problems I see with bluewhite64, I can only assume it is the hardware being newer. I installed bluewhite64 again from clean source which failed to resolve the issues. For me, slamd64-current does the expected.
One needs to take great care when installing from a corrupt DVD image, in retrospect, I would check the install tree first and delete any faulty files, then rsync the replacement files in before installing. Much confusion in the above would then be avoided.