Click on our Sponsors to help Support SunWorld

Sparking up Linux, part 2

How to upgrade your kernel, run SunOS binaries in emulation mode, and load Linux on your Ultra

By John Little
SunWorld
September  1998
[Next story]
[Table of Contents]
[Search]
Sun's Site
Abstract
Last month John ran down the basic installation of Red Hat 4.2 for older, desktop SPARCstations. This month, he polishes off the installation process with a look at how to install additional packages. You'll also learn how to go about upgrading your kernel, how to run SunOS binaries in emulation mode and -- for those who would like to make a quick evaluation of Linux for SPARC-- John describes the tiny SPARC-based Linux X terminal package, SLXT. Along the way, he touches on the (speedy) installation of Linux on an Ultra 5 system. (2,200 words)


Mail this
article to
a friend

After finishing the initial install, you might want to upgrade to the latest versions of packages available from Red Hat's update directory (see Resources below) or add extra functionality with additional new packages (for example, I always add the dump package).

Red Hat ships a versatile package manager, rpm, to facilitate these operations. It provides functionality similar to that of the Solaris pkgadd/pkginfo/pkgrm suite, but it's all wrapped up in a single program. The rpm's versatility has one drawback, which is that all of the available command-line options and arguments can be quite difficult to remember. To alleviate this problem, a simple graphical user interface (GUI) named glint is also available under X11.

The most commonly used command-line invocation is rpm -ivh <RPM-FILE>. This will install the specified package and print a line of # characters to give some indication of progress. Despite the apparent simplicity, it will also complete dependency checking before starting the install. Thus the command rpm -ivh /tmp/dump-0.3-7a.sparc.rpm will fail if the tape-control package mt-0.3-7a.sparc.rpm isn't already installed, or if the dump package is already installed.

Kernel updates
Red Hat's SPARC-based Linux gives users a certain amount of flexibility with kernel updates. The rpm package manager makes updates a breeze, and Red Hat periodically makes rpm format kernel upgrade packages available in the updates directory on its Web site. This is generally the easiest way to upgrade to a completely new revision.

Of course, because full kernel sources are also available, updating individual files and simply recompiling the kernel is also an option (useful where a simple fix or modification has been posted to the Net).

Yet another method is to download a kernel snapshot -- a precompiled, tar-format collection of the kernel and essential support files (see Resources). The snapshot will generally get you the very latest version of the kernel sometime before it appears as an rpm but, because it's a binary-only distribution, you're limited to the options that are compiled in.

One other bonus of the snapshot method (assuming you like life on the bleeding edge) is that development (beta) kernels are also available. For Linux 2.*-series kernels, the rule of thumb is that a 2.0.* revision number indicates a stable, production kernel, while 2.1.* indicates indicates a development version.

The snapshot upgrade method requires a little more manual intervention than an rpm install. Basically, the existing kernel, module directory and System.map file are moved to one side, and the new versions are installed in their place. The SPARC Linux loader (SILO) configuration can be modified to allow the original kernel to be booted as a possible recovery option.

The actual steps in this operation are as follows:

Step 1. Download the parts of the snapshot. There are three separate files:

You'll need to set FTP to binary mode if you're downloading them manually.

Step 2. Install the new modules. This step will create a separate, new module directory under /lib/modules. 

host#  cd /
host#  tar xvzf <MODULE.TAR>

Step 3. Back up the existing vmlinux and System.map files. 

host#  cd /boot
host#  mv vmlinux.gz vmlinux.gz.ORIG
host#  mv System.map System.map.ORIG

Step 4. Move the new kernel and System.map into place. 

host#  cp <VMLINUX> /boot/vmlinux.gz
host#  gunzip -c <SYSTEM.MAP>  >  /boot/System.map

Step 5. Modify the boot loader to allow easy recovery. This entails modifying the /etc/silo.conf file and adding an entry for the old, original kernel: 

#--- Existing lines
#
root=/dev/sda1
image=/boot/vmlinux.gz
label=linux
read-only
#
#--- New lines for recovery boot
#
image=/boot/vmlinux.gz.ORIG
label=vmlinux.ORIG
read-only
#
#---

Step 6. Run silo to install the updated boot-loader.

Step 7. Reboot the system. By default, the new kernel will be booted. If there are problems with it, reset the system. At the SILO boot: prompt, input vmlinux.ORIG to boot the old kernel. (Or, if you can't remember the name of your original kernel, hit Tab to see a listing of those available.)

Advertisements

Emulation mode
SPARC-based Linux will also run SunOS binaries in emulation mode with a small amount of additional set up. The basic concept is to create a separate directory structure under /usr/gnemul/sunos that will contain both the target binary and any required dynamic libraries.

Note that if the libraries required include any shipped by Sun (the most likely scenario), you should probably have at least a single-user runtime license for SunOS.

Start the emulation set up by creating the /usr/gnemul/sunos directory on your Linux system. This directory tree needs to contain everything that is directly referenced by the SunOS application binary. Effectively, /usr/gnemul/sunos becomes the top-level root (/) directory as far as any SunOS binaries you place in that tree are concerned. For instance, if your application normally requires a config file in the /etc directory, that config file will need to go into the /usr/gnemul/sunos/etc directory on your Linux system. In the same way, if the binary file itself is normally located in /usr/local/bin on your SunOS machine, it would go into /usr/gnemul/sunos/usr/local/bin on the Linux system. This may look overly complicated at first, but once you get the idea of everything being chrooted to the emulation directory, it all starts to make sense.

For some system-configuration files, such as the /etc/hosts and /etc/resolv.conf files, a symbolic link from the system file to the /usr/gnemul/sunos/etc directory makes sense (eliminating the need to update the same information in two separate locations).

To complete the set up, you'll need to install /etc/ld.so.cache (in /usr/gnemul/sunos/etc/ld.so.cache) and /usr/lib/ld.so (in /usr/gnemul/sunos/usr/lib/ld.so). You can then determine exactly which other libraries your application requires by running ldd <APPLICATION>. The output from this command will display the full pathname and revision for all the libraries that are needed.

Any application that uses low-level access to device drivers (such as the SunOS version of format) probably isn't going to work due to the differences between Linux and SunOS drivers. Don't ever be tempted to create a copy of the SunOS /dev directory in the emulation tree in an effort to get an application running. SPARC-based Linux and SunOS use different major and minor numbers for /dev entries, so this will actually cause more problems than it will solve.

Solaris emulation doesn't work very well with Red Hat 4.2 SPARC-based Linux, but there seems to be some development work in progress to get it to work with newer releases. SunOS emulation is the safest bet for the time being.

UltraLinux -- Linux for UltraSPARC architecture machines
The two UltraLinux distributions are the UltraPenguin and UltraPenguin-1.0.9 releases. They differ both in their pedigree and in the machines they support. UltraPenguin is based on the older libc5 and UltraPenguin-1.0.9 on the GNU libc. While UltraPenguin supports Ultra 1 and Ultra 2 desktop machines, the UltraPenguin-1.0.9 release integrates 32-bit and 64-bit CPU support, along with PCI and IDE drivers, to cater to a much wider range of systems. The UltraLinux development page (see Resources) currently lists these machines:

As mentioned in the first part of this article, none of the UltraLinux releases are available on CD-ROM yet. In addition, the boot images are too big to fit on a floppy disk, so the install boot options for the Ultra are currently somewhat limited. An initial network boot is the way to go.

Although the set up to network-boot an Ultra is virtually the same as the older 4.2 release, there is one important difference. The name of the symbolic link to the bootable tftp file no longer requires an architecture specifier as a suffix, so instead of the <IP-ADDRESS>.SUN4U format you might expect, the link for an Ultra is just a plain IP address. For example, the link for an Ultra 5 with an IP address of 172.17.172.51 would look like this:

AC11AC33 -> tftpboot.img

While the link for a SPARCstation 2 with the same IP address would be:

AC11AC33.SUN4C -> tftpboot.img

It is important to note here that a .SUN4U suffix will not work. The Ultra boot-PROM code is looking for a simple, IP-level link with absolutely no suffix attached.

If you have problems net-booting any client (not just a Linux client), I'd recommend using snoop (Solaris) or tcpdump (Linux) to visually verify that the initial client RARP/ARP request matches the tftpboot link format.

UltraPenguin-1.0.9 install
Other than the tftpboot link, the set up for a network boot is the same as that described earlier for the 4.2 release. The UltraPenguin-1.0.9 install program is somewhat newer than the 4.2 version, but still looks very similar. One problem with this version is that there are two FTP sites hard coded in. At the time of writing, one of them, vger.rutgers.edu, didn't actually carry the UltraPenguin-1.0.9 release (and the other, sunsite.ms.mff.cuni.cz, is in Czechoslovakia). Hopefully, some of the other SunSite locations will add this distribution to their archives fairly soon.

When installing on an Ultra 5, Ultra 10 or other IDE system, enabling the "Check for bad blocks" option in the disk partitioning section might appear to hang your system. It doesn't. The disk check will take approximately 15 minutes for a 4.3-gigabyte drive with no visible indication that anything is actually happening. Disabling that option will reduce the time taken to about three or four minutes for the newfs.

Although the disk check is slow, the rest of the install is anything but. On my Ultra 5 system with the "Install everything" option enabled, the actual package install took just slightly more than 12 minutes for approximately 650 megabytes (MB) of data (FTPd from a local copy of the sunsite.ms.mff.cuni.cz archive).

X11 servers
One thing that differs markedly between the SBus and PCI-bus machines is the X server set up. This is a task that causes a lot of grief in the PC world, simply because of the large number of video board and monitor combinations available. In the more standardized Sun world we haven't had this frustration (up until now). Linux for SPARC ships with three X11 server binaries -- all preconfigured to work, out of the box, with the vast majority of existing machines. They are for monochrome, 8-bit color, and 24-bit color frame buffers with a standard 1152 x 900 resolution. The X server file, /usr/X11R6/bin/X, is actually just a link to one of these binaries. If you update the frame buffer in your system, you can simply relink to the appropriate binary and restart X11 with startx.

Unfortunately, with PCI-based video cards now appearing in the newer Ultras, this is changing. The UltraPenguin-1.0.9 install will ask for some basic configuration help if it detects a PCI video card. The cards currently shipping in Ultra 5 systems are Mach64-based and are automatically identified by the program. You might have some difficulty with the monitor specification. Especially if you're using an older monitor, you might find it necessary to read through the /usr/X11R6/lib/X11/doc/Monitors file and identify an 1152 x 900 resolution listing that most closely matches your monitor. You can then use the identifier string (for instance, "Sony CPD-1430") to select that type in the monitor-set up section.

After completing the install and logging in, you can start X11 with the startx command. Some useful keyboard control sequences to control the X-server are:

(The Ctrl-Alt sequence may need to be replaced with Ctrl-Meta on some types of keyboards.)

The SPARC Linux X terminal package (SLXT)
If you have an older, desktop SPARCstation and would like to find out whether it will run SPARC-based Linux, or if you want to speed up an older machine without upgrading the hardware, the SLXT package might be just the thing for you. The package uses only Linux code and binaries, so it's freely-distributable under the terms of the GNU General Public License.

Based on Seth Robertson's Xkernel concept, it enables diskless, low-memory SPARCstations to be used as X terminals. The SPARCstation boots across the network and runs a cut-down SPARC-based Linux kernel, an X11 server process, and very little else. Because of this, machines with as little as 12-to-16 MB of memory will work well.

Unfortunately, the installation and administration scripts for this package are currently tailored to Linux servers, but anyone familiar with diskless, dataless, or X term operations should be able to install it on a SunOS or Solaris server without too much trouble. In fact, if you've created a boot server for tftpboot clients as outlined earlier in these articles, you've already done half of the work. If you're already running Linux on another system (SPARC or Intel), the SLXT package provides a quick way to configure it to support multiple SPARC clients.


Click on our Sponsors to help Support SunWorld

Resources

Linux for SPARC resources SLXT Linux applications and utilities Other Linux resources

About the author
John Little is an Englishman living in Japan and working for an American company. (He frequently uses these facts when attempting to excuse his grammar and spelling). He worked for Sun Microsystems for nine years. Reach John at john.little@sunworld.com.

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
 -Too long
-Just right
-Too short
 -Too technical
-Just right
-Not technical enough
 
 
 
    

SunWorld
[Table of Contents]
Sun's Site 		[Search]
Feedback 		[Next story]
Sun's Site

[(c) Copyright Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-09-1998/swol-09-linuxsparc2.html
Last modified: