How to resolve failed pre-installation checks

joergschaberjoergschaber Vertica Customer


for a vertica 12.0.3 installation we ran the pre-installtion checks using
$ /opt/vertica/oss/python3/bin/python3.9 -m vertica.local_verify

I get

CheckNodeDisk.check_blocksize (0.143s)

FAIL (U0001): FAIL(eU0001): Error running /opt/vertica/share/binlib/read/get-disks

CheckNodeDisk.check_io_scheduler (0.142s)

FAIL (U0001): FAIL(eU0001): Error running /opt/vertica/share/binlib/read/get-disks

CheckNodeDisk.check_io_scheduler_none (0.143s)

FAIL (U0001): FAIL(eU0001): Error running /opt/vertica/share/binlib/read/get-disks

CheckNodeDisk.check_readahead (0.145s)

FAIL (U0001): FAIL(eU0001): Error running /opt/vertica/share/binlib/read/get-disks

Unfortunately, the link is not very helpful. Any idea what could be the problem here?


  • Bryan_HBryan_H Vertica Employee Administrator
    edited April 1

    Try running the get-disks script on its own since that appears to be the issue. On my system, running as dbadmin user returns:
    $ /opt/vertica/share/binlib/read/get-disks


    If it fails, let us know the environment - physical machines, VM, cloud, etc. - and actual disk info returned by a system tool like "lsblk"

  • joergschaberjoergschaber Vertica Customer

    Hi Bryan_H,

    you are right, that seems to be the problem:
    $ /opt/vertica/share/binlib/read/get-disks
    Unable to determine device ID for nvme0c0n1

    Any idea?

  • s_crossmans_crossman Vertica Employee Employee

    There's a debug flag that might expose more details. You set an env variable VERT_DEBUG_GET_DISKS to "1" and then rerun the get_disks. Output looks like below.
    [dbadmin@vertica-node ~]$ export VERT_DEBUG_GET_DISKS=1
    [dbadmin@vertica-node ~]$ /opt/vertica/share/binlib/read/get-disks
    dbg: G_MOUNTED_FS:
    8:1 8:0 xfs 4096 /dev/sda1
    0:0 0:0 xfs 4096 /dev/mapper/rhel_vertica--node-root
    dbg: G_SYS_BLOCK:
    11:0 sr0
    8:0 sda
    2:0 fd0
    253:5 dm-5
    253:4 dm-4
    253:3 dm-3
    253:2 dm-2
    253:1 dm-1
    253:0 dm-0


    Unable to find block device for /dev/mapper/rhel_vertica--node-root.

    You might also be able to debug further by executing the section of code that is failing. This is the function:
    function get_sys_block() {
    # populates G_SYS_BLOCK
    G_SYS_BLOCK="" # reset
    local FQBLOCKD=""
    local BLOCKD=""
    local DEVID=""
    for FQBLOCKD in "$SYS_D/block/"*; do
    BLOCKD=$(v_basename "$FQBLOCKD")
    if [ ! -f "$SYS_D/block/$BLOCKD/dev" ]; then
    # no device identifier found???
    echo "Unable to determine device ID for $BLOCKD" >&2
    exit 1
    read -r DEVID < "$SYS_D/block/$BLOCKD/dev"

    On my system /sys is equivalant to SYS_D, so I can see my block devices by doing:
    [dbadmin@vertica-node ~]$ ls /sys/block
    dm-0 dm-1 dm-2 dm-3 dm-4 dm-5 fd0 sda sr0

    And then I can check each one has a dev dir by doing:
    [dbadmin@vertica-node ~]$ ls /sys/block/dm-1/dev
    [dbadmin@vertica-node ~]$ ls /sys/block/dm-2/dev

    I see that you have an nvme ssd drive based on your error "nvme0c0n1".
    Based on what I could find it seems that nvme drives have a symlink in/sys/block. E.g. this snippet from a wiki:
    "In specific, every NVMe device appears as a symlink in /sys/block that gives you the path to its PCIe node (and in fact the full topology). So on my office machine in its current NVMe setup, I have:
    ; readlink nvme0n1

    Note sure if that has any bearing on the failure but it is different than non nvme devices that have real directories. Ultimately a symlink should present the same path, just in a different way..

    I hope it helps.

  • joergschaberjoergschaber Vertica Customer

    Thanks for the hint, but that did not reveal anything new.
    Interestingly, the install script did not have any problem after all, it's only the vertica.local_verify script that had issues.

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file