Implemented the second half of the solution described in the previous
commit. Resolve UUID= and LABEL= references when searching in the
Mount_Info cache so that mount points of encrypted file systems listed
in /etc/fstab can be found using the later added FS_Info details.
Closes#162 - It is no longer possible to mount a LUKS encrypted file
system
ISSUE DETAILS
GParted no longer enables Partition > Mount on, for unmounted encrypted
file systems listed in /etc/fstab.
Steps to reproduce:
1. Create LUKS mapping and open.
# cryptsetup luksFormat /dev/sdb1 -
# cryptsetup luksOpen /dev/sdb1 sdb1_crypt
2. Create any file system.
# mkfs.ext4 /dev/mapper/sdb1_crypt
# uuid=`blkid -o value -s UUID /dev/mapper/sdb1_crypt`
3. Add /etc/fstab entry.
# mkdir /mnt/1
# echo "UUID=$uuid /mnt/1 ext4 defaults 0 0" >> /etc/fstab
4. Run GParted and try Partition > Mount on.
With GParted >= 1.3 no mount point is available. With GParted <= 1.2
mount point /mnt/1 is available.
EXPLANATION
Up until GParted 1.2.0 it worked like this:
1. Ran blkid and loaded the details for every file system into the
FS_Info cache. This included results for file systems in open LUKS
mappings, such as /dev/mapper/sdb1_crypt in the above example.
2. Read /etc/fstab, resolved UUID= and LABEL= references into block
device names and added those into the Mount_Info cache.
3. Looped through all partitions adding mount points known by the
Mount_Info cache.
After the changes for issue #131 "GParted hangs when non-named device is
hung" and issue #148 "Encrypted file systems are no longer recognised"
it works like this instead:
1. Runs blkid for specified devices and partitions only and loads file
system details into the FS_Info cache. Does not include open LUKS
mappings so no results for those file systems.
2. Loading of /etc/fstab into the Mount_Info cache is unable to resolve
UUID= and LABEL= references for file systems in LUKS mappings, so
they aren't included.
3. No mount points known for encrypted file systems.
Note that currently when an encrypted file system is added into the data
model it extends the FS_Info cache <2>, but this is after the Mount_Info
cache has been loaded <1>. Call flow is like this:
GParted_Core::set_devices_thread()
FS_Info::clear_cache()
FS_Info::load_cache_for_paths()
1> Mount_Info::load_cache()
...
set_device_from_disk()
set_device_one_partition() / set_device_partitions()
set_luks_partition()
detect_filesystem_in_encryption_mapping()
2> FS_Info::load_cache_for_paths()
...
set_mountpoints()
partition.add_mountpoints(Mount_Info::get_fstab_mountpoints())
SOLUTION
Also save unresolved UUID= and LABEL= references from /etc/fstab into
the Mount_Info cache. Then when searching the Mount_Info /etc/fstab
cache resolve encountered UUID= and LABEL= references.
THIS COMMIT
Also save unresolved UUID= and LABEL= references into the Mount_Info
cache.
Closes#162 - It is no longer possible to mount a LUKS encrypted file
system
E2label works the same way whether an ext2/3/4 file system is mounted or
not, by directly reading and writing the superblock from the partition
block device. (Technically the superblock will already be in the kernel
device buffer cache because the kernel has the ext2/3/4 file system
mounted and a reference to the superblock in the device buffer cache).
This is safe and supported as confirmed here [1]. As this method has
always worked, even on the oldest distributions, unconditionally enable
this feature.
# mkfs.ext4 -L label_1 /dev/sdb3
# mount /dev/sdb3 /mnt/3
# e2label /dev/sdb3 label_2
# blkid /dev/sdb3
/dev/sdb3: LABEL="label_2" ...
[1] Is labelling a mounted ext2/3/4 file system safe and supported?
https://lore.kernel.org/linux-ext4/CAMU1PDgNvW_3Jr91iii-Nh=DCuRytVG8ka3-J+a43gKwigx8Yg@mail.gmail.com/T/#u
Bug 600496 - Allow changing ext2/3 label without unmounting
Closes#163 - Feature request: set label on a mounted btrfs
XFS also supports labelling of the file system while it is mounted.
This was added into Linux kernel 4.18 [1] and xfsprogs 4.17.0 [2].
These versions are newer than available in older but still supported
distributions so we'll need to detect versions before enabling support.
These are the oldest releases of distributions which meet the
requirements.
Distro EOL Linux kernel xfsprogs
Debian 10 2024-Jun 4.19.0 4.20.0
RHEL 8 2029-May 4.18.0 5.0.0
Ubuntu 20.04 LTS 2030-Apr 5.4 5.3.0
As with btrfs a mounted XFS is labelled via it's mount point:
# mkfs.xfs -L label_1 /dev/sdb2
# mount /dev/sdb2 /mnt/2
# xfs_io -c 'label -s mnt_label_2' /mnt/2
label = "mnt_label_2"
# blkid /dev/sdb2
/dev/sdb2: LABEL="mnt_label_2" ...
And cleared with:
# xfs_io -c 'label -c' /mnt/2
label = ""
Note that in some error situations xfs_io reports exit status zero and
writes the failure message to stdout.
# xfs_io -c 'label -s "mnt label 3"' /mnt/2
bad argument count 4 to label, expected between 0 and 3 arguments
# echo $?
0
Therefore determine success based on stdout starting with 'label = "'
reporting the new label or not.
Also note that as seen in this failure case, it is not possible to set
an XFS label which contains a space character using xfs_io. However
that is nothing new as that can't be done using the existing xfs_admin
command for an unmounted XFS either.
# umount /mnt/2
# xfs_admin -L 'umnt label 4' /dev/sdb2
Usage: xfs_admin [-efjlpuV] [-c 0|1] [-L label] [-U uuid] device
# echo $?
2
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f7664b31975bd893190708e76b2c424328f0c49b
xfs: implement online get/set fs label
[2] https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git/commit/?id=cfa10b0f972005b38ed294bca66cebf2f65298ec
xfs_io: add label command
Closes#163 - Feature request: set label on a mounted btrfs
Show support for online labelling using a second tick mark in the
Features dialog. This matches how online grow and shrink are shown.
Closes#163 - Feature request: set label on a mounted btrfs
Btrfs supports labelling of the file system while it is mounted. This
was added into Linux kernel 3.10 [1] and btrfs-progs 3.12 [2]. As the
oldest supported distributions have the needed versions or newer,
unconditionally enable without any checking for availability.
Distro EOL Linux kernel btrfs-progs
Debian 9 2022-Jun 4.19 4.7.3
RHEL / CentOS 7 2024-Jun 3.10.0 4.9.1
Ubuntu 18.04 LTS 2023-Apr 4.15.0 4.15.1
Unmounted btrfs is labelled via the block device containing it, where as
a mounted btrfs is labelled via it's mount point.
# mkfs.btrfs -L initial_label /dev/sdb1
# blkid /dev/sdb1
/dev/sdb1: LABEL="initial_label" ...
# btrfs filesystem label /dev/sdb1 unmounted_label_2
# blkid /dev/sdb1
/dev/sdb1: LABEL="unmounted_label_2" ...
# mount /dev/sdb1 /mnt/1
# btrfs filesystem label /dev/sdb1 mounted_label_3
# blkid /dev/sdb1
/dev/sdb1: LABEL="mounted_label_3" ...
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a8bfd4abea3da0e28f215e2a2b8c2f1ca27ebe80
Btrfs: set/change the label of a mounted file system
[2] https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git/commit/?id=619dc61cae1420da2dec48f689d49b9b346abc15
Btrfs-progs: Change the label of a mounted file system
Closes#163 - Feature request: set label on a mounted btrfs
For the same reason as in the previous commit, the UUID is copied when
copying every file system type except for XFS, where a new XFS is
created with a new UUID.
Again preview of the copy operation expects the UUID to be copied.
(Look in Partition > Information of the source and pasted partitions
before the operation is applied).
Fix as before by specifying the desired file system UUID when creating
the new XFS as part of the copy operation.
However there is an extra complication. The XFS kernel driver refuses
to mount a file system with a duplicate UUID of an already mounted XFS.
# mkfs.xfs -L xfs_copy /dev/sdb1
# mount /dev/sdb1 /mnt/1
# tail -2 /var/log/messages
Jun 3 21:41:24 localhost kernel: XFS (sdb1): Mounting V5 Filesystem
Jun 3 21:41:24 localhost kernel: XFS (sdb1): Ending clean mount
# /dev/sdb1: LABEL="xfs_copy" UUID="d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8" TYPE="xfs"
# mkfs.xfs -L xfs_copy -m uuid="d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8" /dev/sdb2
# mount /dev/sdb2 /mnt/2
mount: wrong fs type, bad option, bad superblock on /dev/sdb2,
missing codepage or helper program, or other error.
In some cases useful info is found in syslog - try
dmesg | tail or so.
# echo $?
32
# tail -1 /var/log/messages
Jun 3 21:41:31 localhost kernel: XFS (sdb2): File system has duplicate UUID d654fc7f-e417-4ec6-88e8-8a7d0d46b7d8 - can't mount
Handle this specifying the needed option [1] when mounting the second
XFS during the copy.
# mount -o nouuid /dev/sdb2 /mnt/2
# mount | grep /dev/sdb
/dev/sdb1 on /mnt/1 type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
/dev/sdb1 on /mnt/1 type xfs (rw,relatime,seclabel,nouuid,attr2,inode64,noquota)
Duplicating the UUID may seem troublesome, but it is being done:
1. To make the GParted copied XFS be as much a clone as possible, to
match what is does with other file systems.
2. It has a valid use case; of cloning a Linux installation to a new
drive or restoring a partition image backup. In these cases it is
much simpler if the UUID of the copy remains the same because it
avoids having to edit GRUB2 configuration and fstab file system
mounting which is nearly always done via UUID.
3. GParted has the new UUID operation, to change the UUID for cases
when a copied file system needs to be mounted at the same time as
the source.
[1] xfs(5) - xfs - layout, mount options, and supported file attributes
for the XFS filesystem
https://man7.org/linux/man-pages/man5/xfs.5.html
"MOUNT OPTIONS
...
nouuid Don't check for double mounted file systems using the file
system uuid.
"
Closes!85 - Make XFS copy duplicate the file system label and UUID
As GParted performs block copy of partitions then the label, which is
stored in the file system superblock, is also copied. This is true for
copies performed using the GParted internal block copy and for EXT2/3/4
and NTFS which are copied using the file system specific commands
e2image and ntfsclone respectively. However when an XFS file system is
copied the label is not copied because a new file system is created
using mkfs.xfs and the files copied using xfsdump | xfsrestore.
Preview of the copy operation in GParted also reflects the fact that the
label will be copied.
Fix this by simply specifying the desired label when creating the new
destination XFS.
Closes!85 - Make XFS copy duplicate the file system label and UUID
Debian (and derived) distros with the udisks2 [1] repository and the
additional 'udisks2-inhibit' executable had the location changed from:
/usr/lib/udisks2/
to:
/usr/libexec/udisks2/
with udisks2 version 2.8.4-2 and the following commit:
f6744a33 - Move the daemons to /usr/libexec now that's allowed in the policy
f6744a3364
Distros such as Fedora and openSUSE are unaffected as the udisks [2]
repository does not contain 'udisks2-inhibit'.
[1] udisks2 Debian (and derived) repository
https://salsa.debian.org/utopia-team/udisks2
[2] udisks repository
https://github.com/storaged-project/udisksCloses!84 - Handle change in path for udisks2-inhibit executable
User reported that GParted didn't detect their eMMC drive [1]. Not
recognised device name was /dev/mmcblk0. Confirmed that the regression
was introduced by this commit [2]. Fix the code and regular expression
used to recognise SD/MMC device names.
[1] GParted forum thread: eMMC drive not detected...?
http://gparted-forum.surf4.info/viewtopic.php?id=17994
[2] 52930f30ae
Refactor load_proc_partitions_info_cache() a bit (#131)
Closes!83 - Fix recognition of SD/MMC device names
Mike Fleetwood