Bug#891077: kpartx -d doesn't cleanup

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#891077: kpartx -d doesn't cleanup

Xavier Bestel
Package: kpartx
Version: 0.7.4-3
Severity: important

Hi,

If I execute the following testcase:
        #!/bin/bash -xe
        IMAGE_PATH=bug.img
        truncate -s 3608M "${IMAGE_PATH}"
        /sbin/sfdisk "${IMAGE_PATH}" <<-__EOF__
        4M,512M,L,*
        516M,512M,,
        1028M,512M,,
        1540M,,E,
        ,64M,,
        ,64M,,
        ,,,
        __EOF__
        sudo kpartx -l "${IMAGE_PATH}"
        sudo kpartx -a "${IMAGE_PATH}"
        sudo kpartx -d "${IMAGE_PATH}"
then kpartx won't cleanup its loop devices:
        $ ls -l /dev/loop* /dev/mapper/
        brw-rw---- 1 root disk  7,   0 févr. 22 09:30 /dev/loop0
        brw-rw---- 1 root disk  7,   1 févr. 22 09:30 /dev/loop1
        brw-rw---- 1 root disk  7,   2 févr. 20 11:38 /dev/loop2
        brw-rw---- 1 root disk  7,   3 févr. 20 11:38 /dev/loop3
        brw-rw---- 1 root disk  7,   4 févr. 20 11:39 /dev/loop4
        brw-rw---- 1 root disk  7,   5 févr. 14 11:35 /dev/loop5
        brw-rw---- 1 root disk  7,   6 févr. 14 11:35 /dev/loop6
        brw-rw---- 1 root disk  7,   7 févr. 14 11:35 /dev/loop7
        crw-rw---- 1 root disk 10, 237 févr. 22 09:12 /dev/loop-control

        /dev/mapper/:
        total 0
        crw------- 1 root root 10, 236 févr.  9 13:54 control
        lrwxrwxrwx 1 root root       7 févr. 22 09:30 loop1p1 -> ../dm-0
        lrwxrwxrwx 1 root root       7 févr. 22 09:30 loop1p2 -> ../dm-1
        lrwxrwxrwx 1 root root       7 févr. 22 09:30 loop1p3 -> ../dm-2
        lrwxrwxrwx 1 root root       7 févr. 22 09:30 loop1p4 -> ../dm-3
        lrwxrwxrwx 1 root root       7 févr. 22 09:30 loop1p5 -> ../dm-4
        lrwxrwxrwx 1 root root       7 févr. 22 09:30 loop1p6 -> ../dm-5
        lrwxrwxrwx 1 root root       7 févr. 22 09:30 loop1p7 -> ../dm-6
        $ sudo losetup -l
        NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                    DIO LOG-SEC
        /dev/loop1         0      0         0  0 /home/xav/bug_kaprtx/bug.img   0     512
        /dev/loop0         0      0         0  0 /home/xav/bug_kaprtx/bug.img   0     512
this is really problematic, because you can't invoke kpartx twice - in
some scripts, the loop devices indices become wrong.

Cheers
        Xav

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (900, 'stable'), (500, 'stable-updates'), (90, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kpartx depends on:
ii  dmsetup             2:1.02.145-4.1
ii  libc6               2.26-6
ii  libdevmapper1.02.1  2:1.02.145-4.1
ii  udev                237-3

kpartx recommends no packages.

kpartx suggests no packages.

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

Bug#891077: kpartx -d doesn't cleanup

Ritesh Raj Sarraf-4
Control: tag -1 +confirmed


Hello Xavier,

Thanks for the bug report. I'm aware of the problem but haven't had
time to root cause it, yet. Hopefully soon.

On Thu, 2018-02-22 at 09:50 +0100, Xavier Bestel wrote:

> Package: kpartx
> Version: 0.7.4-3
> Severity: important
>
> Hi,
>
> If I execute the following testcase:
>         #!/bin/bash -xe
>         IMAGE_PATH=bug.img
>         truncate -s 3608M "${IMAGE_PATH}"
>         /sbin/sfdisk "${IMAGE_PATH}" <<-__EOF__
>         4M,512M,L,*
>         516M,512M,,
>         1028M,512M,,
>         1540M,,E,
>         ,64M,,
>         ,64M,,
>         ,,,
>         __EOF__
>         sudo kpartx -l "${IMAGE_PATH}"
>         sudo kpartx -a "${IMAGE_PATH}"
>         sudo kpartx -d "${IMAGE_PATH}"
> then kpartx won't cleanup its loop devices:
--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#891077: kpartx -d doesn't cleanup

Darshaka Pathirana-2
Hey,

any progress on that? Just stumbled over this issue and asked myself
if there is a fix or at least a reliable workaround available.

Regards from DebConf18, Taiwan :),
 - Darsha

On 02/22/2018 03:29 PM, Ritesh Raj Sarraf wrote:

> Control: tag -1 +confirmed
>
>
> Hello Xavier,
>
> Thanks for the bug report. I'm aware of the problem but haven't had
> time to root cause it, yet. Hopefully soon.
>
> On Thu, 2018-02-22 at 09:50 +0100, Xavier Bestel wrote:
>> Package: kpartx
>> Version: 0.7.4-3
>> Severity: important
>>
>> Hi,
>>
>> If I execute the following testcase:
>>         #!/bin/bash -xe
>>         IMAGE_PATH=bug.img
>>         truncate -s 3608M "${IMAGE_PATH}"
>>         /sbin/sfdisk "${IMAGE_PATH}" <<-__EOF__
>>         4M,512M,L,*
>>         516M,512M,,
>>         1028M,512M,,
>>         1540M,,E,
>>         ,64M,,
>>         ,64M,,
>>         ,,,
>>         __EOF__
>>         sudo kpartx -l "${IMAGE_PATH}"
>>         sudo kpartx -a "${IMAGE_PATH}"
>>         sudo kpartx -d "${IMAGE_PATH}"
>> then kpartx won't cleanup its loop devices:


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#891077: kpartx -d doesn't cleanup

Ritesh Raj Sarraf-4
On Wed, 2018-07-25 at 15:32 +0200, Darshaka Pathirana wrote:
>
> any progress on that? Just stumbled over this issue and asked myself
> if there is a fix or at least a reliable workaround available.

Nope. I've not had time to look at it yet.


--
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#891077: kpartx -d doesn't cleanup

Chris Hofstaedtler
In reply to this post by Darshaka Pathirana-2
Control: tags -1 + upstream confirmed

> >> If I execute the following testcase:
> >>         #!/bin/bash -xe
> >>         IMAGE_PATH=bug.img
[..]
> >>         sudo kpartx -a "${IMAGE_PATH}"
> >>         sudo kpartx -d "${IMAGE_PATH}"
> >> then kpartx won't cleanup its loop devices:

Indeed. The problem here is that the loop device refers to the image
file by full path, and then the comparison at -d time fails.
In general upstream thinks that this is a convenience feature and
you should delete mappings by passing the loop device name instead
(so kpartx -d /dev/loop1).

This is also LP#1747044.

Upstream has improved/fixes this in commit
c1adcc5ba452bb1252c97c8066e340433976c23e (past 0.7.7).

Cheers,
Chris