Your message dated Tue, 28 Aug 2007 15:24:56 -0600
with message-id <[EMAIL PROTECTED]>
and subject line Bug#298816: resolved in mount 2.13-1
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: mount
Version: 2.12-10
Severity: normal
Tags: patch
Mount is unable to identify disks that were created using the
device-mapper by their label or uuid. It therefore fails to mount those
disks from the -L or -U command line options.
I have created a simple patch that iterates over the block devices in
/dev/mapper and adds them to the uuidCache. The patch is not ideal,
given that it only looks in /dev/mapper, I could not figure out a way
to glean information from /proc about the device names (other than
dm-0,dm-1, etc.), which seems to be the proper way to do this.
However, this is not a serious drawback, since mount assumes that
hda, sda, and other devices will be in /dev, so it does not seem to be
an unreasonable assumption that device-mapper devices will
be in /dev/mapper. Even with this limitation, it seems to work quite
well and if the device nodes are not in that directory, no
functionality is lost.
Kevin
Note: I believe this is a different issue from #282144,#290324,#164144
since this patch is intended only to identify device-mapper drives, not
to create the drives. Also, if support is added to mount to create the
dm-crypt devices (which would be really cool), this method of
identification could still be used to re-mount the disks or to mount
devices created using dm-setup/cryptsetup.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10.20050309a
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages mount depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
-- no debconf information
--- util-linux-2.12p.orig/mount/mount_by_label.c 2004-12-21
18:15:33.000000000 -0500
+++ util-linux-2.12p/mount/mount_by_label.c 2005-03-09 22:41:47.512288688
-0500
@@ -37,6 +37,7 @@
#define PROC_PARTITIONS "/proc/partitions"
#define DEVLABELDIR "/dev"
#define VG_DIR "/proc/lvm/VGs"
+#define DM_DIR "/dev/mapper"
#define EVMS_VOLUME_NAME_SIZE 127
#define PROC_EVMS_VOLUMES "/proc/evms/volumes"
@@ -104,6 +105,35 @@
closedir(vg_dir);
}
+/* Device Mapper Support
+ *
+ * Note: For the same reasons mentioned below, this is not an ideal solution.
+ * There is no specific requirement that the device nodes be created in
+ * the DM_DIR directory, and if they are somewhere else this function will not
+ * find them. Ideally, they should be meaningly identified in /proc.
+ */
+static void
+uuidcache_init_dm(void) {
+ char dm_device[PATH_MAX];
+ DIR *dm_dir;
+ struct dirent *dm_ent;
+ char uuid[16], *label;
+
+ dm_dir = opendir(DM_DIR);
+ if (dm_dir == NULL)
+ return; /* Assume no dm devices */
+
+ while ((dm_ent = readdir(dm_dir))) {
+ if (dm_ent->d_type != DT_BLK) /* Skip control and directories */
+ continue;
+
+ sprintf(dm_device, "%s/%s", DM_DIR, dm_ent->d_name);
+ if (!get_label_uuid(dm_device, &label, uuid))
+ uuidcache_addentry(xstrdup(dm_device), label, uuid);
+ }
+ closedir(dm_dir);
+}
+
static int
uuidcache_init_evms(void) {
FILE *procvol;
@@ -256,6 +286,7 @@
fclose(procpt);
uuidcache_init_lvm();
+ uuidcache_init_dm();
}
#define UUID 1
--- End Message ---
--- Begin Message ---
Version: 2.13-1
On Tue, Aug 28, 2007 at 09:15:21PM +0200, Christoph Thomas wrote:
> the problem described ist resolved (mount 2.13-1). You can refer to
> bug 439617.
done.
Thanks.
lamont
--- End Message ---
