VSHA-536 Support virtio

[rustydb]

Summary and Scope

• Fixes: VSHA-536

Issue Type

• Bugfix Pull Request
• RFE Pull Request

Change drive inclusion behavior from keying off of the TRANSPORT value of lsblk to the SUBSYSTEM. The TRANSPORT value makes it easy to see which bus is being utilized by a disk, however this value is NULL (empty) for virtio devices.

In order to include virtio devices, such as devices used by Google Cloud, we can key off of the SUBSYSTEM value instead. The SUBSYSTEM value provides similar information, allowing us to continue choosing sas, sata, nvme, and scsi while excluding usb devices.

Some refactoring is included in this change to fix variables that were (in some cases) undefined.

Fixes metal_resolve_disk, which was returning disks even if they failed the conditional check.

Add metal-log.sh This hook will copy any and all current and future log files made by metal in /tmp, presuming any new logs start with ^metal and end with .log. Currently this produces a just a handful of logs:

ncn-s001:~ # ll /var/log/metal/bootstrap/
total 16
-rw-r--r-- 1 root root   39 Feb 14 04:09 metal_md_exit.log
-rw-r--r-- 1 root root 9797 Feb 14 04:09 pave.log

Prerequisites

• I have included documentation in my PR (or it is not required)
• I tested this on internal system (if yes, please include results or a description of the test)
• I tested this on a vshasta system (if yes, please include results or a description of the test)

Testing for VSHA-536:

• Verified metal and vshasta k8s-masters, k8s-workers, and storage-ceph nodes successfully deployed with all expected, respective partitions
• Verified metal and vshasta k8s-masters, k8s-workers, and storage-ceph nodes successfully redeployed with all expected, respective partitions (rebooting with metal.no-wipe=0 after already deploying yielded a fresh rebuild)
• Verified metal and vshasta k8s-masters, k8s-workers, and storage-ceph nodes successfully produced crash dumps (kdump)
• Verified metal k8s-masters, k8s-workers, and storage-ceph nodes successfully disk booted
• Verified metal and vshasta k8s-masters, k8s-workers, and storage-ceph nodes successfully disk-rebooted and mounted all expected, respective partitions
• Verified metal and vshasta k8s-masters, k8s-workers, and storage-ceph nodes successfully net-rebooted with metal.no-wipe=1 and mounted all expected, respective partitions
• Verified vshasta PXE disks were preserved during the auto-wipe
• Verified all existing hardware types plus Google's standard disk produced the desired partitions (scsi : sata, sas, and virtio; and nvme)
• Verified the pre-install-toolkit successfully crash dumped (kdump) on USB (skipping remoteISO)

I used redbull and a VshastaV2 machine to test my changes and verify parity between metal and vshasta.

Idempotency

Redeploying and rebooting (net and disk) both produced the same behavior.

Risks and Mitigations

This updates the disk selection logic, while leaving the disk formatting/partitioning logic alone. Existing partition expectations are unchanged.

[rustydb]

This has one issue I want to fix before merging, this prints on disk boots (when there are no logs to copy):

[    9.895545] dracut-pre-pivot[2195]: cp: cannot stat '/var/log/metal/*': No such file or directory