I'm currently testing 14.04 and while there are many things I like about it, the udisks bugs are upsetting. I'm currently running 12.04 on all production systems due to these problems which if I'm not mistaken began with 12.10 and have been present ever since.

When I try to use Benchmarking from within disks on an unmounted partition on sda, I get the following error:

Error seeking to offset 2560872448 (g-io-error-quark, 13)

Supporting data (too long to include here):


  • 2
    Well it should run ok in 14.04, it uses udisks instead of udisks2 & the other deps are also still available. Best to rebuild on 14.04 as an upgrade. So rather than beat around the bush packages & adjusted source here. I have no intention to maintain or fix any isses so maybe try, if ok dl the source so you can build yourself if need be. It opens a little small, you'll need to resize or max. As far as usb creator, the 14.04 version is fine, just format the flash drive first to fat32, then open usb creator. https://launchpad.net/~mc3man/+archive/trusty-tests – doug May 27 '14 at 0:37
  • 1
    @doug Flawless. I pulled the 3.10.0-1ubuntu3.really.3.0.2-2ubuntu8 package from your PPA. Write this up as an answer! You have the bounty and my thanks. – Elder Geek May 27 '14 at 22:41

The older 3.0.2 source should still be viable thru 14.04 as most of the deps are available for 14.04. However better to rebuild & package for trusty as an upgrade to current gnome-disk-utility package, so to that end a ppa.


Notes: Uses the last 3.0.2 source in Ubuntu - 3.0.2-2ubuntu7 precise (- the package name inadvertently got 8 at end, no matter really.

Only real change was to remove nautilus extension & launchpad integration as no longer working or used & would cause a ftbfs.

The default opening window size is a bit small, needs to be resized or maxed after opening. If I stumble upon a way to adjust in source will do so. ( patch welcome.

If unsuitable then either use ppa-purge or just remove ppa, remove gnome-disk-utility, update sources & re-install current gnome-disk-utility.

Copied over a previous build to ppa for saucy (saucy is almost EOL

As far as usb creator, the 14.04 version is fine, just format the flash drive first to fat32, then open usb creator and it should work ok.

| improve this answer | |

I've checked the source of gnome-disk-utility from their git repository and the problem is that on 32bit architectures it uses 32bit lseek() function to seek the signed offset. So it succeeds for the first few seeks, but then it fails beyond 2^31 bytes (2560872448 is beyond this bound).

Based on the manual of lseek64 the fix is either to add just one line before all headers:

#define _FILE_OFFSET_BITS 64

Or switch to lseek64 prototype.

| improve this answer | |
  • Interesting. Wouldn't seeking an LBA rather than a specific byte result in lower values thus allowing the seek to succeed? This indicates that benchmarking would fail on any drive much over about 2GB with the 32-bit version. I'm baffled as to why an approach like this would be taken and will do some testing on a 2 GB storage media. – Elder Geek Oct 17 '14 at 16:59
  • I can confirm that this works under 2^31. (Tested on 2.1GB media) why would the manual of lseek64 be relevant to the 32 bit version of lseek? – Elder Geek Oct 17 '14 at 19:53
  • It has nothing to do with LBA, this is Linux kernel interface. By default on 32bit architecture 32bit lseek gets compiled and with this option you get 64bit lseek which is equivalent to lseek64. Well, you can always read the source. – MariusM Oct 18 '14 at 18:24
  • Thank you for your response: If I understand what you are saying if the kernel interface for Ubuntu 32 bit was compiled with #define _FILE_OFFSET_BITS 64 by default instead, benchmarking and imaging wouldn't fail. Is this an accurate statement? – Elder Geek Oct 19 '14 at 14:23
  • 1
    Yes, this one single line solves the problem. I did it on old i686 computer, so 64bit computer is not required. In udisk case there could more files like that and there might be a broader (maintainer) issue: such options are better be configured in some global config.h file using some autoconf/automake tools, rather than fixed by considering individual cases like I did. – MariusM Oct 22 '14 at 9:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.