On an system with a multipath storage setup, the reboot after the installation failed. It turned out that the multipath-tools package was not installed.
Cause
A regular SLE-15-SPx or Leap 15.x or Tumbleweed installation uses the _inst_diskproposal client in the installation workflow which at its end determines which storage features (e.g. Btrfs, XFS, LVM, multipath) are used and adds the software packages that are needed for those technologies to the pool of packages that are going to be installed.
But MicroOS has a different installation workflow, and it doesn't use that default _inst_diskproposal client at all; instead, it uses a custom _partitionsproposal client to handle the storage proposal. And in that client, the packages handling was missing.
Fix
Added the packages handling to that _partitionsproposal client.
To avoid code duplication, that handling was factored out from the _inst_diskproposal client: It is now done by a new PackageHandler::set_proposal_packages_for(devicegraph) method which is now called from both clients.
Test
New unit tests for that new method and for fringe cases
Manual test in a Leap 15.5 VM with the changed files to test against regressions
Manual test in a MicroOS 5.3 VM to check if the support packages are added; changed the storage setup between the default Btrfs to a nonstandard XFS and observed the log file if the packages were added correctly.
Installer Self-Update / Maintenance Update
No self-update needed for SLE-15-SP5 / Leap 15.5
The change can wait for the next QU for SLE-15-SP5 / Leap 15.5
coverage: 97.749% (+0.001%) from 97.748% when pulling 985006eb068162588ec383c1a0da7a5bb97cff24 on huha-pkg-sp5 into 5884c805f1c4ea56aa8d6366bbe93b80237c3870 on SLE-15-SP5.
Target Branch / Product
This is the merge to SLE-15-SP5 of #1346 .
Bugzilla
https://bugzilla.suse.com/show_bug.cgi?id=1212452
Trello
https://trello.com/c/T9nqET80/
Problem
On an system with a multipath storage setup, the reboot after the installation failed. It turned out that the multipath-tools package was not installed.
Cause
A regular SLE-15-SPx or Leap 15.x or Tumbleweed installation uses the _inst_diskproposal client in the installation workflow which at its end determines which storage features (e.g. Btrfs, XFS, LVM, multipath) are used and adds the software packages that are needed for those technologies to the pool of packages that are going to be installed.
But MicroOS has a different installation workflow, and it doesn't use that default _inst_diskproposal client at all; instead, it uses a custom _partitionsproposal client to handle the storage proposal. And in that client, the packages handling was missing.
Fix
Added the packages handling to that _partitionsproposal client.
To avoid code duplication, that handling was factored out from the _inst_diskproposal client: It is now done by a new
PackageHandler::set_proposal_packages_for(devicegraph)
method which is now called from both clients.Test
New unit tests for that new method and for fringe cases
Manual test in a Leap 15.5 VM with the changed files to test against regressions
Manual test in a MicroOS 5.3 VM to check if the support packages are added; changed the storage setup between the default Btrfs to a nonstandard XFS and observed the log file if the packages were added correctly.
Installer Self-Update / Maintenance Update
No self-update needed for SLE-15-SP5 / Leap 15.5
The change can wait for the next QU for SLE-15-SP5 / Leap 15.5
Related PRs