Source and classification

• Source: Internal Jira/TIC.
• Classification: Product issue.
• Confirmation basis: The TIC determined that the mount options generated by MountBlockDeviceHelper lack nofail and noted that deleting storage does not synchronously remove the entry from /etc/fstab. In the local ZSphere source, the fix commit for ZSV-12865 also changes the normal-device options from defaults to defaults,nofail,x-systemd.device-timeout=10.
• Internal tracking: TIC-6250 and ZSV-12865.

Issue metadata

• Issue IDs: TIC-6250 and ZSV-12865
• Component/product: ZVF ZSphere
• Status: A code fix exists on the write path. Current evidence is insufficient to mark 5.0.2/OEM as fixed, and cleanup of existing entries is tracked separately
• Reported/affected versions: 5.0.2 and 5.1.0
• Last updated: September 2, 2026

Problem description

When storage is added through the UI and Free disk is selected, the backend formats and mounts the block device and writes an entry to /etc/fstab. The old implementation writes defaults for normal devices and defaults,_netdev,x-systemd.device-timeout=10 for multipath devices; both lack nofail. When a device is missing or is not ready in time, systemd waits for the required mount and blocks local-fs.target. In addition, deleting data storage might not synchronously unmount it and remove the original entry. A residual UUID triggers the same failure after the disk is removed, replaced, or reformatted.

Three branches must be distinguished: old builds might write /dev/sdX or /dev/vdX directly; a UUID that does not exist in blkid indicates a residual entry or a changed device; only when the UUID exists and the mount point is correct but startup is still blocked does the fault-tolerance issue caused by missing nofail apply. Do not change mount parameters uniformly merely because emergency mode appears.

Symptoms

• After storage is added with Free disk selected, a line is added to the host's /etc/fstab. If only an existing mount path is entered and no free disk is selected, this process does not write to fstab.
• After the device is removed, replaced, not discovered in time, or the data storage is deleted, the host cannot boot normally after a restart.
• The emergency shell or startup logs show local-fs.target, a mount timeout, or a missing device.

Impact

The host cannot finish booting, affecting its virtual machines and storage access. Deleting an fstab line directly might prevent a local disk or data storage that is still in use from mounting after the next restart. Adding nofail only to new entries does not automatically remove historical residual entries.

Workaround

• Run the following read-only collection commands from the affected host console or recovery environment and save the complete output. Do not delete fstab entries first:

  cat /etc/fstab
  blkid
  lsblk -f
  findmnt --verify --verbose
  journalctl -xb -1 -p err --no-pager | tail -80

• During analysis, record the device identifier, mount point, and options for each fstab entry. For a device-name entry, verify the current device enumeration. For a UUID= entry, find the same UUID in blkid. When the UUID exists, also verify the file system, mount point, and data-storage ownership. The expected result is that findmnt --verify --verbose reports no missing device or syntax error. Proceed with the fix only if it points to the target ZStack entry.
• Support-assisted method: ZStack Technical Support and the storage administrator first create a recoverable backup of /etc/fstab, and then process only the confirmed target entry. Add nofail to an entry that remains valid but requires startup fault tolerance. Remove a residual entry only when the device has been permanently removed and the platform resource has also been deleted. Do not modify the system root partition, /boot, or any mount item whose ownership is unknown.
• After the change, run findmnt --verify --verbose again and confirm that the target UUID, mount point, and options are correct before restarting during a maintenance window. The host is expected to pass local-fs.target and connect to ZSphere normally. If validation still reports an error, the target disk is not mounted, or the file system is abnormal, immediately restore the backup and stop restart attempts.
• A temporary self-service workaround when creating storage is to avoid selecting a free disk and use only a path that the administrator has already mounted correctly. The tradeoff is that this process cannot directly use an entire raw disk. This method does not fix historical fstab entries.
• Validation criteria: findmnt --verify --verbose shows no error for the target entry, the host boots normally and connects to ZSphere after a maintenance-window restart, and every file system that must be retained remains mounted at its original path. If any criterion is not met, restore the fstab backup and stop.

Affected products

• ZVF ZSphere: 5.0.2 and 5.1.0
• Deployment and dependent components: Hosts that use local or multipath block devices and have ZSphere write entries to /etc/fstab. This issue does not apply when this mount mechanism is not used.

Fix status

• Current status: ZSV-12865 has a write-path code fix. Current evidence does not prove that the fix is included in the customer 5.0.2 or Nexa VM OEM deliveries, so these builds cannot be marked as fixed. Cleanup of existing entries is tracked separately by ZSV-9315.
• Fixed version: The target version recorded in Jira is 5.2.0. The local repository shows that the fix was once merged into the zsv_5.1.1 code line, but this does not prove that every 5.1.1/5.0.2 delivery contains it. Confirm against the customer's complete version string and package commit.
• Related defect/fix records: ZSV-12865 adds nofail and a device timeout; ZSV-9315 tracks fstab cleanup during unmount/deletion.

Related information

• Related TIC/Jira: TIC-6250 and ZSV-12865.
• Code fact: The currently visible ZSphere commit changes both FSTAB_OPTIONS_MULTIPATH and FSTAB_OPTIONS_DEFAULT to include nofail. This fact proves only the fix implementation and does not replace delivery validation for the target OEM branch.