multipath-tool autopkg test fail on s390

Bug #1644253 reported by Christian Ehrhardt 
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
multipath-tools (Ubuntu)
Fix Released
Medium
Unassigned

Bug Description

Hi,
I just happened to see that multipath-tools autpkgtest is on "always failed" on s390x.
For a platform that so heavily relies on multipath-tools that should be fixed on next merge.

Here is one example:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/s390x/m/multipath-tools/20161123_134257_37ee0@/log.gz

You can pick whatever is the latest from:
http://autopkgtest.ubuntu.com/packages/multipath-tools

P.S. the same is true for armhf but they are less "multipathy" IMHO.

Changed in multipath-tools (Ubuntu):
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Worked on s390x LPAR as well as in an s390x KVM guest just as is.

I think it is related to
/dev/mapper/control: open failed: Operation not permitted
Failure to communicate with kernel device-mapper driver.
Check that device-mapper is available in the kernel.
Incompatible libdevmapper 1.02.136 (2016-11-05) and kernel driver (unknown version).

The script runs with needs-root anyway, so that isn't it.
But the unavailable kernel driver makes me wonder.

aupkg02 is a z/VM Guest that will be used for that - I don't know of the specific setup details.
I know that there is work ongoing to make this more of a normal *stack setup.

We have
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=y
So this should always be there.

But the following executed by one who is allowed on one of the systems should help to debug:
pull-lp-source multipath-tools
cd multipath-tools-0.5.0+git1.656f8865/debian/tests
sudo ./kpartx-file-loopback
# The former should reproduce the error
# Then look why/what might be going on with /dev/mapper/control
ls -laF /dev/mapper/control
lsmod | grep dm
# check dmesg ?
# more?

I need access, help from one with access or have to wait for the new *stack systems

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

s390x autopkgtest is the only autopkgtests that run in LXD containers unpriviledged, unlike all other autopkgtests. Thus please use isolation-machine for now.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Ok, discussion showed that there is still a LXD in between - thanks xnox.

That said the flags of the tests are incomplete, it needs isolation-machine.

Not considering SRU, once *stack infratstruture is used they will start to work for X&Y.

Changed in multipath-tools (Ubuntu):
status: Confirmed → Triaged
Changed in multipath-tools (Ubuntu):
status: Triaged → In Progress
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (6.7 KiB)

This bug was fixed in the package multipath-tools - 0.6.4-3ubuntu1

---------------
multipath-tools (0.6.4-3ubuntu1) zesty; urgency=medium

  * Merge from Debian. (LP: #1621340, LP: #1645274) Remaining changes:
    - d/control:
      - Bump udev dependencies
      - multipath-udeb: add sg3-udeb Depends
    - d/rules: Move udev rules to priority 95, because rules that load modules
      should be >90.
    - d/multipath-tools.preinst: modprobe dm-multipath; This will make sure
      that multipathd will be able to start.
    - Split kpartx initramfs bits into kpartx-boot for dmraid (LP: #941874)
      - d/initramfs/kpartx.hook
      - d/kpartx-boot.postinst
      - d/kpartx-boot.postrm
      - d/control: Add kpartx-boot package for dmraid
      - d/rules: Install kpartx initramfs hook
      - d/kpartx.install: install all arch /lib* kpartx udev rules
    - patches (some refreshed to new version) to multipath source
      - d/p/1000--set-umask-in-multipathd.patch: Set umask in multipathd.
      - d/p/path_selector.patch: switch the default path selector
        back to round-robin while service-time isn't available to the installer
        multipath-modules.
      - d/p/kpartx_more_loopback_fixes.patch: fix loopback mounted
        files some more: since we stat() the loopback device node, we can't rely
        on S_ISREG() tests to handle this case, and should look at the device
        itself instead. (LP: #1543430)
      - d/p/enable-find-multipaths.patch: re-enable find_multipaths
        by default -- see the removed 'add_find-multipaths.patch' (LP: #1463046)
   - multipath initramfs fixes for booting from multipathed devices
      - d/initramfs/hooks: also copy wwids file on the installed system to
        ensure all paths come up on boot. (LP: #1479929)
      - d/initramfs/hooks: install multipathd and required directories.
      - d/initramfs/hooks: copy dm-mpath-lvm & multipath udev rules to initramfs
      - d/initramfs/hooks: do not copy kpartx rules to initramfs
      - d/initramfs/local-bottom: remember to stop multipathd.
      - d/initramfs/local-premount: wait for udev to settle before the call to
        resolve_device() in local_mount_root(), so the by-uuid/ symlinks have a
        chance to be updated by the multipath udev rules (LP: #1503286).
      - d/initramfs/local-premount: Run multipath with -B so not to assign names
        nor change /etc/multipath/bindings during initramfs (LP: #1561103)
      - d/rules: install d/initramfs/local-bottom
      - d/rules: install d/initramfs/local-premount
   - Remove partition device nodes of individual paths (for LVM on multipath)
     (LP: #1540401)
   - Disable -fexceptions on multipath-udeb (LP: #1489379): the flag causes
     libchecktur.so to link with libgcc_s.so.1 (even with -static-libgcc),
     which is not available in the installer environment.
     - d/p/disable-fexceptions-udeb.patch: conditionally disable -fexceptions
       with CFLAGS_DISABLE_FEXCEPTIONS.
     - d/rules: set CFLAGS_DISABLE_FEXCEPTIONS to build multipath-udeb.
   - d/tests/kpartx-file-loopback: add an autopkgtest to catch future cases
     where uploads might break kpartx's loopback file handling.
   -...

Read more...

Changed in multipath-tools (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.