Install exfatprogs into the CentOS 7 GitLab CI image, enabling unit
testing of GParted's use of exFAT programs. Exfatprogs is not yet
available for Ubuntu 20.04 as used in the Ubuntu GitLab CI image, only
for Ubuntu 20.10 so far.
Closes!30 - Add exFAT support
Libparted only allows selection of the partition type indirectly by
specifying the type of the file system it will contain [1] and so far
doesn't know about the exFAT file system. Therefore when GParted is
creating a new exFAT partition, it gets the GParted default of 83
(Linux file system) on MBR partition tables.
Example operation details:
Create Primary Partition #1 (exfat, 512.00 MiB) on /dev/sdb
* create empty partition
* clear old file system signatures in /dev/sdb1
* set partition type on /dev/sdb1
new partition type: ext2
* create new exfat file system
fdisk report:
# fdisk -l /dev/sdb
Disk /dev/sdb: 8 GiB, 8589934592 bytes, 16777216 sectors
Disk model: VBOX HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xa2aab629
Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 1050623 1048576 512M 83 Linux
However the "exFAT file system specification" says:
https://docs.microsoft.com/en-us/windows/win32/fileio/exfat-specification
"10.2 Partition Tables
To ensure interoperability of exFAT volumes in a broad set of usage
scenarios, implementations should use partition type 07h for MBR
partitioned storage and partition GUID
{EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} for GPT partitioned storage.
"
Fix this.
[1] ped_partition_new(..., const PedFileSystemType* fs_type, ...)
https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca75880f9e0c3ce57f7a4b72faf5
ped_partition_set_system(..., const PedFileSystemType* fs_type)
https://www.gnu.org/software/parted/api/group__PedPartition.html#g2f94ca75880f9e0c3ce57f7a4b72faf5Closes!30 - Add exFAT support
With exfatprogs (https://github.com/exfatprogs/exfatprogs) installed the
following operations on exFAT file systems are supported:
- Creation
- Checking
- Labelling
As of the current exfatprogs 1.0.4 the following are not supported:
- Reading usage
- Resizing
- Updating the UUID
Closes!30 - Add exFAT support
On Ubuntu the gparted shell wrapper still attempts to mask lots of
non-block device based file systems. Remove the --quiet option from the
systemctl --runtime mask command to see:
$ gparted
Created symlink /run/systemd/system/snap-gnome\x2d3\x2d34\x2d1804-66.mount -> /dev/null.
Created symlink /run/systemd/system/snap-core-10583.mount -> /dev/null.
Created symlink /run/systemd/system/boot-efi.mount -> /dev/null.
Created symlink /run/systemd/system/snap-gtk\x2dcommon\x2dthemes-1514.mount -> /dev/null.
Created symlink /run/systemd/system/snap-core-10577.mount -> /dev/null.
Created symlink /run/systemd/system/snap-core18-1944.mount -> /dev/null.
Created symlink /run/systemd/system/run-user-1000-doc.mount -> /dev/null.
Created symlink /run/systemd/system/snap-gtk\x2dcommon\x2dthemes-1506.mount -> /dev/null.
Created symlink /run/systemd/system/snap-gnome\x2d3\x2d28\x2d1804-128.mount -> /dev/null.
Created symlink /run/systemd/system/snap-snap\x2dstore-518.mount -> /dev/null.
Created symlink /run/systemd/system/snap-gnome\x2d3\x2d28\x2d1804-145.mount -> /dev/null.
Created symlink /run/systemd/system/snap-core18-1932.mount -> /dev/null.
Created symlink /run/systemd/system/snap-snap\x2dstore-467.mount -> /dev/null.
Created symlink /run/systemd/system/snap-gnome\x2d3\x2d34\x2d1804-60.mount -> /dev/null.
Created symlink /run/systemd/system/-.mount -> /dev/null.
GParted 1.0.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3
The gparted shell wrapper is currently looking for non-masked Systemd
mount units where the 'What' property starts "/dev/". However Ubuntu
also uses snap packages which are mounted file images via loop devices:
$ grep '^/dev/' /proc/mounts | sort
/dev/fuse /run/user/1000/doc fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
/dev/loop0 /snap/core/10583 squashfs ro,nodev,relatime 0 0
/dev/loop10 /snap/snap-store/518 squashfs ro,nodev,relatime 0 0
/dev/loop11 /snap/snap-store/467 squashfs ro,nodev,relatime 0 0
/dev/loop12 /snap/gtk-common-themes/1506 squashfs ro,nodev,relatime 0 0
/dev/loop1 /snap/core/10577 squashfs ro,nodev,relatime 0 0
/dev/loop3 /snap/core18/1944 squashfs ro,nodev,relatime 0 0
/dev/loop4 /snap/core18/1932 squashfs ro,nodev,relatime 0 0
/dev/loop5 /snap/gnome-3-34-1804/66 squashfs ro,nodev,relatime 0 0
/dev/loop6 /snap/gnome-3-28-1804/128 squashfs ro,nodev,relatime 0 0
/dev/loop7 /snap/gnome-3-34-1804/60 squashfs ro,nodev,relatime 0 0
/dev/loop8 /snap/gnome-3-28-1804/145 squashfs ro,nodev,relatime 0 0
/dev/loop9 /snap/gtk-common-themes/1514 squashfs ro,nodev,relatime 0 0
/dev/sda1 /boot/efi vfat rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 0
/dev/sda5 / ext4 rw,relatime,errors=remount-ro 0 0
Fix by excluding:
1. Device name "/dev/fuse" because it's a character not a block device
and the mount point is associated with snap,
2. Device names starting "/dev/loop" and where the mount point starts
"/snap/" [1]. This is to allow for use of GParted with explicitly
named loop devices.
[1] The system /snap directory
https://snapcraft.io/docs/system-snap-directoryCloses#129 - Unit \xe2\x97\x8f.service does not exist, proceeding
anyway
The gparted shell wrapper masks Systemd mount units to prevent it
automounting file systems while GParted is running [1], excluding
virtual file system which GParted isn't interested in [2]. The problem
is that there are a lot of virtual file systems and they have changed
between Fedora 19 and 33 so now the exclusion list is out of date.
Run GParted on Fedora 33 and query the mount units while it is running:
$ systemctl list-units -t mount --full --all
UNIT LOAD ACTIVE SUB DESCRIPTION
-.mount loaded active mounted Root Mount
* boot.mount masked active mounted /boot
dev-hugepages.mount loaded active mounted Huge Pages File System
dev-mqueue.mount loaded active mounted POSIX Message Queue File System
* home.mount masked active mounted /home
* proc-fs-nfsd.mount masked inactive dead proc-fs-nfsd.mount
proc-sys-fs-binfmt_misc.mount loaded inactive dead Arbitrary Executable File Formats File System
run-user-1000-gvfs.mount loaded active mounted /run/user/1000/gvfs
* run-user-1000.mount masked active mounted /run/user/1000
* run-user-42.mount masked active mounted /run/user/42
sys-fs-fuse-connections.mount loaded active mounted FUSE Control File System
sys-kernel-config.mount loaded active mounted Kernel Configuration File System
sys-kernel-debug.mount loaded active mounted Kernel Debug File System
* sys-kernel-tracing.mount masked active mounted /sys/kernel/tracing
* sysroot.mount masked inactive dead sysroot.mount
* tmp.mount masked active mounted /tmp
* var-lib-machines.mount masked inactive dead var-lib-machines.mount
* var-lib-nfs-rpc_pipefs.mount masked active mounted /var/lib/nfs/rpc_pipefs
* var.mount masked inactive dead var.mount
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
19 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
So it masked these virtual file systems which didn't need to be masked:
* proc-fs-nfsd.mount masked inactive dead proc-fs-nfsd.mount
* run-user-1000.mount masked active mounted /run/user/1000
* run-user-42.mount masked active mounted /run/user/42
* sys-kernel-tracing.mount masked active mounted /sys/kernel/tracing
* var-lib-machines.mount masked inactive dead var-lib-machines.mount
* var-lib-nfs-rpc_pipefs.mount masked active mounted /var/lib/nfs/rpc_pipefs
Lines from /proc/partitions for some of these virtual file systems:
$ egrep '/run/user|/sys/kernel/tracing|/var/lib/nfs/rpc_pipefs' /proc/mounts
tmpfs /run/user/42 tmpfs rw,seclabel,nosuid,nodev,relatime,size=202656k,nr_inodes=50664,mode=700,uid=42,gid=42,inode64 0 0
tmpfs /run/user/1000 tmpfs rw,seclabel,nosuid,nodev,relatime,size=202656k,nr_inodes=50664,mode=700,uid=1000,gid=1000,inode64 0 0
none /sys/kernel/tracing tracefs rw,seclabel,relatime 0 0
sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw,relatime 0 0
gvfsd-fuse /run/user/1000/gvfs fuse.gvfsd-fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
And for contrast the lines from /proc/mounts for disk backed file systems:
$ egrep '^/dev/' /proc/mounts
/dev/sda1 /boot ext4 rw,seclabel,relatime 0 0
/dev/sda2 / btrfs rw,seclabel,relatime,space_cache,subvolid=258,subvol=/root 0 0
/dev/sda2 /home btrfs rw,seclabel,relatime,space_cache,subvolid=256,subvol=/home 0 0
Going back to first principles GParted cares that Systemd doesn't
automount file systems on block devices. So instead only mask mount
units which are on block devices. Where the 'What' property starts
"/dev/".
Systemd maintains hundreds of properties for each unit.
$ systemctl show boot.mount | wc -l
221
The properties of interest for all mount units can be queries like this:
$ systemctl show --all --property=What,Id,LoadState '*.mount'
...
What=sunrpc
Id=var-lib-nfs-rpc_pipefs.mount
LoadState=masked
What=/dev/sda1
Id=boot.mount
LoadState=masked
...
[1] 4c109df9b5
Use systemctl runtime mask to prevent automounting (#701676)
[2] 43de8e326a
Do not mask virtual file systems when using systemctl (#708378)
Closes#129 - Unit \xe2\x97\x8f.service does not exist, proceeding
anyway
With Systemd 246 on Fedora 33, running GParted reports this error and no
longer masks the system mount units:
$ gparted
Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
GParted 1.1.0
configuration --enable-libparted-dmraid --enable-online-resize
libparted 3.3
$ systemctl list-units -t mount --full --all --no-legend
-.mount loaded active mounted Root Mount
boot.mount loaded active mounted /boot
dev-hugepages.mount loaded active mounted Huge Pages File System
dev-mqueue.mount loaded active mounted POSIX Message Queue File System
home.mount loaded active mounted /home
proc-fs-nfsd.mount loaded inactive dead NFSD configuration filesystem
proc-sys-fs-binfmt_misc.mount loaded inactive dead Arbitrary Executable File Formats File System
run-user-1000-gvfs.mount loaded active mounted /run/user/1000/gvfs
run-user-1000.mount loaded active mounted /run/user/1000
run-user-42.mount loaded active mounted /run/user/42
sys-fs-fuse-connections.mount loaded active mounted FUSE Control File System
sys-kernel-config.mount loaded active mounted Kernel Configuration File System
sys-kernel-debug.mount loaded active mounted Kernel Debug File System
sys-kernel-tracing.mount loaded active mounted Kernel Trace File System
* sysroot.mount not-found inactive dead sysroot.mount
tmp.mount loaded active mounted Temporary Directory (/tmp)
var-lib-machines.mount loaded inactive dead Virtual Machine and Container Storage (Compatibility)
var-lib-nfs-rpc_pipefs.mount loaded active mounted RPC Pipe File System
* var.mount not-found inactive dead var.mount
^
[Unicode Black Circle character (U+25CF) replaced with star to avoid
making this this commit message Unicode.]
Currently the gparted shell wrapper lists the Systemd mount units and
takes the first space separated column as the unit name. If the LOAD
status of the unit is not "loaded" then Systemd prefixes the name with
an optional Black Circle. Prior to Systemd 246 these extra 2 characters
at the start of the line, including the optional Black Circle, were
suppressed by the --no-legend option, but with Systemd 246 this no
longer happens. As the mount unit names no longer start in the first
character of the line no units are masked. Instead the Unicode Black
Circle character, UTF-8 byte sequence E2 97 8F, is found at the start of
highlighted lines which results in this error:
Unit \xe2\x97\x8f.service does not exist, proceeding anyway.
Fix by adding the --plain option to suppress the optional Black Circle
in the systemctl output. Confirmed this option is available in the
oldest supported distributions with Systemd.
RedHat / CentOS 7 Systemd 219 systemctl has --plain option.
Ubuntu 16.04 LTS Systemd 229 systemctl has --plain option.
Closes#129 - Unit \xe2\x97\x8f.service does not exist, proceeding
anyway
std::vector<> is no longer used in TreeView_Detail.h since this commit
replaced them:
fae909897e
Use PartitionVector class throughout the code (#759726)
Since August 2020, GitLab Continuous Integration test jobs have been
failing on the CentOS 7 image like this from
tests/test_SupportedFileSystems.log:
process 6319: D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/etc/machine-id' should contain a hex string of length 32, not length 0, with no other text
See the manual page for dbus-uuidgen to correct this issue.
D-Bus not built with -rdynamic so unable to print a backtrace
Running main() from test_SupportedFileSystems.cc
DISPLAY=":99"
/usr/bin/xvfb-run: line 181: 6319 Aborted (core dumped) DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@" 2>&1
Not sure why this has just started failing in the CentOS 7 CI image now,
but the error is widely known [1][2][3][4]. Use
systemd-machine-id-setup to generate a machine ID [5][6]; rather than
dbus-uuidgen [7] as it's designed to integrate into VMs and does the
right thing if a valid machine ID already exists.
[1] Red Hat Bug 598200 - D-Bus library appears to be incorrectly set up;
failed to read machine uuid: UUID file '/var/lib/dbus/machine-id'
https://bugzilla.redhat.com/show_bug.cgi?id=598200
[2] Free Desktop Bug 13194 - When machine-id not found, dbus should not
abort
https://bugs.freedesktop.org/show_bug.cgi?id=13194
[3] D-Bus library appears to be incorrectly set up
https://unix.stackexchange.com/questions/117741/d-bus-library-appears-to-be-incorrectly-set-up
[4] Generate uuid for container
https://xpra.org/trac/wiki/Usage/Docker/CentOS
[5] CentOS / RHEL 7 : How to Change the machine-id
https://www.thegeekdiary.com/centos-rhel-7-how-to-change-the-machine-id/
[6] man systemd-machine-id-setup
https://man7.org/linux/man-pages/man1/systemd-machine-id-setup.1.html
[7] man dbus-uuidgen
https://dbus.freedesktop.org/doc/dbus-uuidgen.1.htmlCloses!62 - Fix CentOS 7 CI test job failures because of zero sized
/etc/machine-id
These PipeCapture unit tests are also failing, preventing the
ubuntu_test CI job passing:
PipeCaptureTest.ReadEmbeddedNULCharacter
PipeCaptureTest.ReadNULByteInMiddleOfMultiByteUTF8Character
These tests are also failing locally in both Ubuntu 20.04 LTS and
Fedora 32 VMs, but not in Ubuntu 18.04 LTS or Fedora 31 VMs. As this is
not specifically a Ubuntu docker image update related issue, temporarily
exclude these failing tests.
Closes!60 - Fix GitLab CI job failures following Ubuntu docker image
updates
Next the Ubuntu image CI job is failing without a C++ compiler like
this:
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl.exe... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether the C++ compiler works... no
configure: error: in `/builds/mfleetwo/gparted':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
...
ERROR: Job failed: exit code 1
The published "Ubuntu" docker image has been updated to Ubuntu 20.04 LTS
and must no longer include the build tools by default, or not be a
dependency of any of the other installed packages. Explicitly install
build-essential to get the C++ compiler [1]. Also don't list make as
build-essential includes it.
[1] Installing the GNU C compiler and GNU C++ compiler
https://help.ubuntu.com/community/InstallingCompilersCloses!60 - Fix GitLab CI job failures following Ubuntu docker image
updates
The Ubuntu based GitLab CI jobs have recently started being terminated
after the default 1 hour timeout. Installing / updating packages in the
image is updating the tzdata package which is prompting for input which
it will never receive, hence the hang. The end of output from the job
looks like this:
Setting up tzdata (2020a-0ubuntu0.20.04) ...
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
Configuring tzdata
------------------
Please select the geographic area in which you live. Subsequent configuration
questions will narrow this down by presenting a list of cities, representing
the time zones in which they are located.
1. Africa 4. Australia 7. Atlantic 10. Pacific 13. Etc
2. America 5. Arctic 8. Europe 11. SystemV
3. Antarctica 6. Asia 9. Indian 12. US
Geographic area:
...
ERROR: Job failed: execution took longer than 1h0m0s seconds
This is a well known issue [1][2][3]. Probably occurring now because of
a new release of tzdata not included in the base Ubuntu image we are
using. Fix by telling the underlying dpkg tools this installation is
non-interactive.
[1] Avoiding user interaction with tzdata when installing certbot in a
docker container
https://askubuntu.com/questions/909277/avoiding-user-interaction-with-tzdata-when-installing-certbot-in-a-docker-contai
[2] How to install tzdata on a ubuntu docker image?
https://serverfault.com/questions/949991/how-to-install-tzdata-on-a-ubuntu-docker-image
[3] apt-get install tzdata noninteractive
https://stackoverflow.com/questions/44331836/apt-get-install-tzdata-noninteractiveCloses!60 - Fix GitLab CI job failures following Ubuntu docker image
updates
This previous commit [1] excluded unit test
BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches because GNOME
GitLab Docker CI images don't have /dev/disk hierarchy and so no
symbolic links to block devices.
Create the /dev/disk/by-id directory and a symlink for this unit test to
use in the new tests/makedev.sh script.
[1] fe2fc33e67
Exclude unit test which fails in Docker CI image (!4)
test_SupportedFileSystems is another unit test that has been failing
since 23-Feb-2020 in GNOME GitLab Continuous Integration test jobs.
Fragments from tests/test-suite.log from a failed test CI job:
FAIL: test_SupportedFileSystems
===============================
...
[ RUN ] My/SupportedFileSystemsTest.Create/lvm2pv
test_SupportedFileSystems.cc:387: Failure
Failed
create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img'
losetup: test_SupportedFileSystems.img: failed to set up loop device: No such file or directory
create_loopdev(): Losetup failed with exit status 1
create_loopdev(): Failed to create required loop device
Error: Could not stat device - No such file or directory.
test_SupportedFileSystems.cc:446: Failure
Value of: lp_device != NULL
Actual: false
Expected: true
test_SupportedFileSystems.cc:490: Failure
Value of: m_fs_object->create(m_partition, m_operation_detail)
Actual: false
Expected: true
Operation details:
lvm pvcreate -M 2 '' 00:00:00 (ERROR)
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Device not found.
detach_loopdev(): Execute: losetup --detach ''
losetup: /dev/: detach failed: Inappropriate ioctl for device
detach_loopdev(): Losetup failed with exit status 1
detach_loopdev(): Failed to detach loop device. Test NOT affected
[ FAILED ] My/SupportedFileSystemsTest.Create/lvm2pv, where GetParam() = 20 (64 ms)
...
[ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs
test_SupportedFileSystems.cc:387: Failure
Failed
create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img'
losetup: test_SupportedFileSystems.img: failed to set up loop device: No such file or directory
create_loopdev(): Losetup failed with exit status 1
create_loopdev(): Failed to create required loop device
Error: Could not stat device - No such file or directory.
test_SupportedFileSystems.cc:446: Failure
Value of: lp_device != NULL
Actual: false
Expected: true
test_SupportedFileSystems.cc:503: Failure
Value of: m_fs_object->create(m_partition, m_operation_detail)
Actual: false
Expected: true
Operation details:
mkfs.btrfs -L '' '' 00:00:00 (ERROR)
btrfs-progs v4.9.1
See http://btrfs.wiki.kernel.org for more information.
ERROR: failed to check size for : No such file or directory
detach_loopdev(): Execute: losetup --detach ''
losetup: /dev/: detach failed: Inappropriate ioctl for device
detach_loopdev(): Losetup failed with exit status 1
detach_loopdev(): Failed to detach loop device. Test NOT affected
[ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs, where GetParam() = 7 (11 ms)
All the test_SupportedFileSystems unit tests which need a loop device
are failing when running losetup like this:
losetup: <IMAGE_NAME>: failed to setup loop device: No such file or directory
losetup uses /dev/loop-control [1][2] which no longer exists in the
Docker image. However even after creating /dev/loop-control in the
image, losetup continues to fail. Also tried stracing losetup but that
fails like this, presumably because it is not allowed inside the Docker
image:
$ strace losetup --find --show /tmp/disk.img
strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted
+++ exited with 1 +++
For now I have run out of ways to investigate and resolve this, so just
exclude the 12 tests which required loop devices. All the tests still
execute when run locally outside the restricted GNOME GitLab CI Docker
setup.
Closes!59 - Fix GNOME GitLab CI test job failures because of missing
/dev entries
From 23-Feb-2020 onwards, GNOME GitLab Continuous Integration test jobs
have been failing running unit tests which previously succeeded. With
some extra debugging added into test_BlockSpecial to print 'bname' and
'bs' values in the failing tests, here are fragments from
tests/test-suite.log for the the test_BlockSpecial failures in a test CI
job:
FAIL: test_BlockSpecial
=======================
...
[ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice
bname="/dev/sr0"
bs=BlockSpecial{"/dev/sr0",0,0}
test_BlockSpecial.cc:218: Failure
Value of: bs.m_major > 0 || bs.m_minor > 0
Actual: false
Expected: true
[ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice (0 ms)
...
[ RUN ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices
bname1="/dev/sr0"
bname2="/dev/sda"
bs1=BlockSpecial{"/dev/sr0",0,0}
bs2=BlockSpecial{"/dev/sda",0,0}
test_BlockSpecial.cc:250: Failure
Value of: bs1.m_major != bs2.m_major || bs1.m_minor != bs2.m_minor
Actual: false
Expected: true
[ FAILED ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices (1 ms)
Contents of /proc/partitions inside the Docker image when this test CI
job failed:
$ cat /proc/partitions
major minor #blocks name
11 0 1048575 sr0
8 0 573367448 sda
8 1 573366407 sda1
And the listing of /dev/:
$ ls -l /dev/
total 0
lrwxrwxrwx 1 root root 11 Mar 3 09:00 core -> /proc/kcore
lrwxrwxrwx 1 root root 13 Mar 3 09:00 fd -> /proc/self/fd
crw-rw-rw- 1 root root 1, 7 Mar 3 09:00 full
drwxrwxrwt 2 root root 40 Mar 3 09:00 mqueue
crw-rw-rw- 1 root root 1, 3 Mar 3 09:00 null
lrwxrwxrwx 1 root root 8 Mar 3 09:00 ptmx -> pts/ptmx
drwxr-xr-x 2 root root 0 Mar 3 09:00 pts
crw-rw-rw- 1 root root 1, 8 Mar 3 09:00 random
drwxrwxrwt 2 root root 40 Mar 3 09:00 shm
lrwxrwxrwx 1 root root 15 Mar 3 09:00 stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 Mar 3 09:00 stdin -> /proc/self/fd/0
lrwxrwxrwx 1 root root 15 Mar 3 09:00 stdout -> /proc/self/fd/1
crw-rw-rw- 1 root root 5, 0 Mar 3 09:00 tty
crw-rw-rw- 1 root root 1, 9 Mar 3 09:00 urandom
crw-rw-rw- 1 root root 1, 5 Mar 3 09:00 zero
See how the test_BlockSpecial fixtures are getting major=0 and minor=0
for the block special devices they are testing with. This is happening
because there aren't any entries in /dev for those disks and partitions
listed in /proc/partitions. Assume that Docker in GNOME GitLab has
changed and that unneeded and unwanted devices in /dev are no longer
being created inside images.
In the test CI jobs execute new script, tests/makedev.sh, to create just
the first two block special devices mentioned in /proc/partitions needed
by test_BlockSpecial.
Closes!59 - Fix GNOME GitLab CI test job failures because of missing
/dev entries
Seems to be referring to how Fill_Label_Device_Info() worked in the
past, but from history before the beginning of the GIT repository.
Remove out of date comment.
Debian user reported a bug [1] that when they had PS_FORMAT environment
variable set it prevented GParted running:
# export PS_FORMAT='ruser,uid,pid,ppid,pri,ni,%cpu,%mem,vsz,rss,stat,tty,start,time,command'
# gparted
The process gpartedbin is already running.
Only one gpartedbin process is permitted.
# echo $?
1
Using ps column 'command' includes the command and all it's arguments,
rather than just the command name as ps displays by default. Thus the
shell wrapper finds the grep command it's using when searching for the
gpartedbin executable.
# ps -e | grep gpartedbin
root 0 26114 14777 19 0 0.0 0.0 112712 940 S+ pts/0 10:42:02 00:00:00 grep --color=auto gpartedbin
Fix by searching for running processes using pidof. pgrep does regular
expression matching where as pidof checks program name is the same [2].
Therefore use of pidof is preferred over pgrep [3].
[1] Debian bug #864932 - gparted fails if PS_FORMAT options are
specified
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864932
[2] Difference between pidof and pgrep?
https://stackoverflow.com/questions/52151698/difference-between-pidof-and-pgrep
[3] [PATCH] gparted.in: Use reliable way of detecting gpartedbin process
existence
https://git.alpinelinux.org/aports/tree/community/gparted/gparted.in-Use-reliable-way-of-detecting-gpartedbin-.patchCloses!54 - Fix gparted not launching when PS_FORMAT environment
variable set
To better reflect that they represent the version of mke2fs executable
from the e2fsprogs package, even though the executable is called as
mkfs.ext4.
$ ls -il /sbin/mke2fs /sbin/mkfs.ext*
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mke2fs
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext2
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext3
1978670 -rwxr-xr-x. 4 root root 96384 Aug 9 2019 /sbin/mkfs.ext4
$ mkfs.ext4 -V
mke2fs 1.42.9 (28-Dec-2013)
Using EXT2FS Library version 1.42.9
$ mke2fs -V
mke2fs 1.42.9 (28-Dec-2013)
Using EXT2FS Library version 1.42.9
With removal of support for RHEL / CentOS 5 and it's e4fsprogs package
[1][2] it is no longer necessary to accept:
mke4fs 1.41.12 (17-May-2010)
only:
mke2fs 1.42.9 (28-Dec-2013)
[1] 6c4ab5dc28
Remove checks for e4fsprogs commands (#794253)
[2] de6e70d933
Simplify ext2::get_filesystem_support() with regard ext4 support (#794253)
This earlier commit [1] from 2013 recognised the new names for programs
in dosfstools >= 3.0.18, specifically mkfs.fat and fsck.fat. Now that
the oldest supported distributions use dosfstools >= 3.0.18 it is no
longer necessary to support using the old names of mkdosfs and dosfsck,
so remove that code.
Oldest supported Dosfstools
distributions Version
Debian 8 3.0.27
RHEL / CentOS 7 3.0.20
SLES 12 3.0.26
Ubuntu 14.04 LTS 3.0.26
[1] 1ae03dee95
Recognise new dosfstools program names (#704629)
Closes!57 - Raise minimum support dosfstools to 3.0.18 released
2013-06-06
A user reported that formatting a whole disk device with a file system
failed like this:
Format /dev/sdd as ext4 (ERROR)
+ calibrate /dev/sdd (SUCCESS)
path: /dev/sdd (device)
start: 0
end: 15633407
size: 15633408 (7.45 GiB)
+ clear old file system signatures in /dev/sdd (SUCCESS)
+ write 512.00 KiB of zeros at byte offset 0 (SUCCESS)
+ write 4.00 KiB of zeros at byte offset 67108864 (SUCCESS)
+ write 512.00 KiB of zeros at byte offset 8003780608 (SUCCESS)
+ write 4.00 KiB of zeros at byte offset 8004239360 (SUCCESS)
+ write 8.00 KiB of zeros at byte offset 8004296704 (SUCCESS)
+ flush operating system cache of /dev/sdd (SUCCESS)
+ create new ext4 file system (ERROR)
+ mkfs.ext4 -F -O ^64bit -L '' '/dev/sdd' (ERROR)
mke2fs 1.44.1 (24-Mar-2018)
/dev/sdd is apparently in use by the system; will not make a filesystem here!
Opening the whole disk block device exclusively causes mkfs.ext4 to
report that error like this:
# python
>>> import os
>>> f = os.open('/dev/sdb',os.O_RDONLY|os.O_EXCL)
>>> ^Z
[1]+ Stopped python
# mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb'
mke2fs 1.42.9 (28-Dec-2013)
/dev/sdb is apparently in use by the system; will not make a filesystem here!
# echo $?
1
I have not been able to reproduce this error, but with debugging and
sleeping in GParted, stracing GParted and using 'udevadm monitor' to
watch udev events the following sequence of events is seen:
gparted |format(partition, operationdetail)
gparted | erase_filesystem_signatures(partition, operationdetail)
gparted | get_device(device_path="/dev/sdb", lp_device, flush=false)
gparted | ped_device_get("/dev/sdb")
libparted | open("/dev/sdb", O_RDONLY) = 11
libparted | close(11)
gparted | ped_device_open(lp_device)
libparted | open("/dev/sdb", O_RDWR) = 11
gparted | ped_device_sync(lp_device)
libparted | ioctl(11, BLKFLSBUF)
gparted | ped_device_close()
libparted | close(11)
udev(async)| KERNEL change /devices/.../sdb (block)
udev(async)| UDEV change /devices/.../sdb (block)
gparted | set_partition_type(partition, operationdetail)
gparted | create_filesystem(partition, operationdetail)
gparted | ext2::create(partition, operationdetail)
gparted | FileSystem::execute_command("mkfs.ext4 -F -O ^64bit -L '' '/dev/sdb')
So it is assumed that the processing of the udev change rule after
closing the block device in erase_filesystem_signatures() overlaps with
the execution mkfs.ext4 and causes the seen error. Fix by waiting for
those udev events to complete as was previously done by commits [1][2]
[3].
Also note that this is specific to creating file systems on and
formatting unpartitioned whole disk devices because set_partition_type()
is a no-operation. Where as on a partitioned device
set_partition_type() calls commit() which already waits for udev rules
to complete [3].
[1] 50c8924a8e4d9cc96a2ea45f13291114402affee
Wait for udev to recreate /dev/PTN entries when querying partition
FSs (!46)
[2] 4f6c312e3bc68cafb5e6035fd4a5b5bbbfcea992
Wait for udev change on /dev/DISK when querying whole device FS
(!46)
[3] 2f53876c0f
Wait for the kernel and udev to settle partitions for a second time
(#790418)
Closes#83 - /dev/sdd is apparently in use by the system; will not make
a filesystem here!
