Hey Patrick, yes this.
I’ve run some more tests in the container and can confirm that is the problem.
./build-steps.d/3200_create-raw-image --target virtualbox --flavor whonix-gateway-cli
./build-steps.d/4400_zerofree-raw --target virtualbox --flavor whonix-gateway-cli
losetup --all
/dev/loop1: [65027]:1228234 (/home/user/derivative-binary/17.4.0.2/Whonix-Gateway-CLI-17.4.0.2.Intel_AMD64.raw)
/dev/loop0: [65027]:1228234 (/home/user/derivative-binary/17.4.0.2/Whonix-Gateway-CLI-17.4.0.2.Intel_AMD64.raw)
It’s kpartx that fails to remove the loop device.
kpartx -asv /home/user/derivative-binary/17.4.0.2/Whonix-Gateway-CLI-17.4.0.2.Intel_AMD64.raw
add map loop3p1 (252:7): 0 204800 linear 7:3 2048
add map loop3p2 (252:8): 0 2048 linear 7:3 206848
add map loop3p3 (252:9): 0 209504256 linear 7:3 208896
losetup --all
/dev/loop1: [65027]:1228234 (/home/user/derivative-binary/17.4.0.2/Whonix-Gateway-CLI-17.4.0.2.Intel_AMD64.raw)
kpartx -d -s -v /home/user/derivative-binary/17.4.0.2/Whonix-Gateway-CLI-17.4.0.2.Intel_AMD64.raw; echo $?
0
losetup --all
/dev/loop1: [65027]:1228234 (/home/user/derivative-binary/17.4.0.2/Whonix-Gateway-CLI-17.4.0.2.Intel_AMD64.raw)
The loop device needs to be targeted directly to remove the mount.
kpartx -dsv /dev/loop1
del devmap : loop1p1
del devmap : loop1p2
del devmap : loop1p3
This is accomplishes the same as dmsetup remove
But that’s the only way to completely remove it, after the dismount.
losetup -d /dev/loop1
losetup --all
kpartx -d against the raw seems to do nothing. Whether that’s docker related or maybe a kernel specific issue, I’m not sure.
uname -a
Linux 3a5a4cah2c01 6.12.22-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.22-1 (2025-04-10) x86_64 GNU/Linux
If you have the time, could you maybe run the container once?
I would like to confirm if I’m going crazy or not.
Anyone would be welcome to share a test run, actually. There’ve been a bunch of clones but no feedback
Just one tiny thing if you do, comment line 20 in entrypoint.sh/
#lo_check; \
