Bug#900449: kpartx -d fails with no error when disk path is using more than 63 characters
Hello Ritesh, Yes, the issue occurs with the latest version of kpartx (multipath-tools). I reproduced it using the same reproductions steps on version 0.7.7 and even the latest commit on master: 00a54edd. Minor erratum from my original reproduction steps: according to the given script the "file" variable to use is **FILE1** and not FILE. As FILE1=t1 / FILE1=t12. Thanks, Julien On Mon, Jun 11, 2018 at 10:22 PM Ritesh Raj Sarraf wrote: > Hello Julien, > > Thank you for the bug report. > > You've tagged it upstream. Does the issue occur with the latest version > (0.7.4) too ? > > Thanks, > Ritesh > >
Bug#900449: kpartx -d fails with no error when disk path is using more than 63 characters
Hello Julien, Thank you for the bug report. You've tagged it upstream. Does the issue occur with the latest version (0.7.4) too ? Thanks, Ritesh On Wed, 2018-05-30 at 15:22 -0700, Julien Langlois wrote: > Package: kpartx > Version: 0.6.4-5 > Severity: normal > Tags: upstream > > Hi, > > The problem happens when using the disk path instead of the loop > device (/dev/loopXX) to delete partition mappings. > > == Reproduction steps == > > Consider the following script: > > DIR1=/tmp/test1/123456789/abcdefghi/123456789/abcdefghi/123456789 # > 60 characters long > mkdir -p $DIR1 > dd if=/dev/zero of=$DIR1/$FILE1 bs=1 count=0 seek=10M > parted --script $DIR1/$FILE1 mklabel msdos > kpartx -sav $DIR1/$FILE1 > kpartx -v -d $DIR1/$FILE1 > > When exceuted with FILE=t1 (63 characters long file path), there is > no problem, the partition mappings is added (creating a /dev/loop) > and then deleted (releasing the /dev/loop). > > But, when exceuted with FILE=t12 (64 characters long file path), the > partition mappings is properly added and but not deleted: > * losetup -a still shows the resource > * kpartx does not print the same message as usual in verbose mode > (del devmap : loop0p2) but stop with return code 0 > > > == Workaround == > > Use the /dev/loop path instead of the drive path to delete the > mapping > kpartx -d -v /dev/loop0 > losetup -d /dev/loop0 > > > I also reproduced this bug on Ubuntu 14.04 using kpartx version > 0.4.9-3ubuntu7. > > Julien > > > -- System Information: > Debian Release: 9.4 > APT prefers stable > APT policy: (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), > LANGUAGE=en_CA.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages kpartx depends on: > ii dmsetup 2:1.02.137-2 > ii libc6 2.24-11+deb9u3 > ii libdevmapper1.02.1 2:1.02.137-2 > ii udev232-25+deb9u2 > > kpartx recommends no packages. > > kpartx suggests no packages. > > -- no debconf information > -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: This is a digitally signed message part
Bug#900449: kpartx -d fails with no error when disk path is using more than 63 characters
Package: kpartx Version: 0.6.4-5 Severity: normal Tags: upstream Hi, The problem happens when using the disk path instead of the loop device (/dev/loopXX) to delete partition mappings. == Reproduction steps == Consider the following script: DIR1=/tmp/test1/123456789/abcdefghi/123456789/abcdefghi/123456789 # 60 characters long mkdir -p $DIR1 dd if=/dev/zero of=$DIR1/$FILE1 bs=1 count=0 seek=10M parted --script $DIR1/$FILE1 mklabel msdos kpartx -sav $DIR1/$FILE1 kpartx -v -d $DIR1/$FILE1 When exceuted with FILE=t1 (63 characters long file path), there is no problem, the partition mappings is added (creating a /dev/loop) and then deleted (releasing the /dev/loop). But, when exceuted with FILE=t12 (64 characters long file path), the partition mappings is properly added and but not deleted: * losetup -a still shows the resource * kpartx does not print the same message as usual in verbose mode (del devmap : loop0p2) but stop with return code 0 == Workaround == Use the /dev/loop path instead of the drive path to delete the mapping kpartx -d -v /dev/loop0 losetup -d /dev/loop0 I also reproduced this bug on Ubuntu 14.04 using kpartx version 0.4.9-3ubuntu7. Julien -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=en_CA.utf8, LC_CTYPE=en_CA.utf8 (charmap=UTF-8), LANGUAGE=en_CA.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kpartx depends on: ii dmsetup 2:1.02.137-2 ii libc6 2.24-11+deb9u3 ii libdevmapper1.02.1 2:1.02.137-2 ii udev232-25+deb9u2 kpartx recommends no packages. kpartx suggests no packages. -- no debconf information
