Gparted does not list dmraid devices

[Tom Louwrier]

Binary package hint: gparted

hi,

I'm rescuing data off a Win2k machine with a MSI k7t266 pro2 ru (ms6380) motherboard. The 2 disks are on a Fastrack100 chip as striped set: 2x40GB=80GB.
Booting from a daily LiveCD (Lucid i386 desktop, dated 31 march 2010) works OK and I can access the single NTFS partition and move data from it to an external USB disk (recovered some 69GB without trouble).

However, when I launch Gparted to prepare for a Ubuntu installation (need dual boot with Win because of some apps I must retain) then Gparted will not see the disks as one partition. It seems it ignores the mount point provided by dmraid and tries to access the disks directly instead.

cheers
Tom

[Jan Claeys (janc)]

Tom, can you tell us what the device name of your striped device is?

If you're not sure, please attach the contents of /etc/mtab after accessing the striped device.

[Tom Louwrier (tom-louwrier)]

hi Jan,

Here goes:
- attaching a copy of /etc/mtab, freshly pulled off a live cd session
- in Nautilus the disk is reported as Local Disc, found in /media/local disk
- Gparted lists 2 disks: /dev/sda and /dev/sdb, both about 37GB
- Gparted also reports 'Partition table unrecognized' and 'Warning: can't have a partition outside the disc'
- Disk Utility sees both /dev/mapper/pdc_jcchiiab (80GB, no file system) and /dev/mapper/pdc_jcchiiab1 (80GB, not partitioned, but NTFS anyway)

Hope this helps. Maybe I can partition this array using the alternative CD (text mode and 'straight' parted) but I'd like the LiveCD to handle this right from the start.

cheers
Tom

[Tom Louwrier (tom-louwrier)]

Having found that the Winblows installation was too far gone to be rescued, I decided to try a fresh install without shrinking the existing partition.
Using a Lucid LiveCD dated 31 march 2010, and choosing the 'update this program' option to refresh Ubiquity I went in and chose a manual partitioning as follows:
- primary 20GB, fat32, no mount point (later to be formatted to ntfs and used for Win)
- logical 5GB, ext4, mount point /
- logical 5GB, ext4, mount point /home
- logical 2GB, swap
- primary 48GB, fat32, no mount point (later to be formatted to ntfs and used for data)
Everything went OK, and just before starting the install I could even click Advanced and specify where to load Grub.
Then the creation of the first file system failed and Ubiquity bombed out with an error 151.

It seems there is more to this than just Gparted not reading from devicemapper.
There have been drivers for linux available from Promise for a while, so I expect these to work although I don't know if they are open source or blobs. Anyway I can access the disk from the LiveCD / Nautilus.

Attaching a copy of /var/log/syslog, copied after the installation crashed. Note that the clock was reset halfway the install, I'm not sure why.

cheers
Tom

[Curtis Gedak (gedakc)]

I have been able to confirm this problem using the "ubuntu-10.04-beta2-desktop-i386.iso" disk image. My Intel software RAID (/dev/mapper/isw_cjbdddajhi_Vol0) does not display in the drop down list in GParted.

GParted Live 0.5.2-7, which uses parted-2.2, does work and successfully recognizes my Intel Software RAID.

It is possible that this problem might be fixed by a patch that has been applied to the Fedora copy of parted-2.2:
"Parted should not canonicalize symlinks under /dev/mapper (#577824)"
http://koji.fedoraproject.org/koji/buildinfo?buildID=165650

Since Ubuntu has also patched parted-2.2, it is also possible that this change has impacted the ability to recognize dmraid devices.

[Phillip Susi (psusi)]

Confirming, gparted does not list dmraid devices on lucid rc, though parted does ( print devices shows it ).

[Curtis Gedak (gedakc)]

The GParted code relies on device names being in the form "/dev/mapper/..." and not "/dev/dm-#" in order to work properly with dmraid devices.

As such I think that that the following patch might be required (we include it on the GParted Live 0.5.2-9 image):
http://git.debian.org/?p=parted/parted.git;a=commit;h=c1eb485b9fd8919e18f192d678bc52b0488e6ee0

[Tom Louwrier (tom-louwrier)]

Curtis,

I already downloaded 0.5.2-9 but did not have time to try it yet. This
will be sometime tomorrow or the day after.
I'll let you know asap.

cheers
Tom

[Tom Louwrier (tom-louwrier)]

Booted Gparted LiveCD 0.5.2-9.
It recognized my striped drive just fine although I couldn't access or get details of the NTFS partitions.

I got the following partitions listed:
1 - /dev/mapper/pdc_jcchiiabp1 / primary / NTFS / 18.63 GB
2 - /dev/mapper/pdc_jcchiiabp2 /11.22 GB / extended
3 - /dev/mapper/pdc_jcchiiabp3 /primary / NTFS / 44.70 GB
4 - (there ain't none)
5 - /dev/mapper/pdc_jcchiiabp5 / ext4 / 4.66 GB / corrupted or not formatted
6 - /dev/mapper/pdc_jcchiiabp6 / ext4 / 4.66 GB / corrupted or not formatted
7 - /dev/mapper/pdc_jcchiiabp7 / linux-swap / 1.91 GB / corrupted or not formatted

Partitions 2 and 5,6,7 are reported as having 0 free space before and after. They should fill up the allocated space nicely.
Partitions 5,6,7 obviously are not formatted (correctly) as the installer crashed at that point last time. If formatted correctly, I think I can finish the Lucid installation as planned, so I decided to format them as ext4, ext4 and linux-swap. Three actions were lined up and then applied.

Alas, that crashed right at the first action. I couldn't retrieve the details of log, but I saw an error that the requested device wasn't found in /dev/mapper.
After that Gparted became unresponsive and I stopped it. Couldn't start it again (it hung) and neither the rest of the apps on the desktop. Got a terminal session but not much fun in that either, due ot lack of cli-skills.

Machine wouldn't reboot correctly; it got stuck in a loop of I/O error messages. Gave it a hard reset.

I can do this again and get better information from logs if you want, but plz give me the commands you need output from. I'll be writing down whatever and re-type it here (oh the days of sneaker networks and chinese interfaces :-) ) unless you help me mount a usb-drive and copy the output you need onto that.

cheers
Tom

[Tom Louwrier (tom-louwrier)]

Oh, to be more complete: the partitions listed above are in numerical order.
In the GUI the are as follows:
1 - /dev/mapper/pdc_jcchiiabp1 / primary / NTFS / 18.63 GB
2 - /dev/mapper/pdc_jcchiiabp2 /11.22 GB / extended
     5 - /dev/mapper/pdc_jcchiiabp5 / ext4 / 4.66 GB
     6 - /dev/mapper/pdc_jcchiiabp6 / ext4 / 4.66 GB
     7 - /dev/mapper/pdc_jcchiiabp7 / linux-swap / 1.91 GB
3 - /dev/mapper/pdc_jcchiiabp3 /primary / NTFS / 44.70 GB

Tom

[Phillip Susi (psusi)]

On Wed, 2010-05-05 at 16:44 +0000, Curtis Gedak wrote:
> The GParted code relies on device names being in the form
> "/dev/mapper/..." and not "/dev/dm-#" in order to work properly with
> dmraid devices.
>
> As such I think that that the following patch might be required (we
> include it on the GParted Live 0.5.2-9 image):
> http://git.debian.org/?p=parted/parted.git;a=commit;h=c1eb485b9fd8919e18f192d678bc52b0488e6ee0

I tried this patch and it did not seem to change anything. Still does
not list the dmraid device in the drop down box, but specifying it on
the command line works, and parted print devices does list the dmraid
device.

[Curtis Gedak (gedakc)]

Phillip, thank you for testing the patch and confirming that it does not fix the problem for Ubuntu 10.04 Lucid Lynx.

I think you might be on the right track with the parted-devel mailing list thread you started:
"linux: use devicemapper task name instead of device node name" causes dmraid breakage"
http://lists.alioth.debian.org/pipermail/parted-devel/2010-May/003657.html

All of the GParted DMRAID code is stored in the file src/DMRaid.cc. To detect DMRAID devices, GParted uses the following command:
     dmraid -sa -c

The result of this command is then prefixed with "/dev/mapper" and passed to libparted as the device name.

The src/DMRaid.cc file contains much code that uses kpartx, dmraid, and dmsetup to create and remove device nodes.

As long as both parted and kpartx match in what these tools call the device and partition names, then GParted should work.

When I developed this code, the general rule of thumb for partition naming was:

If a device name ended in a number (e.g., /dev/mapper/isw_cjbdddajhi_Disk0)
then partition names would have the letter "p" appended prior to appending the partition number.
(e.g., /dev/mapper/isw_cjbdddajhi_Disk0p1)

If a device name did not end in a number (e.g., /dev/mapper/isw_cjbdddajhi_Volume)
then the partition names would only have the partition number appended.
(e.g., /dev/mapper/isw_cjbdddajhi_Volume1)

If the patches to parted in Ubuntu 10.04 deviate from this, then you may just have found the source of the problem.

[Danny Wood (danwood76)]

Hi,

Gparted does seem to list the dmraid partitions, but you need to make sure kpartx is installed as it is not a dependency of the gparted package.

One issue I have found is to do with the partition naming. When gparted tries to format my devices that end in a letter kpartx has renamed these to XXXp1 and when gparted calls mkfs.ext4 it uses the old partition name of XXX1 so fails miserably. In addition to this the new device name is incompatible with ubiquity as an install fails when you install to a XXXp1 partition.

My question is, is it really necessary to use kpartx in gparted. I removed all traces of kpartx from the DMRaid.cc file and built gparted. Gparted now works perfectly on my two dmraid RAID0 volumes, One named "jmicron_HD2" and the other "isw_bgafaifadd_DATA" indicating that kpartx is not required at all. (two different naming formats with two different RAID controllers)

I plan to post a bug report soon when I get some more free time.

best regards,
Danny

[Curtis Gedak (gedakc)]

Hi danwood76,

I believe you have solved the mystery of why GParted does not list dmraid partitions -- kpartx is missing!

As far as I know, the kpartx command does not "rename devices that end in a letter to XXXp1". If this is indeed happening then the nature of how the kpartx command appears to have changed since ubuntu 8.04. To my knowledge, the kpartx command will create new devices if needed according to the general rule of thumb listed in comment #11.

GParted uses both the dmraid and kpartx commands to create the required device name entries in the /dev/mapper directory.

The dmraid command appears to always append the partition number to the device name. It does not follow the rule of thumb for partition naming.

For instance on my computer, my Intel software RAID is named "isw_cjbdddajhi_Vol0"

In the /dev/mapper directory, the following three partition names are created by the dmraid command:

isw_cjbdddajhi_Vol01
isw_cjbdddajhi_Vol02
isw_cjbdddajhi_Vol03

These next three partition names are created by the kpartx command:

isw_cjbdddajhi_Vol0p1
isw_cjbdddajhi_Vol0p2
isw_cjbdddajhi_Vol0p3

You can view the code that creates the device partition names for dmraid devices at:
     http://git.gnome.org/browse/gparted/tree/src/DMRaid.cc
Search for the method "create_dev_map_entries" to see the command line options used by GParted when calling the dmraid and kpartx commands.

In theory, if the dmraid device name ends in a letter then the kpartx command would not be required. At the moment the GParted code will requires both dmraid and kpartx to be present (search for "is_dmraid_supported" method)

[Phillip Susi (psusi)]

On 05/30/2010 02:43 PM, Curtis Gedak wrote:
> In theory, if the dmraid device name ends in a letter then the kpartx
> command would not be required. At the moment the GParted code will
> requires both dmraid and kpartx to be present (search for
> "is_dmraid_supported" method)

So if gparted can't find kpartx then it won't list the dmraid devices?
That sounds like it solves the mystery then. FYI, upstream dmraid and
lvm/libdevmapper have moved to always inserting the 'p' before the
partition number. Ubuntu has patches to maintain the old behavior
currently that will likely be dropped in maverick.

Out of curiosity, why does gparted need kpartx?

[Danny Wood (danwood76)]

I don't think gparted needs kpartx.

I have removed its dependency in my package and it operates perfectly on the dmraid device nodes both with letters and numbers at the end of the device node.

Its odd that its required as in the code the dmraid command returns a string so it shouldn't matter at all what the partition ends are (from a programming point of view). In my opinion it seems like a hack way of getting the desired result.

I've uploaded my lucid gparted (without the kpartx dependency) to my testing ppa if you would like to test:
https://launchpad.net/~danwood76/+archive/ppa-testing

[Curtis Gedak (gedakc)]

Phillip,

If the upstream dmraid command has changed the way it names partitions, then perhaps kpartx is no longer required.

In the past, GParted required kpartx because dmraid did not follow the partition naming guidelines outlined in the general rule of thumb listed in comment #11.

In fact this difference in behaviour is a good part of the reason why I wrote the DMRaid.cc source code file in the first place. At that time dmraid was not directly supported by libparted-1.8.8. It was necessary to ensure that the dmraid partition names matched the names that libparted would generate. Also device entries for the new partitions were not automatically created when the partition table was changed using libparted.

The kpartx command is used to create these device entries so that they match with the partition names generated by libparted. GParted then uses these partition names as arguments to external commands such as mkfs.ext2.

Danny,

Thanks for posting your work. I took a look at the patch code, and this lead me to believe that perhaps you still had kpartx installed on your system when you tested with your two dmraid setups.

Would you be able to check if kpartx is still installed on your test system?

If so, could you try removing kpartx and then re-running your tests?

[Phillip Susi (psusi)]

On 05/31/2010 11:15 AM, Curtis Gedak wrote:
> In fact this difference in behaviour is a good part of the reason why I
> wrote the DMRaid.cc source code file in the first place. At that time
> dmraid was not directly supported by libparted-1.8.8. It was necessary
> to ensure that the dmraid partition names matched the names that
> libparted would generate. Also device entries for the new partitions
> were not automatically created when the partition table was changed
> using libparted.

It sounds like dmraid.cc can be removed then. Libparted now directly
supports dmraid devices and handles the dev node creation. Actually now
we are using devfs for /dev, so the kernel creates the dev nodes, rather
than either udev or libdevmapper.

[Curtis Gedak (gedakc)]

Phillip, do you recall when dmraid support was added to libparted?

Phillip Susi wrote in comment #17:
> It sounds like dmraid.cc can be removed then. Libparted now directly
> supports dmraid devices and handles the dev node creation. Actually now
> we are using devfs for /dev, so the kernel creates the dev nodes, rather
> than either udev or libdevmapper.

Unfortunately I do not think that dmraid can simply be removed at this point in time. Following are the reasons that I believe DMRaid.cc is needed for at least a while longer (perhaps a year or more):

1) To maintain backward compatibility with current GNU/Linux distributions.
     Parted 1.9.0 was released on July 23, 2009. Newer versions like 2.2 were only released in February of 2010. This means that these versions have been available for less than a year, and are not likely included with Long Term Support Gnu/Linux distributions.

2) To avoid some problems with libparted device detection.

     Currently GParted contains it's own code to detect disk devices.
     Search for method "set_devices" in GParted_Core.cc:
     http://git.gnome.org/browse/gparted/tree/src/GParted_Core.cc

     Following are two reasons why GParted performs it's own device detection:

     A) If libparted device detection is used, it takes an inordinate amount of time to scan devices on computer systems that do not have a physical floppy drive installed, but do have the BIOS set to indicate a floppy drive is present.
          This problem was tracked in GParted bug #351753.
          Missing floppy causes loop on scanning devices.
          https://bugzilla.gnome.org/show_bug.cgi?id=351753

          This problem was also reported in Parted ticket #194.
          ped_device_probe_all() returns /dev/fd0 when no physical floppy device present.
          http://parted.alioth.debian.org/cgi-bin/trac.cgi/ticket/194

     B) If libparted device detection is used, some versions of libparted might not detect dmraid devices, or will list all partitions as dmraid devices as well.
          I remember this problem from past testing because I do not recall documenting this problem elsewhere.

Do the above explanations help describe why it might not be prudent to remove DMRaid.cc at this time?

[Curtis Gedak (gedakc)]

Thank you Phillip for indicating that "Libparted now directly supports dmraid devices and handles the dev node creation".

And also thank you Danny for saying that "When gparted tries to format my devices that end in a letter kpartx has renamed these to XXXp1".

This behaviour Danny mentioned seemed really odd to me so I decided to do some testing myself. Following is a description of my testing:

Immediately after booting from a Live CD of Ubuntu 10.04, the /dev/mapper directory contained the following entries:

control
isw_cjbdddajhi_Vol0
isw_cjbdddajhi_Vol01
isw_cjbdddajhi_Vol02
isw_cjbdddajhi_Vol03

Next I used parted (not GParted) to create another primary partition. After exiting parted the /dev/mapper directory contained the following entries:

control
isw_cjbdddajhi_Vol0
isw_cjbdddajhi_Vol0p1
isw_cjbdddajhi_Vol0p2
isw_cjbdddajhi_Vol0p3
isw_cjbdddajhi_Vol0p4

Based on this I can see that significant changes in behaviour have occurred with dmraid devices and parted from the Ubuntu 10.04 CD. Not only were new device entries created that match the rule of thumb for naming partitions, but the previous partition names as normally created by dmraid, were missing. Since kpartx was used, I can only assume that parted or some other subsystem is responsible for the change in partition names.

I'll bet that these discrepancies in behaviour are causing some confusion for people using dmraid devices and parted/gparted.

[Curtis Gedak (gedakc)]

s/Since kpartx was used/Since kpartx was NOT used/ :-)

[Danny Wood (danwood76)]

Hi Curtis,

Thankyou for looking into my patch.
I dont have kpartx installed on my system at the moment but the changes listed in the ppa package are just the diffs from the previous ppa version which still had a kpartx dependency. (I have actually commented all the kpartx calls out).
Its not meant to be a proper patch it was merely testing.

I will try and re describe the error I get in gparted as I realise my first description was confusing.

On my system I have a jmicron controller with several partitions:

jmicron_HD2
jmicron_HD21
jmicron_HD25
jmicron_HD26

On the live CD when I try to say format partition 6 from within Gparted I get an error because it passes the above "jmicron_HD26" to mkfs when in fact the partition names have been changed by kpartx to be "jmicron_HD2p6"

the ls /dev/mapper now looks like this:
jmicron_HD2
jmicron_HD2p1
jmicron_HD2p5
jmicron_HD2p6

After removing the kpartx calls Gparted functions correctly and the partition names remain the same as in the first instance.
I think there must be a bug with naming within the dmraid.cc file which doesn't pass on the partition name changes from kpartx.
This is a separate bug to the one we are discussing so I will open a new bug report when I get some time.

Though from my testing I think it indicates that kpartx isn't actually required as it handles new partition creation and formating just fine once it is removed.

[Phillip Susi (psusi)]

On 05/31/2010 02:00 PM, Curtis Gedak wrote:
> Phillip, do you recall when dmraid support was added to libparted?

Sometime between 1.8 and 2.2.

> Unfortunately I do not think that dmraid can simply be removed at
> this point in time. Following are the reasons that I believe
> DMRaid.cc is needed for at least a while longer (perhaps a year or
> more):

Then perhaps it could be disabled by the configure script when it
detects that you have (lib)parted 2.2?

> A) If libparted device detection is used, it takes an inordinate
> amount of time to scan devices on computer systems that do not have a
> physical floppy drive installed, but do have the BIOS set to indicate
> a floppy drive is present. This problem was tracked in GParted bug
> #351753. Missing floppy causes loop on scanning devices.
> https://bugzilla.gnome.org/show_bug.cgi?id=351753

How long are we talking here? I would expect a few seconds to be spent
trying to access the floppy before giving up, and the proper fix to that
is not to misconfigure the bios so that it thinks it has a floppy.
Looking at the parted bug, it seems like a NOTABUG to me. If your
system has a broken floppy, then it has a broken floppy; it really isn't
(lib)parted's job to guess that it isn't really supposed to be there at
all and hide it. If the kernel says the device exists, then
lib/g/parted should list it.

Now if it is getting stuck for more than 15 seconds or so then that
sounds like a software bug doing too many retries before giving up.

> Based on this I can see that significant changes in behaviour have
> occurred with dmraid devices and parted from the Ubuntu 10.04 CD. Not
> only were new device entries created that match the rule of thumb for
> naming partitions, but the previous partition names as normally created
> by dmraid, were missing. Since kpartx was used, I can only assume that
> parted or some other subsystem is responsible for the change in
> partition names.
>
> I'll bet that these discrepancies in behaviour are causing some
> confusion for people using dmraid devices and parted/gparted.

Yes, there was a serious regression in lucid for dmraid devices that you
have noticed. See lp #568050, which is unfortunately full of useless
vitriol. As I said before, upstream has moved to adding the p but
Ubuntu has had a patch for a while to revert to the old behavior of not
adding the p in dmraid. The new code that came with parted 2.2 does
insert the p, which is why it shows up when you run parted but not when
dmraid creates the device.

[Curtis Gedak (gedakc)]

Phillip Susi wrote:
> On 05/31/2010 02:00 PM, Curtis Gedak wrote:
>> Unfortunately I do not think that dmraid can simply be removed at
>> this point in time. Following are the reasons that I believe
>> DMRaid.cc is needed for at least a while longer (perhaps a year or
>> more):
>
> Then perhaps it could be disabled by the configure script when it
> detects that you have (lib)parted 2.2?

This is a good suggestion on how to address this problem. :-)

>> A) If libparted device detection is used, it takes an inordinate
>> amount of time to scan devices on computer systems that do not have a
>> physical floppy drive installed, but do have the BIOS set to indicate
>> a floppy drive is present. This problem was tracked in GParted bug
>> #351753. Missing floppy causes loop on scanning devices.
>> https://bugzilla.gnome.org/show_bug.cgi?id=351753
>
> How long are we talking here? I would expect a few seconds to be spent
> trying to access the floppy before giving up, and the proper fix to that
> is not to misconfigure the bios so that it thinks it has a floppy.
> Looking at the parted bug, it seems like a NOTABUG to me. If your
> system has a broken floppy, then it has a broken floppy; it really isn't
> (lib)parted's job to guess that it isn't really supposed to be there at
> all and hide it. If the kernel says the device exists, then
> lib/g/parted should list it.
>
> Now if it is getting stuck for more than 15 seconds or so then that
> sounds like a software bug doing too many retries before giving up.

My testing showed that libparted spent 33 seconds in libparted's ped_device_probe_all() when the BIOS was misconfigured. See https://bugzilla.gnome.org/show_bug.cgi?id=351753#c20

I agree that the root cause is an improperly configured BIOS. However, some users reported that some versions of Windows would not work without this BIOS setting. Since I only use GNU/Linux I was unable to confirm this claim.
See https://bugzilla.gnome.org/show_bug.cgi?id=453555#c12

> Yes, there was a serious regression in lucid for dmraid devices that you
> have noticed. See lp #568050, which is unfortunately full of useless
> vitriol. As I said before, upstream has moved to adding the p but
> Ubuntu has had a patch for a while to revert to the old behavior of not
> adding the p in dmraid. The new code that came with parted 2.2 does
> insert the p, which is why it shows up when you run parted but not when
> dmraid creates the device.

Do you know if the new dmraid always adds the letter "p", or does it only add it when the device name ends in a number?

Ideally dmraid should use the same device naming scheme as parted.

[Phillip Susi (psusi)]

On 6/1/2010 11:52 AM, Curtis Gedak wrote:
> My testing showed that libparted spent 33 seconds in libparted's
> ped_device_probe_all() when the BIOS was misconfigured. See
> https://bugzilla.gnome.org/show_bug.cgi?id=351753#c20

That sounds like a bug somewhere... it should only take about 1 or 2
seconds for the kernel to fail any given read. Perhaps
ped_device_probe_all() continues retrying a dozen times rather than
giving up. That should probably be fixed.

For that matter, why does it even consider floppies? They can't be
partitioned so it should pay no attention to them.

> I agree that the root cause is an improperly configured BIOS.
> However, some users reported that some versions of Windows would not
> work without this BIOS setting. Since I only use GNU/Linux I was
> unable to confirm this claim. See
> https://bugzilla.gnome.org/show_bug.cgi?id=453555#c12

That appears to be an isolated incident with a broken bios. The vast
majority of systems out there are not misconfigured to think they have a
floppy when they don't, and do not have issues. Telling the bios it has
a floppy when it does not has a quite noticeable effect of causing a
floppy drive to appear in my computer in both Ubuntu and Windows, that
of course, fails to open. Occasionally this is reported on the Ubuntu
forums and users are told to correct the bios configuration and this
resolves the issue.

> Do you know if the new dmraid always adds the letter "p", or does it
> only add it when the device name ends in a number?

I _think_ it always adds it, but I'm not very sure about that.

[Curtis Gedak (gedakc)]

Phillip Susi wrote:
> On 6/1/2010 11:52 AM, Curtis Gedak wrote:
>> My testing showed that libparted spent 33 seconds in libparted's
>> ped_device_probe_all() when the BIOS was misconfigured. See
>> https://bugzilla.gnome.org/show_bug.cgi?id=351753#c20
>
> That sounds like a bug somewhere... it should only take about 1 or 2
> seconds for the kernel to fail any given read. Perhaps
> ped_device_probe_all() continues retrying a dozen times rather than
> giving up. That should probably be fixed.
>
> For that matter, why does it even consider floppies? They can't be
> partitioned so it should pay no attention to them.

I whole heartedly agree. Parted and libparted should not even consider floppy drives.

[Tom Louwrier (tom-louwrier)]

hi all,

gave it antoher go today, using the Gparted LiveCD v0.6.0-4.
No luck. It boots and sees my disks and partitions fine, but won't format / write to them.
Attaching the log.

cheers Tom

[Curtis Gedak (gedakc)]

From looking at the log file Tom, it appears that the partition names do not follow the general rule of thumb listed in comment #11.

Except from gparted_details.htm log file:
   Could not stat /dev/mapper/pdc_jcchiiabp5 --- No such file or directory

Instead the partition name appears to have been derived by simply appending "p" plus the partition number to the device name.

Still, the kpartx command included in GParted Live should have created the necessary /dev/mapper/pdc_jcchiiab5 device entry....

I suspect that we are encountering a mismatch in dmraid partition naming amoung parted, gparted, dmraid, and kpartx.

Could you list the contents of the /dev/mapper command after GParted fails to create or format a partition?
E.g., ls -l /dev/mapper

[Tom Louwrier (tom-louwrier)]

Hi Curtis,

Went back today and got you some more info.

root@debian:~# ls -la /dev/mapper
total 0
drwxr-xr-x 2 root root 200 2010-07-08 11:13 .
drwxr-xr-x 16 root root 3300 2010-07-08 11:13 ..
crw------- 1 root root 10, 59 2010-07-08 11:10 control
lrwxrwxrwx 1 root root 7 2010-07-08 11:08 pdc_jcchiiab -> ../dm-0
lrwxrwxrwx 1 root root 7 2010-07-08 11:13 pdc_jcchiiab1 -> ../dm-1
lrwxrwxrwx 1 root root 7 2010-07-08 11:13 pdc_jcchiiab2 -> ../dm-2
lrwxrwxrwx 1 root root 7 2010-07-08 11:13 pdc_jcchiiab3 -> ../dm-3
lrwxrwxrwx 1 root root 7 2010-07-08 11:13 pdc_jcchiiab5 -> ../dm-5
lrwxrwxrwx 1 root root 7 2010-07-08 11:13 pdc_jcchiiab6 -> ../dm-6
lrwxrwxrwx 1 root root 7 2010-07-08 11:13 pdc_jcchiiab7 -> ../dm-7

GParted sees 3 disks:
 /dev/sda
 /dev/sdb
these are the physical disks forming the striped set, and
 /dev/mapper/pdc_jcchiiab
this is the logical disk made up by the striped set, on which the partitions are:
 /dev/mapper/pdc_jcchiiabp1
 /dev/mapper/pdc_jcchiiabp2
 /dev/mapper/pdc_jcchiiabp5
 /dev/mapper/pdc_jcchiiabp6
 /dev/mapper/pdc_jcchiiabp7
 /dev/mapper/pdc_jcchiiabp3
Note the use of a 'p' before the partition number
pdc_jcchiiab1
pdc_jcchiiabp1 (etc)

I got a bit more adventurous and started parted from the command line.
 select /dev/dm-0
 print
gives a correct overview of 80GB total disk space and the partitions within (you want that output as well?)

Then I tried fdisk from the command line
 fdisk -l /dev/dm-0
which gave me:
Device Boot Start End Blocks id System
/dev/dm0p1 * 1 2432 19531259 7 HPFS/NTFS
Partition 1 does not end on cylinder boundary.
/dev/dm0p2 2432 3897 11765505 5 Extended
Partition 2 does not end on cylinder boundary.
Partition 2 does not start on physical sector boundary.
/dev/dm0p3 3897 2432 46868224 7 HPFS/NTFS
Partition 3 does not end on cylinder boundary.
/dev/dm0p5 2432 3040 4882688 83 Linux
/dev/dm0p6 3040 3648 4882688 83 Liunx
/dev/dm0p7 3648 3897 1999872 82 Liunx Swap / Solaris

Again we see an extra p in the device name and also a 0 instead of a -
/dev/dm-1
/dev/dm0p1 (etc)

I did not perform other actions with either parted or fdisk for now. No modifications, no writing, nada.
Restarting went OK, btw. On the previous CD's it hung and I had to reset the pc manually.

cheers
Tom

[Curtis Gedak (gedakc)]

Good news! I believe that I have solved this problem by removing the dependency on kpartx and ensuring that the partition names are compatible with the dmraid command. I would like some help with testing to determine if the problem is indeed resolved.

Is anyone able to compile and test GParted source code from the GNOME git repository?

Instructions on how to compile GParted from the git source code repository can be found at the following link:
     How to Build GParted from git Source Code Repository
     http://gparted-forum.surf4.info/viewtopic.php?id=14136

[Tom Louwrier (tom-louwrier)]

Hi Curtis,

Sorry, that is beyond me.
Apart from that, I really wanted to move on with this machine and used Phillip Susi's updated libparted0 as workaround in LP 568050 (thanx Phillip).

This gave me a *near* correct install of Lucid. All partitions and files were created and copied as they should. Only bummer is that grub2 fails to install on whatever acts as MBR of my striped array. It sees it, but just doesn't install so that I still get no Grub menu but boot straight into XP. This seems to be the same bug as mentioned in LP 568050 comment #164. I have not found a way around this one yet. Chrooting into the fresh install and set up Grub from there didn't work.

I can however download some ISO (Gparted, Ubuntu), boot it up from that and do some stuff to my /home partition (like shrink it and create en extra one in the free space). Just point me in that direction and I'll gladly test and report back.

cheers
Tom

[Tom Louwrier (tom-louwrier)]

Update: managed to get my system running from a Maverick beta alternative CD dd 05 sept 2010.
Partitioning went just fine, but Grub and/or Grub installer still do very much misbehave.
Also it seems thee are disagreements between kernel, udev, dmraid and grub about the right naming of partitions on dmraid. see LP 631795 for more info.
Installing to, and booting from a dmraid set is quite broken since Lucid. Admittedly it is somewhat of a freak system (striped fakeraid and dual boot Ubuntu/ WinXP) but does not really work out of the box.

Anything I can do to give more information of test, please let me know.

cheers
Tom

[Curtis Gedak (gedakc)]

Thank you Tom for continuing to offer to help with resolution of this problem.

Recently another user confirmed that the enhancements in the upstream git repository do indeed resolve this problem. The relevant bug report can be found at the following link:

     Bug #615753 - raid not detected (sb750) on ubuntu 9.10 and 10.04.1
     https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/615753

These enhancements are planned for upstream release later in September as GParted 0.6.3.

[Tom Louwrier (tom-louwrier)]

Hi Curtis,

OK, great to hear. I'll try Gparted 0.6.3 when I see it, just to make
sure and close this bugreport as OP :-)
Thaks for all the work.

cheers
Tom

[Curtis Gedak (gedakc)]

The enhancements to address this bug report have been included in GParted 0.6.3 which was released upstream on September 23, 2010.

[Curtis Gedak (gedakc)]

Hi Tom,

GParted Live 0.6.3-3 is now available if you would like to test out the new GParted 0.6.3 using a Live CD image.

Regards,
Curtis

[Phillip Susi (psusi)]

Gparted still does not show dmraid devices on the Maverick livecd, unless you first install the karptx package. Any idea why that is required Curtis?

[Phillip Susi (psusi)]

Nevermind, I just read your comments from earlier. I guess it just hasn't made its way into Ubuntu yet.

[Curtis Gedak (gedakc)]

No worries Phillip. :-)

GParted 0.6.3 removes the requirement for kpartx to support dmraid devices. GParted 0.6.4 removes a regression that I introduced in 0.6.3.

Hopefully Debian and Ubuntu pick up the latest version soon.

[Tom Louwrier (tom-louwrier)]

hi Curtis,

Finally got time to follow up on this. Did not burn and boot a full Gparted CD (sorry), but pulled Gparted 0.7 from the Natty repositories. That installed fine and it does see the DMraid correctly. I could shrink an NTFS partition, fill the space with a new primary and format that to ext4. Then removed the new partition. All without a hitch, and it seemed to be quicker too reading the disks's contents.

I'm confident this is solved. Thank you.

cheers
Tom

[Curtis Gedak (gedakc)]

Thank you Tom for confirming that the problem is now resolved.

[Tom Louwrier (tom-louwrier)]

Thank you Curtis.
Case closed...

[Phillip Susi (psusi)]

This fix has made it to Natty and is working well.

[Tom Louwrier (tom-louwrier)]

Hooray and thank you very much!

cheers
Tom