So that, even though the menu item is greyed out, it is correctly named
Activate or Deactivate for an LVM2 Physical Volume on a whole disk
device, rather than the default Mount or Unmount.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
At this time we are providing read-only support for file systems on
whole disk devices. Also all manipulation operations fail at the
calibrate step with libparted error "unrecognised disk label", and
manage flags is for real partitions only.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
For file systems which libparted recognises, when found on the whole
disk device, it reports with partition table "loop" and a partition
covering the whole disk. GParted duly displays this to the user.
For file systems which libparted doesn't recognise it reports
"unrecognised disk label". As of the latest libparted 3.2, these file
system aren't recognised and can't currently be shown when on the whole
disk device:
BitLocker, Crypt LUKS, exFAT, F2FS, LVM2 Physical Volume,
Linux Software RAID, ReFS, Reiser 4
So only when libparted doesn't recognise a file system on the whole disk
device and GParted does, either via blkid or it's internal code, display
this with partition table "none".
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Move code which queries the file system label and UUID of a partition
into a separate helper function.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Make GParted_Core::get_filesystem() capable of recognising file system
signatures on whole disk devices. Pass NULL for lp_partition to make it
read signatures from the whole disk rather than a specific partition.
Add debugging to test it works.
# fgrep sdb /proc/partitions
8 16 8388608 sdb
# lvm pvcreate /dev/sdb
Writing physical volume data to disk "/dev/sdb"
Physical volume "/dev/sdb" successfully created
# ./gpartedbin
======================
libparted : 1.8.1
======================
Unable to open /dev/sdb - unrecognised disk label.
DEBUG: /dev/sdb (lvm2 pv)
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Used 'fstype' as the name of local variable storing the FILESYSTEM
enumeration type.
'fs_type' was the name of the local variable storing the string with the
name of the file system type. Rename it to 'fsname' to distinguish it
from the aforementioned variable.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Refactor GParted internal file system signature detection to remove code
duplication. There were 5 separate copies of code to: allocate a
buffer, open, read and close the device, free the buffer and compare the
signature.
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
(1) Add recognition of LUKS signatures detected by blkid command, via
the FS_Info cache.
(2) Relocate internal GParted detection of LUKS signature to back after
libparted and blkid identification. This reverses previous commit:
7695593d21
Improve crypt-luks detection (#578300)
Bug 578300 must have been caused by either: (1) reading stale data from
the whole disk device, or (2) formatting as LUKS over the top of ext3
leaving old signatures behind. Case (1) has been resolved by commit:
3bea067596
Flush devices when scanning to prevent reading stale signatures
(#723842)
Re-tested case (2) and find that no old signatures are left behind:
# mkfs.ext3 /dev/sda8
# wipefs /dev/sda8
offset type
----------------------------------------------------------------
0x438 ext3 [filesystem]
UUID: 756dcd5f-73c5-4881-81ee-dc88e8b18f42
# cryptsetup luksFormat /dev/sda8
# wipefs /dev/sda8
offset type
----------------------------------------------------------------
0x0 crypto_LUKS [crypto]
UUID: de15ed1a-f461-46b7-803b-d0fd3b4bd680
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
Trying to create an XFS file system causes the following error and
the create new xfs file system step to never complete.
# ./gpartedbin
======================
libparted : 2.4
======================
(gpartedbin:15572): glibmm-CRITICAL **:
unhandled exception (type Glib::Error) in signal handler:
domain: g-shell-error-quark
code : 0
what : Text ended before matching quote was found for ". (The text was 'mkfs.xfs -f -L "mylabel" " /dev/sdb8')
Creation of XFS file systems was broken by the extra stray double quote
added to the command before the device name, by commit:
63aeb150ac
Rename member variables and methods in Partition class (#741424)
Bug 744108 - Creating an XFS file system never completes
Encountered this dialog:
Libparted Bug Found!
(-) Invalid argument during seek for read on /dev/md1
[ Retry ] [ Cancel ] [ Ignore ]
After investigation found that GParted was asking libparted to read from
sector -1. Libparted was actually reporting an error but GParted was
incorrectly displaying this as a bug. This was because setting the
dialog title was falling through from the error case to the bug case.
Fix this.
Also provide unique titles for all libparted exception types so that
they can all be distinguished.
* List of exceptions from libparted: enum _PedExceptionType
http://www.gnu.org/software/parted/api/group__PedException.html
Bug 743825 - gparted displaying dialog: libparted bug found!
Provide credit for patch to add support for GPT partition names.
Also indicate significant effort by Sinlu Bes while we tried different
ideas for how GPT partition name support should work.
Update the GParted Manual to reflect the change in terminology from
Partition Label to File System Label in the GParted GUI. And make it
explicit that it is the file system label in a partition being changed.
Bug 741424 - Add support for GPT partition names
Embedded devices (Android) use GPT partition names to identify
partitions, instead of file system labels. Add support for viewing and
changing them.
As partition names are used to provide unique identification they are
never copied when copying the contents of one partition to another.
Note that GNU/Linux uses file system labels, UUIDs or device names for
identification during the boot process and afterwards so while partition
names can be used, they are optional and purely for user information.
Bug 741424 - Add support for GPT partition names
This and the following few commits rename variables, methods, classes,
etc from *label_partition* to *label_filesystem* so that the code also
reflects that it is the label of the file system that is being modified
and to separate it from the name partition operation about to be added.
enum OPERATION_LABEL_PARTITION -> OPERATION_LABEL_FILESYSTEM
Bug 741424 - Add support for GPT partition names
Rename the Partition Label concept to File System Label throughout the
GUI. This is to better reflect that it is the label of the file system
that is being modified and to separate it from the Partition Name
concept about to be added.
Bug 741424 - Add support for GPT partition names
GParted reports used figure of active swap space from 4 KiB upwards,
actually 1 page, where as 'swapon -s' reports figures from 0 upwards.
This is because GParted is counting the 1 page swap space overhead as
used space.
# sfdisk -s /dev/sdb1
262144
# mkswap /dev/sdb1
# swapon /dev/sdb1
# swapon -s
Filename Type Size Used Priority
/dev/sdb1 partition 262140 0 -1
For this case GParted reports used as 4 KiB.
(ptn size - swap size = 262144 - 262140 = 4)
Instead make GParted report used figure without any overhead from 0
upwards, matching what 'swapon -s' reports.
Bug 742647 - Swap usage doesn't match figures reported by swapon -s
GParted's internal block copy has an off by one sector bug when the
source is before the destination; and the copy is performed backwards
from high block to low block. It is as though the source and
destination partitions were both one sector earlier on the disk.
In ASCII art it it looks like this:
Initial layout: x<--SRC--><--DST-->
Actually wrote: x<--SRC--
Should have written: <--SRC-->
Affects moving partitions too.
This bug has existed since commit:
bd9e16f22f
Thread the internal copy algorithm (#685740)
Effectively the last sector of the partition is missed and one sector
before the start of the partition is corrupted. Most of the time file
systems don't get around to using the very last sector so didn't notice.
Bug 742920 - GParted internal copy is overstepping partition boundaries
Mike Fleetwood