Background:
GParted_Core::calibrate_partition() reloads the partition path name and
boundary to ensure they are correct before the operation is performed.
(See comments in calibrate_partition() for the reasons why this is
necessary). This also displays details of the partition being modified
in the operation details to inform the user.
The operation object contains these relevant member objects:
* partition_original
Partition before the operation is applied.
* partition_new
Partition as it is intended to be after the operation has been
applied.
* partition_copied (for the copy operation only)
Source partition being copied.
Issues:
GParted_Core::apply_operation_to_disk() was always calibrating partition
object partition_original, but for about half the operations
partition_original was not used and partition_new is used, so should be
calibrated instead.
Copy into an existing partition calibrated three partitions, the source,
destination before and destination after the operation was applied.
This doesn't really make sense in the operation details to the user.
They would expect to only see the source and destination partitions and
don't care about the distinction between the before and after
representation of the destination.
Minor issues:
The previous fix had to copy the correct partition path from the
calibrated partition_original object to the used partition_new object
for the format, label file system, name partition and change uuid
operations.
Calibrate was called for the create operation too, even though the
partition didn't yet exist. It was a no-operation.
Fix:
Stop always calibrating the partition_original object and instead
calibrate the correct partition object in each operation case. For the
copy into existing partition operation only calibrate the right two
partition objects as the user would expect.
Bug 746559 - Various operations fail when following paste into existing
partition
Format, label file system and new UUID operations would fail when
applied in a sequence to the destination partition following a previous
copy-paste operation.
Giving the copy of a file system a new label and a new UUID are the sort
of actions which should be performed when the disk containing the copy
remains attached to the same computer. This really should work.
Fragment of the failing operation details for a copy and label operation
sequence:
+ Copy /dev/sdb1 to /dev/sdb2
+ calibrate /dev/sdb2
+ calibrate copy of /dev/sdb1
+ calibrate /dev/sdb1
+ check the file system on /dev/sdb1 for errors and (if possible fix them
+ copy file system of /dev/sdb1 to /dev/sdb2
+ Set file system label "small-dst" on copy of /dev/sdb1
+ calibrate copy of /dev/sdb1
path: /dev/sdb2 (partition)
...
+ set file system label to "small-dst" on copy of /dev/sdb1
+ e2label copy of /dev/sdb1 "small-dst"
Usage: e2label device [newlabel]
This is failing because the file system specific command is passed
"copy of /dev/sdb1" as the device name. Code sequence:
1) OperationCopy::OperationCopy() sets the real path name of the
partition_new object to "copy of /dev/SRC" for display purposes.
2) GParted_Core::apply_operation_to_disk() calls calibrate_partition()
on partition_original object, restoring the real path name for
object partition_original.
3) apply_operation_to_disk() calls format(), label_filesystem() or
change_uuid() on the partition_new object, which still has the real
path name set to "copy of /dev/SRC". File system specific commands
fail with this as a path name.
Fix by copying the real path name from object partition_original to
partition_new, as is already done for the resize/move operation. Also
apply this fix to the name partition operation, because it uses the
partition_new object and so that it displays the real path name in the
operation details.
Bug 746559 - Various operations fail when following paste into existing
partition
When the partition is named in the Create New Partition dialog, set the
partition name as part of the create partition operation. Currently
this is only supported for GPTs. See
Utils::get_max_partition_name_length() for details.
Bug 746214 - Partition naming enhancements
Add a partition name entry box to the Create New Partition dialog. The
entry box is greyed out (not sensitive) for partition table types which
don't support partition naming. Currently only supported for GPTs. See
Utils::get_max_partition_name_length() for details.
There was a slightly wider gap between the file system combobox row and
the label entry row when there were only three widgets on the right hand
side of the dialog. This has been removed now that there are four
widgets so that they are all evenly spaced and they line up with the
four widgets on the left hand side.
So far the partition name can be entered and previewed, but isn't yet
applied to the disk.
Bug 746214 - Partition naming enhancements
Adding a partition name entry to the Create New Partition dialog will
need access to these two Device methods: partition_naming_supported()
and get_max_partition_length(). The Set_Data() function already takes
two parameters, only_unformatted and disktype, taken from Device member
variables.
Rather than add two more parameters to the Set_Data() function pass the
Device object instead, replacing the current only_unformatted and
disktype parameters.
Bug 746214 - Partition name enhancements
This is a small tidy-up to remove Gtk::Entry method calls on the file
system label entry box in the Create New Partition dialog which serve no
purpose.
filesystem_label_entry.set_activates_default( true );
It trying to make the Create New Partition dialog automatically
close when Enter is pressed with focus in the label entry box.
However this doesn't work, presumably because the default widget for
the dialog is not the Add button. Remove.
filesystem_label_entry.set_text( partition.get_filesystem_label() );
Initialises the text in the entry box with the file system label
from the passed partition object. The label is blank and the entry
box defaults to blank. Achieves nothing. Remove.
filesystem_label_entry.select_region( 0, filesystem_label_entry.get_text_length() );
Highlights the empty text in the entry box. Achieves nothing.
Remove.
NOTE:
The same set of Gtk::Entry method calls in Dialog_FileSystem_Label() and
Dialog_Partition_Name, which are editing the existing file system label
and partition name respectively, do work and have a useful effect so
shouldn't be removed.
Rename Gtk::Entry object entry -> filesystem_label_entry in the
Dialog_Partition_New class. This is in preparation for the introduction
of the partition name entry box in the Create New Partition dialog.
Bug 746214 - Partition name enhancements
Preview of the format operation cleared the partition name, yet when
applied, the partition name reappeared. Fix the preview to reflect
reality.
Bug 746214 - Partition naming enhancements
Previously partition naming had only been implemented for gpt. Make the
code ready to support naming of the other partition table types for
which libparted supports naming. Specifically: amiga, dvh, mac and
pc98 in addition to gpt. Document issues found with some of these
partition table types, which can relatively easily been worked around.
Leave support of naming for partition table types other than gpt
disabled, mostly just to reduce ongoing testing effort, at least until
there is any user demand for it.
Bug 746214 - Partition naming enhancements
Allow partition names to be changed whether or not the partition is
busy, rather than only when not busy, because it doesn't effect the busy
file system or change the partition boundaries in any way.
Bug 746214 - Partition naming enhancements
Attempting to create a new partition on a pc98 partition table fails
with the following libparted error:
The flag 'lvm' is not available for pc98 disk labels.
This has been broken since LVM2 Physical Volume read-write support was
first added in this commit:
c3ab62591b
Add creation of LVM2 PVs (#670171)
Fix by only clearing and setting the lvm partition flag when the type of
the partition table supports it. When creating a partition to contain
an LVM2 PV and the lvm flag is not support add the following message to
the operation results to explain that setting the lvm partition flag was
skipped and why:
Skip setting unsupported partition flag: lvm
Bug 746204 - Creating partitions on pc98 table fails with lvm flag not
available
Refactor GParted_Core::set_partition_type().
1) Set lp_partition variable earlier and use a single if lp_partition
set condition, rather than in both if conditions for the normal file
system case and the LVM2 Physical Volume case.
2) Stop calling Utils::get_filesystem_string() multiple times, instead
save the result in a local variable.
Tidies the code a little and reorders it in preparation for the
following fix to only set the lvm partition flag when support, making
that code change simpler.
Bug 746204 - Creating partitions on pc98 table fails with lvm flag not
available
In order to prevent potential corruption of newly created file systems,
when available use udisks2-inhibit with gpartedbin execution to prevent
automounting.
Original report:
Xubuntu install fail due partition auto mount defeats Gparted
https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1078445
Some GNU/Linux distributions use the udisks2 "udisksd" daemon and have
udisks2-inhibit at a known location. The known location is not in the
default PATH environment variable.
One known distribution that matches this criteria is xubuntu 14.04.
Interestingly neither kubuntu 14.04 nor ubuntu 14.04 appear to have the
udisks2 "udisksd" daemon running and do not suffer from this specific
automounting problem.
Bug 745349 - gparted wrapper script needs updated for udisks2
GParted now recognizes file system formats on disk devices without
partition tables. Update the manual with:
- how to format a disk device without a partition table
- manage flags not available for devices without partition tables
- use format to cleared to delete a file system from an unpartitioned
disk
Bug 743181 - Add unpartitioned drive read-write support
resize_move() and move() stopped using the device parameter in this
commit from 2006-07-23:
d663c3c277
removed cylindersize buffering during resize from the filesystems. It is
create() stopped using the device parameter in this commit from 2006-03-19:
ad9f2126e7
fixed issues with copying (see also #335004) cleanups + added FIXME added
For reference most other operation methods had the device parameter
removed in this earlier commit from 2005-12-07:
642f0a145b
from now on each partition has a reference to it's device. make use of new
When the following conditions were met GParted would fail to recognise a
newly created whole disk device file system, and instead show an unknown
file system filling the disk:
1) Disk was previously partitioned and contained at least one partition.
2) Using libparted version 2.0 to 3.0 inclusive.
Initial status:
# blkid | fgrep sdc
# fgrep sdc /proc/partitions
8 32 976762584 sdc
8 33 104857600 sdc1
# parted /dev/sdc
GNU Parted 2.4
Using /dev/sdc
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1049kB 107GB 107GB primary
When creating the loop partition table libparted would not inform the
kernel to delete the old partitions. /proc/partitions still contained
the details of the old partitions.
(parted) mktable loop
Warning: The existing disk label on /dev/sdc will be destroyed and
all data on this disk will be lost. Do you want to continue?
Yes/No? Yes
(parted) print
Model: ATA ST1000LM024 HN-M (scsi)
Disk /dev/sdc: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: loop
Number Start End Size File system Flags
(parted) quit
# fgrep sdc /proc/partitions
8 32 976762584 sdc
8 33 104857600 sdc1
Creation of the whole disk device file system goes unnoticed by blkid
because the kernel and therefore blkid's cache have stale partition
information.
# mkfs.xfs -f /dev/sdc
# blkid | fgrep sdc
NOTE:
On a Linux Software RAID array, as opposed to a hard disk, blkid does
notice creation of the whole disk device file system. However the
kernel still has old partition details.
This was fixed in libparted 3.1 by commit:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=f5c909c0cd50ed52a48dae6d35907dc08b137e88
libparted: remove has_partitions check to allow loopback partitions
Fix by deleting old partitions before creating the loop table when
compiled with a broken version of libparted. The GParted UI provides
no feedback while a new partition table is created, and with some
versions of GTK the UI become unresponsive too, so it is important to be
as fast as possible. Evaluated three different methods, deleting 15 and
22 MSDOS partitions on a physical 5400 RPM hard drive using libparted
2.4:
M1) Delete and commit one partition at a time.
Takes up to 24 seconds to delete 15 partitions. With 22 partitions
libparted always reports finding some of the partitions busy and
unable to inform the kernel about the modifications.
Too slow and doesn't work.
M2) Delete all partitions in one go and commit once.
Takes up to 1.4 seconds to delete either 15 or 22 partitions. Never
removes partitions 17 and higher from the kernel.
Doesn't work.
M3) Write GPT table (letting libparted delete any old partitions).
Takes up to 0.8 seconds to delete either 15 or 22 partitions.
Fast and works.
Use method 3 - write a GPT table thus using libparted code to inform the
kernel of the old partition deletions.
Bug 743181 - Add unpartitioned drive read-write support
Older versions of blkid don't correctly distinguish between FAT16 and
FAT32 file systems when overwriting one with the other. This effects
GParted too with these file systems on whole disk devices where only
blkid is used to recognise the contents. See previous fix for why only
blkid is used in this case:
Avoid whole disk FAT being detected as MSDOS partition table
(#743181)
Example:
# blkid -v
blkid from util-linux 2.20.1 (liblkid 2.20.0, 19-Oct-2011)
# mkdosfs -F16 -I /dev/md1
# blkid | fgrep md1
/dev/md1: SEC_TYPE="msdos" UUID="7C23-95D9" TYPE="vfat"
# mkdosfs -F32 -I /dev/md1
# blkid | fgrep md1
/dev/md1: SEC_TYPE="msdos" UUID="7F93-98F4" TYPE="vfat"
So blkid recognised the UUID changed but didn't remove the SEC_TYPE for
the FAT32 file system. See FS_Info::get_fs_type() as it uses this to
distinguish between FAT16 and FAT32. This is a caching update bug in
blkid, because telling blkid not to use the cache gets the right
results:
# blkid -c /dev/null | fgrep md1
/dev/md1: UUID="7F93-98F4" TYPE="vfat"
With testing determined that blkid from util-linux 2.23 and later are
not affected and earlier versions are affected. Mostly recently known
affected distribution is Ubuntu 14.04 LTS with util-linux 2.20.1.
The straight forward fix would be to instruct blkid to not use its cache
with 'blkid -c /dev/null'. But using blkid's cache is needed to prevent
blkid hanging for minutes when trying to access a non-existent floppy
drive when the BIOS is set incorrectly. See commit:
18f863151c
Fix long scan problem when BIOS floppy setting incorrect
Instead, when using an older affected version of blkid and when blkid
cache reports a vfat file system, run blkid again bypassing the cache.
The device is known to exist and contain a vfat file system, just not
whether it is a FAT16 or FAT32 file system, so can't be a non-existent
floppy device and won't hang.
Bug 743181 - Add unpartitioned drive read-write support
Libparted 1.9.0 to 2.3 inclusive, recognises whole disk device FAT file
systems as MSDOS partition tables. This causes GParted to do the same.
# dd if=/dev/zero bs=1M of=/dev/md4
# mkdosfs -F32 -v -I /dev/md4
# blkid /dev/md4
/dev/md4: UUID="53FE-31F2" TYPE="vfat"
# parted /dev/md4
GNU Parted 2.1
Using /dev/md4
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Unknown (unknown)
Disk /dev/md4: 536MB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
(parted) quit
# /tmp/parted24/bin/parted /dev/md4
GNU Parted 2.4
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Linux Software RAID Array (md)
Disk /dev/md4: 536MB
Sector size (logical/physical): 512B/512B
Partition Table: loop
Number Start End Size File system Flags
1 0.00B 536MB 536MB fat32
(parted) quit
This was fixed in libparted 2.4 by commit:
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=616a2a1659d89ff90f9834016a451da8722df509
libparted: avoid regression when processing a whole-disk FAT partition
Make GParted immune to this bug by moving blkid performed whole disk
device file system detection before libparted partition detection. Also
have to always erase old file system signatures on whole disk devices
when creating new partition tables to ensure that blkid doesn't detect
those old signatures before libparted has a chance to detect the new
partition table.
Bug 743181 - Add unpartitioned drive read-write support
When writing "loop" partition table over the top of some whole disk
device file system types GParted continued to show those whole disk
device file systems rather than the virtual unknown partition from the
"loop" partition table.
This affected btrfs, jfs, reiser4 and reiserfs. It occurred because of
several factors:
1) Libparted only zeroed the first and last 9.5 KiB (assuming 512 byte
sectors) of the device before writing a new partition table. See
ped_disk_clobber().
2) These file systems have their super blocks and therefore signatures
after the first 9.5 KiB.
3) Whole disk device file system detection is performed using blkid
before checking for a libparted "loop" partition table. See
GParted_Core::set_devices_thread().
Ref:
libparted 3.2: disk.c:ped_disk_clobber()
http://git.savannah.gnu.org/cgit/parted.git/tree/libparted/disk.c?id=v3.2#n302
Fix by always erasing any possible file system signatures on the device
before creating a new "loop" partition table.
NOTE:
This is typically taking up to 0.5 seconds in my testing on a 5400 RPM
hard drive, during which time the GParted UI is hung and the create
partition table dialog shows the apply button pressed but no other
progress indication.
Bug 743181 - Add unpartitioned drive read-write support
Creating a new partition table was getting libparted to read any
existing partition table before creating a new partition table on the
device. This is an unnecessary step, and if the device didn't already
contain a partition table also printed this error from libparted:
/dev/sdb: unrecognised disk label
Since get_device_and_disk() has been split into two, just call
get_device() instead to just populate the PedDevice object representing
the disk device. Removes a small unnecessary step.
Bug 743181 - Add unpartitioned drive read-write support
The preview of clearing a whole disk device file system was previewing
the same as formatting to all other file system types; as a cleared file
system spanning the whole disk device. However when implemented this
removes all signatures on the disk so it actually becomes an unallocated
and unpartitioned device. Make the preview match what happens in when
implemented.
GParted previously used mydevice.max_prims = -1 to represent an
unpartitioned device. It is now represented as:
mydevice.max_prims = 1
mydevice.disktype = _("unrecognized")
mydevice.partitions[0].type = TYPE_UNALLOCATED
mydevice.partitions[0].whole_device = true
mydevice.partitions[0].filesystem = FS_UNALLOCATED
and the check for an unpartitioned device in Win_GParted.cc becomes:
partitions[0].type == TYPE_UNALLOCATED && partitions[0].whole_device
Bug 743181 - Add unpartitioned drive read-write support
Previously GParted displayed a device containing the parted "loop"
partition table signature "GNU Parted Loopback 0" and nothing else, as
an unrecognised device.
Now make GParted display this as a virtual whole disk device partition
with unknown contents, complete with the unable to detect a file system
warning. This change then allows a whole disk device file system to be
created with the following two steps:
1) Create "loop" partition table on a device;
2) Format to required file system.
GParted represents a whole disk device file system as:
mydevice.max_prims = 1
mydevice.disktype = "none"
mydevice.partitions[0].type = TYPE_PRIMARY
mydevice.partitions[0].whole_device = true
mydevice.partitions[0].filesystem = FS_EXT4 (example)
Now represents just Parted's "loop" signature as:
mydevice.max_prims = 1
mydevice.disktype = "loop"
mydevice.partitions[0].type = TYPE_PRIMARY
mydevice.partitions[0].whole_device = true
mydevice.partitions[0].filesystem = FS_UNKNOWN
And as before, an unpartitioned device as:
mydevice.max_prims = -1
mydevice.disktype = _("unrecognized")
mydevice.partitions[0].type = TYPE_UNALLOCATED
mydevice.partitions[0].whole_device = true
mydevice.partitions[0].filesystem = FS_UNALLOCATED
Bug 743181 - Add unpartitioned drive read-write support
Only allow resizing, not moving of a whole disk device file system.
There is no actual partition to move and moving a file system away from
the start of a disk only makes it unrecognisable.
Also don't perform the partition resize step as there's no actual
partition to be resized. Only the file system is being resized.
(Libparted actually allows the virtual partition spanning a whole disk
device to be resized, implementing it as a no-operation, but only for
recognised file systems. For unrecognised file systems it fails with
"unrecognised disk label").
Note that the existing resize dialog was designed for resizing partition
boundaries, and their contained file systems, not for resizing file
systems within a fixed boundary. The difference is noticeable when
there is unallocated space because the file system doesn't fill the
whole disk device. The dialog starts resizing a virtual partition the
size of the whole disk device, not the actual size of the file system.
Leave addressing this for a possible future update.
Bug 743181 - Add unpartitioned drive read-write support
GNOME Translation Robot