In the operational results of the calibrate step include the type of the
path GParted is working with, either partition or whole disk device. Do
the same for the create empty partition step too for consistency, even
though it only ever creates partitions. Looks like:
create empty partition
path: /dev/sdb3 (partition)
start: 2099200
end: 4196351
size: 2097152 (1.00 GiB)
calibrate /dev/sdc
path: /dev/sdc (device)
start: 0
end: 1953525167
size: 1953525168 (931.51 GiB)
Makes it explicit to the users what GParted has detected. Helps the
developers when looking at saved results to understand what decisions
were made and why specific steps were performed or not.
Bug 743181 - Add unpartitioned drive read-write support
This enables the Check, Label and New UUID operations to succeed on
whole disk device file systems even when libparted doesn't recognise the
file system.
This benefits reiser4 and lvm2 pv file systems with all versions of
libparted, current version is 3.2, and for nilfs2 with libparted < 2.4.
Bug 743181 - Add unpartitioned drive read-write support
get_device_and_disk() basically calls libparted to get a PedDevice
object representing a disk device and a PedDisk object representing a
partition table. Re-implement get_device_and_disk() using two separate
functions, get_device() and get_disk(), to get one of these objects
each.
No functionality changes with this commit. It enables future commits to
incrementally add support for whole disk devices into GParted without
needing libparted to recognise the contents and create a virtual "loop"
partition table.
Bug 743181 - Add unpartitioned drive read-write support
Enable operations on whole disk devices containing any recognised file
system.
The new partition operation on an empty whole disk device continues to
display the "No partition table found on device /dev/DEVICE" information
dialog.
Specifically unsupported operations:
* Delete -
Deletion of a partition only involves removal of the entry in the
partition table leaving the file system intact on the disk. However
this doesn't work for a whole disk device file system. Instead the
file system signatures would have to be erased which is much more
destructive and virtually impossible to undo. Therefore don't
implement whole disk device file system deletion. Alternatives are
to format the file system to cleared or create a partition table on
the device. Both of these imply overwriting the existing data and
set the expectation that undo is not possible.
* Manage flags -
There's no partition table, so there's no partition, so there's no
flags.
Resize/Move operation is being supported so that a whole disk device
file system can be resized to handle devices which can be resize, such
as those from SANs or Linux Software RAID arrays. The start of the file
system must remain fixed so move won't be allowed.
So far only simple operations work if they don't need libparted support
at all [1], or only need libparted support for the calibrate step AND
the file system on the whole disk device is recognised by libparted [2].
(Needs libparted to provide a "loop" partition, hence the recognition
requirement, so that the calibrate step can successfully read the
virtual "loop" partition table. Doesn't matter whether it's an old
version of libparted and it gets the name of the device wrong as GParted
is already using the whole disk device name anyway).
[1] Operations not needing any libparted support:
Mount on, Unmount, Swapon, Swapoff, Activate and Deactivate
[2] Operations only needing libparted support for the calibrate step:
Check, Label, New UUID
Bug 743181 - Add unpartitioned drive read-write support
Need to be able to take different actions in the GParted_Core partition
manipulation methods and in Win_GParted UI methods to deal with
libparted supported partitions or whole disk devices without a partition
table. Add boolean whole_device to the partition object and set
appropriately to allow for this.
Bug 743181 - Add unpartitioned drive read-write support
As was done with a failed mount operation, include the failed activate/
deactivate command in the error dialog. Two example error dialogs now
look like this:
(-) Could not deactivate swap
# swapoff -v /dev/sdb7
swapoff: /dev/sdb7: swapoff failed: Invalid argument
[ OK ]
(-) Could not unmount /dev/sdb6
# umount -v "/mnt/6"
umount: /mnt/6: not mounted
[ OK ]
On RHEL/CentOS 6, GParted fails to mount nilfs2 file system like this:
# mkfs.nilfs2 /dev/sdb1
# mount /dev/sdb1 /mnt/1
mount: you must specify the filesystem type
This fails because mount internally uses libblkid to determine the file
system type when it is not specified on the command line. However on
RHEL/CentOS 6 libblkid is too old to recognise nilfs2.
GParted used libparted recognition first and blkid second. Mount only
uses libblkid. When there are multiple signatures on a partition
GParted may report a different result to blkid alone. Therefore fix by
first trying to mount the file system without specifying the type, as is
already done, and if that fails, trying specifying the file system type.
This allows GParted to mount nilfs2 file systems.
# mount -t nilfs2 /dev/sdb1 /mnt/1
# mount | fgrep sdb1
/dev/sdb1 on /mnt/1 type nilfs2 (rw,gcpid=30946)
And for unsupported file systems the error dialog from the failed mount
command shows both commands like this:
(-) Could not mount /dev/sdb3 on /mnt/3
# mount -v /dev/sdb3 "/mnt/3"
mount: unknown filesystem type 'reiser4'
# mount -v -t reiser4 /dev/sdb3 "/mnt/3"
mount: unknown filesystem type 'reiser4'
[ OK ]
Bug 742741 - Nilfs2 file system is unusable on RHEL/CentOS 6
Function Utils::get_filesystem_kernel_name() returns the name of the
file system as needed for use in the mount command:
mount -t TYPE DEVICE DIR
Needed because the kernel / mount name is 'hfsplus' where as libparted /
GParted, as reported by Utils::get_filesystem_string(), calls it 'hfs+'.
So far just added debugging when mounting a file system to test the
function works.
# ./gartedbin
======================
libparted : 2.1
======================
DEBUG: (hfsplus) # mount -v /dev/sdb5 "/mnt/5"
DEBUG: (nilfs2) # mount -v /dev/sdb1 "/mnt/1"
Bug 742741 - Nilfs2 file system is unusable on RHEL/CentOS 6
On RHEL/CentOS 6 GParted fails to mount nilfs2 file system. Include the
failing file system mount command in the error dialog so the user knows
what command failed. The error dialog now looks like:
(-) Could not mount /dev/sdc1 on /mnt/1
# mount -v /dev/sdc1 "/mnt/1"
mount: you must specify the filesystem type
[ OK ]
Also stop telling the dialog that the secondary text contains pango
markup as the command line and error message certainly isn't pango
markup text.
Bug 742741 - Nilfs2 file system is unusable on RHEL/CentOS 6
GParted can create a nilfs2 file system on RHEL/CentOS 6, yet both
libparted and blkid are too old to recognise it when created. Add
GParted internal detection of nilfs2 file systems.
Easy way to get the required signature needed to recognise nilfs2 is
using wipefs to report the signature bytes it erases, using a more up to
date distribution. So using CentOS 7:
# mkfs.nilfs2 /dev/sdb1
# wipefs -a /dev/sdb1
/dev/sdb1: 2 bytes were erased at offset 0x00000406 (nilfs2): 34 34
Also from util-linux source libblkid/src/superblocks/nilfs2.c
#define NILFS_SB_MAGIC 0x3434
Bug 742741 - Nilfs2 file system is unusable on RHEL/CentOS 6
For libparted recognised file systems covering the whole disk device,
libparted reports the partition table as "loop". With libparted 3.1 and
earlier, the partition device was reported wrongly as /dev/sdb1, instead
of /dev/sdb, by the ped_partition_get_path() call. This causes GParted
to fail to report file system usage, label and UUID, and busy status.
Also multiple file system tool command errors from using the wrong
device are displayed.
# mkfs.ext4 -L whole-ext4 /dev/sdb
# ./gpartedbin
Example partition errors:
e2label: No such file or directory while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
tune2fs 1.42.8 (20-Jun-2013)
tune2fs: No such file or directory while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
dumpe2fs 1.42.8 (20-Jun-2013)
dumpe2fs: No such file or directory while trying to open /dev/sdb1
Couldn't find valid filesystem superblock.
Unable to read the contents of this file system!
Because of this some operations may be unavailable.
This cause might be a missing software package.
The following list of software packages is required for ext4 file
system support: e2fsprogs v1.41+.
This also breaks most of the manipulation operations, again because it
is using the wrong device name.
Fix by ignoring libparted's "loop" partition table and just let it get
displayed via the "none" partition table mechanism.
Doing this renders the direction taken in bug 683643 to make GParted
work with libparted "loop" partition tables mute, as GParted no longer
works with such partition tables. Instead they are replaced by "none"
partition tables within GParted.
Bug 683643 - Doesn't properly support partitionless drives
https://bugzilla.gnome.org/show_bug.cgi?id=683643
Bug 741430 - GParted cannot recognise LVM signature on unpartitioned
drive
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
Mike Fleetwood