#670 Problems with device-mapper-multipath on sysv to systemd upgrade
Closed None Opened 12 years ago by adamwill.

Hi, FESCo. I recently filed this bug against device-mapper-multipath:

https://bugzilla.redhat.com/show_bug.cgi?id=739279

it was disabled by default - at least so far as the package configuration was concerned - under SysV, so by policy, it should not be enabled by default after systemd migration.

However, the maintainer points out a legitimate concern with the upgrade case: on multipath systems, device-mapper-multipath has to be enabled for the system to boot. We don't want it to go from enabled to disabled on upgrades. But the current systemd guidelines don't seem to make any attempt to convert the current state of services when upgrading; they just say 'if it was enabled by default before the upgrade, turn it on, otherwise, don't'. This seems rather below optimal.

Regardless, if there's no way to reliably transfer service state, device-mapper-multipath will need an exception from FESCo to allow it to blindly turn itself on on upgrades, I think.

Note that I think anaconda actually has code to install the package (and enable the service, which is why this worked in F15) when necessary:

class MultipathDevice(DMDevice):
""" A multipath device """
_type = "dm-multipath"
_packages = ["device-mapper-multipath"]
_services = ["multipathd"]
_partitionable = True
_isDisk = True

in pyanaconda/storage/devices.py , so going forward, we could probably just take it out of comps, let it be enabled by default in its package config, and have anaconda install it only when it's actually needed. But unfortunately, we're already somewhat screwed for the F15 -> F16 case.


Enable service by default, conditional on the presence of a configuration file as was proposed in https://bugzilla.redhat.com/show_bug.cgi?id=739279#c6

Could it be added into Guidelines?

Login to comment on this ticket.

Metadata