SuSE installation on Clitunno

SuSE installation on the AMD64
15 January 2004

This file is mainly of historical interest --- the story of the first Linux installation on Clitunno. It came of course with SuSE already installed, but I moved the OS from the RAID to an IDE disk, and made some other changes. Much of what was accomplished at this stage is still being used in the Debian installation.

Software and guides

SuSE FAQ on sourceforge

Unofficial packages

Planet SuSE
SuSE support database

SuSE support mailing list

Subscribe to mailing lists

Monarch Computers support

System order 99883
Serial Number 43172
Invoice date 9 Feb 2004
1-800-611-0875
MoBo Tyan Thunder K8S S2880GNR AMD 8131 Opteron DDR ECC 333
System support forum

Tyan support manuals

Thunder K8S (pdf file of the manual you have)
Thunder K8S SATA RAID manual (pdf file, Windows-oriented)
Beep codes

SuSE Installation history

21 February 2004: waiting for transcode

Transcode and the various modules are not yet ported to AMD64, but Mike Phillips <phillim2@comcast.net> is working on it. He has a SuSE 9 installation -- same setup as me. He wrote today to the SuSE AMD64 list that he's half-way through porting xvid, noting it requires yasm rather than nasm. Yasm is a nasm replacement and not yet packaged for SuSE.

19 February 2004: NFS mounting the RAID volumes

The RAID5 volumes /ssa and /ssb wouldn't NFS mount -- it looked like they mounted, but the sizes were wrong and files were not accessible. I moved both of them to /mnt and everything worked. For some reason mounting a root-level directory failed; this may be general.

Couldn't get samba to work -- it's an old version and SuSE's Yast interface for Samba is terrible. Gubbio's syslog says, "smbfs: mount_data version 1919251317 is not supported" -- could be a version problem.

Debian is so much better; I can't wait to switch. I can start putting Debian on /spare when there's something there.

Problem: when you NFS mount the IDE drives and then NFS unmount them, they can't be unmounted locally.

Figured out how to compile transcode but some component segfaulted and it was really slow. It produced decent xvid files, though.

18 February 2004: spinning down the IDE drives

To allow the IDE drives to get a rest, add this to /etc/init.d/boot.local (the equivalent of Debian's /etc/init.d/bootmisc.sh):

hdparm -c 1 -S 242 -k 1 /dev/hda
hdparm -c 1 -S 242 -k 1 /dev/hdc

I've looked for the netload command but haven't found the package. I installed gkrellm instead.

16 February 2004 update: resetting the CMOS

Greg at Monarch's tech support responded to my ps/2 keyboard query by recommending I enter the bios boot menu and disable all keyboards. It certainly worked, but too well -- now I had no access to the bios or the grub boot menu. I called Ricky and was assured that using the mobo jumper to reset the cmos would have no adverse effects; defaults would be fine. In fact the cmos changed in all kinds of ways and I made some changes -- including allowing PXE to be enabled, which is what I'll need for wake-on-LAN (that's next and should work fine).

The main thing, however, is that resetting the cmos cause the boot device table to be reread, so that now I have /dev/hda as (hd0)! I then issued

grub-install /dev/hda3

to tell grub to boot directly from the new /boot drive. This is now working fine -- finally! The Monarch people are more clueless than I had hoped, however.

I've found no solution to the PS/2 keyboard requirement -- either you turn all keyboards off, or you have to have a PS/2 plugged in. Perhaps in a BIOS update this will be fixed? As of now, everything is working, and I can remove the old OS installation on the /ssa drive. I'll leave it for the moment.

15 February update: moving Linux from /dev/sda2 to /dev/hda1

I followed the advice of Andrew Halliwell <spike1@ridcully.fsnet.co.uk> to use cp -a, and to do it for each directory to maintain some control. I copied over all directories except proc, mnt, ssa, ssb, and tmp, which I just created.

[However, John Goerzen says,

mkdir newpath
cd oldpath
tar -cSpf - . | tar -xvSpf - -C /newpath

cp -a does not, afaik, preserve hard links nor sparse files.

OTOH, I've not run into problems after using cp -a on SuSE, or a simple mv on the Debian chroot. Or like this with tar:

cd mnt
tar -xvjpf /PATH/file.tar.bz
mv NEW_DIR debian64

It seems the pros are used to using tar for this.]

[Here's another one:

mkdir newpath
cd oldpath
find . | cpio -pmvd /newpath

Not tried -- though a different cpio gave me problems on SuSE.]

I modified /boot/grub/menu.lst by adding the option to boot into the new partition and rebooted (while the old system was still intact).

Regrettably, the machine beeped several times and did not reboot! That is to say, it didn't even show the BIOS screen -- it does a single beep first, then a brief pause, then a succession of six beeps. I found out at http://bioscentral.com/beepcodes/amibeep.htm that this is keyboard related and plugged in the ps/2 keyboard. Problem solved! Wow.

Next, I had no luck booting from /dev/hda3. The problem was the grub reads the boot devices from the BIOS. At one point I got stuck with a system that only booted to the grub shell. I figured out to issue this:

kernel (hd2,2)/boot/vmlinuz root=/dev/hda1 acpi=off showopts
initrd (hd2,2)/boot/initrd
boot

Note that if you don't boot with the initrd drive, you don't get RAID at all -- that information is stored in the ramdisk.

The problem with grub reading the boot devices from the BIOS could have been worked around by mapping devices -- I didn't try this. A cleaner solution is to reset the CMOS with jumpers. This worked and I could now run

grub-install /dev/hda3

to get Clitunno to boot from the /boot partition. For grub examples, see these.

14 February 2004 update on apt for SuSE

I configured the second NIC as mutt so that I could use the extra bandwidth (while the other NIC was copying files), figured out how to activate the at daemon, how to add an online mirror as my "software source media" and discovered on SuseFAQ -- using apt4rpm -- that apt is supported by SuSE -- also for x86_64!

http://ftp.gwdg.de/pub/linux/suse/apt/

This is announced as the latest news on the apt4rpm site [gwdg.de], which explains,

An SUSE-9.0 x86_64 apt repository is available on ftp.gwdg.de. The repository hosts over 5000 rpms! It is unknown whether a client is available, but most likely the x86(_32) one from suser-rbos can be used. The component list shows the available components.

The 9.0 apt rpm includes a script called apt. This script is a frontend to the apt commands: apt-get, apt-cache, apt-cdrom and apt-config. It further provides some additional command line options. The usage of the command 'apt' is simple and not to be feared, examples are: apt install <pkg(s)> and apt show <pkg(s)>. Other examples are apt update, apt --test upgrade (in this case the rpm command will be called with the --test argument), apt install --sources security.list upgrade (if the security.list config file exist of course), etc.

I might wait until there's an official x86_64 version of the apt rpm. See rpms added to the apt repository.

You can create a sources.list file, as shown in examples:

#
# Repository created by: aptate (version 0.65.3)
# At: Sun Feb 15 08:09:56 MET 2004
# More info about aptate at: http://apt4rpm.sourceforge.net
#
rpm      ftp://ftp.gwdg.de/pub/linux/suse/apt SuSE/9.0-x86_64 \
 base update-prpm update suse-people suse-projects kde kde-unstable security-prpm security
rpm-src  ftp://ftp.gwdg.de/pub/linux/suse/apt SuSE/9.0-x86_64 \
 base update-prpm update suse-people suse-projects kde kde-unstable security-prpm security

Note that you can also give these as files, possibly in conjunction with mounting SuSE's mirror via NFS or Samba. This all looks fine; leave it for the moment.

Not sure how much of dpkg, apt, or even wajig have been ported to SuSE. The comments I read suggested this might be best to leave alone for now, and so I did.

13 February 2004 update

The unit was delivered to 334 Kinshey Hall on Thursday 12 February 2004; I borrowed a dolly from the mechanical shop in the Kinsey basement and rolled it to Hershey. There it stood until Friday night. Around 7pm I unpacked it, struggled to open the lid (it slides), and mounted two IDE drives in a very jerry-rigged manner under the hood. I then figured out how the server rack sliders worked, mounted them on the unit and on the cabinet, and slid it in place. Nothing was straightforward but everything worked without too much delay.

Booting up, I discovered that nothing showed up on the screen. I started by plugging in a USB keyboard with attached mouse, but thought this might not have worked (it was actually just the monitor that was the problem), so substituted a PS/2 keyboard and mouse. I then substituted a CRT monitor and it worked; I figured out how to configure gpm for the USB mouse, and let Yast configure the MS Natural keyboard for XFree. I added some lines to the XFree config file to detect the USB mouse and the wheel and got everything working.

The two gigabit NICs were both set for dhcp; I left one and put the other on a fixed address. It worked at once. I called the machine clitunno, set a new root password, and created a user.

The technicians had told me they had created two RAID arrays (or file systems) of 500MB each, but only one was mounted (the / partition, /dev/sda2). I saw in /etc/fstab that the other array was /dev/sdb2 and mounted it as /ssb (storage server b). When the 3ware driver for SuSE 9.0 comes out, you should be able to create terabyte arrays if you want to.

They adviced I install the OS on a separate drive, and with this in mind I created appropriate partitions on the /dev/hda drive (the 250GB IDE drive I added myself). I may be able to create a new SuSE 9.0 installation on the /dev/hda1 partition, with a /boot on /dev/hda3, using loop-mounted disk images.

I then copied over /etc/hosts and ssh'd in. I set the machine to boot into run level 3 instead of 5 -- all services will be available, but X11 won't start.

I then verified that I can run x-windows remotely, including Yast2. It was four in the morning when I quit. I had dropped wrench on my foot and limped to the car.

The next day, I mounted NFS volumes and samba shares and I started copying the Spencer files from gubbio:/vs to clitunno:/ssb a month at a time to avoid disk overheating. One file was corrupt, but reading it into kino and reexporting it worked around the problem. Kino appeared to be more tolerant of errors than cp, and better at working around them.

The machine is so noisy that I don't think I should leave it on all the time. Move the video archives onto clitunno, and keep working files on the quite ample disks left on the old machines. They can stay on as before.