dmraid failure when array name contains spaces

Bug #1262161 reported by Gordon Ball
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GParted
Invalid
High
gparted (Ubuntu)
New
Undecided
Unassigned

Bug Description

(see #1262151 concerning the same issue with mdadm)

Ubuntu: saucy dmraid: 1.0.0.rc16-4.2ubuntu1

System: Acer S5-391
Contains two flash drives configured as (Intel) fakeraid. dmraid detects this array exists, and attempts to assemble it, but the resulting block device name contains an escaped space that makes them effectively unusable. The raid array contains a GPT-formatted disk, and boots with UEFI.

dmraid -s
*** Group superset isw_foobar
--> Subset
name : isw_foobar_Aspire S5-391
...

dmraid -ay produces devices named like
/dev/mapper/isw_foobar_Aspire\x20S5-391
/dev/mapper/isw_foobar_Aspire\x20S5-391p[1-6]

These block devices correctly map to the correct disk blocks (eg, mkfs.ext4 /dev/mapper/isw_foobar_Aspire\\x20S5-391p4 successfully creates a new filesystem), but anything that attempts to pass the names through appears to either fail to interpret the escapes or incorrectly splits the device into two arguments.

`gparted` started without argument refuses to read the device (/dev/mapper/isw_foobar_Aspire does not exist)
`gparted /dev/mapper/isw_foobar_Aspire\\x20S5-391` correct shows the partitions on the disk, but attempts to launch further tools (eg, create an ext4 filesystem in an existing partition), fails with non-existent device errors
`ubiquity` shows the partitions (providing `dmraid -ay` was run first), but similarly fails to actually create a filesystem or write anything into it

I was eventually able to install this system using `mdadm` to mount the disks and `debootstrap` to install the base system (since ubiquity will not work with md devices), but the experience was not at all fun. Consequently the extra information/logs I can provide is probably a bit limited as I'd rather not start messing around with the RAID again if I can possibly help it.

Revision history for this message
Phillip Susi (psusi) wrote :

You set the name when you created the array with the bios utility, so this isn't a bug in dmraid. gparted shouldn't choke on such names though, so reassigning the bug there.

affects: dmraid (Ubuntu) → gparted (Ubuntu)
Revision history for this message
Curtis Gedak (gedakc) wrote :

I believe that this is the same as the following upstream report:
https://bugzilla.gnome.org/show_bug.cgi?id=649509

Revision history for this message
Gordon Ball (chronitis) wrote :

It appears to be the same as that upstream report, yes.

The RAID name has been set by the manufacturer in this case, and to dual-boot without re-installing everything it was necessary to use it. Is it correct behaviour for `dmraid` to escape the space to `\x20` in this case though, given it is a valid character in a file name? (Assuming there aren't different rules for block device names I don't know about).

Changed in gparted:
importance: Unknown → High
status: Unknown → New
Changed in gparted:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.