GParted automatically enables the Partition > Unmount action for busy
partitions. This is not going to be supported for jbds so disable it.
Closes#89 - GParted doesn't recognise EXT4 fs journal partition
Continuing from the state in the previous commit, create an ext4 file
system using the previously created external journal and mount it.
# mke2fs -t ext4 -J device=/dev/sdb1 -L test-ext4 /dev/sdb2
# mount /dev/sdb2 /mnt/2
Did some experimenting with trying to create a second file system using
the same external journal which is already in use.
# mke2fs -t ext4 -J device=/dev/sdb1 -L 2nd-test-ext4 /dev/sdb3
...
/dev/sdb1 is apparently in use by the system; will not make a journal here!
# exit $?
1
Examined the source code of mke2fs and found that it performs an
exclusive read-only open of the named journal block device to check if
it is in use by the system or not [1]. Use the same method in GParted.
Not used alternative method would be to mark the jbd active when the
ext3/4 file system using it is active, but that requires working out the
linkage between them. That can be done using either blkid or dumpe2fs
output but that involves parsing more fields and caching more data so is
much more code than just testing the block device busy status using the
same method which mke2fs uses.
Matching UUIDs via blkid output.
# blkid /dev/sdb1 /dev/sdb2
/dev/sdb1: LABEL="test-jbd" UUID="6e52858e-0479-432f-80a1-de42f9a4093e" TYPE="jbd"
/dev/sdb2: LABEL="test-ext4" UUID="cea5c2cd-b21c-4abf-a497-8c073bb12300" EXT_JOURNAL="6e52858e-0479-432f-80a1-de42f9a4093e" TYPE="ext4"
Matching UUIDs via dumpe2fs output.
# dumpe2fs -h /dev/sdb1 | egrep 'Filesystem UUID|Journal users'
dumpe2fs 1.46.3 (27-Jul-2021)
Filesystem UUID: 6e52858e-0479-432f-80a1-de42f9a4093e
Journal users: cea5c2cd-b21c-4abf-a497-8c073bb12300
# dumpe2fs -h /dev/sdb2 | egrep 'Filesystem UUID|Journal UUID'
dumpe2fs 1.46.3 (27-Jul-2021)
Filesystem UUID: cea5c2cd-b21c-4abf-a497-8c073bb12300
Journal UUID: 6e52858e-0479-432f-80a1-de42f9a4093e
If GParted was going to show the journal to file system linkage in the
UI then doing this would be needed. However so far there has only been
a single reported case of a GParted user using an external journal,
therefore adding the code complexity for this feature is not currently
justified. The simple busy detection method used by mke2fs is all that
is needed.
[1] mke2fs source code
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/
misc/mke2fs.c:main()
check_mount(journal_device, force, _("journal"));
misc/util.c:check_mount()
ext2fs_check_if_mounted(device, &mount_flags);
lib/ext2fs/ismounted.c:ext2fs_check_if_mounted()
ext2fs_check_mount_point(file, mount_flags, NULL, 0);
lib/ext2fs/ismounted.c:ext2fs_check_if_mounted()
if (stat(device, &st_buf) == 0 &&
ext2fsP_is_disk_device(st_buf.st_mode)) {
int fd = open(device, O_RDONLY | O_EXCL);
if (fd >= 0) {
/*
* The device is not busy so it's
* definitelly not mounted. No need to
* to perform any more checks.
*/
close(fd);
*mount_flags = 0;
return 0;
} else if (errno == EBUSY) {
busy = 1;
}
}
Closes#89 - GParted doesn't recognise EXT4 fs journal partition
A user reported that they were using an external journal with an ext4
file system, but that GParted didn't recognise it. (They had the jbd
on an Intel Optane drive and the ext4 file system on an SSD).
Create a jbd like this:
# mke2fs -O journal_dev -L test-jbd /dev/sdb1
# blkid /dev/sdb1
/dev/sdb1: LABEL="test-jbd" UUID="6e52858e-0479-432f-80a1-de42f9a4093e" TYPE="jbd"
Add recognition of jbd. Use Blue Shadow colour, the same as ext4,
because jbd is primarily used by ext3/4 [1][2]. jbd is also used by
ocfs2 [1][3] and lustre [4][5] clustered file systems, but they are very
unlikely to encountered by GParted users. Also xfs [6] and jfs [7] can
have external journals so if recognition of them is ever added they will
get the same colour as their respective file systems too.
[1] Journaling block device
https://en.wikipedia.org/wiki/Journaling_block_device
"JBD is filesystem-independent. ext3, ext4 and OCFS2 are known to
use JBD"
[2] https://ext4.wiki.kernel.org/index.php/Frequently_Asked_Questions#What_are_the_key_differences_between_jbd_and_jbd2.3F
[3] OCFS2: The Oracle Clustered File System, Version 2
https://www.kernel.org/doc/ols/2006/ols2006v1-pages-289-302.pdf
"Metadata journaling is done on a per node basis with JBD"
[4] Efficient Object Storage Journaling in a Distributed Parallel File
System
https://www.usenix.org/legacy/event/fast10/tech/full_papers/oral.pdf
[5] Lustre Software Release 2.x Operations Manual
https://doc.lustre.org/lustre_manual.pdf
6.4.2. Choosing Parameters for an External Journal
[6] mkfs.xfs(8) - construct an XFS filesystem
https://man7.org/linux/man-pages/man8/mkfs.xfs.8.html
"OPTIONS
...
logdev=device
This is used to specify that the log section should reside on
the device separate from the data section. The internal=1 and
logdev options are mutually exclusive.
"
[7] jfs_mkfs(8) - create a JFS formatted partition
https://manpages.debian.org/testing/jfsutils/jfs_mkfs.8.en.html
"OPTIONS
...
-j journal_device
Create the external JFS journal on journal_device, ...
"
Closes#89 - GParted doesn't recognise EXT4 fs journal partition
As found by the GitLab Continuous Integration job on CentOS 7 with
itstool 2.0.2, building the GParted Manual breaks on the Russian
translation like this:
$ ./autogen.sh
$ make clean
$ cd help
$ make
...
if ! test -d "ru/"; then mkdir "ru/"; fi
if test -d "C"; then d="../"; else d="/home/mike/programming/c/gparted/help/"; fi; \
mo="ru/ru.mo"; \
if test -f "${mo}"; then mo="../${mo}"; else mo="/home/mike/programming/c/gparted/help/${mo}"; fi; \
(cd "ru/" && itstool -m "${mo}" ${d}/C/index.docbook) && \
touch "ru/ru.stamp"
Error: Could not merge translations:
'NoneType' object has no attribute 'node'
make: *** [ru/ru.stamp] Error 1
On Fedora 35 with itstool 2.0.6 building the GParted Manual merely
reports a warning, leaving one paragraph untranslated, but the build
completes successfully:
$ ./autogen.sh
$ make clean
$ cd help
$ make
...
if ! test -d "ru/"; then mkdir "ru/"; fi
if test -d "C"; then d="../"; else d="/home/fedora/programming/c/gparted/help/"; fi; \
mo="ru/ru.mo"; \
if test -f "${mo}"; then mo="../${mo}"; else mo="/home/fedora/programming/c/gparted/help/${mo}"; fi; \
(cd "ru/" && itstool -m "${mo}" ${d}/C/index.docbook) && \
touch "ru/ru.stamp"
Warning: Could not merge translation for msgid:
Set the <application>grub</application> root device by specifying the device returned by the <command>find</command> command. This should be the partition containing the boot directory. <_:screen-1/>
...
$ echo $?
0
Fix translation of DocBook markup tag in the Russian translation of the
GParted Manual by commit:
17f4c3176d
Update Russian translation
Closes!98 - Fix translation of DocBook markup tag of the GParted Manual
Udev stopped supporting volatile udev rules in /dev/.udev/rules.d in
udev 176, released 2012-01-11 [1]. The oldest supported distributions
use much more recent combined systemd and udev releases.
Distro EOL udevadm -V
Debian 9 2022-Jun 232
RHEL / CentOS 7 2024-Jun 219
Ubuntu 18.04 LTS 2023-Apr 237
Now udev only reads volatile rules from /run/udev/ruled.d [2]. Simplify
the code a little.
[1] udev 176 NEWS
https://git.kernel.org/pub/scm/linux/hotplug/udev.git/tree/NEWS?h=176
"A writable /run directory (ususally tmpfs) is required now for a
fully functional udev, there is no longer a fallback to /dev/.udev."
[2] man 7 udev
"RULES FILES
The udev rules are read from the files located in the system rules
directory /usr/lib/udev/rules.d, the volatile runtime directory
/run/udev/rules.d and the local administration directory
/etc/udev/rules.d."
From the setup in the previous commit, unregister (stop) all of the
bcache backing and cache devices.
# bcache unregister /dev/sdb2
# bcache unregister /dev/sdb1
# bcache unregister /dev/sdc1
# bcache show
Name Type State Bname AttachToDev
/dev/sdb2 1 (data) inactive Non-Exist Alone
/dev/sdb1 1 (data) inactive Non-Exist Alone
/dev/sdc1 3 (cache) inactive N/A N/A
Run GParted. Just the device scanning causes the stopped bcache devices
to be restarted.
# bcache show
Name Type State Bname AttachToDev
/dev/sdb2 1 (data) clean(running) bcache1 /dev/sdc1
/dev/sdb1 1 (data) clean(running) bcache0 /dev/sdc1
/dev/sdc1 3 (cache) active N/A N/A
This is nothing new with this patchset, but as a result of existing udev
behaviour. The chain of events goes like this:
1. GParted calls ped_device_get() on each whole device;
2. Libparted opens each partition read-write to flush the cache;
3. When each is closed the kernel emits a block change event;
4. Udev fires block rules to detect the possibly changed content;
5. Udev fires bcache register (AKA start) rule.
More details with the help of udevadm monitor, strace and syslog:
GParted | set_devices_thread()
GParted | ped_device_get("/dev/sdb")
Libparted| ...
Libparted| openat(AT_FDCWD, "/dev/sdb1", O_WRONLY) = 9
Libparted| ioctl(9, BLKFLSBUF) = 0
Libparted| close(9)
KERNEL | change /devices/.../block/sdb/sdb1 (block)
KERNEL | add /devices/virtual/bdi/250:0 (bdi)
KERNEL | add /devices/virtual/block/bcache0 (block)
KERNEL | change /devices/virtual/block/bcache0 (block)
UDEV | change /devices/.../block/sdb/sdb1 (block)
UDEV | add /devices/virtual/bdi/250:0 (bdi)
UDEV | add /devices/virtual/block/bcache0 (block)
UDEV | change /devices/virtual/block/bcache0 (block)
SYSLOG | kernel: bcache: register_bdev() registered backing device sdb1
# grep bcache-register /lib/udev/rules.d/69-bcache.rules
RUN+="bcache-register $tempnode"
Fix this by temporarily adding a blank udev override rule to suppress
automatic starting of bcache devices, just as was previously done for
Linux Software RAID arrays [1].
[1] a255abf343
Prevent GParted starting stopped Linux Software RAID arrays (#709640)
Closes#183 - Basic support for bcache
A bcache device provides accelerated access to a backing device in a one
to one relationship. Multiple bcache backing devices can be attached to
and accelerated by the same cache device. Extending the setup from the
previous commit, create an additional backing device and attach it to
the same cache.
# bcache make -B /dev/sdb2
# bcache attach /dev/sdc1 /dev/sdb2
# bcache show
Name Type State Bname AttachToDev
/dev/sdb2 1 (data) clean(running) bcache1 /dev/sdc1
/dev/sdb1 1 (data) clean(running) bcache0 /dev/sdc1
/dev/sdc1 3 (cache) active N/A N/A
List a couple of bcache specific sysfs files which identify registered
(active) bcache devices (components).
# ls -l /sys/block/sd?/sd??/bcache/{dev,set}
lrwxrwxrwx. 1 root root 0 Jan 7 10:08 /sys/block/sdb/sdb1/bcache/dev -> ../../../../../../../../../../virtual/block/bcache0
lrwxrwxrwx. 1 root root 0 Jan 7 11:53 /sys/block/sdb/sdb2/bcache/dev -> ../../../../../../../../../../virtual/block/bcache1
lrwxrwxrwx. 1 root root 0 Jan 7 11:53 /sys/block/sdc/sdc1/bcache/set -> ../../../../../../../../../../../fs/bcache/9945e165-0604-4f29-94bd-b155d01080ad
As was done with previous software block devices [1][2][3][4] show the
bcache (access) device as the mount point of a backing device
(component). Use the /sys/block/DEV[/PTN]/bcache/dev sysfs symlinks to
provide the bcache device names. Bcache cache devices (components)
don't get mount points because they aren't accessible.
[1] commit 8083f11d84
Display LVM2 VGNAME as the PV's mount point (#160787)
[2] commit f6c2f00df7
Populate member mount point with SWRaid array device (#756829)
[3] commit 538c866d09
Display array device as mount point of mdadm started ATARAID members
(#75)
[4] commit 538c866d09
Display array device as mount point of mdadm started ATARAID members
(#75)
Closes#183 - Basic support for bcache
GParted automatically enables the Partition > Unmount action for busy
partitions. Unregister (deactivate) bcache devices is not going to be
supported so disable it.
Closes#183 - Basic support for bcache
Make (format as) bcache backing device (-B) and cache device (-C) and
implicitly attach the backing device to the cache to enable caching, all
in one.
# bcache make -B /dev/sdb1 -C /dev/sdc1
# bcache show
Name Type State Bname AttachToDev
/dev/sdb1 1 (data) clean(running) bcache0 /dev/sdc1
/dev/sdc1 3 (cache) active N/A N/A
After experimenting with 'bcache unregister', 'bcache register' and
stracing 'bcache show' the bcache kernel module creates the sysfs
directory /sys/block/DEV[/PTN]/bcache and it's contents only when the
bcache device is registered with the kernel (bcache component is
active). Use this to identify whether any bcache device (component)
should be displayed as active or not in GParted.
# ls -ld /sys/block/sd?/sd?1/bcache
drwxr-xr-x. 6 root root 0 Jan 7 10:08 /sys/block/sdb/sdb1/bcache
drwxr-xr-x. 2 root root 0 Jan 7 10:08 /sys/block/sdc/sdc1/bcache
Closes#183 - Basic support for bcache
Add pattern to recognise block cache devices as valid devices for
GParted to work with. Devices are named by the Linux kernel device
driver like /dev/bcache0 [1] with partitions named like /dev/bcache0p1
[2].
Note bcache devices can be partitioned but all the documents I have seen
guide users to create file systems directly in a bcache device and not
partition it [3][4] (plus all other Internet search results I looked
at). This might be because bcache is a specialist use case and the
bcache backing device can be a partition itself.
[1] linux 5.15 drivers/md/bcache/super.c bcache_device_init()
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/md/bcache/super.c?h=v5.15#n945
[2] Contents of /proc/partitions for a bcache partitioned backing device
$ grep bcache /proc/partitions
251 0 524280 bcache0
251 1 523256 bcache0p1
[3] Linux kernel document: A block layer cache (bcache)
https://www.kernel.org/doc/Documentation/bcache.txt
[4] The Linux kernel user's and administrator's guide > A block layer
cache (bcache)
https://www.kernel.org/doc/html/latest/admin-guide/bcache.htmlCloses#183 - Basic support for bcache
Use blkid to detect bcache formatted devices. Requires blkid from
util-linux >= 2.24 for detection of bcache devices [1].
Use util-linux's FS images when testing GParted detection.
# wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/blkid/images-fs/bcache-B.img.xz
# xzcat bcache-B.img.xz > /dev/sdb1
# wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/blkid/images-fs/bcache-C.img.xz
# xzcat bcache-C.img.xz > /dev/sdc1
# blkid /dev/sdb1 /dev/sdc1
/dev/sdb1: UUID="8fb7f716-4c19-4517-bfbb-6f4a2becad60" TYPE="bcache" PARTUUID="f8f1485e-01"
/dev/sdc1: UUID="7a343627-ac87-4bf0-b76f-46067cbc9b8c" TYPE="bcache" PARTUUID="f46e8c86-01"
To tidy-up after testing GParted detection, stop the bcache device in
case it was automatically started and wipe the signatures. This is to
prevent udev rules from automatically starting the bcache device on
every subsequent reboot.
# echo 1 > /sys/block/sdb/sdb1/bcache/stop
# wipefs -a /dev/sdb1 /dev/sdc1
Closes#183 - Basic support for bcache
Currently the Face Skin colour range from the GNOME palette represent a
mixture of file systems and software block devices:
JFS - Face Skin Medium
LVM2_PV - Face Skin Dark
NILFS2 - Face Skin Shadow
LINUX_SWRAID - Dark Brown
ATARAID - Dark Brown
We are about to add recognition of bcache [1][2][3], another software
block device. Reorganise the colour assignments so that Face Skin
colour range is exclusively used by types of software block devices and
assign JFS and NILFS2 new colours.
Face Skin Light (#EFE0CD) -
Face Skin Medium (#E0C39E) - BCACHE [New assignment]
Face Skin Dark (#B39169) - LVM2_PV
Face Skin Shadow (#826647) - LINUX_SWRAID [New assignment]
Brown Dark (#5A4733) - ATARAID
NILFS2 has flash friendly characteristics [4] so use Accent Red colours
along with F2FS.
Accent Red (#DF421E) - F2FS
Accent Red Dark (#990000) - NILFS2 [New assignment]
Move JFS to a group with XFS and UFS. The hue of the GNOME palette
Accent Yellow Dark colour, as used by UFS, was more Orange compared to
Accent Yellow and a bit too close to the Orange used by BTRFS. So use
the hue of the GNOME Accent Yellow and extend the range and assign like
this.
Accent Yellow (#EED680) - XFS
Accent Yellow Dark (#D6B129) - JFS [Updated hue.
New assignment]
Accent Yellow Shadow (#AA8F2C) - UFS [New colour.
New assignment]
Accent Yellow Dark Shadow (#826F2B) - [New colour]
[1] bcache
https://bcache.evilpiepirate.org/
[2] Linux kernel document: A block layer cache (bcache)
https://www.kernel.org/doc/Documentation/bcache.txt
[3] The Linux kernel user's and administrator's guide > A block layer
cache (bcache)
https://www.kernel.org/doc/html/latest/admin-guide/bcache.html
[4] NILFS, Relative performance
https://en.wikipedia.org/wiki/NILFS#Relative_performanceCloses#183 - Basic support for bcache
GParted currently performs these relevant steps for a copy operation:
1. Check source file system
2. Copy to destination
3. If destination partition is larger than source
3.1. check destination file system
3.2. grow destination file system
Always checking the source was added by this commit:
a54b52ea33
xfs copy now uses xfsdump and xfsrestore. icw some hacks in the other 2
...
Also the source file system is now checked before the actual copy
is performed. If damaged beyond repair, the copy won't start.
I think users have an expectation that a copy operation accesses the
source read-only and performing a file system check on the source
breaks that expectation. Also uses may accidentally or deliberately try
to copy a file system off a failing drive, where trying to check the
source could lead to further data loss. (ddrescue is the proper tool
for recovering data from damaged drives but ddrescue is not a tool the
user may know -- they know about GParted).
For a failing drive, not checking the source first means the copy might
fail instead, however a failed copy is preferable to greater chance of
further damaging the source file system by checking it.
In order to keep the new process as similar as possible to before,
always check the destination instead. This changes the copy operation
from performing one or two file system checks to always performing only
one check. The new relevant copy operation steps are:
1. Copy to destination
2. check destination file system
3. If destination partition is larger than source
3.1. grow destination file system
This has exactly the same error handling as before, if the check of the
destination file system fails the operation stops and any grow step
won't be performed. This represents the minimum change in behaviour
from before.
Bug 723571 - Copying ext4 partitions should not fix the source but the
destination
Closes!95 - Check copy destination instead of source
Since the only use of SWRaid_Info::get_uuid() assign the returned value
this doesn't actually save any copy construction. Do it for consistency
with the other get_*() methods in SWRaid_Info.
Closes!94 - Make more getter methods use return-by-constant-reference
Have to use a second constant reference variable array_path_2 in
GParted_Core::set_mountpoints() because by design C++ does not implement
rebinding of references [1].
[1] why doesn't C++ allow rebinding a reference?
https://stackoverflow.com/questions/27037744/why-doesnt-c-allow-rebinding-a-referenceCloses!94 - Make more getter methods use return-by-constant-reference
All uses of get_description() copy construct to a local variable, not
assign to a reference, so this doesn't save anything. It is just being
done to be consistent with making other getters return a constant
reference.
Closes!94 - Make more getter methods use return-by-constant-reference
Method already returned a constant reference. Change local variables to
constant references to avoid copy constructing them.
Closes!94 - Make more getter methods use return-by-constant-reference
A number of GParted methods named get_*() are returning properties and
are return-by-value. For objects this implies the returned value is
copy constructed and later destroyed when it goes out of scope. Change
them to use return-by-constant-reference to avoid unnecessary object
duplication. Just have to make sure the reference goes out of scope
before the referenced object is destroyed to avoid having a reference
(pointer) to freed memory. Assigning to a local variable instead of
of a local reference still duplicates the object so can be used when the
lifetime of the gotten object needs to be longer that the referenced
object.
Previously done for other getters here:
d948cbcb91
Make get_custom_text() and get_generic_text() return by reference
This change just makes Device::get_path() return a constant reference
and updates uses to match to avoid copy constructing the returned value.
Closes!94 - Make more getter methods use return-by-constant-reference
The first two clauses say is the partition object type unallocated
inside an extended partition, or a logical partition (which only occur
inside an extended partition). As these are the only two partition
object types which can occur inside an extended partition, this is
equivalent to saying is the partition object inside an extended
partition. Simplify.
The create new and paste into new dialogs are both composing a new
partition into the unallocated selected_partition they are passed. The
starting sector of this unallocated partition is the first sector the
newly composed partition could possibly have. To ensure it doesn't
overlay with the partition table or EBR (Extended Boot Records) it calls
MB_Needed_for_Boot_Record() to indicate if the first 1 MiB needs to be
reserved in the dialog or not.
Code:
Dialog_Partition_New::set_data(..., selected_partition, ...)
...
MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(selected_partition);
Dialog_Partition_Copy::set_data(selected_partition, ...)
...
MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(selected_partition);
However the resize/move dialog is different. It is passed the existing
selected_partition object and the vector of partitions from which it
determines if there is a previous unallocated partition object or not.
When there is no previous unallocated partition object, there is no need
to reserve 1 MiB because the selected_partition can't be moved further
to the left. In the other case when there is a previous unallocated
partition object the start of the existing selected_partition can be
moved to the left. However the code passes the selected_partition
object to MB_Needed_for_Boot_Record() so doesn't have the first sector
the newly composed partition could possibly have so doesn't reserve the
first 1 MiB to prevent it overlapping with the partition table at the
start of the drive. These two commits addressed this limitation:
* Ensure 1 MiB reserved when moving extended partition to start of drive
* Ensure 1 MiB reserved when moving partition to start of disk
Code:
Dialog_Partition_Resize_Move::set_data(selected_partition, ...)
new_partition = selected_partition.clone();
if (selected_partition.type == TYPE_EXTENDED)
Resize_Move_Extended(...);
else
Resoze_Move_Normal(...);
Dialog_Partition_Resize_Move::Resize_Move_Normal(...)
...
if (previous <= 0)
MIN_SPACE_BEFORE_MB = 0;
else
{
if (START < MEBIBYTE / new_partition->sector_size)
MIN_SPACE_BEFORE_MB = 1;
else
MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(*new_partition);
}
Dialog_Partition_Resize_Move::Resize_Move_Extended(...)
...
if (previous <= 0)
MIN_SPACE_BEFORE_MB = 0;
else
{
if (START < MEBIBYTE / new_partition->sector_size)
MIN_SPACE_BEFORE_MB = 1;
else
MIN_SPACE_BEFORE_MB = Dialog_Base_Partition::MB_Needed_for_Boot_Record(*new_partition);
}
So instead pass the previous unallocated partition object as that
contains the left most start sector the newly composed partition could
possibly have, therefore the check for overlapping the partition table
in the first 1 MiB of the drive can succeed.
On an MSDOS partitioned drive, create an extended partition at least 2
MiBs from the start of the drive. Like this:
dd if=/dev/zero bs=1M of=dev/sdb
echo 4096,4096,5 | sfdisk -uS --force /dev/sdb
The resize/move dialog appears to allow the extended partition to be
moved and/or resized to the very start of the drive, over the top of the
partition table, without reserving the first 1 MiB. Ensure the dialog
reserves the first 1 MiB, like it does when moving normal partitions.
Reference:
ceab9bde57
Ensure 1 MiB reserved when moving partition to start of disk
This case is an extension of the setup in the previous commit. Add a
second partition several megabytes after the first. It looks like this:
[TABLE][PTN#1] [PTN#2]
<-- 1st MiB -><- several MiBs ->
Just need to make the gap 2 MiB or more so that it can be seen what the
resize/move dialog is allowing. Setup like this using an 8 MiB gap and
8 MiB partition #2.
For MSDOS use:
dd if=/dev/zero bs=1M of=/dev/sdb
(echo 1,2047; echo 18432,16384) | sfdisk -uS --force /dev/sdb
mkswap /dev/sdb2
For GPT use:
sgdisk --zap-all /dev/sdb
sgdisk --set-alignment=1 --new 1:34:2047 /dev/sdb
sgdisk --new 2:18432:34815 /dev/sdb
mkswap /dev/sdb2
In GParted try to move partition sdb2 to the left as much as possible,
or try to resize the start to the left as much as possible. GParted
insists on having a 1 MiB of padding before the start of sdb2, forcing
it to start at sector 4096, even though sector 2048 is free and aligns
to whole megabytes.
Delete the preceding partition. Now GParted allows sdb2 to be moved or
resize to start at sector 2048.
Fix another off by one error in the sector comparison for the
resizing/moving of partitions.
Closes#172 - GParted doesn't allow creation of a partition starting at
sector 2048 if there is a partition before it
[This commit message and test case is written assuming a drive with a
(logical) sector size of 512 bytes. GParted equally well works with
other sector sizes because the limit is expressed as 1 MiB / sector
size. Adjust the test case sector counts as needed when testing with
different sector sized drives.]
Prepare an MSDOS or GPT partitioned disk with the first partition within
the first 1 MiB.
For MSDOS use:
dd if=/dev/zero bs=1M of=/dev/sdb
echo 1,2047 | sfdisk -uS --force /dev/sdb
For GPT use:
sgdisk --zap-all /dev/sdb
sgdisk --set-alignment=1 --new 1:34:2047 /dev/sdb
In GParted create a new partition on /dev/sdb as near to the start of
the drive as possible. GParted insists on added an extra 1 MiB of space
before the new partition, making it start at sector 4096, even though
sector 2048 is free and aligns to whole megabytes.
Delete the preceding partition. Now GParted allows the new partition
to be created starting at sector 2048.
GParted only needs to add padding of 1 MiB to account for the partition
table at the start of the drive when the possible start is within the
first MiB, not already at the first MiB. Fix this off by one error in
the sector comparison.
The reason this has bug has never occurred before is because it is very
unusual to have the first partition entirely within the first 1 MiB.
Normally either the (start of) the drive is free so GParted creates an
unallocated partition object starting at sector 0, so adding 1 MiB of
padding to preserve the partition table is correct; or the first
partition starts at 1 MiB so the possible start for a second partition
is much later in the drive.
Closes#172 - GParted doesn't allow creation of a partition starting at
sector 2048 if there is a partition before it
Accessibility relations are essential for usage with screen readers. It
enables the screen reader to read the corresponding label along with the
value of a widget when it gains focus, rather than just the value of the
widget itself.
Test by running Orca screen reader and tab around the elements of the UI
and listen to what is read out. For example before it would be
"500 GiB", where as after it would be "Unused 500 GiB".
Closes!92 - Add accessibility relations
A S Alam