NiceOS RPM dist-git source for device-mapper-multipath
Find a file
NiceOS DistGit Import Bot f3faf65d1e Sync device-mapper-multipath from NiceOS Core snapshot
EVR: 0.10.0-1
Lock-SHA256: 27cb0fd0ede3fa777b8ceaf27d7b12b79a06c31a433eb93749bfa8ed53f7cfac
Branch: niceos-5.2
2026-05-01 16:20:12 +03:00
METADATA Sync device-mapper-multipath from NiceOS Core snapshot 2026-04-27 21:45:45 +03:00
SBOM Sync device-mapper-multipath from NiceOS Core snapshot 2026-04-27 21:45:45 +03:00
SOURCES Sync device-mapper-multipath from NiceOS Core snapshot 2026-04-27 21:45:45 +03:00
SPECS Sync device-mapper-multipath from NiceOS Core snapshot 2026-04-27 21:45:45 +03:00
.gitignore Sync device-mapper-multipath from NiceOS Core snapshot 2026-04-27 21:45:45 +03:00
OWNERS Sync device-mapper-multipath from NiceOS Core snapshot 2026-04-27 21:45:45 +03:00
README.md Sync device-mapper-multipath from NiceOS Core snapshot 2026-05-01 16:20:12 +03:00
README_RU.md Sync device-mapper-multipath from NiceOS Core snapshot 2026-05-01 16:20:12 +03:00

device-mapper-multipath

Overview

device-mapper-multipath provides userspace tools for working with Linux device-mapper multipath setups. In practical terms, it helps the system detect, assemble, monitor, and configure storage devices that are reachable through more than one I/O path. Fedora packaging documentation describes the package as providing tools to manage multipath devices, including multipath and multipathd. (packages.fedoraproject.org)

This package exists in the distribution so administrators can manage multipath storage in a supported RPM form, with configuration, packaging metadata, and update policy kept separately from the upstream source. The exact set of shipped subpackages or helper files may vary by branch; NiceOS maintainers should verify the spec before relying on any branch-specific detail. (packages.fedoraproject.org)

Purpose and typical use cases

Typical use cases include:

  • assembling multipath block devices at boot or after storage changes;
  • watching for path failures and updating device-mapper state;
  • applying site-specific multipath configuration for SAN or other redundant storage setups;
  • inspecting or tuning multipath behavior during storage troubleshooting.

Typical users are:

  • system administrators and storage administrators;
  • infrastructure engineers running servers with redundant block-device paths;
  • CI/CD or image-build maintainers who need to keep storage-related packages aligned with the target distribution;
  • developers or testers reproducing multipath-related behavior in a controlled environment.

Red Hat documentation for DM Multipath also treats multipath.conf and multipathd as the main operational entry points, so package updates often need coordination with local configuration practices. (access.redhat.com)

Upstream project

The upstream project is the Linux device-mapper multipath userspace toolset. The historical upstream project page on Sourceware identifies the multipath tools and points to the project documentation and mailing list resources. (sourceware.org)

Upstream documentation is centered around the multipath tools, the multipathd daemon, and the configuration file conventions used by DM Multipath. NiceOS maintainers should verify the exact upstream source location for the branch being maintained if the packaging metadata points to a newer upstream hosting location. (sourceware.org)

Dist-git repository contents

This dist-git repository is organized as follows:

  • SPECS/ — RPM spec file(s) used to build the package;
  • SOURCES/ — source metadata, manifests, and any packaging-side source artifacts;
  • METADATA/ — repository metadata used by the packaging workflow;
  • SBOM/ — software bill of materials artifacts, when present in the branch.

The repository is intended to contain packaging inputs and metadata, not a full upstream source mirror.

Source storage and integrity policy

Large upstream source archives are intentionally not stored in this Git repository. Instead, source integrity is tracked through manifest files in SOURCES/ and through the packaging metadata that references the expected upstream sources. This keeps the Git history small and avoids duplicating large tarballs in dist-git.

For maintainers, that means:

  • verify that the SOURCES/ manifest still matches the intended upstream source set;
  • confirm that any added or removed patch files are intentional;
  • make sure the spec still points at the correct source artifacts after an upstream refresh.

Do not rely on handwritten assumptions about source contents; check the manifests and the spec together.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check:

  • whether the upstream configuration format or command behavior changed in a way that affects local defaults;
  • whether downstream patches still apply cleanly and are still needed;
  • whether SPECS/ needs regeneration for changelog entries, patch lists, or conditional logic;
  • whether SOURCES/ manifests need to be refreshed after source or patch changes;
  • whether multipath.conf or any packaged default configuration still matches NiceOS policy;
  • whether the update changes daemon behavior, path-failure handling, or startup integration in ways that need testing.

Risks to consider:

  • storage packages can affect boot-time device discovery;
  • configuration changes can alter how devices are blacklisted, grouped, or monitored;
  • patch refreshes may silently drop downstream fixes if not reviewed carefully;
  • a package update may require matching changes in documentation or generated metadata.

If any of these points are uncertain for a specific branch, NiceOS maintainers should verify them before shipping the update.

Build and verification checklist

A practical maintainer checklist:

  1. Review the upstream change set and compare it with downstream patches.
  2. Verify the RPM spec for source references, patch ordering, conditionals, and subpackage definitions.
  3. Check SOURCES/ manifests after any source refresh or patch change.
  4. Confirm that generated packaging files, if any, were regenerated intentionally.
  5. Build in a clean mock or equivalent build environment.
  6. Install the resulting RPMs in a test system or container where multipath behavior can be exercised safely.
  7. Validate that the daemon starts as expected and that configuration files are placed where the package expects them.
  8. Run a quick functional check such as configuration parsing or a non-destructive multipath/multipathd query appropriate for the test environment.
  9. Review logs for warnings about missing rules, configuration parsing errors, or path discovery problems.
  10. If the update touches storage defaults, confirm that it does not change policy unexpectedly for existing deployments.

The exact test commands depend on the NiceOS build environment and the package split in the branch, so maintainers should adapt the checklist to local tooling.

References

Russian documentation

See README_RU.md for the Russian version of this documentation.

Dist-git repository notes

  • Package repository: rpms/device-mapper-multipath
  • NiceOS branch: niceos-5.2
  • This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.