BRU 18.0 Frequently Asked Questions

The following FAQ's apply to BRU v.18.0 only.

What are BRU's pre-installation requirements?

BRU only requires that you have an OS installed with a working tape drive, XBRU on the other hand requires that TCL/Tk 8.3.x installed. Please ensure that you have TCL/Tk installed and is at least version 8.3.x. To check your tclsh version do this:

# tclsh
% puts $tcl_version
8.3
% exit
#

^ Top of Page

How do I enter my license strings into my BRU Demo?

Since BRU 17.0 it has been possible to convert your working demonstration product into a fully licensed product. When you purchase BRU, you will receive a set of license strings. To enter these into BRU, use our setlicense utility: 

# /bru/setlicense
You can confirm your new license with either of the following: 
# /bru/showlicense
# bru -h

^ Top of Page

Can BRU write to a CD?

BRU has gained a reputation of being able to write to most any device and CDs are no exception. While BRU is capable of sending archive information to a CD, the problem comes in attempting to write multiple volume archives. Unless you can get the CD-writing program to "wait" while you change CDs, you're not going to be able to write multi-volume archives.

To enable this, we have created versions of the /etc/brutab and our MOUNTCMD and UNMOUNTCMD pre and post scripts that properly handle CD/R, CD/RW, DVD/R, etc. media. Download the CDR_Files.bru and extract it using BRU (bru -xvf ./CDR_Files.bru). Examine the extracted files modifying the brutab and cdunmountcmd.sh files for your specific environment.

^ Top of Page

Does BRU Workstation or Desktop Edition work with autoloaders or libraries?

Yes. BRU provides a mechanism that allows you to control autoloaders and libraries during the start and at tape change instances. By configuring the MOUNTCMD and UNMOUNTCMD variables to point to scripts or executables, BRU will pass control to the scripts and wait for the operation to complete. Once completed, control returns to BRU and we continue where we left off.

If you have access to the mtx utility, you may expand the library support to actually allow BRU to use the random slot access supported by larger libraries. We show two methods of setting up autoloaders on our site.

Note: The current X11 interface for BRU, XBRU, doesn't work with autoloaders. Since XBRU is released as Open Source under the QPL, please feel free to extend the existing functionality to include features that you may find missing.

^ Top of Page

BRU will not read tapes made on an old system/another system. How do I fix this?

BRU's ability to access tapes made under old versions of your current operating system or another system depends upon compatability with the way the tape was previously written. Tape drives are managed in different ways on different systems, or even different versions of the same system.

To read a tape, the system's device driver, BRU's buffering, and the media all need to agree upon issues like variable vs. fixed block mode, block size, and buffer size.

For instance, on a Linux 2.4 kernel based system, a DDS4 DAT drive defaults to fixed block, 512 bytes per block, tape layout. However, on a SGI IRIX system, that same DDS4 drive may be configured to operate in variable block mode. If we create a tape on the SGI system and attempt to read it on the Linux system, the Linux driver will issue an EIO (errno = 5) access error.

To fix this, use the Linux system's 'mt' tool to set the tape drive into variable block mode (to match the SGI setting) using: 

# mt -f /dev/nst0 setblk 0

This will match the setting between the two systems and we will now be able to successfully access the tape under Linux.

The next issue is to make sure that BRU is using the same buffer size on both systems. If the BRU configuration on the SGI system used a 64k bufsize, then you must use that same bufsize on the Linux system for BRU to read the data. You may override your /etc/brutab settings for a single run by specifying a '-b 64k' on the command line.

^ Top of Page

Why won't BRU 18 install on my system?

BRU 18 utilizes a system recognition program that attempts to determine what OS is being used. You can see if BRU is going to install the correct binary by looking at the first line of output after starting the install script. An example for an x86 Linux system would be:

Installing BRU from ./brufiles/x86-linux-glibc2.1...

If the binary shown is not correct, see the README on the CD or the BRU User Manual for instructions on manual installation.

Another problem could be that the license strings are incorrect or are being entered incorrectly.

As long as the system recognition program detects the correct binary to install, try installing BRU without entering your license strings.

When prompted for your License Data and Key, simply press <Enter> without entering anything.

If BRU operates correctly without your license strings, the license strings being entered are incorrect.

You can add your license strings to your installed and working BRU to see if that causes your product to fail: 

# /bru/setlicense
If the adding of the license strings cause BRU to fail, remove the .license file and contact TOLIS Group Technical Support for assistance. 
# rm /bru/.license

^ Top of Page

Why do I get "E134" or "Internal Error 100" when installing BRU?

BRU is a time-sensitive program. As such, we check your system time before all initial operations begin. On some systems, the timezone reference file is broken. If this is the case, BRU will report the following error: 

bru: [E134] internal error 100 - failed self consistency and portability checks

The fix is to set your system's timezone variable (TZ) to your local timezone. You should look in your timezone directory for a timezone file that matches your area of the world. There should be one that lists your time slot.

Some example fixes would be: 

TZ=CST6CDT ; export TZ
TZ=EST5EDT ; export TZ
TZ=MST7MDT ; export TZ

^ Top of Page

Why doesn't BRU 17 CD mount properly on my HP-UX system?

The BRU 17 CD is formatted to iso9660 standards with the Rock Ridge extensions. While most Unix/Linux systems recognize this format, some, such as HP-UX, do not. When properly mounted, a list of the CD's base directory should show something like the following. Note that there are no metacharacter filenames, just alpha-numeric: 

dr-xr-xr-x . . . Manuals/
-r--r--r-- . . . README
-r--r--r-- . . . autorun.sh
dr-xr-xr-x . . . brufiles/
-r-xr-xr-x . . . install
dr-xr-xr-x . . . unsupported/
You must mount the CD as an iso9660. Under HP-UX, you will need the PFS utilities, pfs_mount and pfs_umount as outlined in HP Technical Document KBAN00000197. To mount a Rock Ridge iso9660 CD, use the following (substituting for your device name [x]): 
# pfs_mount -t rrip /dev/dsk/cxtxdx /cdrom
WARNING: To unmount, do not use the normal umount command. This can (will) lock up your system and require a reboot to clear! To unmount a Rock Ridge iso9660 CD: 
# pfs_umount /cdrom

It is also suggested in the HP TechDoc that you kill the pfsd and the pfs_mountd deamons.

^ Top of Page

Why can't I execute the install file on my BRU CD?

Some systems mount CD-ROMs without the ability to execute binaries on the mounted system (noexec). Obviously, this will prevent the installation of BRU. Check to see how the BRU CD is mounted. Your command may vary; however, the following should work: 

# mount
You should be able to fix this by changing your /etc/fstab file to allow exec privileges for the CD-ROM (removing noexec if it is listed). Mounting the CD manually. Check your mount command for details. For example: 
# mount -t iso9660 -o exec /dev/cdrom /mnt/cdrom

^ Top of Page
Page Load Time: 0.000771 seconds / 0.771 milliseconds.
Page File Size: 22843 bytes.