APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

Follow the bouncing dependencies

© October 2009 Bill Mohrhardt
2009/10/08 by Bill Mohrhardt

I am working on building a Linux box to replace our old SCO Openserver machine, and I had a spare Digi host card and concentrator, so I needed to install & configure those. Red Hat Enterprise Linux 5 was not listed, so I called Tech Support to ask which version I should try. The tech said to try dgap-1.3-15.src.rpm, the most recent beta version of dgap from Digi's website. He said that if I wanted support I would have to pay $75, as the PCI host card whose serial # I gave to him had its warranty expire in 2004. Fine, I proceeded on my own, as usual.

Now, given that I installed RHEL 5.3 from rpms, and did not compile my own kernel, I figured that I would be missing some packages, but it turned into a major pain. First of all, Digi's instructions require rpmbuild, so thanks to pbone.net, I got rpm-build-, and that installed nicely. Then, the dgap source said that it needed elfutils, so I eventually found the elfutils matching my version on RHEL5 elfutils-0.137-3.el5.i386.rpm. Oddly, when I checked rpm -qa | grep elfutils, my RHEL5 had elfutils-libelf-0.137-3.el5 and elfutils-libs-0.137-3.el5, but not just the plain elfutils.... Whatever, that rpm'ed fine. But then, the dgap install got most of the way finished, and complained that it needed curses (funny, I had already been providing some of those!). When I checked my rpms, I had ncurses but not curses. I tried setting curses as a symlink to the most recent ncurses library but that did not work. I Googled around, and one linux site said that I needed the ncurses-devel package, but when I downloaded and tried to rpm that one, it said that it needed some other libraries, so I decided to go home at that point.

The next day, I Googled around some more, and one site said that when downloading ncurses-devel, you must make sure to get the same version as your ncurses. My RHEL5 had ncurses-5.5-24.20060715, and again pbone.net had the matching rpm for that, so I downloaded and rpm'ed, and that went through no problem. With the ncurses-devel library in place, the rpmbuild --rebuild dgap-1.3-15.src.rpm actually worked! So now I had the dgap rpm and again the rpm command installed that. Now, I try mpi to configure the card, and the menus get to the point where I choose the type of card (Digi C/X), and then seems to hang. Now I did a ps -ef | grep pts/1 to see if it was a process gone awry, but there was no CPU usage on that port, and there was a long command listed as a process that appeared to be the next question that the mpi menu was trying to ask. After some muttering, I figured that it must be trying to do some graphics that would not display on the telnet session, so I killed it and executed it from the console. That did the trick. I then did the chkconfig --add dgap to add it to the boot-up list.

Then I was able to connect an old Wyse 160 monochrome terminal (yes, I still have one), and I set the baud rate with ditty ttya12 speed 57600. Then I sent echo 'Hello' > /dev/ttya12, and the polite greeting appeared on the terminal. Then I added a12:2345:respawn/sbin/agetty -L ttya12 57600 wy60 to /etc/inittab. To get it to re-execute with the changes, I then did telinit q. A login prompt appeared on the wyse terminal, and I started testing the application programs.

We still use the PCI-card-based Digis, as we have 5 active C/CON 16 concentrators at one location (linked via several pairs of Digi Fiber Modules), and another 2 at our other site. The nice thing about dumb terminals is that they just work, with no maintenance, and nobody messing around on the Internet. We don't use the monochrome Wyse units anymore, we use Spotline terminals that take any colour monitor and keyboard.

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> Follow the bouncing dependencies


Inexpensive and informative Apple related e-books:

Take Control of OS X Server

El Capitan: A Take Control Crash Course

Take Control of IOS 11

Take Control of Preview

Photos: A Take Control Crash Course

More Articles by © Bill Mohrhardt

Thu Oct 8 11:13:03 2009: 7132   TonyLawrence

RPM dependencies can be maddening, but persistence (raw stubbornness!) pays off.

Thu Oct 8 12:23:00 2009: 7135   BruceGarlock

I know the pain. Yes, you have to be incredibly persistent, and eventually you will get there, hoping that nothing else gets broken because of the different lib versions of other packages tied to the distro.

Couldn't Digi somehow statically link against the versions dgap needs somehow?

Thu Oct 8 13:59:30 2009: 7146   BigDumbDinosaur

Like Windows, everyone seems to use Digi hardware despite its general junkiness and spotty support for anything Linux. I have a few clients who still process on dumb terminals, one of which has 18 of the old critters, 6 of which are ADDS 4000/260LFC color terminals (a great replacement for the venerable WYSE 60 -- also uses a standard monitor and PC keyboard). In all cases, the serial hardware is Equinox, not Digi. I came to the conclusion some 20 years ago that even though Digi was real popular (back when SCO was shipping UNIX 3.2v4.whatever) the Equinox hardware was superior in all respects, including driver support. Even HP PA-RISC servers were shipped with Equinox serial hardware.

In 2005 I started an earnest effort to move all of my clients to Linux, which I have succeeded in doing (with one exception -- they switched to Windows). The servers equipped with Equinox SST serial interfaces were a breeze because Avocent (who acquired the Equinox some time ago) had current and tested drivers available. The drivers were 32 bit, but the source code was available and I was able to compile 64 bit versions. There was no cursing of any kind involved, either on the server or by this writer.

Then I was able to connect an old Wyse 160 monochrome terminal (yes, I still have one)...

I have three Wyse 60s here. Up until the fire we had last April, I also had a very ancient DEC VT100 in the computer graveyard (that's the space under the basement steps), right next to a carton with several 386DX40 motherboards. I concluded while we were cleaning up the mess that the VT100 and the mobos were not likely to ever be pressed into service. Sadly, they went into the dumpster along with tons of waterlogged drywall, carpeting and who-knows-what.

Thu Oct 8 14:11:19 2009: 7148   TonyLawrence

It's funny - Steggy doesn't like Digi, and I don't like Equinox.

Or I should say "didn't like" - it's been quite a while since I've had reason to deploy any new multiport serial boards.

But back in the day, early on I used Equinox and Computone. I had a LOT of problems with dead ports, so I switched to Digi. No doubt those problems are long gone. But there is still a lot out there, and for whatever reason, I've seen more Digi than Equinox - even where I wasn't the one pulling out the dead stuff!

Ahh, old fogies talking about dumb terminals. This must be so interesting for the young-uns :-)

Thu Oct 8 14:32:11 2009: 7150   BigDumbDinosaur

Ahh, old fogies talking about dumb terminals.Whaddya mean, "old fogies?" I very much resemble that remark. In fact, my wife refers to me as the "geezer geek." I keep telling her I'm not a geek. <Grin>

Thu Oct 8 22:44:48 2009: 7154   basicbillm

I like the geezer comment with respect to the dumb terminals. Our facility here is not climate-controlled, so we are cold & dry in the winter and unthinkably hot & humid in the summer. PC's would not survive for very long. Many of the Spotline terminals have been in service since 1998 or 1999. Many monitors and keyboards have been replaced, but the terminal units have persevered. We have 14 active terminals at the moment, including 3 for our custom time-clock application, but the number would be higher if business was better. I have never tried the Equinox serial boards, but the main reason that I have stuck with Digi is reliability. Most of our Digi equipment was installed in late 1997, and the only thing that I have replaced is one power supply. Call me a Geezer if you must, but the stuff works every day, with zippo ongoing costs.

Fri Oct 9 14:11:43 2009: 7162   BigDumbDinosaur

I have one system installation that I did in 1990, in which the server (a 386DX33 box) was fitted with an Equinox SST 16 port serial interface. When we replaced the 386 box with an AMD 486DX120 machine in 1994, we kept the SST -- there was no reason not to. In 2000, we again replaced the server, this time with an Athlon unit. The SST hardware was installed in the new unit and a second panel was added to bring it up to 32 ports. Two years ago, I upgraded the server to an Opteron, but kept the SST hardware. Obviously the Equinox hardware was a worthwhile investment.

I estimate we've built and shipped at least 40 UNIX and Linux servers with Equinox SST hardware over the years (but about three times that many where the only connectivity was via Ethernet). We've also built servers with the smaller 8 and 16 port non-expandable Equinox units, of which most are still in service. We have never had to eat the warranty on any of them. I was sold on the performance and reliability of Equinox's SST hardware many years ago. Although it is highly unlikely at this point in time that we will ever ship another server with a multiport serial interface setup, I would not hesitate to use an SST interface if one was required.

Fri Oct 9 16:55:20 2009: 7163   TonyLawrence

I don't think I'd have a problem with SST either - I'm sure they didn't manage to stick around this long by making junk. I'd still go with Digi, though, but only because I'm familiar with the hardware and software. I'd have to learn whatever replaces "ditty" and how to set ports to hold settings...

But as we all know, the likelihood of spec'ing out a brand new serial system today is pretty slim. And honestly - I'd probably decline the business anyway!

Thu Oct 15 18:45:21 2009: 7258   anonymous

We have dumped all true serial connections over the past 3 years. The cost and frustration (ie, moden PCI boards not supporting older cards) was too much to deal with.

We have since moved to Moxa's serial to ethernet technology and have never looked back.

They do have very good linux drivers if you need a real comm port and a huge range of options. I think we have one customer remaining on an SST board, the next server migration, it will be tossed in the junk pile


Printer Friendly Version

Have you tried Searching this site?

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.

Contact us

Printer Friendly Version

UNIX is simple. It just takes a genius to understand its simplicity. (Dennis Ritchie)

Linux posts

Troubleshooting posts

This post tagged:




Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode