gnome-disk-image-mounter fails after upgrade to 20.10

[Tessa]

after upgrading to 20.10, mounting ISOs fails after a bit over 20s, with a GTK dialogue that reads:
```
Error attaching disk image:
GDBus.Error:org.freedesktop.UDisks2.Error.Fails: Error waiting for loop object after creating '/dev/loop5': Timed out waiting for object (udisks-error-quark, 0)
```

note that the loop device named increases on every attempt, it doesn't appear to be freeing previously allocated devices.

here's the only output when run from the shell:

```
$ time gnome-disk-image-mounter some.iso

real 0m23.141s
user 0m0.144s
sys 0m0.019s

```

ProblemType: Bug
DistroRelease: Ubuntu 20.10
Package: gnome-disk-utility 3.38.0-1ubuntu1
ProcVersionSignature: Ubuntu 5.8.0-25.26-lowlatency 5.8.14
Uname: Linux 5.8.0-25-lowlatency x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia
ApportVersion: 2.20.11-0ubuntu50
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Fri Oct 23 23:42:34 2020
InstallationDate: Installed on 2020-07-15 (101 days ago)
InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423)
SourcePackage: gnome-disk-utility
UpgradeStatus: Upgraded to groovy on 2020-10-24 (0 days ago)

[Sebastien Bacher (seb128)]

Thank you for your bug report. Is that specific to an iso? The issue doesn't happen on a new installation trying a xubuntu iso
Could you add a 'journalctl -b 0' log after getting the issue?

[Tessa (unit3)]

hmmm. it doesn't seem to be every disk image, but it does seem to be a great number of them. my 20.04.1 install ISO works fine, but the virtio-win-0.1.185.iso that I was using fine in 20.04 causes this problem consistently for me. I watched the output of `journalctl -b 0`, and nothing was printed during the timeout period or after it fails and displays the error, so wherever this should be logging, it's not going to the systemd journal or syslog.

[Sebastien Bacher (seb128)]

Trying with https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.185-1/virtio-win-0.1.185.iso it mounts fine here

Could you do
$ journalctl -f

try to mount and see if the log has any output? here it writes
 udisksd[1519]: Set up loop device /dev/loop61 (backed by /tmp/virtio-win-0.1.185.iso)

[Tessa (unit3)]

ok, this is what happens in journalctl when an ISO successfully is mounted:

```
Oct 29 18:02:06 boxxy kernel: loop1: p1 p2
Oct 29 18:02:06 boxxy kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Oct 29 18:02:06 boxxy kernel: ISO 9660 Extensions: RRIP_1991A
Oct 29 18:02:06 boxxy udisksd[2567]: Mounted /dev/loop1p1 at /media/tessa/Ubuntu 20.04.1 LTS amd64 on behalf of uid 1000
Oct 29 18:02:06 boxxy udisksd[2567]: Set up loop device /dev/loop1 (backed by /home/tessa/Downloads/ISOs/ubuntu-20.04.1-desktop-amd64.iso)
Oct 29 18:02:07 boxxy fwupd[6497]: 01:02:07:0315 FuEngine ccgx failed to change udev device /sys/devices/virtual/block/loop1: cannot ensure ID: FuUdevDevice:
Oct 29 18:02:07 boxxy fwupd[6497]: Unknown Device
Oct 29 18:02:07 boxxy fwupd[6497]: Flags: none
Oct 29 18:02:07 boxxy fwupd[6497]: 01:02:07:0319 FuEngine ccgx failed to change udev device /sys/devices/virtual/block/loop1/loop1p2: cannot ensure ID: FuUdevDevice:
Oct 29 18:02:07 boxxy fwupd[6497]: Unknown Device
Oct 29 18:02:07 boxxy fwupd[6497]: Flags: none
Oct 29 18:02:07 boxxy fwupd[6497]: 01:02:07:0320 FuEngine ccgx failed to change udev device /sys/devices/virtual/block/loop1/loop1p1: cannot ensure ID: FuUdevDevice:
Oct 29 18:02:07 boxxy fwupd[6497]: Unknown Device
Oct 29 18:02:07 boxxy fwupd[6497]: Flags: none

```

but when I try to mount that virtio iso, it just times out, displays that error dialogue, and literally nothing goes to `journalctl`. is there a way to run it with debug logging?

[Sebastien Bacher (seb128)]

what's the output of?

$ udisksctl loop-setup -f virtio-win-0.1.185.iso

[Tessa (unit3)]

Mapped file virtio-win-0.1.185.iso as /dev/loop0.

and then the ISO shows as mounted in nautilus. so I guess it's not a problem with the ISO itself, but with whatever nautilus+gnome is doing to try and mount it.

[Sebastien Bacher (seb128)]

Hum, I though gdu would basically call to udisks. You could perhaps also report the bug directly to the software writers on https://gitlab.gnome.org/GNOME/gnome-disk-utility/-/issues , they know better the code and might have a better clue on guessing the issue

[Tessa (unit3)]

filed an upstream bug for this one as well:
https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1901286

[Sebastien Bacher (seb128)]

Thanks!

[Sebastien Bacher (seb128)]

Upstream seems to be belive the new udisks should fix the issue, any chance you could try the newer Ubuntu serie see if the issue is resolved there for you?

[Tessa (unit3)]

I'm actually running Arch on my desktops now, so I don't have a free system to try this out with. if upstream says it's fixed, then it's probably fine to close this for now and re-open it if the problem re-appears for someone else.