Disk Utility claims creating a ext4 partition failed

[Ethan Bissett]

Binary package hint: gnome-disk-utility

I decided to test out the new disk partitioner in Karmic. I used an old external eSATA/USB2 HD enclosure with a spare SATA 160GB drive installed in it.

When I created an ext4 partition on the disk the partitioner created the partition and I believe it began the format. The disk rumbled for a while and then an error appeared stating: "Error creating file system: helper exited with exit code 1: cannot create directory /var/run/DeviceKit-disks/job-mkfs-B1LSQj: No such file or directory"

This partition however was mountable at this point so I believe to the format was successful. Formating the partition manually using mkfs.ext4 worked fine with no errors. The Disk Utility gave the same error regardless if the disk used a MBR or GPT partition table. Using the disk via eSATA or USB made no difference.

In case anyone cares the ThermalTake enclosure details (via lsusb) are: Bus 001 Device 007: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge

ProblemType: Bug
Architecture: amd64
Date: Thu Oct 1 21:52:11 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: gnome-disk-utility 2.28.0-0ubuntu2
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.36-generic
SourcePackage: gnome-disk-utility
Uname: Linux 2.6.31-11-generic x86_64

[Ethan Bissett (draimus-deactivatedaccount)]

Binary package hint: gnome-disk-utility

I decided to test out the new disk partitioner in Karmic. I used an old external eSATA/USB2 HD enclosure with a spare SATA 160GB drive installed in it.

When I created an ext4 partition on the disk the partitioner created the partition and I believe it began the format. The disk rumbled for a while and then an error appeared stating: "Error creating file system: helper exited with exit code 1: cannot create directory /var/run/DeviceKit-disks/job-mkfs-B1LSQj: No such file or directory"

This partition however was mountable at this point so I believe to the format was successful. Formating the partition manually using mkfs.ext4 worked fine with no errors. The Disk Utility gave the same error regardless if the disk used a MBR or GPT partition table. Using the disk via eSATA or USB made no difference.

In case anyone cares the ThermalTake enclosure details (via lsusb) are: Bus 001 Device 007: ID 152d:2338 JMicron Technology Corp. / JMicron USA Technology Corp. JM20337 Hi-Speed USB to SATA & PATA Combo Bridge

ProblemType: Bug
Architecture: amd64
Date: Thu Oct 1 21:52:11 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: gnome-disk-utility 2.28.0-0ubuntu2
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-11.36-generic
SourcePackage: gnome-disk-utility
Uname: Linux 2.6.31-11-generic x86_64

[Zeuthen (zeuthen)]

> Often, /var/run/ is on a tmpfs nowadays, so creating it on "make install"
> (as the current source does) is not sufficient.

First, I think a lot of other programs do this and the FHS specifically allows for it ("Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file.").

Second, 'make install' should use (and does, at least with rpm and deb) DESTDIR so at least the package payload should be correct.

Third, I think if you are careful you can still have /var/run on a tmpfs if you really want. You just need to have some logic that copies the directories over from the real /var/run directory at boot time. You also need some logic when you do package install/uninstalls at run-time.

Btw, won't you see the same problem with lots of other software? I can imagine a piece of software even creating /var/run/foo that is owned by the user foo and all of the executables for that software run as the foo user. You can't do mkdir in any of these executables because /var/run is not writable for foo. Then there's also extended attributes for these directories - e.g. SELinux security contexts.

[Achim (ach1m)]

If I try to create an encrypted ext4 partition I also get the same error. I guess I hit the same bug.

'Error creating file system: helper exited with exit code 1: cannot create directory /var/run/DeviceKit-disks/job-mkfs-eCRH6x: No such file or directory'

[Martin Pitt (pitti)]

$ Btw, won't you see the same problem with lots of other software?

Mixed. Some software, like cups, mkdirs/chowns itself, for others (like dbus) we need to do the mkdir/chown in the init/upstart script. If we need an upstart script for a daemon anyway, then the mkdir/chown is not a biggie.

But installing an upstart job for _just_ an mkdir is quite a large overhead; also, this is a bit tricky with d-bus activated services since you have to ensure that the mkdir happens before d-bus startup.

The "make install" approach works here because the directory is owned by root:root (and thus having a subdirectory isn't even strictly necessary). It does not work any more for services which require a system user-owned subdirectory, since you can't put the system user/group (>= 100, < 500) IDs into the .rpm/.deb.

Anyway, I'm fine with keeping this as a local patch as well, if you don't want/need it in Fedora/RH.

[Martin Pitt (pitti)]

Created an attachment (id=30064)
Use /tmp/ for temporary directories

So, just for the record, I used option (2) for Debian/Ubuntu. It's a classic usage of a temporary file/dir. It's not state which needs to be kept through the lifetime of DK-disks, so it doesn't really need to go into /var/run/ (https://bugzilla.redhat.com/show_bug.cgi?id=491744 does not really give a convincing reason why /var/run/ should be used).

Keeping that here for transparency, or for other distros which might have the same problem.

[Achim (ach1m)]

devicekit-disks (007-1karmic1) karmic; urgency=low

  * Debian git head snapshot to get the bug fix below.
  * debian/rules: Enable quilt patch system. Add quilt build dependency.
  * Add mkfs-tempdir.patch: Daemon does not create /var/run/DeviceKit-disks/,
    so mkfs jobs fail. Just create the directory in /tmp, this is what /tmp is
    for, after all. (See https://bugs.freedesktop.org/show_bug.cgi?id=24265)

 -- Martin Pitt < e-mail hidden > Mon, 05 Oct 2009 10:32:15 +0200

If the problem is still present with this package version, please reopen this bug.

[Martin Pitt (pitti)]

David, do you think the attached patch is okay? It uses /tmp/ for what it's supposed to be used for, but I realize this might need some feedback from your SELinux folks?

Otherwise this should probably be closed as "wontfix", and we just keep it in the distros.

[Zeuthen (zeuthen)]

(In reply to comment #4)
> David, do you think the attached patch is okay? It uses /tmp/ for what it's
> supposed to be used for, but I realize this might need some feedback from your
> SELinux folks?
>
> Otherwise this should probably be closed as "wontfix", and we just keep it in
> the distros.
>

I still think it's better to use /var/run/udisks... and I think something is wrong with the OS if the /var/run/udisks isn't available. FWIW, the FHS is very very clear on this ("Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file.") and I doubt udisks is the only piece of software you need to patch. I'm closing the bug as WONTFIX.