© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
> If dmraid does not add the 'p' and kpartx does, then kpartx ends up
> creating duplicate devices for the partitions with the 'p', so you
> have one with, and one without.
In my testing I recall some GNU/Linux distributions as having both
/dev/mapper and /dev/dm-# entries for the same dmraid device (and not
symbolic links). Hence duplicate entries might already exist, even
without using GParted. 'Just thought you might want to know that this
situation can arise even without the use of GParted.
Many users run GParted from a Live CD or USB image so that no
partitions are mounted and the full capabilities of GParted are
available. In this situation, the device naming does not matter to
the GNU/Linux distributions on the hard disk device because the live
image partition names disappear on reboot.
To better understand your perspective, why are you concerned that
GParted creates devices that follow the old dmraid naming standard?
> Now that libparted has the functionality, shouldn't it be removed
> from gparted, rather than duplicating it? If it is going to duplicate
> it, then it should at least do it the same way.
> Long term it seems like the whole DMRaid.cc module could go away and
> go back to letting libparted handle things, since it does so
> correctly now.
The long term plan would be to remove DMRaid.cc. However to my
knowledge (lib)parted versions that support dmraid have not been out
for very long. Parted 2.3 was released on 28 May 2010, so it has not
even been out for a year.
Parted versions 1.9.0 up to and including 2.2 have been out for longer
but have experienced a critical problem to varying degrees. The
critical problem is a failure to inform the kernel of partition
changes. This causes grief when used with GParted.
See:
Problem Resizing File Systems with GParted
http://
GParted contains a work-around for these earlier version,
but it does not work 100% of the time.
Hence if I am to change the minimum requirement of GParted to be
libparted 2.3, then more time is needed for major GNU/Linux
distributions to all be using at least this version or higher in the
their currently supported releases.
> If gparted wants to be able to work with older versions of libparted,
> then perhaps it could be made a configuration option?
Yes, compatibility with older versions of (lib)parted is desired for
the reasons described above. I would suggest that this configuration
option should automatically be set based on the (lib)parted
version.
> As for fixing this bug for Natty, it looks like the -P argument
> needs dropped, and gparted needs to add the 'p'. Parted and dmraid
> also could be patched to add the 'p' only if the previous character
> is a digit. Does that sound like a reasonable simple fix for now?
If the goal is to have better support for dmraid devices in Natty, I
would suggest that a more recent version of GParted be used.
A problem with the dmraid path name was fixed in GParted 0.7.1:
https:/
The -P argument could be dropped; however, I think your idea to scan
the output would then be required to determine what type of partition
name was created by dmraid (e.g., with or without the 'p').