6739fa8ef4
Turns out the default VM images have basic support to handle even multipathing. But might not contain the actual bits to enable the kernel initial ramdisk to be regenerated at a later point in time with those artifacts. This creates a situation where a user could deploy the image on a physical host, make other changes or perform an upgrade later, and suddenly loose the ability to boot via multipath. Alternatively, it also creates a situation where resulting DIB images may explicitly loose multipath support where the base image worked just fine. Change-Id: I8e165cf65b1d5db4bcad3264b5c2b098db84fbb8
14 lines
729 B
YAML
14 lines
729 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Fixes an issue on RHEL or Centos based image builds where an initial
|
|
source image state may have a multipath capible initial ramdisk,
|
|
but then lack the necessary package to support regeneration of a new
|
|
ramdisk with multipathing. The end result being that a regenerated or
|
|
updated ramdisk after the fact is that the ramdisk then fails to boot
|
|
when multipath devices are present where it previously booted without
|
|
any issues. This is because the ramdisk build process used by ``dracut``
|
|
does not fail if it does not find the necessary multipath components,
|
|
thus requiring the ``device-mapper-multipath`` package to be present
|
|
for the ramdisk with the necessary artifacts.
|