GNOME Bugzilla – Bug 715191
LVM2 PV space usage details not working on fake BIOS RAID
Last modified: 2020-11-13 10:40:27 UTC
Problem: LVM2 PV recognition and space usage not working on fake BIOS RAID Hypothesis: I believe the root cause of the recognition and space usage problem stems from multiple device partition entries (e.g., /dev/mapper/* and /dev/dm-*) that refer to the exact same partition. EXAMPLE DEMONSTRATING LVM2 PV ON FAKE BIOS RAID =============================================== The following example was performed on Kubuntu 12.04 with parted-2.3-8ubuntu5.1 and GParted 0.16.2-git compiled without any extra configure flags. To demonstrate the problem I set up: a fake RAID named isw_efjbbijhh_Vol0 Using GParted I created: an extended partition that spanned the RAID isw_efjbbijhh_Vol01 a 10240 MiB lvm2 pv in the extended partition isw_efjbbijhh_Vol05 The device and partitions are defined by multiple device entries. $ ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Nov 24 10:07 control lrwxrwxrwx 1 root root 7 Nov 24 11:40 isw_efjbbijhh_Vol0 -> ../dm-1 lrwxrwxrwx 1 root root 7 Nov 24 11:32 isw_efjbbijhh_Vol01 -> ../dm-4 lrwxrwxrwx 1 root root 7 Nov 24 11:40 isw_efjbbijhh_Vol05 -> ../dm-5 lrwxrwxrwx 1 root root 7 Nov 24 11:40 isw_efjbbijhh_Vol0p1 -> ../dm-0 lrwxrwxrwx 1 root root 7 Nov 24 11:40 isw_efjbbijhh_Vol0p5 -> ../dm-2 $ ls -l /dev/dm-* brw-rw---- 1 root disk 252, 0 Nov 24 11:40 /dev/dm-0 brw-rw---- 1 root disk 252, 1 Nov 24 11:40 /dev/dm-1 brw-rw---- 1 root disk 252, 2 Nov 24 11:40 /dev/dm-2 brw-rw---- 1 root disk 252, 4 Nov 24 11:32 /dev/dm-4 brw-rw---- 1 root disk 252, 5 Nov 24 11:40 /dev/dm-5 These device entries correspond to the following device and partitions entries: Device: isw_efjbbijhh_Vol0 is also /dev/dm-1 Extended Partition: isw_efjbbijhh_Vol01 is also /dev/dm-4 and /dev/mapper/isw_efjbbijhh_Vol0p1 and /dev/dm-0 Logical Partition (LVM2 PV): isw_efjbbijhh_Vol05 is also /dev/dm-5 and /dev/mapper/isw_efjbbijhh_Vol0p5 and /dev/dm-2 I created a volume group and logical volume using: # vgcreate myvg /dev/mapper/isw_efjbbijhh_Vol05 Volume group "myvg" successfully created # lvcreate --name mylv --size 1G myvg Logical volume "mylv" created At this point, GParted recognized the LVM2 PV partition, but did not report the space usage details. From looking at the LVM2_PV_Info cache loading commands, it appears that the second command (as shown below) uses device entry /dev/dm-5. # lvm vgscan Reading all physical volumes. This may take a while... Found volume group "myvg" using metadata type lvm2 # lvm pvs --config "log{command_names=0}" --nosuffix --noheadings \ --separator , --units b -o pv_name,pv_size,pv_free,vg_name /dev/dm-5,4290772992,3217031168,myvg # lvm pvs --config "log{command_names=0}" --nosuffix --noheadings \ --separator , --units b -o vg_name,vg_attr,lv_name,lv_attr myvg,wz--n-,mylv,-wi-a- myvg,wz--n-,, # Hence the lvm command references the /dev/dm-5 entry which is: neither the /dev/mapper/isw_efjbbijhh_Vol05 entry used by dmraid, nor the /dev/mapper/isw_efjbbijhh_Vol0p5 entry used by libparted, though each of these entries actually reference the same logical partition. I believe the root of the problem is that: dmraid uses one name isw_efjbbijhh_Vol05 libparted users another name isw_efjbbijhh_Vol0p5 and lvm could a further two names /dev/dm-5 or /dev/dm-2 Note that at this time, the LVM2 PV partition is recognized in GParted. On subsequent reboots, the LVM2 PV partition is no longer recognized and one fewer /dev/dm-* entries is created. $ ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Nov 25 10:56 control lrwxrwxrwx 1 root root 7 Nov 25 10:56 isw_efjbbijhh_Vol0 -> ../dm-0 lrwxrwxrwx 1 root root 7 Nov 25 11:04 isw_efjbbijhh_Vol05 -> ../dm-3 lrwxrwxrwx 1 root root 7 Nov 25 10:56 isw_efjbbijhh_Vol0p1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Nov 25 10:56 isw_efjbbijhh_Vol0p5 -> ../dm-2 $ ls -l /dev/dm-* brw-rw---- 1 root disk 252, 0 Nov 25 10:56 /dev/dm-0 brw-rw---- 1 root disk 252, 1 Nov 25 10:56 /dev/dm-1 brw-rw---- 1 root disk 252, 2 Nov 25 10:56 /dev/dm-2 brw-rw---- 1 root disk 252, 3 Nov 25 11:04 /dev/dm-3 I believe that these multiple device names and the inconsistency in which tools create which device name entries is likely at the root of this problem. NOTE: This problem was discovered while testing patches for the following report: Bug #712533 - Partitions not detected as busy inside Software RAID on some distros LOW LIKELIHOOD OF USERS ENCOUNTERING PROBLEM AND WORKAROUND EXISTS ================================================================== One saving grace is that I do not think this problem is widespread. A primary reason for using fake BIOS RAID is to permit working with both Windows and GNU/Linux on the same RAID. However Windows will not work with LVM2 PVs. This negates sharing information between these two operating systems. Hence I believe the likelihood of users configuring fake BIOS RAID with LVM2 PVs will be remote. Even with this noted problem, GParted can still be used to create an LVM2 PV partition on fake BIOS RAID. However due to the lack of space usage determination and LVM2 PV recognition, GParted cannot be used to resize/move an LVM2 PV partition on fake BIOS RAID. Instead a user will need to resort to other tools, such as on the command line, to work with LVM2 PVs on fake BIOS RAID. FACTORS AFFECTING PROBLEM RESOLUTION ==================================== A few factors will affect how the problem might be resolved, and the complexity of said solution. 1) The DMRAID package appears to be no longer actively supported (no new motherboard BIOS RAIDs are being added.) Further, mdadm appears to be adopting support for some motherboard BIOS RAID / fake RAID that were previously only supported by dmraid. See "Picking up development of dmraid" mailing list thread: https://www.redhat.com/archives/ataraid-list/2012-July/msg00000.html Short Summary: mdadm is taking over from dmraid for some motherboard BIOS RAID. 2) GParted contains custom code to handle DMRAID. However libparted can handle fake RAID / DMRAID as of version 2.3. When libparted 2.3 or higher is in widespread use, there will be no impact to currently supported distros by removing the GParted custom DMRAID code (DMRaid.cc). At the time of this bug report (Nov 2013) the parted versions in use for currently supported distros are as follows: OLDEST SUPPORTED PARTED DISTRO VERSION VERSION ----------------- ------------ CentOS 5.6 1.8.1-28(?) CentOS 6.4 2.1-19(?) debian 7 (wheezy) 2.3-12 fedora 18 3.1-12 opensuse 11.4 2.3-8.2 ubuntu 10.04 2.2-5ubuntu5 These above factors lead me to believe that this problem will be easier to fix (and subsequently maintain) at a later date.
Today while testing a patch set for bug 712533, I have discovered that I am unable to recreate the problem where the LVM2 PV partition on a fake BIOS RAID fails to be recognized after reboot. I have tried a few times with deleting the LVM2 PV partition and recreating the partition both with and without the patch set, but cannot reproduce the situation in which the LVM2 PV partition fails to be recognized on reboot. I cannot explain this change in behaviour and I am confident that my eyes did not deceive me yesterday when the LVM2 PV on fake BIOS RAID recognition problem first occurred. Since I cannot reproduced the failed LVM2 PV recognition problem I am renaming this report from: LVM2 PV recognition and space usage not working on fake BIOS RAID to: LVM2 PV space usage details not working on fake BIOS RAID
I'm not sure what is creating the wrong partition device ( without the 'p' ). I swear I sorted all that out on 12.04. Are you building with --enable-libparted-dmraid?
Hi Phillip, As mentioned in comment #0, no configure flags were set. > EXAMPLE DEMONSTRATING LVM2 PV ON FAKE BIOS RAID > =============================================== > > The following example was performed on Kubuntu 12.04 with > parted-2.3-8ubuntu5.1 and GParted 0.16.2-git compiled without any > extra configure flags. Fortunately the scenario depicted in this report is not likely to be widely used. Curtis
Ahh, that is why. You need to --enable-libparted-dmraid, or gparted runs dmraid to activate the array and explicitly tells it not to insert the 'p'. It looks like this is a case of a workaround gparted adopted to fix a bug elsewhere that has now come back to bite it now that the bug was really fixed.
Hi Phillip, Thank you for reviewing this and a number of older bug reports. I am slowly working my way through the backlog. I just finished testing on kubuntu 12.04 with gparted-0.17.0 and parted-2.3-8ubuntu5 using the --enable-libparted-dmraid configure option. When testing I substituted the correct device names as appropriate (e.g., isw_efjbbijhh_Vol0p5 for isw_efjbbijhh_Vol05). Unfortunately the original problem with LVM2 PV space usage details not working on fake BIOS RAID still exists when the --enable-libparted-dmraid is used. I believe that the problem arises due to the multiple names used to refer to the same device. In the case where --enable-libparted-dmraid is used there is one less device name (the one created by dmraid). I agree that this problem will be easier to resolve when the workaround dmraid code is eventually dropped. In the meantime this problem remains regardless of which configure options are used for GParted. I still think that this problem is better solved at a later date according to the "FACTORS AFFECTING PROBLEM RESOLUTION" I listed in comment #0. Curtis
Ahh yes, it looks like pvdisplay likes to use the /dev/vg/lv name instead of /dev/mapper/vg-lv. I guess gparted will need to account for that when parsing the output of pvdisplay.
Wait, no, that was testing with using a logical volume as a pv, but fakeraid doesn't have a /dev/vg name... what is the output of pvdisplay for you?
Following is the output from some relevant commands: # ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Jan 3 12:39 control lrwxrwxrwx 1 root root 7 Jan 3 12:39 isw_efjbbijhh_Vol0 -> ../dm-0 lrwxrwxrwx 1 root root 7 Jan 3 12:39 isw_efjbbijhh_Vol0p1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Jan 3 12:44 isw_efjbbijhh_Vol0p5 -> ../dm-2 lrwxrwxrwx 1 root root 7 Jan 3 12:44 myvg-mylv -> ../dm-3 # ls -l /dev/dm-* brw-rw---- 1 root disk 252, 0 Jan 3 12:39 /dev/dm-0 brw-rw---- 1 root disk 252, 1 Jan 3 12:39 /dev/dm-1 brw-rw---- 1 root disk 252, 2 Jan 3 12:44 /dev/dm-2 brw-rw---- 1 root disk 252, 3 Jan 3 12:44 /dev/dm-3 # lvm vgscan Reading all physical volumes. This may take a while... Found volume group "myvg" using metadata type lvm2 # lvm pvs --config "log{command_names=0}" --nosuffix --noheadings \ > --separator , --units b -o pv_name,pv_size,pv_free,vg_name /dev/dm-2,10733223936,9659482112,myvg # lvm pvs --config "log{command_names=0}" --nosuffix --noheadings \ > --separator , --units b -o vg_name,vg_attr,lv_name,lv_attr myvg,wz--n-,mylv,-wi-a- myvg,wz--n-,, # pvdisplay --- Physical volume --- PV Name /dev/dm-2 VG Name myvg PV Size 10.00 GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 2559 Free PE 2303 Allocated PE 256 PV UUID UfAq3u-SsaJ-V11B-deHY-eohV-G3Zg-lDibwr # If you need any other output then let me know.
Looks like a bug in lvm; it shouldn't be using the /dev/dm-x name. It should be fairly simple to work around though by having gparted stat() the device and compare it with a stat() of the known devices, and if they match, take the known name rather than what pvdisplay says.
Hi Curtis, I'm beginning to look at what I need to do to fix the btrfs device membership failings when LUKS encrypted partitions are used (see bug 760080 comment 1). This bug has similarities of the tool reporting /dev/dm-N instead of /dev/mapper/NAME. Possibly also looking at doing a bigger cleanup of path name handling so trying to understand the limits of what GParted has to cope with. With the above setup can you run the following commands: ls -l /dev/mapper ls -l /dev/dm-* dmsetup ls dmsetup table blkid /dev/mapper/* lvm pvs lvm pvs /dev/dm-X (Where X is both device mapper minor numbers which refer to the 2 different names for the same partition containing the LVM Physical Volume). Thanks, Mike
Hi Mike, I re-created the setup I described in the first post. Following is the output to the commands requested. Note that I added a blank line to separate the command output from the next command. # ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Apr 28 09:00 control lrwxrwxrwx 1 root root 7 Apr 28 09:27 isw_efjbbijhh_Vol0 -> ../dm-1 lrwxrwxrwx 1 root root 7 Apr 28 09:26 isw_efjbbijhh_Vol05 -> ../dm-3 lrwxrwxrwx 1 root root 7 Apr 28 09:27 isw_efjbbijhh_Vol0p1 -> ../dm-0 lrwxrwxrwx 1 root root 7 Apr 28 09:27 isw_efjbbijhh_Vol0p5 -> ../dm-2 # ls -l /dev/dm-* brw-rw---- 1 root disk 252, 0 Apr 28 09:27 /dev/dm-0 brw-rw---- 1 root disk 252, 1 Apr 28 09:27 /dev/dm-1 brw-rw---- 1 root disk 252, 2 Apr 28 09:27 /dev/dm-2 brw-rw---- 1 root disk 252, 3 Apr 28 09:26 /dev/dm-3 # dmsetup ls isw_efjbbijhh_Vol0p1 (252, 0) isw_efjbbijhh_Vol0 (252, 1) isw_efjbbijhh_Vol05 (252, 3) isw_efjbbijhh_Vol0p5 (252, 2) # dmsetup table isw_efjbbijhh_Vol0p1: 0 2 linear 252:1 2048 isw_efjbbijhh_Vol0: 0 312494080 mirror core 2 131072 nosync 2 8:48 0 8:32 0 1 handle_errors isw_efjbbijhh_Vol05: 0 20971520 linear 252:1 4096 isw_efjbbijhh_Vol0p5: 0 20971520 linear 252:1 4096 # blkid /dev/mapper/* /dev/mapper/isw_efjbbijhh_Vol05: UUID="cfY0GI-ekZa-suc3-9pJd-CLfo-EIw5-bPVfxA" TYPE="LVM2_member" /dev/mapper/isw_efjbbijhh_Vol0p5: UUID="cfY0GI-ekZa-suc3-9pJd-CLfo-EIw5-bPVfxA" TYPE="LVM2_member" # lvm pvs Found duplicate PV cfY0GIekZasuc39pJdCLfoEIw5bPVfxA: using /dev/dm-3 not /dev/dm-2 PV VG Fmt Attr PSize PFree /dev/dm-3 lvm2 a- 10.00g 10.00g # lvm pvs /dev/dm-2 # Note: isw_efjbbijhh_Vol0p5 Found duplicate PV cfY0GIekZasuc39pJdCLfoEIw5bPVfxA: using /dev/dm-3 not /dev/dm-2 PV VG Fmt Attr PSize PFree /dev/dm-3 lvm2 a- 10.00g 10.00g # lvm pvs /dev/dm-3 # Note: isw_efjbbijhh_Vol05 Found duplicate PV cfY0GIekZasuc39pJdCLfoEIw5bPVfxA: using /dev/dm-2 not /dev/dm-3 PV VG Fmt Attr PSize PFree /dev/dm-2 lvm2 a- 10.00g 10.00g Please let me know if you need any more information. Curtis
You need to compile gparted with --enable-libparted-dmraid so that gparted does not run dmraid to re-activate the volume, without the 'p' separator character before the partition name.
Hi, just a tip herein case it is useful: In KDE Partition Manager we now extract LUKS mapping names with "lsblk --raw --noheadings --output name deviceNode". It might be easier than parsing dmcrypt output.
Thank you Andrius for the lsblk suggestion. Mike, following is the output of the lsblk command both before and after I run GParted for the first time. # lsblk --raw --noheadings --output name /dev/mapper/isw_efjbbijhh_Vol0 isw_efjbbijhh_Vol0 (dm-0) isw_efjbbijhh_Vol0p1 (dm-1) isw_efjbbijhh_Vol0p5 (dm-2) # sudo gparted ====================== libparted : 2.3 ====================== # lsblk --raw --noheadings --output name /dev/mapper/isw_efjbbijhh_Vol0 isw_efjbbijhh_Vol0 (dm-0) isw_efjbbijhh_Vol0p1 (dm-1) isw_efjbbijhh_Vol0p5 (dm-2) isw_efjbbijhh_Vol05 (dm-3) Phillip, thanks for the --enable-libparted-dmraid suggestion. The challenge is that some distros include a version of dmraid that does not follow the same naming standard as libparted (for example Debian 8 Jessie). Hence when Debian boots there is no isw_efjbbijhh_Vol0p1 or isw_efjbbijhh_Vol0p5 partition path. I don't currently have Jessie installed, but can do that for Mike if he needs it for debugging. Curtis
Oh my, that would be a bug in Debian then. After manipulating partitions with (lib)parted, it will create the versions with the 'p' and so the system should also boot that way. I guess somehow the change fixing that in the multipath-tools package never got merged into Debian.
Failure analysis ---------------- I've looked through the output from comment 11. The root cause of LVM not working on top of DMRaid in this case [1] is that LVM is fundamentally not compatible with multiple distinct block devices referring to the same set of blocks. [1] GParted compiled without --enable-libparted-dmraid on Ubuntu 12.04 LTS which then results in GParted creating a second partition specific block device using dmraid (and device-mapper). See how dmsetup ls reports the two different names use two different minor numbers. isw_efjbbijhh_Vol05 (252, 3) isw_efjbbijhh_Vol0p5 (252, 2) And the device entries in the file system reflect this: symlink /dev/mapper/isw_efjbbijhh_Vol05 -> ../dm-3 blockdev 252, 3 /dev/dm-3 symlink /dev/mapper/isw_efjbbijhh_Vol0p5 -> ../dm-2 blockdev 252, 2 /dev/dm-2 LVM requires UUIDs to be unique, but with two different block devices showing exactly the same set of blocks LVM rightly thinks the UUID has been duplicated. This causes lvm pv to flip-flop between reporting the block device containing the PV as on /dev/dm-2 and /dev/dm-3. LVM and multipath devices ------------------------- Question this is how does LVM work with multipath devices where /dev/mapper/mpathX wraps 2 or 4 /dev/sdY devices? A filter is added to /etc/lvm/lvm.conf to prevent LVM from scanning /dev/sd* devices so that it only sees each LVM UUID once via the /dev/mapper/mpathX devices. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/DM_Multipath/multipath_logical_volumes.html Solutions - not yet ------------------- It would be nice if a programmatic way to make GParted always work, without requiring the builder to manually choose to use --enable-libparted-dmraid or not. At the moment I don't know because there are too many combinations of DMRaid partition naming conventions, libparted expected conventions across too many versions of distributions. More testing required ... Mike
Created attachment 327058 [details] GParted 0.26.0 compiled with --enable-libparted-dmraid on Kubuntu 12.04 LTS with DMRaid and LVM2 PV This problem is going to be tougher to solve than we all thought. Even with ideal conditions there will be more than one mapping to the partition path. For example: isw_efjbbijhh_Vol0p5 -> ../dm-2 The attached screenshot from kubuntu 12.04 LTS with native libparted 2.3 and dmraid 1.0.0.rc16-4.1ubuntu8 using GParted compiled with --enable-libparted-dmraid still exhibits the issue. # ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Apr 29 15:42 control lrwxrwxrwx 1 root root 7 Apr 29 15:42 isw_efjbbijhh_Vol0 -> ../dm-1 lrwxrwxrwx 1 root root 7 Apr 29 15:42 isw_efjbbijhh_Vol0p1 -> ../dm-0 lrwxrwxrwx 1 root root 7 Apr 29 15:42 isw_efjbbijhh_Vol0p5 -> ../dm-2 # src/gpartedbin ====================== libparted : 2.3 ====================== # ls -l /dev/mapper total 0 crw------- 1 root root 10, 236 Apr 29 15:42 control lrwxrwxrwx 1 root root 7 Apr 29 15:44 isw_efjbbijhh_Vol0 -> ../dm-1 lrwxrwxrwx 1 root root 7 Apr 29 15:44 isw_efjbbijhh_Vol0p1 -> ../dm-0 lrwxrwxrwx 1 root root 7 Apr 29 15:44 isw_efjbbijhh_Vol0p5 -> ../dm-2 At the moment I can't see a way to get rid of the duplicate mapping in /dev/mapper and /dev/dm-*. Curtis
According to the LVM guys, the /dev/mapper name is the preferred one, and the /dev/dm-x is internal to the kernel. IIRC, parted notices that the dev_t major number corresponds to devmapper, and when it does, takes the minor number, and uses it to build a /sys/block/dm-x path, and in there is a file that lists the device name. That is then appended to /dev/mapper/ to generate the preferred device name, and onto that is appended 'pN' for the partition device. This works no matter what name is given to parted, and whether the distro has /dev/mapper/ as a symlink to /dev/dm-x, or the other way around.
Hi Curtis, It it *CRUCIAL* to differentiate between block devices and symbolic links to block devices. # ls -l /dev/sd* /dev/dm-* brw-rw---- 1 root disk 252, 0 Apr 30 09:26 /dev/dm-0 brw-rw---- 1 root disk 252, 1 Apr 30 09:26 /dev/dm-1 brw-rw---- 1 root disk 252, 2 Apr 30 09:26 /dev/dm-2 brw-rw---- 1 root disk 8, 0 Apr 30 09:26 /dev/sda brw-rw---- 1 root disk 8, 1 Apr 29 23:11 /dev/sda1 brw-rw---- 1 root disk 8, 2 Apr 30 09:26 /dev/sda2 brw-rw---- 1 root disk 8, 5 Apr 29 23:11 /dev/sda5 brw-rw---- 1 root disk 8, 16 Apr 30 09:26 /dev/sdb brw-rw---- 1 root disk 8, 32 Apr 30 09:26 /dev/sdc A block device is a pair or numbers (major, minor device numbers) which the kernel and its' device drives use to refer to a sequence of sectors. Block devices provide access to whole disks, partitions of disks, Device-Mapper (DMRaid, LVM, crypt/LUKS) block mapping, Multiple Devices (mdadm/swraid) block mappings, loop devices and partitions of block devices. # ls -l /dev/mapper/* crw------- 1 root root 10, 236 Apr 29 23:11 /dev/mapper/control lrwxrwxrwx 1 root root 7 Apr 30 09:26 /dev/mapper/isw_cgahfjhcdb_MyArray0 -> ../dm-0 lrwxrwxrwx 1 root root 7 Apr 30 09:26 /dev/mapper/isw_cgahfjhcdb_MyArray0p1 -> ../dm-1 lrwxrwxrwx 1 root root 7 Apr 30 09:26 /dev/mapper/isw_cgahfjhcdb_MyArray0p2 -> ../dm-2 A symbolic link is just a name in the file system referring to another name in the file system. In this case just another name for the same block devices. Case #1: Multiple block devices (each with symlinks) (Everything in this bug report from the beginning to comment 16). GParted compiled *WITHOUT* --enable-libparted-dmraid so it creates a second Device-Mapper block device resulting in 2 different Device-Mapper block devices referring to the same sequence of blocks. LVM is coded under the very valid assumption that all block devices refer to unique ranges of sectors and that finding duplicate UUIDs means the user/administrator has copied the contents. This is what caused LVM to report duplicate UUIDs. LVM uses UUIDs to identify the components and allow for activation of the Volume Groups even if the underlying disks are discovered and named in a different order. For example because they were plugged into different connectors, or there are multiple controllers being scanned in parallel during boot, etc. This case also has symlinks pointing to block devices. Discussed in detail in case #2. Case #2: Single block device with symlinks (As reported in comment 17. Debugged and confirmed). GParted compiled *WITH* --enable-libparted-dmraid so there is only *ONE* Device-Mapper block device but also with the preferred user space symlink name in /dev/mapper. Now when GParted runs it is using whole disk device: /dev/mapper/isw_efjbbijhh_Vol0 and via blkid identifies partition number 5: /dev/mapper/isw_efjbbijhh_Vol0p5 contains an LVM Physical Volume. When GParted tries to get the usage it calls into the LVM2_PV_Info module which runs "lvm pvs" to get the list of known LVM PVs. # lvm pvs PV VG Fmt Attr PSize PFree /dev/dm-3 lvm2 a- 10.00g 10.00g However (perhaps because this is an older version of LVM) it reports the block device name as /dev/dm-2, rather than the now preferred Device-Mapper name of /dev/mapper/isw_efjbbijhh_Vol0p5. As those two strings aren't the same the LVM2_PV_Info module doesn't find the the PV and reports unknown space usage. So this is just a case of the lvm command reporting the actual block device name rather than the preferred symlink name. This is exactly the same case with btrfs on top of crypt-LUKS as found on CentOS 6 and in a corner case on Fedora 23 (in bug 760080 comment 1). Btrfs and /proc/mounts are reporting the /dev/dm-X block device name rather than the preferred Device-Mapper symlink name of /dev/mapper/NAME. Solution for case #2: I will be fixing this. Need to change GParted to stop using just string compare to determine device equality and instead allow symlinks to match with the block devices to which they point. Currently Proc_Partition_Info loads names from /proc/partitions and follows all symlinks loading this into a cache. Any additional names are then used for checking busy status of mounted file system only and displaying in the UI as additional names. Thinking of extending this to also load Device-Mapper symlink names and then using everywhere device paths are compared for equality. To resolve the bugs matching this case #2, it would be in btrfs multi-device membership and LVM PV device matching. But elsewhere too. Solution for case #1: As discussed above in comment #16, at this time I don't have an answer. Only more research required. It may never be automatically resolved by changes to the build system or runtime code. It may just always have to depend on the person building the code to know what to pick. Mike
Indeed, when comparing devices for equality, you must not use the name, but rather the dev_t of each as returned by stat().
Hi Curtis, Can you do some testing / investigation please. Can you build GParted with --enable-libparted-dmraid and test it on a partitioned DMRaid array. Particularly interested in cases where GParted breaks. When I tried viewing a partitioned DMRaid array, creating a partition and then deleting a partition, I find it works: Distro View Create Delete ------ ----- ------ ------ CentOS 5 Works Works Works Ubuntu 12.04 LTS Works Works Works Debian 8 Works Works Works I get breakages on Debian 6, but then that is a no longer supported distribution. NOTES: 1) I'm actually building GParted from my git HEAD with a stack of patches for this bug report. 2) I'm wondering if DMRaid.cc module can be greatly simplified to the equivalent of what is used with --enable-libparted-dmraid. I.e. just reporting DMRaid array names without any calls to "dmraid" command to stop and start arrays, etc. Thanks, Mike
Hi Mike, Shall I test using the latest GNOME git master? Regarding Debian, one issue I encountered is with DMRAID devices that end with a digit (isw_efjbbijhh_Vol0). On boot Debian creates partitions simply by appending the partition number (isw_efjbbijhh_Vol01). When GParted with --enable-libparted-dmraid is started, it did not see the partition as existing because it expects to see the partition with the letter "p" and the partition number appended (isw_efjbbijhh_Vol0p1). To test in Debian: 1) Create partition using GParted (with --enable-libparted-dmraid). This should work as expected because libparted creates the entries. 2) Reboot 3) Start GParted (with --enable-libparted-dmraid) and check partition information. IIRC this should fail to see the partition path entry because DMRAID creates the partition entries. Curtis
Hi Curtis, Turns out I was testing with a DMRaid array name ending in a letter on Debian 8. Then it worked. Now that i am testing with an array name ending in a number it breaks as you describe. # dmraid -r /dev/sdd: isw, "isw_jbgeddaei", GROUP, ok, 16777214 sectors, data@ 0 /dev/sdc: isw, "isw_jbgeddaei", GROUP, ok, 16777214 sectors, data@ 0 # dmraid -sa -c isw_jbgeddaei_MyArray0 # ls -l /dev/mapper/ total 0 crw------- 1 root root 10, 236 Jul 9 21:45 control brw-rw---- 1 root disk 254, 0 Jul 9 21:49 isw_jbgeddaei_MyArray0 brw-rw---- 1 root disk 254, 1 Jul 9 21:49 isw_jbgeddaei_MyArray01 brw-rw---- 1 root disk 254, 2 Jul 9 21:49 isw_jbgeddaei_MyArray02 brw-rw---- 1 root disk 254, 3 Jul 9 21:49 isw_jbgeddaei_MyArray03 brw-rw---- 1 root disk 254, 4 Jul 9 21:49 isw_jbgeddaei_MyArray04 Libparted ped_partition_get_path() is reporting partition paths as "/dev/mapper/isw_jbgeddaei_MyArray0p1", hence GParted is reporting warnings and FS commands failing with no such file or directory for the wrong block special name. Rhethorical question: If RedHat and Ubuntu got this working in their oldest supported distros from 2012 and earlier, how come Debian still haven't managed it by now! Mike
I've been wanting to get rid of dmraid.cc since I added --enable-libparted-dmraid, but Curtis wanted to make sure gparted still supports very old distros with very outdated libparted. If Debian oldstable still has not fixed their dmraid, imho, that is there bug and gparted should just encourage anyone running into that problem to use the current stable release that works. I think the number of people that are still running oldstable, on a fakeraid, and then compiling the latest gparted from source is going to be little to nothing, and so not worth worrying about. If you want to keep your system stable enough to still be running oldstable, you aren't very likely to go build the latest gparted from source for fun.
Oh, also, you could just tell anyone doing this that they can fix their broken debian system by modifying their dmraid init.d script to NOT pass the '-p' flag to dmraid, iirc. Also any work around gparted attempts to fix this broken system behavior will not help command line parted or any other libparted clients ( like the debian installer ), which will still suffer from it.
Hi Phillip, It's good to hear from you. The challenge with Debian exists for the latest versions as well. As such we need DMRaid.cc to work with Debian SID which is used as the base distro for GParted Live. If I recall correctly, you created the patch set for the old DMRAID/DMSETUP to correctly handle partition names. If you are able to get your patches into Debian then that would go a long way towards being able to retire DMRaid.cc from GParted. Thanks, Curtis
Ohh, I thought this was fixed in Jessie? I'll take look at it.
Hi Phillip and Mike, I installed Debian Testing (Stretch 9) and performed some testing. On a default install, the FAKE RAID is set up as */dev/md126*. This implies that the DMRAID module is not installed and hence is not handled by DMRAID. I believe that this behaviour is similar to how Linux Software RAID works. After installing *dmraid* and rebooting, the FAKE RAID is set up as */dev/mapper/isw_efjbbijhh_Vol0*. The first partition has the entry */dev/mapper/isw_efjbbijhh_Vol01*. From this testing I can confirm that Phillip's patches to perform the proper partitions naming standards *are not* implemented in Debian Testing DMRAID. Curtis
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at https://gitlab.gnome.org/GNOME/gparted/-/issues/ by following the guidelines at https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).