How to resolve failed pre-installation checks

joergschaber

Hi,

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
https://www.vertica.com/docs/12.0.x/HTML/index.htm#cshid=U0001

CheckNodeDisk.check_io_scheduler (0.142s)

FAIL (U0001): FAIL(eU0001): Error running /opt/vertica/share/binlib/read/get-disks
https://www.vertica.com/docs/12.0.x/HTML/index.htm#cshid=U0001

CheckNodeDisk.check_io_scheduler_none (0.143s)

FAIL (U0001): FAIL(eU0001): Error running /opt/vertica/share/binlib/read/get-disks
https://www.vertica.com/docs/12.0.x/HTML/index.htm#cshid=U0001

CheckNodeDisk.check_readahead (0.145s)

FAIL (U0001): FAIL(eU0001): Error running /opt/vertica/share/binlib/read/get-disks
https://www.vertica.com/docs/12.0.x/HTML/index.htm#cshid=U0001

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

Bryan_H

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

device,parent_device,/sys/block,readahead,fs,blocksz

/dev/sdd1,sda,128,deadline,ext4,4096
/dev/sdb1,sda,128,deadline,ext4,4096
/dev/sda1,sda,128,deadline,vfat,4096
/dev/sda3,sda,128,deadline,xfs,4096
If it fails, let us know the environment - physical machines, VM, cloud, etc. - and actual disk info returned by a system tool like "lsblk"

joergschaber

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_crossman

Hi,
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

device,parent_device,/sys/block,readahead,fs,blocksz

/dev/sda1,sda,4096,deadline,xfs,4096
Unable to find block device for /dev/mapper/rhel_vertica--node-root.
/dev/mapper/rhel_vertica--node-root,,,,xfs,4096

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
fi
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
/sys/block/dm-1/dev
[dbadmin@vertica-node ~]$ ls /sys/block/dm-2/dev
/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
../devices/pci0000:00/0000:00:03.2/0000:0b:00.0/[...]"

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.

joergschaber

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.