Bug 1081624 - Minor text parsing error
Summary: Minor text parsing error
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gparted
Version: 20
Hardware: x86_64
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Mukundan Ragavan
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-27 17:37 UTC by Peter Trenholme
Modified: 2014-12-19 02:17 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-19 02:17:58 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
gparted error messages (5.84 KB, text/plain)
2014-07-30 15:42 UTC, Peter Trenholme
no flags Details
GParted screenshot (174.23 KB, image/png)
2014-07-30 22:16 UTC, Mike Fleetwood
no flags Details
GParted screenshot 2 (180.84 KB, image/png)
2014-08-02 19:16 UTC, Mike Fleetwood
no flags Details
Requested GParted screenshot (264.85 KB, image/png)
2014-08-03 18:42 UTC, Peter Trenholme
no flags Details

Description Peter Trenholme 2014-03-27 17:37:38 UTC
Description of problem:(gpartedbin:26193): Gtk-WARNING **: Failed to set text from markup due to error parsing markup: Error on line 2 char 42: Odd character '>', expected a '=' after attribute name 'available' of element 'not'


Version-Release number of selected component (if applicable):
libparted 3.1
gparted 0.18.0

How reproducible:
Every time

Steps to Reproduce:
1.Start gparted from a command line
2.Work a bit
3.

Actual results:
Several Gtk-WARNING messages displayed.

Expected results:
No warnings

Additional info:
Since the application seems to work without errors, I assume that this is a minor, mostly cosmetic, "problem."

Comment 1 Peter Trenholme 2014-03-27 17:48:18 UTC
Oh, I just realized that gparted was probably trying to tell me that "Partition information is not available for RAID members," or something similar. (Obviously, getting gparted to do anything with partitions in a RAID array would be quite difficult.)

I mention this not as a compliant, but just to help you find where the message formatting needs a "tweak."

Comment 2 Fedora Admin XMLRPC Client 2014-07-26 17:13:55 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 3 Fedora Admin XMLRPC Client 2014-07-26 19:52:50 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 4 Mike Fleetwood 2014-07-29 13:36:02 UTC
Hi Peter,

If you are still interested in resolving this fault and you can still
reproduce it I will have a look.

On my Fedora 20 VM I formatted one partition as an LVM2 PV and another
as Linux Software RAID memeber.  Viewing details of these partitions
didn't produce any warnings.

Can you post the output of the following commands so that I can create
an eqlivant storage setup, and any specific steps in using GParted to
reproduce the fault.
  lsblk
  blkid

Thanks,
Mike Fleetwood (GParted Developer)

Comment 5 Peter Trenholme 2014-07-30 15:42:01 UTC
Created attachment 922638 [details]
gparted error messages

O.K., here's how I reproduced it (using GParted 0.18.0, and KDE on a Rawhide system.)

1. Open a terminal window (I used Konsole)
2. Enter the command "sudo gparted"
3. Open one of the drives containing a MD raid partition.
4. Right click on the partition and select the "Information" item from the list.

I've included an attachment of my terminal output. The error messages are at the end of the file. You might also want to address the GLib-CRITICAL errors that preceded the messages I reported.

Comment 6 Mike Fleetwood 2014-07-30 22:16:01 UTC
Created attachment 922764 [details]
GParted screenshot

Hi Peter,

GLib-CRITICAL **: Source ID 7 was not found when attempting to remove it
--
This is fixed upstream in GParted 0.19.0 by this commit:

Prevent GSource double-destroy warning messages (#729800)
https://git.gnome.org/browse/gparted/commit/?id=2e7b5d05a6324c1370248af93925cbc95b9db0ac


Gtk-WARNING **: Failed to set text from markup due to error parsing
markup: Error on line 2 char 42: Odd character '>', expected a '=' after
attribute name 'available' of element 'not'
--
I have not been able to reproduce this fault.  I have installed Xfce
desktop, but that shouldn't make any difference as the warning is
comming from Gtk libraries.  My storage setup looks like this:

[root@localhost ~]# lsblk
NAME            MAJ:MIN RM  SIZE RO TYPE   MOUNTPOINT
sda               8:0    0   20G  0 disk   
├─sda1            8:1    0  500M  0 part   /boot
└─sda2            8:2    0 19.5G  0 part   
  ├─fedora-root 253:0    0 17.5G  0 lvm    /
  └─fedora-swap 253:1    0    2G  0 lvm    [SWAP]
sdb               8:16   0    8G  0 disk   
└─sdb1            8:17   0    2G  0 part   
  └─md1           9:1    0    2G  0 linear 
sr0              11:0    1 1024M  0 rom    
[root@localhost ~]# blkid
/dev/sda1: UUID="e0036c00-456a-4b1f-8156-b0232aa87142" TYPE="ext4" PARTUUID="5fa4597c-01" 
/dev/sda2: UUID="nnx9e4-rc0G-NHme-mT2K-nLmV-qlUN-MUjPoI" TYPE="LVM2_member" PARTUUID="5fa4597c-02" 
/dev/mapper/fedora-root: UUID="62f16c00-80a2-4b54-aa83-9b9690855bbd" TYPE="ext4" 
/dev/mapper/fedora-swap: UUID="f993a370-fb40-4065-a844-ce79c2d514cf" TYPE="swap" 
/dev/sdb1: UUID="8d7a22e2-84aa-106e-abef-0fb51f1e1bd3" UUID_SUB="7b9892c9-7913-d225-9d08-90890f5612a6" LABEL="localhost.localdomain:1" TYPE="linux_raid_member" PARTUUID="7203b3b5-01"

Please post your storage setup and anything else that might allow me to
reproduce the warning.

Thanks,
Mike

Comment 7 Peter Trenholme 2014-08-01 22:01:56 UTC
Note that I was trying a "stupid" action, looking for the "information" available for one partition of an active raid-1 array. If I had thought about it before clicking, I would have expected a "Not Permitted" or "Not Supported" message, or perhaps a suggestion that I use the mdadam tools to do that. When I saw the line in the terminal output, I was startled that the program had actually tried to do something to satisfy my (thoughtless) request.

O.K., here's my storage layout. (I also have nine loopback devices mounted, which I've omitted as being more distracting than relevant.)

It is also probably not relevant that the raid-1 device is mounted as /. (The partition mounted a /Fedora is a "production" F20, / is Rawhide.)

$ sudo lsblk
NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda         8:0    0 931.5G  0 disk  
├─sda1      8:1    0   100M  0 part  /Win8/System
├─sda2      8:2    0 430.2G  0 part  /Win8
├─sda3      8:3    0  12.9G  0 part  /Win8/HP_Recover
├─sda4      8:4    0     1K  0 part  
└─sda5      8:5    0 488.3G  0 part  
  └─md127   9:127  0 488.3G  0 raid1 /
sdb         8:16   0   1.8T  0 disk  
├─sdb1      8:17   0 430.3G  0 part  /Fedora
├─sdb2      8:18   0 488.3G  0 part  
│ └─md127   9:127  0 488.3G  0 raid1 /
├─sdb3      8:19   0 488.3G  0 part  
└─sdb4      8:20   0 456.1G  0 part  
sdc         8:32   0   1.8T  0 disk  
├─sdc1      8:33   0   1.8T  0 part  /Backups
└─sdc2      8:34   0  11.7G  0 part  [SWAP]

$ sudo blkid
/dev/sda1: LABEL="SYSTEM" UUID="98CAD0A9CAD08542" TYPE="ntfs" PARTUUID="945663c5-01" 
/dev/sda2: LABEL="OS" UUID="8ECEC31BCEC2FA8B" TYPE="ntfs" PARTUUID="945663c5-02" 
/dev/sda3: LABEL="HP_RECOVERY" UUID="D21A40A51A408885" TYPE="ntfs" PARTUUID="945663c5-03" 
/dev/sda5: UUID="31ae217a-e756-4465-9e52-7f4040dcd2b8" UUID_SUB="cc303eea-91ac-a2cd-7e69-96c6270294b6" LABEL="HP-p6710f:127" TYPE="linux_raid_member" PARTUUID="945663c5-05" 
/dev/sdb1: UUID="d6189260-8c1e-45af-b548-08c5c7130d20" TYPE="ext4" PARTUUID="767f9c5a-01" 
/dev/sdb2: UUID="31ae217a-e756-4465-9e52-7f4040dcd2b8" UUID_SUB="87805290-4027-aefc-1d42-78a94c902e15" LABEL="HP-p6710f:127" TYPE="linux_raid_member" PARTUUID="767f9c5a-02" 
/dev/sdb3: UUID="31ae217a-e756-4465-9e52-7f4040dcd2b8" UUID_SUB="0819db26-bf82-ad13-edac-05b36315032c" LABEL="HP-p6710f:127" TYPE="linux_raid_member" PARTUUID="767f9c5a-03" 
/dev/sdb4: UUID="63ae0d44-3a0b-48b5-93be-f1b8f0b53a7a" TYPE="swap" PARTUUID="767f9c5a-04" 
/dev/sdc1: LABEL="Backups" UUID="da1e3dad-5460-4a45-95b6-a1c3d43f760d" UUID_SUB="5f8ce6bb-7479-4a4c-b907-826165558cfa" TYPE="btrfs" PARTUUID="f51bf978-c707-4682-a822-1f3965580cf8" 
/dev/sdc2: UUID="1f6c397e-8127-4d77-be0b-966eeee752bd" TYPE="swap" PARTUUID="77f138b0-30e4-4881-8772-33789908935f" 
/dev/md127: UUID="31ae217a-e756-4465-9e52-7f4040dcd2b8" TYPE="ext4"

Comment 8 Mike Fleetwood 2014-08-02 19:16:16 UTC
Created attachment 923496 [details]
GParted screenshot 2

Hi Peter,

I have now tried creating a RAID1 array with 2 devices (using 2
partitions on the same disk).  I have used all mdadm's own metadata
formats: 0.9, 1.0, 1.1 & 1.2 and mounted an ext4 file system in the
array.  Still not been able to recreate the Gtk-WARNING when displaying
the partition information for the partitions containing members.

I assume you are looking at the partition information for either sda5 or
sdb2.  Please confirm?
When I do this I don't see anything unusual.  See attached: GParted
screenshot 2.


Something looks unusual in your lsblk and blkid output.
sda5 and sdb2 are your md127 RAID1 array containing / (root) file
system, but sdb3 has the same UUID, LABEL and TYPE as those two
partitions / array members.  Do you know why?

/dev/sdb3: UUID="31ae217a-e756-4465-9e52-7f4040dcd2b8" UUID_SUB="0819db26-bf82-ad13-edac-05b36315032c" LABEL="HP-p6710f:127" TYPE="linux_raid_member"


Can you post:
1) A screenshot showing the contents of the Partition Information dialog
   with GParted in the background;
2) The output of:
      parted /dev/sda print
      parted /dev/sdb print
      parted /dev/sdc print
      cat /proc/mdstat


Thanks,
Mike

Comment 9 Peter Trenholme 2014-08-02 21:31:47 UTC
I'll post that output tomorrow (I'm away from that system today.) but, to answer your question about the third partition, it is configured as a "spare" to the RAID-1 array. (One of the two partitions I set up was - inadvertently - configured with twice the space it needed, so I split it.)

Comment 10 Peter Trenholme 2014-08-03 18:37:35 UTC
Here's the info you requested. (I think I misspoke in comment #9 - it's been more than a year since I looked at the mirror setup so my memory was being creative. Looking at the mdadam output, that (sdb3) was in the array as a spare, but I must have removed it for some reason which I've forgotten.) 

# for p in a b c;do parted /dev/sd${p} p;done
Model: ATA ST31000528AS (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  106MB   105MB   primary   ntfs         boot
 2      106MB   462GB   462GB   primary   ntfs
 3      462GB   476GB   13.9GB  primary   ntfs
 4      476GB   1000GB  524GB   extended
 5      476GB   1000GB  524GB   logical   ext4         raid

Model: ATA ST2000DL003-9VT1 (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size   Type     File system     Flags
 1      8225kB  462GB   462GB  primary  ext4            boot
 2      462GB   986GB   524GB  primary  ext4            raid
 4      986GB   1476GB  490GB  primary  linux-swap(v1)
 3      1476GB  2000GB  524GB  primary  ext4

Model: ATA WDC WD20EARX-00P (scsi)
Disk /dev/sdc: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name  Flags
 1      17.4kB  1988GB  1988GB  btrfs                 msftdata
 2      1988GB  2000GB  12.6GB  linux-swap(v1)

# cat /proc/mdstat
Personalities : [raid1] 
md127 : active raid1 sdb2[4] sda5[3]
      512001912 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

-------------------------------------------------------

You didn't ask for this, but it may clarify the info above:

# mdadm --misc -E /dev/sda5 /dev/sdb[23]
/dev/sda5:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 31ae217a:e7564465:9e527f40:40dcd2b8
           Name : HP-p6710f:127
  Creation Time : Fri Oct  7 02:57:37 2011
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1024004096 (488.28 GiB 524.29 GB)
     Array Size : 512001912 (488.28 GiB 524.29 GB)
  Used Dev Size : 1024003824 (488.28 GiB 524.29 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1968 sectors, after=272 sectors
          State : clean
    Device UUID : cc303eea:91aca2cd:7e6996c6:270294b6

    Update Time : Sun Aug  3 11:08:01 2014
       Checksum : a5459ce8 - correct
         Events : 368512


   Device Role : Active device 1
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdb2:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 31ae217a:e7564465:9e527f40:40dcd2b8
           Name : HP-p6710f:127
  Creation Time : Fri Oct  7 02:57:37 2011
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1024004096 (488.28 GiB 524.29 GB)
     Array Size : 512001912 (488.28 GiB 524.29 GB)
  Used Dev Size : 1024003824 (488.28 GiB 524.29 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1960 sectors, after=272 sectors
          State : clean
    Device UUID : 87805290:4027aefc:1d4278a9:4c902e15

    Update Time : Sun Aug  3 11:08:01 2014
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : bbe9ce5e - correct
         Events : 368512


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

/dev/sdb3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : 31ae217a:e7564465:9e527f40:40dcd2b8
           Name : HP-p6710f:127
  Creation Time : Fri Oct  7 02:57:37 2011
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 1024004096 (488.28 GiB 524.29 GB)
     Array Size : 512001912 (488.28 GiB 524.29 GB)
  Used Dev Size : 1024003824 (488.28 GiB 524.29 GB)
    Data Offset : 2048 sectors
   Super Offset : 8 sectors
   Unused Space : before=1960 sectors, after=272 sectors
          State : clean
    Device UUID : 0819db26:bf82ad13:edac05b3:6315032c

    Update Time : Wed May 21 16:41:11 2014
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 897262d9 - correct
         Events : 364800


   Device Role : Active device 0
   Array State : AA ('A' == active, '.' == missing, 'R' == replacing)

Comment 11 Peter Trenholme 2014-08-03 18:42:08 UTC
Created attachment 923652 [details]
Requested GParted screenshot

Note that the information text box lacks any scroll bar, and that it extends past the bottom of the screen. Perhaps that's related to the error message?

Comment 12 Mike Fleetwood 2014-08-03 20:54:02 UTC
Hi Peter,

The sda5 partition use to contain an ext4 file system before being
overwritten as a Linux Software RAID member and so it contains two
different signatures.  Blkid reports it as "linux_raid_member" but
parted (libparted) reports it as "ext4".  You can use wipefs to display
all the signatures like this:

[root@localhost ~]# wipefs /dev/sdb1
offset               type
----------------------------------------------------------------
0x438                ext3   [filesystem]
                     LABEL: test1-ext3
                     UUID:  d09d8ec6-a197-4d5a-854b-c2e178efb606

0x1000               linux_raid_member   [raid]
                     LABEL: localhost.localdomain:1
                     UUID:  0a9b6f38-6747-84df-8b58-02e4f69bb599


GParted uses the libparted answer and queries sda5 as an ext4 file
system with "dumpe2fs -h /dev/sda5" to get the file system usage
figures.  This reports an error so GParted puts it in the warnings for
the partition as shown in the screen shot from comment #11.  The output
included the text on line 2:
  Last mounted on:  <not available>

The GTK text widget doesn't recognise "<not available>" as valid markup,
hence the warning message written to the terminal:
--
Gtk-WARNING **: Failed to set text from markup due to error parsing
markup: Error on line 2 char 42: Odd character '>', expected a '=' after
attribute name 'available' of element 'not'


Peter,
You will need to erase the old ext4 file system signature from sda5 (and
the other RAID memebers too as required) so that GParted doesn't find
the old signature.  Use "wipefs -o 0x438 /dev/sda5".  Wipefs won't do it
on a busy partition though.  Options I see are (1) reboot using some
rescue media to do it, (2) drop one member at a time out of the mirror
to do it, (3) use dd to surgically zero the ext4 signature.


I can see a number of fixes needed to various software:
(1) GParted - Use blkid identification over libparted identification
(2) GParted - Handle markup embeded in displayed text
(3) Parted (libparted) - Recognise Linux Software RAID members and
    before file systems as blkid does
(4) mdadm - Erase all previous signatures when creating a member

I'll see what I can do with the GParted ones at least.


Thanks,
Mike

Comment 13 Peter Trenholme 2014-08-07 00:43:53 UTC
I used wipefs to clean out the ext sig.s. (Although I needed to use the --force option, even when /dev/md127 was unmounted. I suspect, but didn't check, that having the md daemon running flags the components as "in use," even when they aren't.) After that, both sda5 and sdb2 had "unexceptional" information pop-ups.

FYI: I noticed that the information pop-up for /dev/md127 told me that the ext4 file system did not use the whole device, and suggested that I select the partition, click on the Partition button, and select "Check" from the pull-down list. That option was (of course) grayed.

Comment 14 Mike Fleetwood 2014-08-08 19:36:19 UTC
Hi Peter,

Thanks for getting back and reporting that the issue is fixed.

Good to see wipefs --force worked on a busy device.  (A raid member is
busy when the array is active.  See "cat /proc/mdstat").

The check operation is greyed out because the file system is busy
mounted.

Thanks,
Mike

Comment 15 Mukundan Ragavan 2014-12-19 02:17:58 UTC
Closing since this issue seems to be fixed. Please reopen if the bug persists.


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