CNUT on Linux other than Red Hat

I have built a Mepis Linux Box that I would like to install CNUT on. I am fairly new to Linux, but I am muddling through reasonably well.

I have tried to install the CNUT, however I get the following error:

Do you accept the terms of this license (yes/no)?
Installing the networkupdater-1.00.r1-1 RPM package on this system.
Please wait…

Error: An error was encountered while installing this package.
A log has been generated at /tmp/networkupdater-1.00.r1-1.i386.log.

rpm: To install rpm packages on Debian systems, use alien. See README.Debian.
error: cannot open Packages index using db3 - No such file or directory (2)
error: cannot open Packages database in /var/lib/rpm

I am running Java
java version "1.4.1"
Java™ 2 Runtime Environment, Standard Edition (build Blackdown-1.4.1-01)
Java HotSpot™ Client VM (build Blackdown-1.4.1-01, mixed mode)

Do I need a diferent version of CNUT? Do I have to run Red Hat? Any help would be appreciated.


I myself have tried to install CNUT on debian, mandrake, and gentoo. I have gotten the files installed and I can get the CNUT to open. I can even add update packages. But I cannot update units. I get an error saying “package could not be loaded”.

For debian systems you have to extract the rpm off the end of the shell script. If you cannot accomplish this on your own I would reccommend just installing it on redhat, because the steps after that become much more complicated (including the custom writing of many scripts for a debian based system).


Ah, just as I suspected. Well I guess I’ll be rebuilding that Win2k box…


Brutal. Anyone have a procedure laid out for use with Debian?

I can’t believe that otherwise I’ll have to use Windows somehow… my policy is “no Windows on the Internet” and I really don’t want to change that.

I did it on Knoppix (which is a Debian based linux) quite painless. It was required to manually install the Perl modules. I am using this machine for FW updates and Canopy configuration as I have an alias on the eth interface for the 169.254. subnet. Works very good.

Where did you get the perl modules?

And if that’s what is failing… why no error message from CNUT? :frowning:

The modules are in the package. I used ‘alien’ to convert the RPM to DEB.

When extracted the archives (from RPM), I did find this modules in the /tmp/Canopy directory:


Then, in each directory I ran:

perl Makefile.PL
make test (optional but recommended)
make install

After that, from the console in X I issued the command:

# networkupdater &

And it was launched and worked. Previously you have to watch the console output for some errors which will give you a hint whats going on.
Hope this help.

I don’t find any such packages with the 1.1 Canopy setup.

This is becoming more than frustrating, I can’t understand how Motorola could make such errors as the way CNUT is distributed for *nix.

If it’s RPMs, so be it… but they should be individually available. :frowning:

OK, some more work and… the 1.1 release works fine on Debian. There just aren’t ANY error messages to let you know what is going on. Once I got a full X implementation on the server (there were a couple packages missing, not unusual on a dark-room server), up came the app. A little bit of error reporting when it wouldn’t work would be nice, though.


Over a plain SSH session, X apps (and GTK apps like nmapfe and ethereal) work just great, but CNUT won’t. The display on the remote end is corrupted… I’ve run into this before with Java on other machines including SPARCs but never really got it solved. However, good old TightVNC came to the rescue and now I have a working CNUT in a TightVNC session.

All is well… except for the 5.7Ghz unit that locked up during programming and refused to restart even with a power cycle. 120km away and 130 feet straight up. :frowning:

Further mystery… or revelation, you choose…

With another copy of Debian Linux, I can run CNUT just great as a remote X application. So my problem appeared to be a mismatch of X servers (one running Xfree/Sarge and one running Xorg/6.9alpha/Gentoo).

Now, no reason to run it over VNC, although that was working nicely as well.