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
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
Back in 2009 devicekit-disks package was renamed to udisks [1]. All
supported distributions use udisks (or more recently udisks2). None
have the old devkit-disks command. Therefore remove it from the GParted
shell wrapper.
[1] https://www.freedesktop.org/wiki/Software/DeviceKit-disks/
"Note
On December 1st 2009, DeviceKit-disks was renamed to udisks. This
release is expected to appear in distributions released in the first
half of 2010."
GParted fails to display when run under Wayland [1][2][3]. This is
because by intentional design Wayland doesn't allow applications with
root privileges access to the display [4].
As an interim workaround make the gparted shell wrapper use xhost to
grant root access to the X11 server if root doesn't already have access,
but only when configured. Granting root access must be explicitly
enabled when building GParted like this:
./configure --enable-xhost-root
It defaults to disabled. When gpartedbin binary ends the shell wrapper
revokes root access only if it granted such access.
[1] GNOME Bug 776437 - GParted fails to run as root under Wayland
https://bugzilla.gnome.org/show_bug.cgi?id=776437
[2] Ubuntu Bug 1652282 - GParted does not work in GNOME on Wayland
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1652282
[3] Fedora Bug 1397103 - gparted not working under Wayland
https://bugzilla.redhat.com/show_bug.cgi?id=1397103
[4] Common Fedora 25 bugs
Running graphical apps with root privileges (e.g. gparted) does not
work on Wayland
https://fedoraproject.org/wiki/Common_F25_bugs#wayland-root-apps
Bug 776437 - GParted fails to run as root under Wayland
Now that the gparted script is intended to be run by ordinary users, as
well as root, install it into directory $prefix/bin rather than
$prefix/sbin.
Bug 776437 - GParted fails to run as root under Wayland
Move calling of the privilege escalation program which allows a normal
user to run GParted as root from the desktop file into the gparted
wrapper script. This is in preparation for further changes needed to
grant root access to the X11 display under Wayland.
Don't introduce yet another script so that there aren't two different
names to run GParted by for normal users and root. Using the same
gparted name but placing two different scripts at /usr/bin/gparted and
/usr/sbin/gparted is not possible because on Arch Linux /usr/sbin is a
symbolic link to /usr/bin.
Frequently asked questions, Does Arch follow the FHS?
https://wiki.archlinux.org/index.php/Frequently_asked_questions#Does_Arch_follow_the_FHS.3F
"Arch Linux follows the file system hierarchy for operating systems
using the systemd service manager. See file-hierarchy(7) for an
explanation of each directory along with their designations. In
particular, /bin, /sbin, and /usr/sbin are symbolic links to
/usr/bin, and /lib (and /lib64 if applicable) are symbolic links to
/usr/lib".
Bug 776437 - GParted fails to run as root under Wayland
In order to prevent potential corruption of newly created file systems,
when available use udisks2-inhibit with gpartedbin execution to prevent
automounting.
Original report:
Xubuntu install fail due partition auto mount defeats Gparted
https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1078445
Some GNU/Linux distributions use the udisks2 "udisksd" daemon and have
udisks2-inhibit at a known location. The known location is not in the
default PATH environment variable.
One known distribution that matches this criteria is xubuntu 14.04.
Interestingly neither kubuntu 14.04 nor ubuntu 14.04 appear to have the
udisks2 "udisksd" daemon running and do not suffer from this specific
automounting problem.
Bug 745349 - gparted wrapper script needs updated for udisks2
Applying operations or just scanning the partitions in GParted was
causing all stopped Linux Software RAID arrays to be automatically
started. This is not new with this patch set, but as a result of the
following behaviour which has existed for a long time. Chain of events
goes likes this:
1) Gparted calls commit_to_os() to update the kernel with the new
partition table;
2) Libparted calls ioctl() BLKPG_DEL_PARTITION on every partition to
delete every partition from the kernel. Succeeds on non-busy
partitions only;
3) Kernel emits udev partition remove event on every removed partition;
4) Libparted calls ioctl() BLKPG_ADD_PARTITION on every non-busy
partition to re-add the partition to the kernel;
5) Kernel emits udev partition add event on every added partition;
6) Udev rule:
SUBSYSTEM=="block", ACTION=="add", ENV{ID_FS_TYPE}=="linux_raid_member", \
RUN+="/sbin/mdadm -I $tempnode"
from either /lib/udef/rules.d/64-md-raid.rules or
.../65-md-incremental.rules incrementally starts the member in a
Linux Software RAID array.
Fix by temporarily adding blank override rules files which does nothing,
so that when the udev add and remove events for Linux Software RAID
array member partitions fire nothing is done; but only when required.
Note that really old versions of udev don't have rules to incrementally
start array members and some distributions comment out such rules.
Bug #709640 - Linux Swap Suspend and Software RAID partitions not
recognised
This enhancement removes the virtual file systems from the list of file
systems (shown below) to be masked.
The following output was captured using Fedora 19:
$ systemctl list-units --full --all -t mount
UNIT LOAD ACTIVE SUB DESCRIPTION
-.mount loaded active mounted /
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
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
sys-fs-fuse-connections.mount loaded active mounted FUSE Control File System
sys-kernel-config.mount loaded active mounted Configuration File System
sys-kernel-debug.mount loaded active mounted Debug File System
tmp.mount loaded active mounted Temporary Directory
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.
10 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
Bug #708378 - Advertised new feature: Use systemctl runtime mask to
prevent automounting (#701676) doesn't work
A mistake was made in the following commit:
Use systemctl runtime mask to prevent automounting (#701676)
4c109df9b5
The intention was to use 'systemctl list-units' rather than
'systemctl list-unit-files' so that auto-generated mount files would
also be masked and hence prevented from auto-mounting.
Now 'systemctl list-units' is used.
Bug #708378 - Advertised new feature: Use systemctl runtime mask to
prevent automounting (#701676) doesn't work
Only one partition editing tool should be in use at any one point
in time. If more than one is in use concurrently, then data loss
might occur through operations on common partitions or partition
tables. As such, prevent multiple copies of GParted from running
at the same time.
With the beta release of Fedora 19, invoking gparted appears to
automatically mount partitions. The systemd daemon appears to be
performing the automounting. Hence use systemctl runtime mask to
prevent this automounting from occurring.
Bug #701676 - gparted doesn't inhibit systemd mounting, leading to
potential data loss
Note the license text of this file differs slightly from the C++
source code license text to indicate this file is a part of GParted.
See: https://www.gnu.org/licenses/gpl-howto.html
For programs that are more than one file, it is better to replace
“this program” with the name of the program, and begin the
statement with a line saying “This file is part of NAME”.
- Removed gparted-disable-automount.fdi handling.
- Renamed gparted binary to gpartedbin to permit a calling script to be named gparted.
- Added new calling script gparted.in to permit using hal-lock to acuiqre device locks to prevent automounting while executing gpartedbin.
- Renamed gparted.desktop.in to gparted.desktop.in.in to permit parsing installdir.
svn path=/trunk/; revision=826
