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
So far when prompting for the LUKS passphrase the dialog always looks
like this:
+------------------------------------------------+
| LUKS Passphrase /dev/sdb1 |
+------------------------------------------------+
| Enter LUKS passphrase to open /dev/sdb1 |
| Passphrase: [ ] |
| |
| |
| [ Cancel ] [ Unlock ] |
+------------------------------------------------+
Specifically the first line of the dialog says the reason to provide the
passphrase is to open the encryption mapping. Now the passphrase may
also be requested when resizing the encryption mapping, as part of a
resize of check operation, show the appropriate reason in the password
dialog.
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
A check operation involves (1) checking the file system, (2) growing the
encryption volume and (3) growing the file system. Therefore prompt for
the LUKS passphrase as required when composing a check operation too.
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
This is the final piece which enables GParted to pass the LUKS
passphrase when resizing an open LUKS encryption mapping when
'cryptsetup resize' will prompt for it.
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
This is the equivalent to what was previously done when adding opening
of LUKS mappings. Namely to add a way to pass the LUKS passphrase to
'cryptsetup luksOpen' via standard input. Previously the functionality
was added to Utils::execute_command() [1]. Now it is also needed to
pass the LUKS passphrase to 'cryptsetup resize', which is executed as
part of applying resize and check operations to an encrypted file
system. So add this functionality to FileSystem::execute_command().
For now writing to stdin is only needed for the one variant of
FileSystem::execute_command() which doesn't have progress tracking
callbacks. Writing to stdin can easily be added to the other progress
tracking callback variants of execute_command() when needed.
[1] 8dff80edc6
Add ability for small writes to stdin of child processes (#795617)
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
When composing a resize operation on an open encryption mapping, use the
existing LUKS password dialog to prompt for the passphrase, if and only
if 'cryptsetup resize' will prompt and GParted doesn't already have a
password. 'cryptsetup resize' will prompt for a LUKS passphrase when
the passphrase was stored in the kernel keyring service,
key_loc == KEYLOC_KeyRing. See the previous commit "Capture LUKS
mapping master encryption key location (#59)" for more details.
As commented in the code GParted specifically doesn't support the case
where the LUKS passphrase is changed while GParted is running and it
knew the old passphrase. When resizing an open encryption mapping
GParted will just pass the old out of date passphrase it knows and the
resize will fail like this:
# cryptsetup status sdb2_crypt | egrep 'type|key location'
type: LUKS2
key location: keyring
# dmsetup table --target crypt
sdb2_crypt: 0 491520 crypt aes-xts-plain64 :64:logon:cryptsetup:3d040240-97ba-4559-af98-72c3be500498-d0 0 8:18 32768
# echo -n oldpassword | cryptsetup -v --size 491520 resize sdb2_crypt
No key available with this passphrase.
Command failed with code -2 (no permission or bad passphrase).
# echo $?
2
To work around this either close and restart GParted or close and reopen
the encryption mapping. The former because GParted doesn't save
passwords across a restart so will prompt and the latter because GParted
will use the wrong old passphrase to try to open the mapping and then
prompt for the correct passphrase until successfully opened.
Closes#59 - Resize of LUKS2 encrypted file system fails with "Nothing
to read on input"
Curtis Gedak