grml/grml-debootstrap

Installing stretch VM system might fail due to unclosed file handles

Opened this issue · 0 comments

mika commented

Forwarding a bug report I received via IRC hereby:

The executed cmdline was:

# grml-debootstrap --mirror http://deb.debian.org/debian --hostname $1 \
  --nopassword --vmsize ${4}g --chroot-scripts $MY_TEMPDIR/ \
  --force -r $DISTRO --debopt "--include=fai-client,git,ssh,vim,cfengine2" \
  --vmfile --target $IMAGE_FILE

running on a Debian/stretch bare metal system with the grml-debootstrap version from stretch.
Inside "$MY_TEMPDIR" there's just a script echoing into a file (so shouldn't be relevant).

Problem:

   Executing stage upgrade_system
Running update + upgrade
Ign:1 http://deb.debian.org/debian stretch InRelease
Hit:2 http://security.debian.org stretch/updates InRelease
Hit:3 http://deb.debian.org/debian stretch Release
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libssl1.0.2 sensible-utils
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1305 kB of archives.
After this operation, 49.2 kB disk space will be freed.
Get:1 http://security.debian.org stretch/updates/main amd64 sensible-utils all 0.0.9+deb9u1 [10.8 kB]
Get:2 http://security.debian.org stretch/updates/main amd64 libssl1.0.2 amd64 1.0.2l-2+deb9u2 [1294 kB]
Fetched 1305 kB in 0s (4099 kB/s)    
Preconfiguring packages ...
(Reading database ... 40416 files and directories currently installed.)
Preparing to unpack .../sensible-utils_0.0.9+deb9u1_all.deb ...
Unpacking sensible-utils (0.0.9+deb9u1) over (0.0.9) ...
Setting up sensible-utils (0.0.9+deb9u1) ...
(Reading database ... 40416 files and directories currently installed.)
Preparing to unpack .../libssl1.0.2_1.0.2l-2+deb9u2_amd64.deb ...
Unpacking libssl1.0.2:amd64 (1.0.2l-2+deb9u2) over (1.0.2l-2+deb9u1) ...
Processing triggers for mime-support (3.60) ...
Setting up libssl1.0.2:amd64 (1.0.2l-2+deb9u2) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...
   Executing stage remove_apt_cache
Cleaning apt cache.
   Executing stage services
[ ok ] Stopping OpenBSD Secure Shell server: sshd.
   Executing stage remove_chrootmirror
Finished chroot installation, exiting.
umount: /mnt/debootstrap.5160/dev: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
 * Removing chroot-script again
 * Unmount /mnt/debootstrap.5160
umount: /mnt/debootstrap.5160: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
 -> Failed (rc=32)
 * Removing /var/cache/grml-debootstrap/variables_test6.img
 * Removing /var/cache/grml-debootstrap/stages_test6.img
[ ok ] Stopping OpenBSD Secure Shell server: sshd.
 * Unmounting /mnt/debootstrap.5160
umount: /mnt/debootstrap.5160: target is busy
        (In some cases useful info about processes that
         use the device is found by lsof(8) or fuser(1).)
 -> Failed (rc=32)
Removing stages directory /var/cache/grml-debootstrap/stages_test6.img: done
 * Removing directory /mnt/debootstrap.5160
rmdir: failed to remove '/mnt/debootstrap.5160': Device or resource busy
 -> Failed (rc=1)
 * Removing loopback mount of file /home/kvm/test6.img.
device-mapper: remove ioctl on loop1p1 failed: Device or resource busy
loop deleted : /dev/loop1
 -> Failed (rc=1)
 * Notice: remove /var/cache/grml-debootstrap/stages_test6.img/umount_chroot to reexecute the stage

According to the bug reporter seems to work for jessie but fails with stretch.
We should try to reproduce this.