Oninit
Talk to an expert →

Informix Error -19

-19 No such device.

An operating-system error code with the meaning shown was unexpectedly returned to the database server. Look for other operating-system error messages that might give more information. If the error recurs, note all circumstances and contact IBM Informix Technical Support.

Oninit® Troubleshooting Guidance

This is an operating-system error number, not an Informix diagnosis.

The same errno is returned by many different operations, so on its own it says what the operating system refused, not what Informix was trying to do. Informix will usually have reported a more specific error alongside it — in the message log, in the SQL or ISAM error pair, or in the accompanying assert failure — and that error normally defines the real cause far more precisely than the errno does. Find it before diagnosing from this number alone.

This matters less than it used to. Later versions of the engine trap many of these conditions and report them as specific Informix errors naming the operation, the object and the context, so a bare errno in this range is increasingly a sign of an older version, an unusual code path, or a failure early in startup before the better reporting is available. If you are seeing one on a current version, the more specific error is worth looking for even harder.

Operating-System Meaning

errno 19 is ENODEV — No such device. It is close enough to -6 (ENXIO, No such device or address) that the two are routinely confused, and separating them is most of the work.

-6 ENXIO -19 ENODEV
Rough meaning The node exists; nothing answers on it The node exists; no driver claims it, or the device cannot do this
Classic cause LUN unmapped, stale node, FIFO with no reader Kernel module not loaded, unsupported operation, filesystem type unknown
Where to look Storage layer, lsblk, multipath lsmod, /proc/devices, /proc/filesystems
Typical fix Restore the storage, fix the path Load the driver, correct the operation or the type

In practice ENODEV arises in three situations:

  1. The driver is not there. A device special file is just a major/minor pair; if no driver has registered that major number, opening it fails this way.
  2. The operation is not supported by this device. An ioctl meaningful for one device type issued to another — tape control commands to something that is not a tape, for instance.
  3. A filesystem type the kernel does not know. mount() with a type whose module is absent.

The boundary with ENXIO is not perfectly crisp across drivers, so do not lean on the number alone — check both possibilities where the distinction matters.

What This Means in Informix

This is a rare error, and the credible sources are few:

  • Tape devices where the driver is absent. The st (SCSI tape) module not loaded, or not present after a kernel upgrade, leaves /dev/st0 or /dev/rmt0 unopenable even though the node and the hardware exist.
  • Tape ioctls to something that is not a tape. TAPEDEV or LTAPEDEV pointing at a disk, a regular file or the wrong node, so rewind and positioning commands are rejected.
  • A backup or staging filesystem whose type is not supported — an NFS or XFS mount attempted where the module is missing, typically in a stripped-down or containerised host.
  • A chunk device whose driver has gone, after a module unload, a failed driver update, or a kernel upgrade that did not carry a third-party storage module forward.
  • Hot-removed hardware, where the node survives the device.

The kernel-upgrade case is worth singling out. A host that has run for years can come back from a reboot with a storage or tape driver missing because the module was never rebuilt for the new kernel, and the resulting failure looks like a hardware problem rather than a packaging one.

Common Causes
  1. A kernel module not loaded — st for tape, or a storage driver for chunks.
  2. A module missing after a kernel upgrade, particularly out-of-tree or vendor drivers.
  3. TAPEDEV/LTAPEDEV naming something that is not a tape device.
  4. A filesystem type unsupported by the running kernel.
  5. Hardware removed while its device node remains.
  6. A container without the device or module the image expects.
Diagnostic Checks

Start with the node and its major number, then ask whether any driver has registered that major:

ls -l /path/to/device
stat -c '%t %T  %n' /path/to/device      # major and minor, in hex
cat /proc/devices

A major number present in ls -l but absent from /proc/devices means no driver is claiming it — that is the diagnosis.

Check the modules you expect to be there:

lsmod | grep -iE '^st |^sg |scsi_tape'
lsmod | grep -iE 'qla|lpfc|mpt|megaraid|nvme'
modinfo st 2>&1 | head -3

If a module is missing, establish whether it is available at all — the distinction between not loaded and not installed for this kernel decides the remedy:

uname -r
ls /lib/modules/"$(uname -r)"/kernel/drivers/scsi/st.ko* 2>&1
modprobe -n -v st 2>&1

For a filesystem type:

cat /proc/filesystems
modprobe -n -v xfs 2>&1
mount | grep /path/to/mountpoint

For tape specifically, confirm the device really is a tape:

grep -nE 'TAPEDEV|LTAPEDEV' "$INFORMIXDIR/etc/$ONCONFIG"
ls -l /dev/st0 /dev/rmt0 2>/dev/null
lsscsi -g | grep -i tape
mt -f /dev/st0 status

mt reporting No such device against a node that exists is the same finding from the other direction.

Check whether hardware or a module went away, and when:

dmesg -T | grep -iE 'removed|unregister|detached|driver|module'
journalctl -k --since '1 day ago' | grep -iE 'st\b|tape|scsi'
Solutions / Resolution
  1. Determine which of the three cases applies — missing driver, unsupported operation, or unknown filesystem type. /proc/devices and lsmod separate them in two commands.
  2. Load the module if it is present but not loaded, and make that persistent rather than manual:
    modprobe st
echo st > /etc/modules-load.d/tape.conf
  3. If the module is not installed for the running kernel, that is a packaging problem. Install or rebuild it for this kernel version — and check whether other drivers went the same way in the same upgrade, since they usually did.
  4. Correct the device parameter where the path names something that is not the device type the operation expects. Do not attempt to make a disk accept tape commands.
  5. Enable the filesystem type or mount the storage by a supported type.
  6. For containers, pass the device through and ensure the module is loaded on the host — a container cannot load kernel modules for itself.
  7. Re-test the Informix operation rather than assuming a successful modprobe was sufficient.
Examples
The tape driver did not come back after a kernel upgrade
$ ls -l /dev/st0
crw-rw---- 1 root tape 9, 0 Sep  9 07:02 /dev/st0

$ grep -E '^ *9 ' /proc/devices
$ 

$ lsmod | grep -c '^st '
0
$ modprobe st
$ grep -E '^ *9 ' /proc/devices
  9 st

The node exists with major 9, and before the modprobe no driver had registered that major. The hardware was never at fault; the module simply was not loaded after the reboot that followed a kernel update. Make it persistent, or the next reboot repeats it.

TAPEDEV pointing at something that is not a tape
$ grep '^TAPEDEV' "$INFORMIXDIR/etc/$ONCONFIG"
TAPEDEV /informix/backups/tapefile

$ ls -l /informix/backups/tapefile
-rw-rw---- 1 ifxprod ifxprod 0 Sep  9 09:14 /informix/backups/tapefile

$ mt -f /informix/backups/tapefile status
/informix/backups/tapefile: No such device

A regular file where the configuration expects a tape device. mt positioning and rewind commands are meaningless against it. Using a file as a backup target is legitimate, but the parameter must be set up for that rather than pointed at a file while tape semantics are still expected.

A filesystem type the kernel does not know
$ mount -t xfs /dev/sdd1 /informix/backups
mount: /informix/backups: unknown filesystem type 'xfs'.

$ grep -c xfs /proc/filesystems
0
$ modprobe -n -v xfs
modprobe: FATAL: Module xfs not found in directory /lib/modules/5.14.0-427.el9.x86_64

Not installed for this kernel rather than merely unloaded — so the remedy is a package installation, not a modprobe.

Platform Note

errno 19 is ENODEV on Linux, AIX, Solaris, HP-UX and the BSD-derived systems — stable, so the number is reliable. What differs is the entire mechanism by which drivers are present, which is where the diagnosis happens:

Task Linux Solaris AIX
Loaded drivers lsmod, /proc/devices modinfo lsdev -C, genkex
Load a driver modprobe modload, add_drv cfgmgr
Device state lsblk, lsscsi cfgadm -al, format lsdev -Cc tape
Filesystem types /proc/filesystems /etc/vfstab, fstyp lsfs -v

On AIX the analogous condition is a device in Defined rather than Available state, resolved with cfgmgr — and lsdev -Cc tape reports it directly. That is also the first thing to check on AIX for -6, which is one reason the two errors are hard to tell apart from the number alone on that platform.

Related Errors / Related Topics
  • -6 — No such device or address. The nearest neighbour and the one most often confused with this; the table above is the quickest way to separate them, and it is worth reading both.
  • -15 — Block device required, where the path names the wrong kind of object.
  • -2 — No such file or directory, where the path does not resolve at all.
  • -16 — Device or resource busy, where the device is present, claimed and working.

Where -19 follows a kernel upgrade, check every driver the instance depends on rather than the one that failed. Storage and tape modules tend to be missed together, and the next failure is usually waiting on the next operation that needs one.