docker.io package: cannot stat /var/lib/docker.migrating/*

This should probably be filed under the docker.io package instead of ubuntu-release-upgrader.

Status changed to 'Confirmed' because the bug affects multiple users.

I've found this bug too.
It fails on postinst script. I've checked it and I'm wondering why does it try to create zfs dataset when it already exists?

When I applied this patch, everything works OK:

--- /var/lib/dpkg/info/docker.io.postinst.orig 2020-11-08 23:21:14.561453080 +0100
+++ /var/lib/dpkg/info/docker.io.postinst 2020-11-08 23:21:25.104740749 +0100
@@ -31,7 +31,7 @@
    # /var with canmount off if doesn’t exist
    rpool="$(zfs mount | awk '$2=="/" {print $1}'| cut -d/ -f1)"

- if [ -n "$rpool" ]; then
+ if [ -z "$rpool" ]; then
     dockermnt="$(findmnt -n -o SOURCE /var/lib/docker || true)"

     # Create <currentpool>/var/lib/docker if doesn’t exist

I have the same problem with a ZFS-based docker deployment.

The issue in my case seems to be, that /var/lib/dpkg/info/docker.io.postinst assumes/hard-coded, that the docker content should be located under the the /var/lib/docker directory. It then tries to migrate this off into a separate dataset.

Too bad: I already created a dedicated ZFS dataset for Docker on my own. And it's also in a different place: My /etc/docker/daemon.json has the following content

    {
        "data-root" : "/srv/docker"
    }

And this is also already a separate ZFS dataset:

   # findmnt -n -o SOURCE /srv/docker
   z4tank/docker

Looking at the docker.io.postinst file, the problem is that it hard-coded always assume /var/lib/docker and does not respect a potential diverting "data-root" setting:

https://git.launchpad.net/ubuntu/+source/docker.io/tree/debian/docker.io.postinst?h=applied/ubuntu/focal-updates#n38

@raczkow @etjohns2 : Do you both share something from my setting? i.e. a preconfigured ZFS dataset or a non-default data-root configuration?

I'm affected by this bug, too, and I confirm that @raczkow patch solves the problem