Gparted not usable on fakeraid arrays

[RonParent]

Common to Ubuntu 10.04 and Mint 9, Gparted will not see or perform any functions on Fakeraid arrays. The biggest impediment and the one most a problem is that unless the target partition(s) is pre-formatted with gparted run in an earlier version of the OS the installof 10.04 or Mint 9 will fail. There are work arounds, but, the average user with only cursory knowledge of raid will not be able to cope. Of note, the selection of manual partitioning in the installer will see the existing raid partition and permit installation to one selected as long as you don't try to format it. A note that pertains primarily to the installer is that by selecting advance in step 8 you will be offered the option of installing the grub boot loader to the MBR of the raid, but. despite that an error ensued and I had to proceed with completing the install without a boot loader.

I doubt that the problem exist with gparted itself or dmraid. More likely is that some boot function in the current OS's negates the ability of gparted to see raid drives. Once installed, the interoperability of the current OS's with raids is much improved. The raid partitions are, for example, are seen and easily mounted in nautilus. Needless to say, don't expect do be able to use gparted to modify or create any raid partitions.

[RonParent (ronap)]

The behavior of gparted in Ubuntu 10.10 alpha 2 continues. At this state, 10.10 cannot be installed unless the target partition(s) is pre-formatted. At the point of formatting the installation will fail.

The bootloader, however will be accepted and installed to the raid drive. The progress message, however, will erroneously state that the bootloader is being installed on sda (a very minor issue considering)?

My conclusions are as previously stated that the problem is with the kernel or boot process since the same version of gparted works fine with earlier Ubuntu versions. Also the interoperability of the 10.10 alpha 2 remains much improved.

[Adil Arif (adisari06)]

Do you think this has something to do with Grub2?

[RonParent (ronap)]

Seems highly unlikely. The behavior is also observable when gparted is run on a live cd - it prevents installation to an unformatted partition.

[RonParent (ronap)]

This may be rekated - it appears at the end of my bootlog:

Jul 19 16:02:29 ron-test-desktop kernel: [ 136.410460] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.410712] device-mapper: ioctl: unable to remove open device nvidia_aebhdfib5
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.410832] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.411051] device-mapper: ioctl: unable to remove open device nvidia_aebhdfib6
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.411158] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.411371] device-mapper: ioctl: unable to remove open device nvidia_aebhdfib7
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.411478] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.450292] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.490410] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.520375] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.550394] device-mapper: ioctl: device doesn't appear to be in the dev hash table.
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.550651] device-mapper: ioctl: unable to remove open device nvidia_aebhdfib
Jul 19 16:02:29 ron-test-desktop kernel: [ 136.550764] device-mapper: ioctl: device doesn't appear to be in the dev hash table

[Art Shelest (art-netscale)]

Just hit this bug on a fresh Lucid install with JMICRON fake RAID.
Spent multiple hours, having to (1) use Karmic to partition disks, (2) Lucid workstation CD to complete install, and (3) Lucid server CD rescue function to update grub2.

Booting from 10.04 Live CD, the parted/gparted simply does not work.
For example, if the fake RAID device is called /dev/mapper/jmicron_MIRROR,
gparted first primary partition will show up as /dev/mapper/jmicron_MIRRORp1 (note the "p"),
in the mapper, but gparted will invoke mkfs to format the old name /dev/mapper/jmicron_MIRROR1 (no "p") and fail.

This new/old confusion appears in several places. If the 9.10 is used to partition the array,
then the naming is consistent (/dev/mapper/jmicron_MIRROR1, no "p"), and Lucid will happily
install on it.

The introduction of "p" naming convention may have been justified, but it was not done consistently in all utilities and drivers and resulted in an install-blocking issue for certain configurations.

A secondary issue complicated the install as well: in 9.04, 9.10 and 10.04, gparted does not see active fake raid devices, instead it lists physical disks. The workaround is to invoke "gparted /dev/mapper/jmicron_MIRROR", or whatever your RAID device name may be.

[RonParent (ronap)]

"A secondary issue complicated the install as well: in 9.04, 9.10 and 10.04, gparted does not see active fake raid devices, instead it lists physical disks. The workaround is to invoke "gparted /dev/mapper/jmicron_MIRROR", or whatever your RAID device name may be."

I haven't seen this last observation. Gparted in 9.04 for me shows all the raid partitions. I can't speak about 9.10 but have been recently in correspondence with someone who used the 9.10 live cd to create a target raid partition for a raid 0+1 to install 10.04 to. As stated in prior posts gparted has been useless for partitioning in 10.04 and the 10.10 pre-release. I'll have to look at the naming convention problem and report back.

[RonParent (ronap)]

Very interesting. I used the command:

sudo gparted /dev/mapper/nvidia_aevhdfib

to access my raid with gparted. I shrank a partition and created a new ext4 partition. The partition was created without flaw and conformed to the naming convention! It appears that the behavior of gparted may also be inconsistent between supported chipsets?! Not at all a comfortable situation for the average advance user.

[Curtis Gedak (gedakc)]

GParted requires both dmraid and kpartx to properly function with FAKERAID. The Ubuntu 10.04 Live CD did not ship with kpartx and this is why GParted will not automatically detect FAKERAID setups.

The kpartx application is required to create the proper device names when the dmraid command does not create the proper name.

The general rule of thumb or convention for partition names used by libparted is as follows:

1) If the device name ends in a letter, then for the partition name simply append the partition number/
     E.g.,
          Device name = /dev/mapper/isw_cjbdddajhi_Volume
          Partition name = /dev/mapper/isw_cjbdddajhi_Volume3

2) If the device name ends in a number, then for the partition name append the letter 'p' and the partition number.
     E.g.,
          Device name = /dev/mapper/isw_cjbdddajhi_Vol6
          Partition name = /dev/mapper/isw_cjbdddajhi_Vol6p3

Older versions of dmraid always appended the partition number only. I think newer versions of dmraid might always append the letter 'p' and the partition number, though I have not extensively tested this theory.

[Art Shelest (art-netscale)]

Curtis wrote:
> GParted requires both dmraid and kpartx to properly function with FAKERAID.
> The Ubuntu 10.04 Live CD did not ship with kpartx and this is why GParted
> will not automatically detect FAKERAID setups.

Thank you Curtis, I will remember the kpartx dependency for my next install.

>>
1) If the device name ends in a letter, then for the partition name simply append the partition number/
     E.g.,
          Device name = /dev/mapper/isw_cjbdddajhi_Volume
          Partition name = /dev/mapper/isw_cjbdddajhi_Volume3

2) If the device name ends in a number, then for the partition name append the letter 'p' and the partition number.
     E.g.,
          Device name = /dev/mapper/isw_cjbdddajhi_Vol6
          Partition name = /dev/mapper/isw_cjbdddajhi_Vol6p3
>>

In my experience, this logic was reversed in one of the utilities. Don't have a repro sequence, but at some point I ended up with a partitions named "jmicron_MIRRORp1" and "jmicron_MIRRORp11". Applying the logic you described, I should have gotten "jmicron_MIRROR1" and "jmicron_MIRROR1p1", which would make sense.

[Curtis Gedak (gedakc)]

Good news! I believe that I have solved this problem, and I would like some help with testing.

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

[Peter Hurley (phurley)]

I will be happy to test this on an Intel esb2 raid 0 array. I know for a fact that gparted worked on this array with karmic and custom 2.6.33 kernel.

I'll let you know. It's going to be a little while though because I'm in the middle of a maverick kernel build right now.

[Peter Hurley (phurley)]

I can confirm that the latest commit of gparted (Aug 17 commit c55a8de) does correctly *list* my firmware raid array (/dev/mapper/isw_cbdbfhdjad_Raid0) and the partitions thereon.

Before I experiment to see if it can edit the partitions, I need to find out why the boot log is saying my "partition table is partially beyond EOD". -- I think it's because dm-raid45 hasn't loaded yet so the partition table read is only 1/2 the stripe --

FYI - I built a .deb package of the git instead which was very straightforward from the source deb diff.

[Curtis Gedak (gedakc)]

Thank you Peter for confirming that current git version of GParted does correctly list your firmware RAID array.

When GParted is started, it invokes the command "dmraid -ay -v" to ensure that the /dev/mapper device entries are created.

If you have found a problem in the boot log, then you might wish to try the following command to check if there is a problem according to parted:
     parted /path-to-your-dmraid-device unit s print

If there is a partition that extends beyond the end of the disk, my first suspect would be the extended partition if you are using an MSDOS partition table.

[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.