Bug 592957 - libparted returns wrong path for partition
libparted returns wrong path for partition
Product: Fedora
Classification: Fedora
Component: parted (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Hans de Goede
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-05-17 09:27 EDT by Ruben Kerkhof
Modified: 2010-08-12 15:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-12 15:57:20 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ruben Kerkhof 2010-05-17 09:27:22 EDT
Description of problem:

I have some scripts which use pyparted to create new partitions on a logical volume. I use the path property of a Partition instance to pass throught to resize2fs.

The following works fine on F-12 (pyparted-2.1.2-1.fc12.x86_64):

[root@host1 ~]# ipython -nobanner

In [1]: import parted
In [2]: dev = parted.Device('/dev/vgdata/parted-test')
In [3]: dsk = parted.Disk(device=dev)
In [4]: dsk.partitions[0].path
Out[4]: '/dev/mapper/vgdata-parted--testp1'

However, on F-13 (pyparted-3.3-1.fc13.x86_64), the path property returns:

[root@host2 ~]# ipython -nobanner

In [1]: import parted
In [2]: dev = parted.Device('/dev/vgdata/parted-test')
In [3]: dsk = parted.Disk(device=dev)
In [4]: dsk.partitions[0].path
Out[4]: '/dev/dm-10p1'

This path doesn't exist.

I guess this has something to do with a change in lvm, which now creates symlinks to /dev/dm for logical volumes, but not for partitions on those logical volumes.

This is F-13:
[root@host2 ~]# ls -l /dev/mapper/vgdata-parted--test*
lrwxrwxrwx. 1 root root       8 May 17 14:51 /dev/mapper/vgdata-parted--test -> ../dm-10
brw-rw----. 1 root disk 253, 11 May 17 15:03 /dev/mapper/vgdata-parted--testp1

and this is F-12:
[root@host1 ~]# ls -l /dev/mapper/vgdata-parted--test*
brw-rw----. 1 root disk 253, 20 2010-05-17 13:44 /dev/mapper/vgdata-parted--test
brw-rw----. 1 root disk 253, 21 2010-05-17 13:44 /dev/mapper/vgdata-parted--testp1
Comment 1 David Cantrell 2010-05-20 15:52:45 EDT
This is actually in libparted, which pyparted just calls:


        /* Check for devfs-style /disc => /partN transformation
           unconditionally; the system might be using udev with devfs rules,
           and if not the test is harmless. */
        if (!strcmp (dev->path + path_len - 5, "/disc")) {
                /* replace /disc with /path%d */
                strcpy (result, dev->path);
                snprintf (result + path_len - 5, 16, "/part%d", num);
        } else if (dev->type == PED_DEVICE_DAC960
                        || dev->type == PED_DEVICE_CPQARRAY
                        || dev->type == PED_DEVICE_ATARAID
                        || dev->type == PED_DEVICE_DM
                        || isdigit (dev->path[path_len - 1]))
                snprintf (result, result_len, "%sp%d", dev->path, num);
                snprintf (result, result_len, "%s%d", dev->path, num);

The "%sp%d" format string is used, but probably should not be used for PED_DEVICE_DM.  Reassigning to parted.
Comment 2 Hans de Goede 2010-05-21 02:38:08 EDT
Hi Ruben,

Normally parted resolves symlinks which causes the behaviour you are seeing. There is a patch in parted to not do this for device mapper devices because of the lvm changes you refer to. But this patch keys of the device path starting with /dev/mapper, from the parted ChangeLog:

* Tue Apr  6 2010 Hans de Goede <hdegoede@redhat.com> 2.1-6
- Parted should not canonicalize symlinks under /dev/mapper (#577824)

So if you use the symlink under /dev/mapper rather then using the /dev/VgName/LvName one things should work.

Please let us know if this resolves your issue.


Comment 3 Ruben Kerkhof 2010-05-21 07:26:35 EDT
Hi Hans,

I've changed my scripts now to use the /dev/mapper entries, and this works ok.
Comment 4 Hans de Goede 2010-08-12 15:57:20 EDT
Closing per comment #3.

Note You need to log in before you can comment on or make changes to this bug.