Bug 7001

Summary:	error in options given to /sbin/multipath command in /lib/systemd/fedora-storage-init on line 12
Product:	Mageia	Reporter:	Derek Higgins <d.higgins>
Component:	RPM Packages	Assignee:	Dan Fandrich <dan>
Status:	RESOLVED OLD	QA Contact:
Severity:	normal
Priority:	Normal	CC:	dan, sysadmin-bugs
Version:	2
Target Milestone:	Mageia 2
Hardware:	x86_64
OS:	Linux
Whiteboard:	has_procedure
Source RPM:	initscripts-9.34-20.mga2.src.rpm	CVE:
Status comment:

Description Derek Higgins 2012-08-10 16:48:19 CEST

Description of problem:

I am configuring mageia 2 on a DELL R720xd for use as a tivoli storage manager TSM backup server. The server has 14 internal disks attached to PERC 720p controller and 4 QLE2560 FC cards, two of which are attached to our SAN fabric and two directly attached to a HDS AMS2600 storage controller.

The internal disks are working OK through PERC controller but I was having problems with setting up multipathing to the AMS array using dm-multipath module and multipath tools.

I could set up multipathing OK by using the multipath software, kpartx and partprobe etc, and create and mount filesystems through the /dev/mapper/mpath devices. However, after a reboot the server would not come up multi-user since it could not mount the filesystems in /etc/fstab presented through the multipath /dev/mapper devices which were not present.

Error message at boot:

Aug 10 14:10:51 dalry systemd-fsck[472]: /dev/sda3: recovering journal
Aug 10 14:10:51 dalry systemd-fsck[472]: /dev/sda3: clean, 580/1048576 files, 137587/4192963 blocks
Aug 10 14:10:51 dalry systemd-fsck[474]: /dev/sda5: recovering journal
Aug 10 14:10:51 dalry systemd-fsck[474]: /dev/sda5: clean, 3571/1581056 files, 203756/6323269 blocks
Aug 10 14:10:51 dalry fedora-storage-init[690]: Unknown switch: (null)
Aug 10 14:10:51 dalry fedora-storage-init[690]: multipath-tools v0.4.9 (05/33, 2016)
Aug 10 14:10:51 dalry fedora-storage-init[690]: Usage:
Aug 10 14:10:51 dalry fedora-storage-init[690]: /sbin/multipath [-d] [-r] [-v lvl] [-p pol] [-b fil] [dev]
Aug 10 14:10:51 dalry fedora-storage-init[690]: /sbin/multipath -l|-ll|-f [-v lvl] [-b fil] [dev]
Aug 10 14:10:51 dalry kernel: [    0.000000] Initializing cgroup subsys cpuset
Aug 10 14:10:51 dalry kernel: [    0.000000] Initializing cgroup subsys cpu


Eventually tracked down to invalid option  to /sbin/multipath command in /lib/systemd/fedora-storage-init scripts on line 12.  The original line was trying to run "/sbin/multipath -u -v 0"  which failed since the -u option is not valid.  Removing the -u switch on this line and rebooting set the multipath devices up as expected.

Regards

Derek

Comment 1 Dan Fandrich 2013-07-25 23:24:34 CEST

The shipped multipath binary doesn't support the -u option, and it looks like the latest Fedora binary doesn't, either. I suspect this is a relic of an old Red Hat patch that went away at some point.

I've checked in a patch on the Mageia 2 branch to fix this, but not having any multipath devices, cannot test it. I expect the following should be sufficient:

1) sudo urpmi multipath-tools
2) sudo touch /etc/multipath.conf
3) Reboot and look for errors with "journalctl |grep fedora-storage-init"

CC: (none) => dan
Component: Others => RPM Packages
Version: unspecified => 2
Assignee: sysadmin-bugs => dan
Product: Infrastructure => Mageia
Target Milestone: --- => Mageia 2

Comment 2 Dan Fandrich 2013-07-25 23:56:02 CEST

I've verified that the procedure in comment #1 works. A failing case shows the message "Unknown switch:" (among many others). A success case shows other fedora-storage-init messages, including possibly some other errors (since no multipath devices are configured), but not that one.

Clean up after the tests by reversing the steps:

1) sudo rm /etc/multipath.conf
2) sudo urpme multipath-tools

Whiteboard: (none) => has_procedure

Comment 3 Dan Fandrich 2013-08-03 00:58:17 CEST

initscripts-9.34-20.1.mga2 is in updates_testing and available to test.

Comment 4 Manuel Hiebel 2013-10-22 12:19:43 CEST

This message is a reminder that Mageia 2 is nearing its end of life.
Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life.  If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete.

-- 
The Mageia Bugsquad

Comment 5 Manuel Hiebel 2013-11-23 16:16:04 CET

Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no
longer maintained, which means that it will not receive any further security or
bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of Mageia
please feel free to click on "Version" change it against that version of Mageia
and reopen this bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

--
The Mageia Bugsquad

Status: NEW => RESOLVED
Resolution: (none) => OLD