Linaro Image Tools

linaro-media-create sometimes fails because the boot loopback device is not registered when formating the bootfs partition

Bug #701678 reported by Guilherme Salgado on 2011-01-11

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	Linaro Image Tools	Fix Released	High	Guilherme Salgado	Linaro Image Tools 0.4.2

Bug Description

This happens occasionally but I still haven't managed to figure out what causes it. The traceback I see usually looks like this:

Cleaning up ...Done
------------------------------------------------------------
proc umounted
Warning: /tmp/beagle.img is not a block device
Disk /tmp/beagle.img: cannot get geometry

sfdisk: ERROR: sector 0 does not have an msdos signature
/tmp/beagle.img: unrecognized partition table type
No partitions found
BLKRRPART: Inappropriate ioctl for device
If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes: dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

Formating boot partition

Traceback (most recent call last):
  File "/usr/bin/linaro-media-create", line 100, in <module>
    args.should_format_bootfs, args.should_format_rootfs)
  File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 63, in setup_partitions
    ensure_partition_is_not_mounted(bootfs)
  File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 83, in ensure_partition_is_not_mounted
    if is_partition_mounted(partition):
  File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 89, in is_partition_mounted
    device_path = _get_udisks_device_path(partition)
  File "/usr/lib/pymodules/python2.6/linaro_media_create/partitions.py", line 198, in _get_udisks_device_path
    return udisks.get_dbus_method('FindDeviceByDeviceFile')(device)
  File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 68, in __call__
    return self._proxy_method(*args, **keywords)
  File "/usr/lib/pymodules/python2.6/dbus/proxies.py", line 140, in __call__
    **keywords)
  File "/usr/lib/pymodules/python2.6/dbus/connection.py", line 620, in call_blocking
    message, timeout)
dbus.exceptions.DBusException: org.freedesktop.UDisks.Error.Failed: No such device

Related branches

lp:~salgado/linaro-image-tools/bug-701678

Merged into lp:linaro-image-tools/11.11 at revision 264

Loïc Minier (community): Approve on 2011-01-27

James Westby (community): Approve on 2011-01-27

lp:linaro-image-tools/11.11

Guilherme Salgado (salgado) on 2011-01-11

Changed in linaro-image-tools:
assignee:	nobody → Guilherme Salgado (salgado)
importance:	Undecided → High
status:	New → Triaged

Revision history for this message

Guilherme Salgado (salgado) wrote on 2011-01-25:

This seems to be because there is a (known and expected) delay between the loopback device being registered and udisks getting to know (via udev) about it. Loïc says we could workaround it by running 'udevadm settle' before using udisks but ideally we should stick to a single tool for both the registration and later lookup.

Revision history for this message

Guilherme Salgado (salgado) wrote on 2011-01-26:

The issue here is that we have some code which ensures a given partition is mounted before we run mkfs on it. We do that because sometimes the automounter may kick in right after we've changed the partition table of the device and mount the partition before we have a chance to run mkfs on it.

The 'udevadm settle' trick didn't work, but Martin Pitt suggested we listen to udisks events about the new partition and only ensure it's unmounted after the event is fired. Another alternative would be to run 'sudo udisks --inhibit' while lmc runs.

However, this race condition is specifically related to the loopback devices that are setup so that we can copy the bootfs/rootfs to the image file and (AFAICT) the automounter never does anything with loopback devices so I think we can just run mkfs on them without having to worry about whether or not they're mounted.

Revision history for this message

Guilherme Salgado (salgado) wrote on 2011-01-26: