After installing the multipath-tools package, no multipath.conf file is generated. The multipath program itself neither creates nor modifies the multipath.conf file. It is impossible to connect to a valid iSCSI target. Calling multipath doesn't seem to have any effect: [root - etc]# systemctl status open-iscsi.service ● open-iscsi.service - Open iSCSI Daemon Loaded: loaded (/usr/lib/systemd/system/open-iscsi.service; enabled; preset: disabled) Active: active (running) since Wed 2023-09-27 15:24:00 CEST; 16h ago Tasks: 2 (limit: 629145) Memory: 5.1M CPU: 1.291s CGroup: /system.slice/open-iscsi.service ├─2899 /sbin/iscsid └─2901 /sbin/iscsid Sep 27 15:24:00 cortex systemd[1]: Starting open-iscsi.service... Sep 27 15:24:00 cortex iscsid[2883]: iSCSI logger with pid=2899 started! Sep 27 15:24:00 cortex systemd[1]: Started open-iscsi.service. Sep 27 15:24:01 cortex iscsid[2899]: iSCSI daemon with pid=2901 started! Sep 27 15:26:07 cortex iscsid[2899]: Connection1:0 to [target: iqn.2004-08.com.qsan:xs3324-000044bc0:dev1.ctr1, portal: 192.168.100.11,3260] through [iface: qsan_iscsi] is operati> Sep 27 15:26:18 cortex iscsid[2899]: Connection2:0 to [target: iqn.2004-08.com.qsan:xs3324-000044bc0:dev1.ctr2, portal: 192.168.200.11,3260] through [iface: qsan_iscsi] is operati> [root - etc]# systemctl status multipathd.service ● multipathd.service - Device-Mapper Multipath Device Controller Loaded: loaded (/usr/lib/systemd/system/multipathd.service; disabled; preset: disabled) Active: active (running) since Wed 2023-09-27 15:48:35 CEST; 16h ago TriggeredBy: ● multipathd.socket Process: 211750 ExecStartPre=/sbin/modprobe -a scsi_dh_alua scsi_dh_emc scsi_dh_rdac dm-multipath (code=exited, status=0/SUCCESS) Main PID: 211759 (multipathd) Status: "up" Tasks: 7 Memory: 18.9M CPU: 2.902s CGroup: /system.slice/multipathd.service └─211759 /sbin/multipathd -d -s Sep 27 16:10:39 cortex multipathd[211759]: sdd: path already removed Sep 27 16:10:39 cortex multipathd[211759]: sde: path already removed Sep 27 16:28:01 cortex multipathd[211759]: sdb: path already removed Sep 27 16:28:03 cortex multipathd[211759]: sdc: path already removed Sep 27 16:28:03 cortex multipathd[211759]: sdd: path already removed Sep 27 16:28:03 cortex multipathd[211759]: sde: path already removed Sep 28 08:06:07 cortex multipathd[211759]: sdb: path already removed Sep 28 08:06:08 cortex multipathd[211759]: sdc: path already removed Sep 28 08:06:08 cortex multipathd[211759]: sdd: path already removed Sep 28 08:06:08 cortex multipathd[211759]: sde: path already removed [root - etc]# ls *multipath* bindings wwids [root - etc]# cat multipath/bindings # Multipath bindings, Version : 1.0 # NOTE: this file is automatically maintained by the multipath program. # You should not need to edit this file in normal circumstances. # # Format: # alias wwid # [root - etc]# cat multipath/wwids # Multipath wwids, Version : 1.0 # NOTE: This file is automatically maintained by multipath and multipathd. # You should not need to edit this file in normal circumstances. # # Valid WWIDs: [root - etc]# multipath [root - etc]# ll multipath.conf ls: Zugriff auf 'multipath.conf' nicht möglich: Datei oder Verzeichnis nicht gefunden [root - etc]# How to reproduce: Just install package multipath-tools. Run "multipath".
Priority: Normal => High
I just noticed that there is an old bug report on Red Hat: Bug 1508483 - Device-Mapper-Multipath package does not create configuration files properly However, this bug report doesn't help me solve this problem.
Thank you for this report. The nearest relevant-looking reference I could find was: drbd-utils:/etc/multipath/conf.d/drbd.conf which however does *not* appear to be relevant here. I could see no package reference to '/etc/multipath/*' at all. Have you used this application before - on Mageia 8? The SRPM does not appear to have changed for a long time. I found this in the project site: "Policy assignment can be set manually at the command line. This one sets the policy to multibus for the multipath containing the device with major 8 and minor 0 (/dev/sda) multipath -p multibus -D 8 0 These policies can optionally be stored in a config file (/etc/multipath.conf). If the file is present, its content override the in-code defaults. All multipath hardware you will use must be described in either the config file if you have one, or the in-code defaults table if not, for the multipath tool to work" This is the only reference to /etc/multipath.conf in the entire Reference Book. It does look as if that file is optional, and normally not required in the place of "the in-code defaults table". From 2010 in the home page: "'show config' output usable as a config file replacement" I wonder whether your complaint should be: It is impossible to connect to a valid iSCSI target The home page: http://christophe.varoqui.free.fr/ shows several references, including: Reference book: http://christophe.varoqui.free.fr/refbook.html FAQ: http://christophe.varoqui.free.fr/faq.html RedHat usage details: http://christophe.varoqui.free.fr/usage.html
CC: (none) => lewyssmithSource RPM: (none) => multipath-tools-0.8.8-2.mga9.src.rpm
Finally, I found a working solution. I downloaded the rpm multipath packages listed in the QSAN document "How to implement iSCSI multipath on Linux OS". I also had to download the required libraries. Then I installed the packages. Now everything works perfectly. # multipath -ll mpatha (3202e0013781103c0) dm-4 QSAN,XS3324 size=73T features='0' hwhandler='1 alua' wp=rw |-+- policy='service-time 0' prio=50 status=active | `- 13:0:0:0 sdf 8:80 active ready running `-+- policy='service-time 0' prio=50 status=enabled `- 14:0:0:0 sdg 8:96 active ready running #
Well done for winning through. Can you please say: * Whether you used this under Mageia 8. * The URL for the QSAN document you cite. For the 'rpm multipath packages listed in the QSAN document', and 'the required libraries': * Which rpm(s) and libraries? * From Mageia repos? If not, from where? TIA
I did not use multipath under Mageia 8. I used the installation procedure described in: "How to implement iSCSI multipath on Linux OS" (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwj54enMydmCAxUQxQIHHbVGBjwQFnoECBgQAQ&url=https%3A%2F%2Fwww.qsan.com%2Fdata%2Fdl_files%2Fqs_wp_iSCSI-MPIO-in-Linux%2520(en).pdf&usg=AOvVaw3GfmEYg6OQqqnRo3IbqAndi&opi=89978449). I did not use the iscsi package mentioned in this document, but the original Mageia 9 package open-iscsi with its automatically selected dependencies. I downloaded the remaining two packages (device-mapper-1.02.79-8.el6.x86_64.rpm, device-mapper-multipath-0.4.9-72.el6.x86_64.rpm) together with device-mapper-multipath-libs-0.4.9-72.el6.x86_64.rpm from https://mirror.chpc.utah.edu/pub/vault.centos.org/6.4/cr/x86_64/Packages. After the open-iscsi configuration and the installation of the three device-mapper packages (sudo rpm -ivh --nodeps ...) I was able to call "mpathconf --enable", which created a multipath.conf file. This program or script is missing in the original Mageia packages. Another difference between this installation and the original Mageia 9 installation is that the default setting for "user_friendly_names" is set to "yes" instead of "no" (Mageia).
Well, this only part of the story, but mcc cannot handle these devices. The following happens if I click on "Browse and configure hardware" in mcc: # mcc Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. "cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 833. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. INTERNAL ERROR: unknown device sdg1 MDK::Common::Various::internal_error() called from /usr/lib/libDrakX/devices.pm:131 devices::entry() called from /usr/lib/libDrakX/devices.pm:146 devices::make() called from /usr/lib/libDrakX/fs/type.pm:269 fs::type::call_blkid() called from /usr/lib/libDrakX/fs/type.pm:276 fs::type::type_subpart_from_magic() called from /usr/lib/libDrakX/fsedit.pm:310 fsedit::get_hds() called from /usr/libexec/drakhardware:389 The devices are listed as follows: # multipath -ll qsan (3202e0013781103c0) dm-4 QSAN,XS3324 size=73T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw `-+- policy='round-robin 0' prio=50 status=active |- 13:0:0:0 sdg 8:96 active ready running `- 14:0:0:0 sdf 8:80 active ready running # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 6,5T 0 disk ├─sda1 8:1 0 64G 0 part [SWAP] └─sda2 8:2 0 6,5T 0 part /data sdb 8:16 1 0B 0 disk sdc 8:32 1 0B 0 disk sdd 8:48 1 0B 0 disk sde 8:64 1 0B 0 disk sdf 8:80 0 72,8T 0 disk └─qsan 252:4 0 72,8T 0 mpath └─qsan-part1 252:5 0 16M 0 part sdg 8:96 0 72,8T 0 disk └─qsan 252:4 0 72,8T 0 mpath └─qsan-part1 252:5 0 16M 0 part sr0 11:0 1 1024M 0 rom nvme0n1 259:0 0 1,9T 0 disk ├─nvme0n1p1 259:1 0 1G 0 part /boot/EFI └─nvme0n1p2 259:2 0 1,9T 0 part └─md0 9:0 0 1,9T 0 raid1 ├─vg0-lv_root 252:0 0 128G 0 lvm / ├─vg0-lv_var 252:1 0 128G 0 lvm /var ├─vg0-lv_opt 252:2 0 128G 0 lvm /opt └─vg0-lv_home 252:3 0 512G 0 lvm /home nvme1n1 259:3 0 1,9T 0 disk ├─nvme1n1p1 259:4 0 1G 0 part └─nvme1n1p2 259:5 0 1,9T 0 part └─md0 9:0 0 1,9T 0 raid1 ├─vg0-lv_root 252:0 0 128G 0 lvm / ├─vg0-lv_var 252:1 0 128G 0 lvm /var ├─vg0-lv_opt 252:2 0 128G 0 lvm /opt └─vg0-lv_home 252:3 0 512G 0 lvm /home
Now something else is also going wrong. After a restart, I have noticed that an NFS-related service no longer starts: # systemctl status nfs-idmapd.service × nfs-idmapd.service - NFSv4 ID-name mapping service Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static) Active: failed (Result: exit-code) since Fri 2023-11-24 11:51:24 CET; 4min 2s ago Process: 2541 ExecStart=/usr/sbin/rpc.idmapd (code=exited, status=1/FAILURE) CPU: 5ms Nov 24 11:51:24 cortex2 systemd[1]: Starting nfs-idmapd.service... Nov 24 11:51:24 cortex2 systemd[1]: nfs-idmapd.service: Control process exited, code=exited, status=1/FAILURE Nov 24 11:51:24 cortex2 systemd[1]: nfs-idmapd.service: Failed with result 'exit-code'. Nov 24 11:51:24 cortex2 systemd[1]: Failed to start nfs-idmapd.service. #
(In reply to Markus Mertens from comment #5) The very long URL you gave for "How to implement iSCSI multipath on Linux OS" redirected to: https://www.qsan.com/data/dl_files/qs_wp_iSCSI-MPIO-in-Linux%20(en).pdf > I did not use the iscsi package mentioned in this document, but the original > Mageia 9 package open-iscsi with its automatically selected dependencies. > > I downloaded the remaining two packages > device-mapper-1.02.79-8.el6.x86_64.rpm, > device-mapper-multipath-0.4.9-72.el6.x86_64.rpm together with > device-mapper-multipath-libs-0.4.9-72.el6.x86_64.rpm from > https://mirror.chpc.utah.edu/pub/vault.centos.org/6.4/cr/x86_64/Packages. We have no pkgs 'device-mapper...', the nearest I can find are: lib64devmapper-event1.02 lib64devmapper1.02 but these are in SRPM lvm2 > I was able to call "mpathconf --enable", which created a multipath.conf file > This program or script is missing in the original Mageia packages There seems to be a lot missing (device-mapper, multipath, mpathconf). CC'ing DaveH in the hope that he can throw some light on this before we pass it on.
CC: (none) => davidwhodgins
$ modinfo dm-mod|grep ^desc description: device-mapper driver device-mapper refers to kernel modules used by things such as dmraid, lvm, and mdadm to create the /dev/mapper device entries. They refer to logical devices rather then physical devices. For example, using lvm, after creating a lvm logical volume "mydata" on a physical volume "mga" on one partition ... # ll /dev/mapper/ total 0 crw------- 1 root root 10, 236 Nov 24 15:53 control lrwxrwxrwx 1 root root 7 Nov 24 15:58 vg--mga-lv_mydata -> ../dm-0 # ll /dev/dm-0 brw-rw---- 1 root disk 252, 0 Nov 24 15:58 /dev/dm-0 # grep /dev/vg-mga /etc/fstab /dev/vg-mga/lv_mydata /mydata ext4 acl,relatime 1 2 I've never used multipath as I've never had access to hardware that could use it. I don't know if it needs additional software.
"For example, using lvm, after creating a lvm logical volume "mydata" on a physical volume "mga" on one partition" refers to ... - create a partition an assign it to a (new in this case) physical volume - within the physical volume, create the logical volume, format and mount it. - update fstab. It's the creating of the logical volume that creates the /dev/mapper entry.
https://www.thegeekdiary.com/understanding-linux-multipath-using-dm-multipath/ has a diagram showing the type of hardware connections needed for using multipath.
Thank you for your comments, and that useful URL; although it starts cryptically with 'HBA', which might be the hardware elements unknown to MCC. It does help with this bit of Markus' comment 6: sdf 8:80 0 72,8T 0 disk └─qsan 252:4 0 72,8T 0 mpath └─qsan-part1 252:5 0 16M 0 part sdg 8:96 0 72,8T 0 disk └─qsan 252:4 0 72,8T 0 mpath └─qsan-part1 252:5 0 16M 0 part The multipath_tools SRPM is scarcely touched, so assigning this bug globally in hope. CC'ing MikeR who committed the current version. and Mageia tools for "mcc cannot handle these devices" comment 6.
CC: lewyssmith => mageiatools, mhrambo3501Assignee: bugsquad => pkg-bugs
HBA = Host bus adapter for the Storage area network. https://en.wikipedia.org/wiki/Host_adapter https://en.wikipedia.org/wiki/Storage_area_network
Today I tried the following: 1. installing Mageia 9 from scratch 2. installing open-iscsi (Mageia 9) after first reboot 3. downloading two newer multipath packages from a centos repository: device-mapper-multipath-0.4.9-133.el7.x86_64.rpm device-mapper-multipath-libs-0.4.9-133.el7.x86_64.rpm from: http://mirror.centos.org/centos/7/os/x86_64/Packages/ 4. installing both multipath packages with "rpm -ivh --nodeps ..." 5. creating a symbolic link libreadline.so.6 -> libreadline.so.8 in /usr/lib64: compiling multipath with actual Mageia libraries could avoid this 6. creating a dummy /etc/multipath.conf file: defaults { user_friendly_names yes } blacklist { } 7. starting multipathd.service 8. calling multipath -ll first time 9. editing the blacklist in /etc/multipath.conf (local disks should be avoided!) blacklist { wwid 3600300570252ea60294f249932176a30 wwid eui.000000000000000100a075212d45e452 wwid eui.000000000000000100a075212d45e45d } 10. reload multipathd.service Results: 1. multipath device is shown properly # multipath -ll qsan (3202e0013781103c0) dm-4 QSAN ,XS3324 size=73T features='1 queue_if_no_path' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=1 status=active |- 14:0:0:0 sdg 8:96 active ready running `- 13:0:0:0 sdf 8:80 active ready running # 2. mcc still crashes 3. no problems with NFS-services anymore # systemctl status nfs-* ● nfs-mountd.service - NFS Mount Daemon Loaded: loaded (/usr/lib/systemd/system/nfs-mountd.service; static) Active: active (running) since Mon 2023-11-27 13:17:28 CET; 34min ago Process: 6497 ExecStart=/usr/sbin/rpc.mountd (code=exited, status=0/SUCCESS) Main PID: 6549 (rpc.mountd) Tasks: 1 (limit: 629145) Memory: 1.1M CPU: 43ms CGroup: /system.slice/nfs-mountd.service └─6549 /usr/sbin/rpc.mountd Nov 27 13:17:28 cortex2 systemd[1]: Starting nfs-mountd.service... Nov 27 13:17:28 cortex2 systemd[1]: Started nfs-mountd.service. Nov 27 13:17:28 cortex2 rpc.mountd[6549]: Version 2.6.3 starting ● nfs-idmapd.service - NFSv4 ID-name mapping service Loaded: loaded (/usr/lib/systemd/system/nfs-idmapd.service; static) Active: active (running) since Mon 2023-11-27 12:23:17 CET; 1h 28min ago Process: 2437 ExecStart=/usr/sbin/rpc.idmapd (code=exited, status=0/SUCCESS) Main PID: 2440 (rpc.idmapd) Tasks: 1 (limit: 629145) Memory: 912.0K CPU: 6ms CGroup: /system.slice/nfs-idmapd.service └─2440 /usr/sbin/rpc.idmapd Nov 27 12:23:17 cortex2 systemd[1]: Starting nfs-idmapd.service... Nov 27 12:23:17 cortex2 rpc.idmapd[2440]: Setting log level to 0 Nov 27 12:23:17 cortex2 systemd[1]: Started nfs-idmapd.service. ● nfs-server.service - NFS server and services Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled; preset: disabled) Active: active (exited) since Mon 2023-11-27 13:19:31 CET; 32min ago Process: 9960 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=1/FAILURE) Process: 9961 ExecStart=/usr/sbin/rpc.nfsd (code=exited, status=0/SUCCESS) Process: 9982 ExecStart=/bin/sh -c if systemctl -q is-active gssproxy; then systemctl reload gssproxy ; fi (code=exited, status=0/SUCCESS) Main PID: 9982 (code=exited, status=0/SUCCESS) CPU: 36ms Nov 27 13:19:30 cortex2 systemd[1]: Starting nfs-server.service... Nov 27 13:19:30 cortex2 exportfs[9960]: exportfs: can't open /etc/exports for reading Nov 27 13:19:31 cortex2 systemd[1]: Finished nfs-server.service. #
Multipath seems to work perfectly, i.e. I can unplug a network cable without losing the connection to the external raid system. When I plug the cable back in, the second connection is re-established. What does not work are drak modules that refer to devices. At least the following two modules crash with an internal error (INTERNAL ERROR: unknown device sdf1): "Browse and configure hardware", "Set up boot system" # multipath -ll qsan (3202e0013781103c0) dm-4 QSAN ,XS3324 size=73T features='1 queue_if_no_path' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=1 status=active |- 13:0:0:0 sdf 8:80 active ready running `- 14:0:0:0 sdg 8:96 active ready running # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 6,5T 0 disk ├─sda1 8:1 0 64G 0 part [SWAP] └─sda2 8:2 0 6,5T 0 part /data sdb 8:16 1 0B 0 disk sdc 8:32 1 0B 0 disk sdd 8:48 1 0B 0 disk sde 8:64 1 0B 0 disk sdf 8:80 0 72,8T 0 disk └─qsan 252:4 0 72,8T 0 mpath sdg 8:96 0 72,8T 0 disk └─qsan 252:4 0 72,8T 0 mpath sr0 11:0 1 1024M 0 rom sr1 11:1 1 4,2G 0 rom nvme0n1 259:0 0 1,9T 0 disk ├─nvme0n1p1 259:4 0 1G 0 part /boot/EFI └─nvme0n1p2 259:5 0 1,9T 0 part └─md0 9:0 0 1,9T 0 raid1 ├─vg0-lv_root 252:0 0 128G 0 lvm / ├─vg0-lv_var 252:1 0 128G 0 lvm /var ├─vg0-lv_opt 252:2 0 128G 0 lvm /opt └─vg0-lv_home 252:3 0 512G 0 lvm /home nvme1n1 259:1 0 1,9T 0 disk ├─nvme1n1p1 259:2 0 1G 0 part └─nvme1n1p2 259:3 0 1,9T 0 part └─md0 9:0 0 1,9T 0 raid1 ├─vg0-lv_root 252:0 0 128G 0 lvm / ├─vg0-lv_var 252:1 0 128G 0 lvm /var ├─vg0-lv_opt 252:2 0 128G 0 lvm /opt └─vg0-lv_home 252:3 0 512G 0 lvm /home # mcc Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. GLib-GObject-CRITICAL **: g_boxed_type_register_static: assertion 'g_type_from_name (name) == 0' failed at /usr/lib64/perl5/DynaLoader.pm line 223. "cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 833. Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. INTERNAL ERROR: unknown device sdf1 MDK::Common::Various::internal_error() called from /usr/lib/libDrakX/devices.pm:131 devices::entry() called from /usr/lib/libDrakX/devices.pm:146 devices::make() called from /usr/lib/libDrakX/fs/type.pm:269 fs::type::call_blkid() called from /usr/lib/libDrakX/fs/type.pm:276 fs::type::type_subpart_from_magic() called from /usr/lib/libDrakX/fsedit.pm:310 fsedit::get_hds() called from /usr/libexec/drakhardware:389 Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257. Ignore the following Glib::Object::Introspection & Gtk3 warnings Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 539. INTERNAL ERROR: unknown device sdf1 MDK::Common::Various::internal_error() called from /usr/lib/libDrakX/devices.pm:131 devices::entry() called from /usr/lib/libDrakX/devices.pm:146 devices::make() called from /usr/lib/libDrakX/fs/type.pm:269 fs::type::call_blkid() called from /usr/lib/libDrakX/fs/type.pm:276 fs::type::type_subpart_from_magic() called from /usr/lib/libDrakX/fsedit.pm:310 fsedit::get_hds() called from /usr/libexec/drakboot:35 #
Assigning to Mageia tools group and updating subject
Assignee: pkg-bugs => mageiatoolsSummary: multipath-tools do not create a required configuration file (/etc/multipath.conf) => Diskdrake fails with "INTERNAL ERROR: unknown device" when multipath storage area network devices present
I think the error is coming from /usr/lib/libDrakX/devices.pm as the qsan/mpath device is not recognized.
Source RPM: multipath-tools-0.8.8-2.mga9.src.rpm => drakxtools-18.65-1.mga9.src.rpm
Yes, I agree. My original assumption that multipath tools would not work under Mageia 9 was incorrect. It does work, but the initial configuration is a bit tricky. Anyway, here is what I found out. After I had successfully installed and configured open-iscsi, I installed multipath-tools with its dependencies from Mageia 9. To get it running, you need to do the following: 1. before installing multipath-tools (mga9), you need to create a very simple multipath.conf file in /etc: # cat /etc/multipath.conf defaults { user_friendly_names yes find_multipaths yes path_grouping_policy multibus } multipaths { } blacklist { } # 2. Then install multipath-tools (mga9) and run it: # urpmi multipath-tools # systemctl enable multipathd.service # systemctl start multipathd.service 3. Try to detect hard disks that should be excluded. On a local system, these can be hardware RAIDs: # multipath -v2 -d 699.219625 | mpathb: setting dev_loss_tmo is unsupported for protocol scsi:unspec : mpathb (3600300570252ea60294f249932176a30) undef FTS,PRAID EP400i size=6.5T features='0' hwhandler='0' wp=undef `-+- policy='service-time 0' prio=1 status=undef `- 10:2:0:0 sda 8:0 undef ready running # 4. Edit the blacklist section in multipath.conf: blacklist { wwid 3600300570252ea60294f249932176a30 } 5. Restart multipathd.service and search for multipath devices: # systemctl restart multipathd.service # multipath -ll mpathd (3202e0013781103c0) dm-4 QSAN,XS3324 size=73T features='0' hwhandler='1 alua' wp=rw `-+- policy='round-robin 0' prio=50 status=active |- 13:0:0:0 sdf 8:80 active ready running `- 14:0:0:0 sdg 8:96 active ready running # 6. Edit the multipaths section in multipaths.conf: multipaths { multipath { wwid 3202e0013781103c0 alias qsan path_selector "round-robin 0" } } 7. Restart multipathd.service and search for multipath devices again. Also check the output of lsblk: # multipath -ll qsan (3202e0013781103c0) dm-4 QSAN,XS3324 size=73T features='0' hwhandler='1 alua' wp=rw `-+- policy='round-robin 0' prio=50 status=active |- 13:0:0:0 sdf 8:80 active ready running `- 14:0:0:0 sdg 8:96 active ready running # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 6,5T 0 disk ├─sda1 8:1 0 64G 0 part [SWAP] └─sda2 8:2 0 6,5T 0 part /data sdb 8:16 1 0B 0 disk sdc 8:32 1 0B 0 disk sdd 8:48 1 0B 0 disk sde 8:64 1 0B 0 disk sdf 8:80 0 72,8T 0 disk └─qsan 252:4 0 72,8T 0 mpath sdg 8:96 0 72,8T 0 disk └─qsan 252:4 0 72,8T 0 mpath sr0 11:0 1 1024M 0 rom sr1 11:1 1 4,2G 0 rom nvme0n1 259:0 0 1,9T 0 disk ├─nvme0n1p1 259:2 0 1G 0 part /boot/EFI └─nvme0n1p2 259:4 0 1,9T 0 part └─md0 9:0 0 1,9T 0 raid1 ├─vg0-lv_root 252:0 0 128G 0 lvm / ├─vg0-lv_var 252:1 0 128G 0 lvm /var ├─vg0-lv_opt 252:2 0 128G 0 lvm /opt └─vg0-lv_home 252:3 0 512G 0 lvm /home nvme1n1 259:1 0 1,9T 0 disk ├─nvme1n1p1 259:3 0 1G 0 part └─nvme1n1p2 259:5 0 1,9T 0 part └─md0 9:0 0 1,9T 0 raid1 ├─vg0-lv_root 252:0 0 128G 0 lvm / ├─vg0-lv_var 252:1 0 128G 0 lvm /var ├─vg0-lv_opt 252:2 0 128G 0 lvm /opt └─vg0-lv_home 252:3 0 512G 0 lvm /home # 8. Enjoy!
The multipath-tools package causes problems when updating the kernel modules. Updating to the latest kernel (6.5.11-desktop-5.mga9) and changes to the graphics driver (nvidia470) make the system unusable. To make changes to the kernel, multipath-tools must first be uninstalled.