The setting of the write label capability for linux-swap was lost
when it was overwritten in the following commit:
Add support for setting UUID (#667278)
9e96159bb2
Even if invalid, the first filesystem in list is always included.
This is an off-by-one error, which was triggered when the first member
of FILESYSTEMS was no longer a regular filesystem, as a result of
commit ce9feeda0e9a04da04cec0a1b01512ed68c2495c:
'Make FileSystem objects in GParted_Core accessible and usable by others'
This assumption was invalidated by commit
ce9feeda0e9a04da04cec0a1b01512ed68c2495c:
'Make FileSystem objects in GParted_Core accessible and usable by others'
This patch removes the dependency on this implicit assumption.
Since linux-swap does not contain data and does not have a resize
command, linux-swap is recreated instead of moved, copied, or resized.
GParted 0.11.0 contained the following enhancement:
Bug #663980 - Avoid redundant file system maximize actions
An unfortunate side effect of this change was that the required
maximize action to recreate linux-swap would not occur when the new
size for the partition was less than or equal to the original size.
The changes associated with this commit address this regression.
Closes Bug #670017 - Corrupting swap partitions
Also update to use LVM terminology, such that a Physical Volume is
referred to as a member of a Volume Group. Status of an LVM2 PV is now
displayed using one of the following messages:
Not active (Not a member of any volume group)
VGNAME not active
VGNAME not active and exported
VGNAME active
Bug #160787 - lvm support
GParted would crash if there were any embeded spaces in the output from
the command used to query LVM2 PVs. There aren't normally any embeded
spaces, but they can occur in certain degrated situations. For example
if one of the PVs in a VG spanning two PVs is lost the PV is displayed
as "unknown device" rather than its actual device name:
# lvm pvs --nosuffix --units b --separator , -o pv_name,pv_free,vg_name,lv_name,lv_attr
Couldn't find device with uuid DMEi8r-9Vvy-w0Ok-CSSn-oLmY-YrY3-1PBznz.
PV,PFree,VG,LV,Attr
/dev/sda11,2143289344,GParted-VG1,,
unknown device,1619001344,GParted-VG1,lvol0,-wi---
unknown device,1619001344,GParted-VG1,,
This was loaded into the cache as:
["/dev/sda11,2143289344,GParted-VG1,,",
"unknown",
"device,1619001344,GParted-VG1,lvol0,-wi---",
"unknown",
"device,1619001344,GParted-VG1,,"]
The crash would happen when trying to access the VG name or LV flags on
a line without enough comma separated fields.
Improve parsing of the output from "lvm pvs" so that lines are not split
on embeded spaces. Don't crash on lines without without enough comma
separated fields.
Bug #160787 - lvm support
Previously any errors which occurred when running LVM commands used to
load the LVM2_PV_Info cache were simply ignored and the cache wasn't
loaded. This lead to missing information about LVM2 PVs, but the user
had no indication as to why.
Now when any errors occur the command ran and all output is captured.
This is displayed to the user, along with a suitable warning message, in
the Partition Information dialog.
Bug #160787 - lvm support
Btrfs file system can be successfully resized to the same size without
failing on Linux 3.2 or higher.
Linux 3.2-rc4 includes commit:
35bae54a255fbf3eab747b842d300d59f6e1abb4
Btrfs: Don't error on resizing FS to same size
Closes bug #669389
Create function Utils::kernel_version_at_least() to check that the
current Linux kernel is a particular version or higher.
Update nilfs2 to use this function to determine whether the kernel is
new enough to support file system resizing.
Restructure and word-smith translatable text associated with the
enhancement to add ability for setting UUID in an effort to better
align with the Gnome Documentation Style Guide.
See Bug #667278 - Add support for setting UUID
Determine the FS type before checking whether a FS is busy,
and check LVM only for LVM PVs.
Remove the LVM busy check for extended partitions, as they
don't contain LVM PVs - or any other FS for that matter.
(and even if they did, the rest of the code silently assumes
they don't...)
Previously used "dmsetup info" to directly list device-mapper mapping
names in the kernel to identify active Logical Volumes. However GParted
failed to recognise active LVs if the VGNAME contains any hyphens (-).
This is because LVM encodes hyphens as double hyphens in the mapping
name.
To avoid having to duplicate the LVM hyphen encoding in GParted, switch
to using "lvm lvs" to list LVs.
# dmsetup info --columns --noheadings --separator , -o name
GParted_VG1-lvol_00
GParted--VG2-lvol--00
# lvm lvs --noheadings --separator , -o lv_name,vg_name,lv_attr
lvol_00,GParted_VG1,-wi-a-
lvol-00,GParted-VG2,-wi-a-
lvol-01,GParted-VG3,-wi---
.^.
(-) not active, (a) or any other character considered active. Reference
lvs(8).
Bug #160787 - lvm support
A Volume Group is active when any of its Logical Volume mappings are
loaded (and enabled) in the Kernel's device-mapper driver. Therefore
all the Physical Volumes in the VG (must be considered) active too.
This is exactly equivalent to a mounted file system, as the kernel is
actively using the partition. Mark active LVM2 PVs as busy in GParted.
Don't use statvfs() for determining sector usage of busy LVM2 PVs as it
will fail with "statvfs(VGNAME): No such file or directory". Instead
always use the LVM2 PV specific method.
Display the status of the LVM2 PV in the Information dialog using one of
the following relevant messages:
Not active (Not part of any volume group)
VGNAME not active
VGNAME active
(The code uses the VGNAME stored in the partition's first mount point,
as displayed in the "Mount Point" column, rather than going back to the
primary source of the information in the LVM2_PV_Info class).
Temporarily prevent GParted from offering to unmount LVM2 PVs until
activating and deactivating Volume Groups is implemented later.
Bug #160787 - lvm support
As the Mount Point column is being borrowed to display the PV's VGNAME,
also suppress generation of the "Mount on" submenu for LVM2 PVs.
Bug #160787 - lvm support
Previously when GParted was started LVM2_PV_Info cache was loaded twice,
executing LVM2 PV querying commands twice. Firstly when
lvm2_pv::get_filesystem_support() was checking if LVM2 PV support was
available, and secondly when forced by a refresh in
GParted_Core::set_devices().
Implement lazy initialization. Only load the cache when forced by the
above mentioned refresh or having to return a value when the cache is
not yet loaded. Do not initialize the cache when just checking if LVM2
PV support is available.
Bug #160787 - lvm support
Joe Hansen