Loop devices are not removed because grep fails

[tabletseeker]

grep in dmsetup ls | grep -q "^${LOOP_PART} " fails because of this space ^${LOOP_PART} " https://github.com/grml/grml-debootstrap/blob/eae91811116fbc452efe45c6b80ecc647547ea1f/grml-debootstrap#L331

  if [ -n "${ORIG_TARGET}" ] ; then
    einfo "Removing loopback mount of file ${ORIG_TARGET}."
    kpartx -d "${ORIG_TARGET}" || eend $?
    # Workaround for a bug in kpartx which doesn't clean up properly,
    # see Debian Bug #891077 and Github-PR grml/grml-debootstrap#112
    if dmsetup ls | grep -q "^${LOOP_PART} "; then
      kpartx -d "/dev/${LOOP_DISK}" >/dev/null || eend $?
    fi
  fi

++ printf ' %s*%s Removing loopback mount of file /home/user/test.img.\n' '' ''
 * Removing loopback mount of file /home/user/test.img.
++ LAST_E_CMD=einfon
++ return 0
++ return 0
++ kpartx -d /home/user/test.img
++ dmsetup ls
++ grep -q '^loop2p3 '
++ '[' -n 1 ']'
++ EXIT=1
++ '[' -n '' ']'
++ exit 1

Removing the space allows grep to work correctly and kpartx -d "/dev/${LOOP_DISK}" to be executed.

    if dmsetup ls | grep -q "^${LOOP_PART}"; then
      kpartx -d "/dev/${LOOP_DISK}" >/dev/null || eend $?
    fi

Test with /dev/loop2

dmsetup ls | grep '^loop2p3'; echo $?
loop2p3	(252:8)
0

[zeha]

Ok, but just removing the space is not correct - it would also match loop22p3 (in your case) ...

[zeha]

Related: #344 - which wants to remove this entirely

[tabletseeker]

Ok, but just removing the space is not correct - it would also match loop22p3 (in your case) ...

 * Removing loopback mount of file /home/user/test.img.
++ LAST_E_CMD=einfon
++ return 0
++ return 0
++ kpartx -d /home/user/test.img
++ dmsetup ls
++ grep -q '^loop0p3 '
++ '[' -n 1 ']'
++ EXIT=1
++ '[' -n '' ']'
++ exit 1

dmsetup ls
loop0p1	(252:0)
loop0p2	(252:1)
loop0p3	(252:2)

dmsetup ls | grep '^loop0p3 ' ; echo $?
1

dmsetup ls | grep '^loop0p3' ; echo $?
loop0p3	(252:2)
0

With space fix applied:

    if dmsetup ls | grep -q "^${LOOP_PART}"; then
      kpartx -d "/dev/${LOOP_DISK}" >/dev/null || eend $?
    fi

++ printf ' %s*%s Removing loopback mount of file /home/user/test.img.\n' '' ''
 * Removing loopback mount of file /home/user/test.img.
++ LAST_E_CMD=einfon
++ return 0
++ return 0
++ kpartx -d /home/user/test.img
++ dmsetup ls
++ grep -q '^loop0p3'
++ kpartx -d /dev/loop0
++ '[' -n 1 ']'
++ EXIT=1
++ '[' -n '' ']'
++ exit 1

[tabletseeker]

@zeha could you clarify? The current pattern grep -q "^${LOOP_PART}" is fine and only matches strings beginning with that exact loop/part id, thus matching exclusively. I guess a more accurate usage of grep would be grep -qw "${LOOP_PART}", but the inclusion of a space doesn't appear useful in any scenario.

[mika]

I'm not entirely sure about this yet, but maybe all of this is no longer relevant once https://github.com/grml/grml-debootstrap/pull/346 gets applied? @tabletseeker any chance you could take a look at the PR to see whether that would fix your issue? 🙏

[tabletseeker]

I'm not entirely sure about this yet, but maybe all of this is no longer relevant once #346 gets applied?

Hello!

Unfortunately, Debian bug #891077 still seems to occur under certain conditions. Instead of fixing the workaround, #346 would simply remove it entirely, which is not helpful.

If you'd consider allowing the workaround to persist, may I ask what the purpose of that space in "^${LOOP_PART} " was, originally?

[adrelanos]

This is might be a bug in kpartx.

Required:

• Minimal instructions on how to reproduce this issue (without grml-debootstrap);
• Upstream bug report to kpartx.

Do you think you could create a minimal repository with a minimal environment able to reproduce this issue? @tabletseeker

[tabletseeker]

Do you think you could create a minimal repository with a minimal environment able to reproduce this issue? @tabletseeker

Yes, no problem.

I only experience this issue inside a debian:bookworm Docker Container.

I could write a Dockerfile similar to the one I'm using with a kpartx script, for the purpose of reproducing it.

There have been some reports on the Docker Forum regarding issues with device mapper and kpartx.

In case this is kernel related, I'm running docker in a Bookworm VM, Kernel 6.12.12 and Docker version 28.1.1

[zeha]

I only experience this issue inside a debian:bookworm Docker Container.

The problem source in such a setup is often outside Docker. If some random background service acquires file descriptors to loop devices, then you get this problem category.

We sometimes see similar issues in GitHub Action Runners, which also run a lot of random stuff in the background.