Bug 592957 - libparted returns wrong path for partition
Summary: libparted returns wrong path for partition
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: parted
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Hans de Goede
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-17 13:27 UTC by Ruben Kerkhof
Modified: 2010-08-12 19:57 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-08-12 19:57:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ruben Kerkhof 2010-05-17 13:27:22 UTC
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 19:52:45 UTC
This is actually in libparted, which pyparted just calls:

libparted/arch/linux.c:

        /* 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);
        else
                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 06:38:08 UTC
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> 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.

Regards,

Hans

Comment 3 Ruben Kerkhof 2010-05-21 11:26:35 UTC
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 19:57:20 UTC
Closing per comment #3.


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