hal sometimes creates volumes for raw device and partitions

Kay Sievers kay.sievers at vrfy.org
Fri Oct 21 09:16:01 PDT 2005


On Fri, Oct 21, 2005 at 05:51:28PM +0200, Martin Pitt wrote:
> With some devices, hal creates a volume node for both the raw device
> (/dev/sda) and the partitions on it (like /dev/sda1). This can be
> produced pretty reliably by mkdosfs'ing the raw device, and then
> partitioning sda and mkdosfs'ing sda1. It seems that the first blocks
> sometimes still have a valid file system signature, despite a valid
> partition table being there as well. This leads to undesired effects
> like invalid drives in gnome-vfs and failed mounts.

Sure, almost all of the crappy unix formatting tools are broken in that
sense. I gave up convincing the stupid maintainers. Some claimed that it
is a "feature" to write only the blocks which are really needed for the
fs instead of invalidating at least the first and last 64kb of a volume.
there are lots of issues like this. Just run mkswap on a FAT volume and
you can still mount the now completely currupted fat volume. Nice "feature"
isn't it? :)
The only sane approach I've seen is libparted, which has invalidate()
methods for every supported fs, and calls all of them before
reformatting a volume.

> See https://bugzilla.ubuntu.com/show_bug.cgi?id=13140 for details, hal
> debug output, etc.

That's known for long. See here:
  http://lists.freedesktop.org/archives/hal/2005-September/003297.html

> Rather than trying to fiddle with drive_id and volume_id, can we
> implement a simple sanity check that does not create a volume for the
> raw device when there are already partition volumes, and removes a raw
> volume as soon as a partition volume arrives?

At the time the event for the main-block device (these are not "raw"
devices :)) arrives, nobody can tell you if a partition will be
recognized later.
I still think, we should just invalidate a successful probed
filesystem from a main-block device if any child device(partition) event
arrives.

Kay


More information about the hal mailing list