Issue/Introduction

The management node log might stop when LicenseManagerImpl calls genlicreq, while the installer reports only that ready was not received. If the log contains Failed to generate thumbprint: unexpected lsblk output: N, the license tool expected one root-disk record, but a topology such as software RAID or LVM thin/device-mapper returned multiple candidates and the tool exited.

Symptoms

• The Start nologo management node installation step fails or stops after waiting 1000 seconds.
• management-server.log ends at LicenseManagerImpl/genlicreq without a Java exception stack.
• The installation log or manually collected evidence contains unexpected lsblk output: 2/3.

Environment

• Verified on ZSphere 4.10.26 with a Hygon C86-4G CPU and an LVM thin/device-mapper root disk.
• TIC-4987 also verified a software RAID 1 environment.
• Not every LVM setup triggers the issue, and a Hygon CPU alone is not sufficient reason to cite this article.

Possible causes

First confirm the exact error in existing logs, and then use read-only commands to display the root mount and block-device parent chain. Without unexpected lsblk, investigate native-tool exit, CPU instructions, OOM, or another LicenseManager branch instead of immediately redesigning the hardware.

Issue classification

• Type: Known product bug/storage-topology compatibility issue.
• Known issue: Yes. TIC-4987 is Closed/Fixed; ZSV-11256 and ZSTAC-79788 remained Open/P1 as of 2026-08-06.
• Root cause: genlicreq assumes one result when identifying the root disk. A complex block-device topology causes lsblk to return multiple root records and the tool exits with a nonzero status. The upper layer might then exit without a clear business error stack.
• Affected version: Field case 4.10.26. There is no official fixed version evidence, so do not claim that a particular version fixes the issue.
• Confidence: High, provided that both the log keyword and topology evidence match.

Resolution

Check 1: Search for license tool errors

• Read-only commands:

  grep -RniE 'LicenseManager|genlicreq|thumbprint|unexpected lsblk|management-node-ready' \
    /tmp/zstack_installation-*.log /usr/local/zstack/apache-tomcat*/logs 2>/dev/null
  journalctl -k --since '-30 min' | grep -Ei 'segfault|illegal instruction|trap|oom|java|genlicreq'

• If unexpected lsblk output: N appears: Continue to confirm the storage topology.
• If only illegal instruction/segfault appears: This article does not apply. Troubleshoot native-binary/CPU compatibility.
• If there is no explicit error: Collect complete installation logs and process/thread evidence; do not determine the root cause.

Check 2: Read the root mount and block-device topology

• Read-only commands:

  findmnt -no SOURCE,FSTYPE,OPTIONS /
  lsblk -P -o NAME,KNAME,PKNAME,TYPE,FSTYPE,MOUNTPOINT,UUID
  lsblk -s "$(findmnt -no SOURCE /)"

• If the root filesystem maps through software RAID or device-mapper to multiple parent devices and the count matches the error: This is the same root-disk identification defect.
• If the root disk is one normal partition and only one record is returned: TIC-4987 does not apply. Escalate for analysis of the tool output.

Check 3: Distinguish CPU-related issues

• Read-only commands:

  lscpu
  uname -a
  dmesg -T | grep -Ei 'illegal instruction|segfault|trap' | tail -50

• If there is no instruction exception and unexpected lsblk is present: The root cause is storage enumeration, not damaged Hygon hardware.
• If an instruction exception is present: A separate compatibility analysis is required.

Recommended actions

For an existing production environment, obtain a matching genlicreq and management node combined patch from R&D for the exact current version, and follow its backup, verification, and rollback instructions. Do not replace only the binary because the management node might verify its digest. For a new environment that can be reinstalled, the customer can redesign it: expose a single logical disk to the OS through hardware RAID, use a normal partition or normal LVM with a unique parent chain for the system root disk, and keep service data disks separate. Do not modify a production root LV online, wrap the system lsblk, or use an untrusted tool package.

Long-term solution

Track ZSV-11256/ZSTAC-79788 so that the license tool generates a stable fingerprint from the actual parent chain of the root mount, with coverage for software RAID, LVM thin, device-mapper, multipath, and other topologies.

Additional information

When to escalate

• There is no unexpected lsblk evidence.
• A production environment requires a patch or root-disk redesign.
• Multi-management-node licensing/hardware fingerprints have changed.
• An illegal instruction, segfault, OOM, or another license validation error occurs.

Information to collect

ZSphere/OS/CPU versions, complete installation logs, management-server.log, the block-device output above, RAID/LVM design, the exact genlicreq error, and multi-management-node status.

Related issues

• TIC-4987, Closed/Fixed.
• ZSV-11256, Open/P1.
• ZSTAC-79788, Open/P1.
• Status verified on 2026-08-06.