Active Linux software RAID devices are detected in the
Proc_Partitions_Info method. Hence the SWRaid method is no longer
required.
Removal of the SWRaid method fixes the problem with the error message:
Could not stat device /dev/md/0 - No such file or directory
This fixes the problem because we no longer use "mdadm --examine
--scan" in an attempt to detect Linux software RAID devices. The
mdadm command was returning device names such as /dev/md/0, which are
incorrect for GParted.
NOTE: With this change, GParted no longer requires the mdadm command
to detect Linux software RAID devices.
Closes Bug #678379 - Could not stat device /dev/md/0 - No such file or
directory
Add regular expression to detect the device entry only (e.g., md127)
and not the partitions (e.g., md127p1).
Linux software RAID devices are listed in /proc/partitions as follows:
# cat /proc/partitions
major minor #blocks name
9 127 523968 md127
259 0 131072 md127p1
259 1 262144 md127p2
Part of Bug #678379 - Could not stat device /dev/md/0 - No such file
or directory
HP Smart Array Devices are listed in /proc/partitions as follows:
major minor #blocks name
104 0 143338560 cciss/c0d0
104 1 104391 cciss/c0d0p1
104 2 24097 cciss/c0d0p2
104 3 143203410 cciss/c0d0p3
The previous regular expression was too broad, and would match many
other forms, including Linux software RAID devices such as md127.
Linux software RAID devices are listed in /proc/partitions as follows:
major minor #blocks name
9 127 523968 md127
259 0 131072 md127p1
259 1 262144 md127p2
This problem with the regexp was discovered while investigating a
problem with Linux software RAID device detection.
The regular expression has been tightened up to match the following
hardware RAID controllers:
Compaq/HP Smartarray RAID controller
E.g., device = /dev/cciss/c0d0, partition = /dev/cciss/c0d0p1
(linux-x.y.z/Documentation/blockdev/cciss.txt)
Compaq SMART2 Intelligent Disk Array controller
E.g., device = /dev/ida/c0d0, partition = /dev/ida/c0d0p1
(linux-x.y.z/Documentation/blockdev/cpqarray.txt)
Mylex DAC960/AcceleRAID/eXtremeRAID PCI RAID Controllers
E.g., device = /dev/rd/c0d0, partition = /dev/rd/c0d0p1
(linux-x.y.z/Documentation/blockdev/README.DAC960)
Related to Bug #678379 - Could not stat device /dev/md/0 - No such
file or directory
In certain situations with a mixture of partition alignments, the MiB
alignment option would try to set the end of a logical partition
beyond the end of the extended partition. This, of course, is an
invalid partition geometry and the libparted library correctly reports
failure when this is attempted.
This enhancement to MiB alignment adds a check to see if the end of
the logical partition would be beyond the extended partition, and
adjusts the end of the logical partition if required.
Closes Bug #686668 - Growing logical partition overlaps end of
extended partition
Prior to this enhancement, GParted ignored the status of the partition
grow operation, and attempted to grow the file system.
Now we check the status of the partition grow operation prior to
growing the file system.
Part of Bug #686668 - Growing logical partition overlaps end of
extended partition
A reiser4 file system with a blank label is displayed as "<none>" by
debugfs.reiser4 and therefore GParted too.
# mkfs.reiser4 -y -L "" -f /dev/sda14
# debugfs.reiser4 /dev/sda14 2> /dev/null | grep label:
label: <none>
Additionally when displaying the Partition Information the following
warning is written to the terminal:
(gpartedbin:19609): Gtk-WARNING **: Failed to set text from markup
due to error parsing markup: Error on line 1 char 23: Element
'markup' was closed, but the currently open element is 'none'
Fix by just assuming "<none>" always means blank. If someone really
does set the label to "<none>" it won't be displayed. This is equlivant
to how btrfs and nilfs2 are already handled.
Closes bug 688760 - GParted displays blank resier4 label as <none>
If gksu was installed on a KDE system (tested with kubuntu 12.04 LTS),
then gksu would prompt for the password three times and always fail to
load gparted. In a prior version of kubuntu 8.04 LTS, gksu would
properly invoke gparted from the "K --> System --> GParted" menu
entry.
Since gksudo also works on KDE (and kubuntu 12.04 LTS), add gksudo to
the root privilege invocation search list ahead of gksu.
Note that gksu has been kept for backwards compatibility with systems
that provide only gksu and not gksudo.
Related to Bug #687813 - Use kdesudo on KDE, as gksu is not
installed by default
Normally gksu is not installed by default on KDE systems. When
compiling and installing gparted on a KDE system without gksu, the
desktop menu entry would try to run gparted as the user, and not with
root privileges.
To fix this, add kdesudo to the search list of root privilege
invocation programs.
Closes Bug #687813 - Use kdesudo on KDE, as gksu is not installed by
default
1) lp_disk is not used and assigned NULL so doesn't need closing.
2) lp_device is already ped_device_open()ed and ped_device_close()d
within the above while loop. lp_device will be set to NULL when the
while loop ends so this doesn't need closing either. Hence
close_device_and_disk() is always passed with two NULL pointers and is a
no operation so can be removed.
They were used like global variables. Now they are moved to the
functions that actually use them to make clearer how the data flow is.
Bug #683149 - Cleanup(?): Remove lp_device and lp_disk from GParted_Core
Use swaplabel to read the Linux swap label so that 1) a blank label can
be read, and 2) to replace deprecated and removed vol_id.
Vol_id was deprecated in May 2009, superseded by blkid and soon
thereafter removed. Swaplabel is available in util-linux 2.18 from Jun
2010.
If the swaplabel command is not available GParted falls back on reading
the label through the FS_Info cache which uses the blkid command. If
the blkid command is also not available FS_Info cache will *NOT* return
any label and GParted will display blank.
Bug 685656 - GParted doesn't notice when file system label is changed to
blank
GParted doesn't notice when a file system label is changed to blank.
GParted first calls the file system specific read_label() method. When
the label is blank read_label() correctly sets partition.label to the
zero length string. Second GParted_Core::set_device_partitions() treats
the zero length string to mean that the label is unset and calls
FS_Info::get_label() to retrieve it from the cache of blkid output.
Blkid also doesn't notice when the file system label has been changed to
blank so reports the previous label. Hence GParted displays the
previous file system label.
Fix by making label a private member variable of the class Partition and
providing access methods set_label(), get_label() and label_known()
which track whether the label has been set or not. This only fixes the
fault for file systems which use file system specific commands to read
the label and when these tools are installed. Otherwise GParted uses,
or has to fall back on using, the buggy blkid command to read the file
system label.
NOTE:
Many of the file system specific read_label() methods use a tool which
outputs more than just the label and use Utils::regexp_label() to match
leading text and the label itself. If the surrounding text changes or
disappears altogether to indicated a blank label, regexp_label() doesn't
match anything and returns the zero length string. This is exactly
what is required and is passed to set_label() to set the label to blank.
Bug 685656 - GParted doesn't notice when file system label is changed to
blank
Traced debugreiserfs on a 10GiB reiserfs file system which was 100% full
full with nearly 900,000 files. It read exactly three 4KiB blocks from
different offsets and the program never took more than 0.1 seconds.
A user had a 190 MiB partition containing an old ext2 file system. When
unmounted it was reported as filling the partition, but when mounted it
was reported as having 6% unallocated space. The file system's inode
tables were approximately twice the size of those created by default
with the current mkfs.ext2 defaults.
To create an equivalent file system in a 190 MiB partition:
mkfs.ext2 -N 97344 /dev/sda15
It turns out that for ext2, ext3 and ext4 file systems what was
described as intrinsic unallocated space during the development of
Bug #499202 is actually file system overhead. When mounted the ext2/3/4
kernel code reports the size of the file system after subtracting the
overhead. Overhead is made up of superblock backups, group descriptors,
allocation bitmaps and largest of all inode tables. E2fsprogs tools
don't subtract this overhead when reporting the file system size.
References:
* The Second Extended File System, Internal Layout, by Dave Poirier
http://www.nongnu.org/ext2-doc/ext2.html
* Linux ext2_statfs() function
http://lxr.linux.no/#linux+v3.5.3/fs/ext2/super.c#L1311
Call the file system specific method for reading the usage of ext2, ext3
and ext4 file systems while mounted. Make it read the file system size
from the on disk superblock to avoid subtraction of overhead and use the
statvfs() system call to return an up to date free space figure.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
Each file system class can now choose how the size and free space of the
file system is determined when it is mounted.
.fs.online_read = FS::NONE (default)
Do nothing. Don't get the file system size and free space.
.fs.online_read = FS::GPARTED
Use internal GParted method which calls statvfs() system call on
the mounted file system.
.fs.online_read = FS::EXTERNAL
Call the file system's member function set_used_sectors(). This
is the same function as called when the file system is not
mounted. It can determine if the file system is mounted or not
by testing partition.busy and acting accordingly.
This means that determining the size and free space of active LVM2
Physical Volumes is no longer a special case. Instead the lvm2_pv class
just elects to have its set_used_sectors() method called for both the
active and deactive cases.
Bug #683255 - ext2: statvfs differs from dumpe2fs (x MB unallocated
space within the partition)
Vol_id command was deprecated in May 2009 and superseded by the blkid
command. Replace the generic vol_id command with the file system
specific debugfs.reiser4 command to read the file system label.
Debugfs.reiser4 will exist as it's already required to read the file
system usage and UUID.
Use the new RFC 4122 none Nil UUID regular expression to validate the
UUID read in all the Linux native file system specific read_uuid()
methods. No longer need to explicitly exclude "<none>" or all zeros Nil
UUID as the regular expression does this.
Not necessary but use the simpler file system tune command rather than
the file system debug command where possible. Also saves creating an
echo process.
For a mounted reiserfs file system with a Nil UUID (all zeros) GParted
will display a partition specific warning. This comes from the reiserfs
specific read_uuid() method. Error demonstration:
# blkid /dev/sda15
/dev/sda15: LABEL="test-reiserfs-2" TYPE="reiserfs"
# mount | grep sda15
/dev/sda15 on /mnt/2 type reiserfs (rw,relatime)
# reiserfstune /dev/sda15
reiserfstune: Reiserfstune is not allowed to be run on mounted filesystem.
Switch to using debugreiserfs to read the UUID as it can be used on a
mounted file system.
# debugreiserfs /dev/sda15 2> /dev/null | grep UUI
UUID: 00000000-0000-0000-0000-000000000000
Bug #684115 - Reiserfs UUID reading issues on Fedora and CentOS
On Fedora up to and including Fedora 16 and Red Hat and CentOS up to the
current 6.3 release the UUID of an unmounted reiserfs file system is
displayed as "<no" and a GTK markup warning is written to the terminal.
This was because the reiserfs-utils package isn't linked with libuuid
support so reiserfs file systems were created with a Nil UUID (all
zeros). To read the UUID GParted first tries to retrieve the UUID from
the blkid command output via the FS_Info cache. Secondly it tries the
reiserfs file system specific read_uuid() method which uses the first
space separated word following the text "UUID:", hence it gets "<no".
# debugreiserfs /dev/sda15 2> /dev/null | grep UUID
UUID: <no libuuid installed>
In September 2012 Red Hat bug 660285 "reiserfstune compiled without UUID
support" was fixed for Fedora 16 and later releases. On Fedora with
this fix applied GParted will display the Nil UUID (all zeros) for a
previously created reiserfs file system rather than suppressing it.
Only accept valid, none Nil UUIDs in the reiserfs file system specific
read_uuid() method.
Bug #684115 - Reiserfs UUID reading issues on Fedora and CentOS
Curtis Gedak