October 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1151703] New: python3-yamllint is missing requirement on python3-setuptools
by bugzilla_noreply＠novell.com 18 Jul '22

18 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1151703 Bug ID: 1151703 Summary: python3-yamllint is missing requirement on python3-setuptools Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: jayvdb(a)gmail.com Reporter: okurz(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- ## Observation yamllint tries to read out information during runtime using "pkg_resources" which is supplied by setuptools, if installed, but the package does not pull in this dependency. ## Steps to reproduce ``` $ docker run --rm -it registry.opensuse.org/opensuse/tumbleweed 5da80e2533ad:/ # zypper -n in python3-yamllint && yamllint Retrieving repository 'openSUSE-Tumbleweed-Non-Oss' metadata ............................................[done] Building repository 'openSUSE-Tumbleweed-Non-Oss' cache .................................................[done] Retrieving repository 'openSUSE-Tumbleweed-Oss' metadata ................................................[done] Building repository 'openSUSE-Tumbleweed-Oss' cache .....................................................[done] Retrieving repository 'openSUSE-Tumbleweed-Update' metadata .............................................[done] Building repository 'openSUSE-Tumbleweed-Update' cache ..................................................[done] Loading repository data... Reading installed packages... Resolving package dependencies... The following 9 NEW packages are going to be installed: libexpat1 libpython3_7m1_0 libuuid1 libyaml-0-2 python-rpm-macros python3-PyYAML python3-base python3-pathspec python3-yamllint 9 new packages to install. Overall download size: 8.9 MiB. Already cached: 0 B. After the operation, additional 34.5 MiB will be used. Continue? [y/n/v/...? shows all options] (y): y Retrieving package libexpat1-2.2.7-1.2.x86_64 (1/9), 87.7 KiB (206.3 KiB unpacked) Retrieving: libexpat1-2.2.7-1.2.x86_64.rpm ..............................................................[done] Retrieving package libpython3_7m1_0-3.7.3-1.3.x86_64 (2/9), 1.1 MiB ( 3.2 MiB unpacked) Retrieving: libpython3_7m1_0-3.7.3-1.3.x86_64.rpm .......................................................[done] Retrieving package libuuid1-2.34-2.1.x86_64 (3/9), 50.3 KiB ( 30.1 KiB unpacked) Retrieving: libuuid1-2.34-2.1.x86_64.rpm ................................................................[done] Retrieving package libyaml-0-2-0.2.2-2.1.x86_64 (4/9), 53.9 KiB (126.3 KiB unpacked) Retrieving: libyaml-0-2-0.2.2-2.1.x86_64.rpm ............................................................[done] Retrieving package python-rpm-macros-20190610.2ee3233-1.2.noarch (5/9), 25.8 KiB ( 47.0 KiB unpacked) Retrieving: python-rpm-macros-20190610.2ee3233-1.2.noarch.rpm ...........................................[done] Retrieving package python3-base-3.7.3-1.3.x86_64 (6/9), 7.2 MiB ( 29.7 MiB unpacked) Retrieving: python3-base-3.7.3-1.3.x86_64.rpm ...............................................[done (4.5 MiB/s)] Retrieving package python3-pathspec-0.5.9-1.4.noarch (7/9), 47.0 KiB (188.0 KiB unpacked) Retrieving: python3-pathspec-0.5.9-1.4.noarch.rpm .......................................................[done] Retrieving package python3-PyYAML-5.1.2-1.1.x86_64 (8/9), 189.8 KiB (739.6 KiB unpacked) Retrieving: python3-PyYAML-5.1.2-1.1.x86_64.rpm .........................................................[done] Retrieving package python3-yamllint-1.17.0-1.1.noarch (9/9), 71.9 KiB (294.0 KiB unpacked) Retrieving: python3-yamllint-1.17.0-1.1.noarch.rpm ......................................................[done] Checking for file conflicts: ............................................................................[done] (1/9) Installing: libexpat1-2.2.7-1.2.x86_64 ............................................................[done] (2/9) Installing: libpython3_7m1_0-3.7.3-1.3.x86_64 .....................................................[done] (3/9) Installing: libuuid1-2.34-2.1.x86_64 ..............................................................[done] (4/9) Installing: libyaml-0-2-0.2.2-2.1.x86_64 ..........................................................[done] (5/9) Installing: python-rpm-macros-20190610.2ee3233-1.2.noarch .........................................[done] (6/9) Installing: python3-base-3.7.3-1.3.x86_64 .........................................................[done] (7/9) Installing: python3-pathspec-0.5.9-1.4.noarch .....................................................[done] (8/9) Installing: python3-PyYAML-5.1.2-1.1.x86_64 .......................................................[done] (9/9) Installing: python3-yamllint-1.17.0-1.1.noarch ....................................................[done] Traceback (most recent call last): File "/usr/bin/yamllint", line 6, in <module> from pkg_resources import load_entry_point ModuleNotFoundError: No module named 'pkg_resources' ``` ``` -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1180383] New: Cannot boot on degraded raid with dual EFI partitions - dracut exits on emergency shell
by bugzilla_noreply＠suse.com 18 Jul '22

18 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1180383 Bug ID: 1180383 Summary: Cannot boot on degraded raid with dual EFI partitions - dracut exits on emergency shell Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: openSUSE Leap 15.2 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: jjletho67-esus(a)yahoo.it QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 844709 --> https://bugzilla.suse.com/attachment.cgi?id=844709&action=edit /etc/fstab file with the aim to make a fully redundant system I created a partition layout in which everything is on raid1 except the EFI partition. (see partition layout and fstab attached) ( EFI on raid was working fine on LEAP 42.3 but with LEAP 15.2 I'm having trouble, see: https://bugzilla.suse.com/show_bug.cgi?id=1179981 and https://forums.opensuse.org/showthread.php/547946-grub2-install-error-with-… ) For EFI partition redundancy I created two different EFI partitions, one for every disks, and i mounted on /boot/efi (disk1) and /boot/efi2 (disk2). I manually copied all the content from efi to efi2 every time it is needed and I launch the efibootmgr command to crate the correct efivars entry. I set the nofail options for efi and efi2 filesystem in fstab, since installation time. By this way the sistem is able to boot from both the efi partitions. When the disk2 is in fail condition (I remove the disk to simulate the failure) the system is able to boot fine. When the disk1 is in fail condition the system cannot complete the boot and emergency shell appears on the screen I'm attaching the rdsosreport.txt generated from dracut emergency shell when the system fails to boot. Please note that when i remove disk1 to simulate the failure condition, the system assign /dev/vda to disk2 (which is normally /dev/vdb) My speculation is the system absolutely want the /boot/efi partition but it cannot find it. This is an illogical behavior because once the system has started booting and the kernel has control, efi partition is not needed anymore. For this reason I set the nofail option in fstab, but it is not honored at some point. From my point of view this is exactly the same bug I found on leap 42.3: https://bugzilla.suse.com/show_bug.cgi?id=1059169 STEP TO REPRODUCE: Install LEAP 15.2 with the same partitions layout described in my attachment Perform a "zypper patch" and reboot it Then remove disk1 and reboot again ACTUAL RESULTS: the system does not boot, Dracut drop me in emergency shell. Last line on the console log is a warning about the /boot/efi missing EXPECTED RESULTS: the system continues to boot properly, after the timeout for the missing disk and partitions is expired -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1165351] New: systemd libpam-systemd immediate memory exhaustion triggers oom upon ssh
by bugzilla_noreply＠novell.com 18 Jul '22

18 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1165351 Bug ID: 1165351 Summary: systemd libpam-systemd immediate memory exhaustion triggers oom upon ssh Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: luis.chamberlain(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I have a fresh install of OpenSUSE Tumbleweed on two HP ProLiant DL380 Gen9, its at version 20200222 right now both with 30 GiB of RAM using systemd-244-2.1.x86_64. On one of them I noticed that whenever I ssh in as a regular user but not root I see the out of memory killer triggered. That is.. 30 GiB of RAM eaten up. The system now has the debug boolean set on /etc/pam.d/common-session and sudo journalctl -f reveals: Feb 29 16:31:18 chivo sshd[16511]: Accepted publickey for mcgrof from 10.100.208.217 port 44016 ssh2: RSA SHA256:tOilLVI1jM/Pvg5uJVQbeXGEAU0mma6Jxma9c5eVX0w Feb 29 16:31:18 chivo sshd[16511]: pam_systemd(sshd:session): pam-systemd initializing Feb 29 16:31:18 chivo sshd[16511]: pam_systemd(sshd:session): Asking logind to create session: uid=1000 pid=16511 service=sshd type=tty class=user desktop= seat= vtnr=0 tty= display= remote=yes remote_user= remote_host=10.100.208.217 Feb 29 16:31:18 chivo sshd[16511]: pam_systemd(sshd:session): Session limits: memory_max=n/a tasks_max=n/a cpu_weight=n/a io_weight=n/a runtime_max_sec=n/a Feb 29 16:31:18 chivo systemd-logind[2184]: New session 62 of user mcgrof. Feb 29 16:31:18 chivo systemd[1]: Starting User Manager for UID 1000... -- <oom trace> --- Feb 29 16:31:34 chivo kernel: oom_reaper: reaped process 16513 ((systemd)), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Feb 29 16:31:34 chivo systemd[1]: user(a)1000.service: Failed with result 'protocol'. Feb 29 16:31:34 chivo systemd[1]: Failed to start User Manager for UID 1000. Feb 29 16:31:34 chivo systemd[1]: Started Session 62 of user mcgrof. Feb 29 16:31:34 chivo sshd[16511]: pam_systemd(sshd:session): Reply from logind: id=62 object_path=/org/freedesktop/login1/session/_362 runtime_path=/run/user/1000 session_fd=7 seat= vtnr=0 original_uid=1000 Feb 29 16:31:34 chivo sshd[16511]: pam_unix(sshd:session): session opened for user mcgrof(uid=1000) by (uid=0) Here's what a vmstat log looks like every second, first with the system on idle, then I create a new ssh session, it takes a while to eat up all the memory and then the oom takes over and kills the pam systemd service, and I am able to log in. The blank links are put in place below to highlight when the ssh session is just delaying and the oom is about to hit: mcgrof@chivo ~ $ sudo vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 248704 31981364 136 160708 2 248 35 252 31 63 0 1 99 0 0 0 0 248704 31981056 136 160856 0 0 0 0 131 101 0 0 100 0 0 0 0 248704 31981056 136 160856 0 0 0 0 82 92 0 0 100 0 0 0 0 248704 31980552 136 160824 52 0 384 0 108 157 0 0 100 0 0 0 0 248704 31980472 136 161196 0 0 0 232 164 280 0 0 100 0 0 0 0 248704 31980200 136 161344 128 0 228 0 155 240 0 0 100 0 0 0 0 248704 31980200 136 161412 0 0 0 0 160 106 0 0 100 0 0 0 0 248704 31979628 136 161484 0 0 0 0 95 108 0 0 100 0 0 0 0 248704 31979628 136 161484 0 0 0 0 114 146 0 0 100 0 0 0 0 248704 31979628 136 161484 0 0 0 0 79 84 0 0 100 0 0 1 0 248704 31932744 136 161484 0 0 16 0 120 133 0 0 100 0 0 0 0 248704 31929664 136 161504 0 0 0 0 116 104 0 0 100 0 0 0 0 248704 31929640 136 161508 0 0 0 0 125 162 0 0 100 0 0 1 0 248704 28031352 136 163092 416 0 1940 0 574 515 3 2 95 0 0 1 0 248704 22681916 136 163092 0 0 64 340 473 354 3 2 95 0 0 1 0 248704 17326052 136 163172 0 0 0 0 364 116 3 2 95 0 0 1 0 248704 11968392 136 163172 0 0 0 0 364 124 3 2 95 0 0 1 0 248704 6612528 136 163172 0 0 0 0 374 110 3 2 95 0 0 1 0 248704 1257168 136 163172 0 0 0 0 366 114 3 2 95 0 0 1 1 565632 215044 136 82292 192 316912 1864 316912 1678 1135 1 2 91 6 0 2 1 954816 207848 136 76672 264 389708 1564 389708 30002 12569 0 1 89 9 0 3 2 353004 24513544 136 78252 140 139752 8480 139752 38917 113910 0 16 83 1 0 0 0 350444 32073372 136 122312 3040 24 42184 68 4774 14383 0 1 98 1 0 0 0 350444 32073372 136 122344 8 0 24 0 134 159 0 0 100 0 0 Running $(sudo htop --sort-key PERCENT_MEM -d 1) reveals the same but in a much more fun way. FWIW it is using yp, and I so I have: /etc/yp.conf domain suse.de server <some-private-ip> domain suse.de server <some-other-ip> However leaving this blank, running $(netconfig update -f), and then ssh'ing in reveals it still triggers. Related public issues: https://github.com/systemd/systemd/issues/11502 https://bugzilla.redhat.com/show_bug.cgi?id=1666690 https://github.com/systemd/systemd/commit/084eeb865ca63887098e0945fb4e93c85… Red Hat's bug reveals it was a bad backport of the fix for CVE-2018-16864 and so that itself introduced another CVE, CVE-2019-3815. I can reproduce very thing with a simple shiny new user created as user named test. The user root does not trigger the issue. What is however odd is that this issue is not reproducible on the other twin system. -- You are receiving this mail because: You are on the CC list for the bug.

2 85

[Bug 1188919] New: polkit no longer honors /etc/polkit-default-privs.local
by bugzilla_noreply＠suse.com 18 Jul '22

18 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1188919 Bug ID: 1188919 Summary: polkit no longer honors /etc/polkit-default-privs.local Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: meissner(a)suse.com Reporter: suse-beta(a)cboltz.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since one of the last Tumbleweed snapshots (somewhen between 20210723 and 20210726), /etc/polkit-default-privs.local gets ignored - with the effect that for example shutdown from KDE no longer works (I use PERMISSION_SECURITY="secure local" + a few polkit local overrides, one of them allows shutdown from KDE). Actually there are two problems in one: - /etc/polkit-default-privs.local was renamed to /etc/polkit-default-privs.local.rpmsave during zypper dup - renaming it back and running set_polkit_default_privs didn't change/fix anything. set_polkit_default_privs completely ignores /etc/polkit-default-privs.local (confirmed by running it with bash -x) I don't have a problem with moving the default config to /usr/etc/ - but PLEASE avoid breaking things while doing so. (Severity major because it's a regression, and because it breaks shutdown and some other things for me.) -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1041090] New: trackerbug: packages do not build reproducibly from unsorted input
by bugzilla_noreply＠novell.com 18 Jul '22

18 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1041090 Bug ID: 1041090 Summary: trackerbug: packages do not build reproducibly from unsorted input Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bwiedemann(a)suse.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: Development Blocker: --- See also https://reproducible-builds.org/docs/stable-inputs/ When linking .o files in random filesystem order the linker will vary the ordering of functions and apply varying optimizations resulting in binaries that differ on every build and thus trigger rebuilds of depending packages and are published to mirrors and users when actually nothing really changed. -- You are receiving this mail because: You are on the CC list for the bug.

2 15

[Bug 1174792] New: Feature request: ship v8-devel from the existing nodejs source
by bugzilla_noreply＠suse.com 15 Jul '22

15 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1174792 Bug ID: 1174792 Summary: Feature request: ship v8-devel from the existing nodejs source Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: i(a)marguerite.su Reporter: stasiek(a)michalski.cc QA Contact: bnc-team-screening(a)forge.provo.novell.com CC: amajer(a)suse.com Found By: --- Blocker: --- Currently the v8 libraries and development resources are built as a part of nodejs packages in OBS. Fedora ships compatibility symlinks that allow other software to use those libraries in the distribution. https://src.fedoraproject.org/rpms/nodejs/blob/master/f/nodejs.spec#_471 To avoid packaging overhead, could we do the same? -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1160091] New: Boinc Manager fails to auto-connect to localhost on application start
by bugzilla_noreply＠novell.com 15 Jul '22

15 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1160091 Bug ID: 1160091 Summary: Boinc Manager fails to auto-connect to localhost on application start Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: marix(a)marix.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When starting up the Boinc Manager application (boinc-manager) it fails to utilise the credentials in gui_rpc_auth.cfg to automatically connect to the Boinc client running on localhost. Weirdly, the automatic connection to localhost does work if the Boinc Manager is started automatically by KDEs session restore. This works even when the client was not connected to localhost when the previous KDE session was ended. Using boinccmd on the command line also works flawlessly. My initial assumption was that this was somehow related to the desktop file of the Boinc manager. However, explicitly launching boinc-manager from the command line and thus bystepping the desktop file shows the same issue. The behaviour I'd expect would be for the client to behave identical when being launched via the application launcher and via KDE's session restore mechanism, ideally auto-connecting successfully in both cases. -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1123721] New: suse-module-tools must not depend on mkintird / dracut
by bugzilla_noreply＠novell.com 14 Jul '22

14 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1123721 Bug ID: 1123721 Summary: suse-module-tools must not depend on mkintird / dracut Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Discussion on https://build.opensuse.org/request/show/657402 and via email. Email from Dominique Leuenberger, 2019-01-24 ------------- Some more thinking and tinkering around the problems with suse-module- tools - and your https://github.com/openSUSE/rpm-config-SUSE/pull/6 Adding a runtime dependency from suse-module-tools to dracut is a bad thing (with the current setup), as you already know: * coreutils buildrequires suse-module-tools in order to get the initrd macros in place. * coreutils is part of the distro bootstrap cycle (which is already large/too large). Adding dracut (plus dependency chain) into this cycle will make it close to impossible to bootstrap any new distro, namely SLE16 This shall not mean that dracut as a dependency on suse-module-tools is wrong per se, and as you did in the last weeks, we should try to find a solution for this issue, and I think the started path is not the worst: * we remove the macro to rebuild the initrd from suse-module-tools, and move that to a common place (rpm-config-SUSE comes to mind, it already contains commonly used macros) * With this, coreutils could completely give up on the dependency on suse-module-tools, which means s-module-tools could be downgraded from a ring0 to a ring1 package. The macro is already smart enough to skipt over the execution of /usr/lib/module-init-tools/regenerate-initrd- posttrans if it does not exist * An additional problem will show up though: dracut requires suse- module-tools, and suse-module-tools will require dracut. To break that cycle in OBS you will have to add a "#!BuildIgnore: suse-module-tools" to suse-module-tools.spec. This way forward would solve the technical difficulties we have around building a self-contained distro, without making it harder on the distro maintainers AND will allow us to add a dependency to s-m-t that is being interpreted by OBS (or we could even add a fileprovides then - once coreutils no longer cares for it) If any mail recipient has a valid reason AGAINST this plan, please speak up - but please also offer alternative solutions. Otherwise, let's get things moving. There are still two ring0 packages that will need touching (rpm-config-SUSE and coreutils) - and ring0 packages are 'tough' as they put a high load onto the distro build, meaning stagins willing to take them are scarse. ------------- https://github.com/openSUSE/rpm-config-SUSE/pull/6 has been accepted for rpm-config-SUSE. The initrd-related macros have _not_ been removed from suse-module-tools yet (15.0.20). The dependency on mkinitrd has been replaced by a weak "recommends". -- You are receiving this mail because: You are on the CC list for the bug.

2 20

[Bug 1123697] New: "rpm -V kernel-default" shows wrong permissions for initrd
by bugzilla_noreply＠novell.com 14 Jul '22

14 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1123697 Bug ID: 1123697 Summary: "rpm -V kernel-default" shows wrong permissions for initrd Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- # rpm -V kernel-default .M....... g /boot/initrd-4.12.14-25.23-default This happens on all distros at least since SLE12-SP3. The reason is that dracut creates the initrd with permissions 0600 (bug 1008340), but the kernel package contains a dummy initrd with permissions 0644. -- You are receiving this mail because: You are on the CC list for the bug.

2 30

[Bug 1122182] New: multipath broken on power on tumbleweed
by bugzilla_noreply＠novell.com 14 Jul '22

14 Jul '22

http://bugzilla.suse.com/show_bug.cgi?id=1122182 Bug ID: 1122182 Summary: multipath broken on power on tumbleweed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: ro(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- looks like the ipr controller strikes again on sle15 it still works: (xinomavro) # lsscsi -H [0] ipr [1] lpfc [2] lpfc [3] ipr # multipath -v3 -ll [...] ===== paths list ===== uuid hcil dev dev_t pri dm_st chk_st vend/prod/rev dev_st 0:2:0:0 sda 8:0 -1 undef undef IBM,IPR-0 6F46AC00 unknown 0:2:1:0 sdb 8:16 -1 undef undef IBM,IPR-0 6F46AC00 unknown 0:2:2:0 sdc 8:32 -1 undef undef IBM,IPR-0 6F46AC00 unknown 0:2:3:0 sdd 8:48 -1 undef undef IBM,IPR-0 6F425500 unknown 3:2:0:0 sde 8:64 -1 undef undef IBM,IPR-0 6F46AC00 unknown 3:2:1:0 sdf 8:80 -1 undef undef IBM,IPR-0 6F46AC00 unknown 3:2:2:0 sdg 8:96 -1 undef undef IBM,IPR-0 6F46AC00 unknown 3:2:3:0 sdh 8:112 -1 undef undef IBM,IPR-0 6F425500 unknown Jan 16 13:15:58 | libdevmapper version 1.03.01 (2017-12-18) Jan 16 13:15:58 | DM multipath kernel driver v1.13.0 Jan 16 13:15:58 | params = 1 queue_if_no_path 1 alua 2 1 service-time 0 1 2 8:48 1 1 service-time 0 1 2 8:112 1 1 Jan 16 13:15:58 | status = 2 0 1 0 2 1 A 0 1 2 8:48 A 0 0 1 E 0 1 2 8:112 A 0 0 1 Jan 16 13:15:58 | 1IBM_IPR-0_6F42550000000020: disassemble map [1 queue_if_no_path 1 alua 2 1 service-time 0 1 2 8:48 1 1 service-time 0 1 2 8:112 1 1 ] Jan 16 13:15:58 | sdd: udev property SCSI_IDENT_LUN_T10 whitelisted Jan 16 13:15:58 | sdd: mask = 0x8 Jan 16 13:15:58 | sdd: path state = running Jan 16 13:15:58 | sdd: detect_prio = yes (setting: multipath internal) Jan 16 13:15:58 | failed to issue vpd inquiry for pgc9 Jan 16 13:15:58 | loading /lib64/multipath/libpriosysfs.so prioritizer Jan 16 13:15:58 | sdd: prio = sysfs (setting: storage device autodetected) Jan 16 13:15:58 | sdd: prio args = "" (setting: storage device autodetected) Jan 16 13:15:58 | sdd: sysfs prio = 50 Jan 16 13:15:58 | sdh: udev property SCSI_IDENT_LUN_T10 whitelisted Jan 16 13:15:58 | sdh: mask = 0x8 Jan 16 13:15:58 | sdh: path state = running Jan 16 13:15:58 | sdh: detect_prio = yes (setting: multipath internal) Jan 16 13:15:58 | failed to issue vpd inquiry for pgc9 Jan 16 13:15:58 | sdh: prio = sysfs (setting: storage device autodetected) Jan 16 13:15:58 | sdh: prio args = "" (setting: storage device autodetected) Jan 16 13:15:58 | sdh: sysfs prio = 10 Jan 16 13:15:58 | 1IBM_IPR-0_6F42550000000020: disassemble status [2 0 1 0 2 1 A 0 1 2 8:48 A 0 0 1 E 0 1 2 8:112 A 0 0 1 ] 1IBM_IPR-0_6F42550000000020 dm-6 IBM,IPR-0 6F425500 size=2.6T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw |-+- policy='service-time 0' prio=50 status=active | `- 0:2:3:0 sdd 8:48 active ready running `-+- policy='service-time 0' prio=10 status=enabled `- 3:2:3:0 sdh 8:112 active ready running [...] on tumbleweed: (obs-power8-01) # multipath -v3 -ll [...] Jan 16 12:10:56 | sdd: size = 6694404096 Jan 16 12:10:56 | sdd: vendor = IBM Jan 16 12:10:56 | sdd: product = IPR-0 5ECDEA00 Jan 16 12:10:56 | sdd: rev = Jan 16 12:10:56 | sdd: h:b:t:l = 3:2:1:0 Jan 16 12:10:56 | sdd: tgt_node_name = Jan 16 12:10:56 | sdd: 61512 cyl, 128 heads, 32 sectors/track, start at 0 Jan 16 12:10:56 | 3:2:1:0: attribute vpd_pg80 not found in sysfs Jan 16 12:10:56 | failed to read sysfs vpd pg80 Jan 16 12:10:56 | sdd: fail to get serial Jan 16 12:10:56 | sdd: detect_checker = yes (setting: multipath internal) Jan 16 12:10:56 | sdd: path_checker = tur (setting: storage device autodetected) Jan 16 12:10:56 | sdd: checker timeout = 60 s (setting: multipath.conf defaults/devices section) Jan 16 12:10:56 | sdd: tur state = up ===== paths list ===== uuid hcil dev dev_t pri dm_st chk_st vend/prod/rev dev_st 0:2:0:0 sda 8:0 -1 undef undef IBM,IPR-10 5ECDEA00 unknown 0:2:1:0 sdb 8:16 -1 undef undef IBM,IPR-0 5ECDEA00 unknown 3:2:0:0 sdc 8:32 -1 undef undef IBM,IPR-10 5ECDEA00 unknown 3:2:1:0 sdd 8:48 -1 undef undef IBM,IPR-0 5ECDEA00 unknown Jan 16 12:10:56 | libdevmapper version 1.03.01 (2018-07-19) Jan 16 12:10:56 | DM multipath kernel driver v1.13.0 Jan 16 12:10:56 | unloading const prioritizer Jan 16 12:10:56 | unloading tur checker obs-power8-01:~ # dmesg | grep -E "mapper|multipath" [ 15.461123] device-mapper: uevent: version 1.0.3 [ 15.461239] device-mapper: ioctl: 4.39.0-ioctl (2018-04-03) initialised: dm-devel(a)redhat.com [ 15.462946] systemd-modules-load[1317]: Inserted module 'dm_multipath' [ 228.941013] device-mapper: multipath service-time: version 0.3.0 loaded [ 228.941142] device-mapper: table: table load rejected: not all devices are blk-mq request-stackable [ 228.941169] device-mapper: table: unable to determine table type [ 228.943508] device-mapper: table: table load rejected: not all devices are blk-mq request-stackable [ 228.943523] device-mapper: table: unable to determine table type [ 228.946381] device-mapper: table: table load rejected: not all devices are blk-mq request-stackable [ 228.946387] device-mapper: table: unable to determine table type [ 228.949130] device-mapper: table: table load rejected: not all devices are blk-mq request-stackable [ 228.949137] device-mapper: table: unable to determine table type [ 334.250096] systemd[1]: Listening on Device-mapper event daemon FIFOs. [ 334.250195] systemd[1]: Listening on multipathd control socket. [ 336.190785] device-mapper: table: 254:0: multipath: error getting device [ 336.190812] device-mapper: ioctl: error adding target to table [ 336.192423] device-mapper: table: table load rejected: not all devices are blk-mq request-stackable [ 336.192430] device-mapper: table: unable to determine table type [ 336.200096] device-mapper: table: 254:0: multipath: error getting device [ 336.200108] device-mapper: ioctl: error adding target to table [ 336.202816] device-mapper: table: table load rejected: not all devices are blk-mq request-stackable [ 336.202821] device-mapper: table: unable to determine table type -- You are receiving this mail because: You are on the CC list for the bug.

2 14