Red Hat Bugzilla – Bug 1496295
container-storage-setup fails on multipath device
Last modified: 2018-08-16 12:05:42 EDT
Description of problem: When I run container-storage-setup on a multipath device, it fails with "Partition specification unsupported at this time" unnecessarily. Version-Release number of selected component (if applicable): container-storage-setup-0.6.0-1.gite67c964.el7.noarch How reproducible: 100% Steps to Reproduce: 1. Set up a multipath device, as in the following example: # multipath -ll 3600a0980383030567a3f472d78475237 dm-3 NETAPP ,LUN C-Mode size=100G features='2 queue_if_no_path retain_attached_hw_handler' hwhandler='1 alua' wp=rw |-+- policy='service-time 0' prio=50 status=active | `- 7:0:0:0 sde 8:64 active ready running `-+- policy='service-time 0' prio=10 status=enabled |- 5:0:0:0 sdc 8:32 active ready running |- 4:0:0:0 sdb 8:16 active ready running |- 6:0:0:0 sdd 8:48 active ready running |- 8:0:0:0 sdf 8:80 active ready running `- 3:0:0:0 sda 8:0 active ready running 2. Use the multipath device as DEVS in /etc/sysconfig/docker-storage-setup as in example: # cat /etc/sysconfig/docker-storage-setup # Edit this file to override any configuration options specified in # /usr/lib/docker-storage-setup/docker-storage-setup. # # For more details refer to "man docker-storage-setup" STORAGE_DRIVER=overlay2 DEVS=/dev/mapper/3600a0980383030567a3f472d78475237 CONTAINER_ROOT_LV_NAME=dockerlv CONTAINER_ROOT_LV_MOUNT_PATH=/var/lib/docker CONTAINER_ROOT_LV_SIZE=100%FREE WIPE_SIGNATURES=true VG=vg_docker 3. Run container-storage-setup Actual results: container-storage-setup gives fatal error "Partition specification unsupported at this time" and exits. Expected results: container-storage-setup completes successfully. Additional info: Can be worked around by patching container-storage-setup like this: --- container-storage-setup.old 2017-09-27 01:45:19.749736493 +0000 +++ container-storage-setup 2017-09-27 01:22:53.386518050 +0000 @@ -666,6 +666,9 @@ if [ "$disktype" == "part" ];then return 0 fi + if [ "$disktype" == "mpath" ];then + return 1 + fi # For loop device partitions, lsblk reports type as "loop" and not "part". # So check if device has a parent in the tree and if it does, there are high
I'm able to reproduce this issue as well. Just adding to what's already been posted # cat /etc/sysconfig/docker-storage-setup DEVS=/dev/mapper/mpatha VG=dockervg WIPE_SIGNATURES=true --- Nov 01 17:25:13 docker2.example.com systemd[1]: Starting Docker Storage Setup... Nov 01 17:25:13 docker2.example.com container-storage-setup[2464]: ERROR: Partition specification unsupported at this time. Nov 01 17:25:13 docker2.example.com systemd[1]: docker-storage-setup.service: main process exited, code=exited, status=1/FAILURE Nov 01 17:25:13 docker2.example.com systemd[1]: Failed to start Docker Storage Setup. Nov 01 17:25:13 docker2.example.com systemd[1]: Unit docker-storage-setup.service entered failed state. Nov 01 17:25:13 docker2.example.com systemd[1]: docker-storage-setup.service failed. --- Looking for where this error originates: /usr/bin/container-storage-setup: --- 732 if is_block_dev_partition ${dev_abs}; then 733 Fatal "Partition specification unsupported at this time." 734 fi [...] 663 is_block_dev_partition() { 664 local bdev=$1 devparent 665 666 if ! disktype=$(lsblk -n --nodeps --output type ${bdev}); then 667 Fatal "Failed to run lsblk on device $bdev" 668 fi 669 670 if [ "$disktype" == "part" ];then 671 return 0 672 fi 673 674 # For loop device partitions, lsblk reports type as "loop" and not "part". 675 # So check if device has a parent in the tree and if it does, there are high 676 # chances it is partition (except the case of lvm volumes) 677 if ! devparent=$(lsblk -npls -o NAME ${bdev}|tail -n +2); then 678 Fatal "Failed to run lsblk on device $bdev" 679 fi 680 681 if [ -n "$devparent" ];then 682 return 0 683 fi 684 685 return 1 686 } --- # lsblk -npls -o NAME /dev/mapper/mpatha|tail -n +2 /dev/sda # lsblk -npls -o NAME /dev/sda|tail -n +2 | wc -l 0
Same for me. Resolved with indicated workaround
Merged upstream. https://github.com/projectatomic/container-storage-setup/commit/5eaf76cf233bf43dea5385f3dfcad7ec72cf05d9
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2474