Thank you censlin for your interest in GParted and pointing out this discrepancy.

GParted was designed to work with partition tables.  As such, the incorrect detection of the device/partition name for a file system on a device lacking a partition table is not surprising.  Having said this, it would certainly be beneficial if GParted could at least properly recognize when a device has been entirely formatted with a file system instead of having a partition table.

The mission statement that guides development of the GParted application can be found at the following link:
http://gparted.org/development.php#mission-statement

This appears to be caused by the way that libparted reports such devices.  It says the disk has a partition table of type "loop" with one partition that contains the whole drive.  gparted probably should notice this and strip the partition number when calculating the device path.

Actually, the path comes from libparted, so it looks like that is where the bug lies.  I'll try to work up a patch.

I have fixed bugs in both parted and gparted to solve this issue.  It turns out there are two bugs in gparted that the following patch fixes.  First, gparted was killing the parted loop label when trying to format the filesystem, causing it to fail, and second, it was trying to set/clear the LVM partition flag, even though most partition types do not support it, including the loop partition type.  Between the two patches, you can now use gparted on partitionless devices.  If it already has a filesystem on it, parted reports a "loop" label with a single partition containing the filesystem, and if not, you can create a loop label, then format the partition to the filesystem type of your choice.

Created attachment 264983 [details] [review]
0001-Fix-loop-labels.patch

Created attachment 265286 [details] [review]
0001-Fix-loop-labels.patch

Had to tweak the patch a bit.  It's working well for me now.

Hi Phillip,

Can you point me to the patches for parted.  I assume they are necessary
because when testing the display of a partitionless device GParted is
getting back "/dev/md2p1" from ped_partition_get_path() for the name of
the first, only, partition.  This then caused GParted to use this
non-existent device to try to query the file system causing error like:

    tune2fs: No such file or directory while trying to open /dev/md2p1
    Couldn't find valid filesystem superblock.

Thanks,
Mike

Yep, that was ( part of ) the problem.  I posted an updated patch last night to bug-parted@gnu.org.  I've also backported it to the debian package and have emailed it to Colin Watson and asked him to upload it, so hopefully it will get into debian unstable and ubuntu 14.04 soon.

Hi Phillip,

While compiling parted v3.1-66-gcf16ea8 from git with your patch added
from http://lists.gnu.org/archive/html/bug-parted/2014-01/msg00001.html
I needed to fix this one line in the parted test case for it to pass.

--- a/tests/t1102-loop-label.sh	2014-01-07 15:29:18.220518291 +0000
+++ b/tests/t1102-loop-label.sh	2014-01-07 15:26:27.634837728 +0000
@@ -73,7 +73,7 @@
 # make sure partition busy check works ( mklabel checks whole disk )
 parted -s "$dev" rm 1 > out 2>&1; test $? = 1 || fail=1
 # create expected output file
-echo "Error: Partition /dev/sde is being used. You must unmount it before you modify \
+echo "Error: Partition $dev is being used. You must unmount it before you modify \
 it with Parted." > exp
 compare exp out || fail=1
 
Thanks,
Mike

Woops, how did that slip in?  Thanks... the tests also fail on non 512 byte sector sizes because parted was still not fixed to detect filesystems there, hence the other patch I submitted to fix that.

Hi Phillip,

From my testing so far it doesn't appear to be necessary to force the
creation of ext2/3/4 and ntfs file systems.  Do you have a scenario
where it was necessary?

Thanks,
Mike

When you try to format a disk with no partition table, they complain that you have to force it to run on a whole disk.

Mkfs of ext2/3/4 (e2fsprogs-1.42.7) and ntfs (ntfsprogs-2013.1.13)
certainly didn't require forcing on Fedora 19.

Which OS did require forcing to run on a whole disk and what were
the versions?

Are you using a loop device or a real disk?  I'm using Ubuntu 13.10, so e2fsprogs-1.42.9 and ntfs3g-1:2013.1.13AR.1-2ubuntu1.

Hi Phillip,

I'd done all my testing until now on Linux Software RAID arrays and
mkfs didn't require forcing on those.  Now I try on a whole disk it does
need forcing.  Sorry for the noise.

Thanks,
Mike

Created attachment 266080 [details]
GParted details - [1] "format to" error

Hi Phillip,


When I format the pretend partition table which fills a loop labelled
disk I get the attached error.  The code sequence in GParted is like
this:
    format()
        erase_filesystem_signatures()
        create_filesystem()
        set_partition_type()
            get_device_and_disk()
            ped_file_system_type_get("ext4")
            ped_disk_get_partition_by_sector()
            ped_partition_is_flag_available()
            ped_partition_set_system()
            commit()
                ped_disk_commit_to_dev() -> 0  //fail
            commit_to_os()
                ped_disk_commit_to_os() -> 1  //success
Looks like a libparted issue to me.


I've reviewed the code and I would like you to make the following
changes:

1)  Change the first patch so that it only does this:
    In set_partition_type() for the loop label case add an operation
    detail message something like this:
        Skipped.  Unnecessary for loop labels
    and does nothing else.  Other partition types are treated as they
    are now.

2)  Move the adding of the force flags to creation of ext* and ntfs
    file systems into a second patch.

This works around the above error and keeps the original ordering and
informs the user why setting partition type is skipped:
    erase file system signatures
    set partition type (reports skipping for loop labels)
    create new file system


Thanks,
Mike

Oops, I fixed that in the create path by switching the order of create_filesystem and set_partition_type.  I thought I got it in the format path too, but apparently not.

Why do you think the force flags should be in another commit?  It seems pretty tightly coupled to this change to me.

Hi Phillip,

(In reply to comment #17)

> Oops, I fixed that in the create path by switching the order of
> create_filesystem and set_partition_type.  I thought I got it in the
> format path too, but apparently not.

See the order in the attached details.  You already did switch the order
to create_filesystem() then set_partition_type() in format case.  


> Why do you think the force flags should be in another commit?  It
> seems pretty tightly coupled to this change to me.

Most file systems can already be created on whole disks so just having
working loop label handling is a useful first patch.  Putting force
flags in a second patch allows (me to write) a more explicite commit
message showing the failure of mkfs.ext2 without the force flag.  Both
patches will still get tagged with this bug number.

Thanks,
Mike

Hi Phillip and Mike,

I was reviewing this report and if I have interpreted the progress correctly, both the libparted patches and gparted patches require work.

1)  Recent bug-parted mailing list thread on fix-loop-labels patch for
    libparted:
https://lists.gnu.org/archive/html/bug-parted/2014-03/msg00011.html

2)  Request thread for gparted patch changes starting with comment #16.

If I have misunderstood the status of this patch, then please feel free to correct me.

Curtis

Mike wanted the gparted patches split up.  I've already taken care of the parted patch, just forgot to post the revised one to the mailing list.  I'll do that tonight and get it pushed soon and it will be in parted 3.4.  We can revisit this once that's out.

Hi Phillip,

Thank you again for working on both parted and gparted.  If there is some additional testing I can help with for the parted release, then please let me know.

I agree that we can revisit this patch once the libparted patch is more widely available either in a new release or at least a patched version in a distro.

In general I find that Mike's code is much easier to understand and hence maintain than my own code -- especially when I have to go back and look at it several months later.  As such I think his suggestions are good improvements.  The first suggestion in comment #16 would also help identify in the details log why the partition operation is skipped.

Curtis

Good news!  The libparted fix for this has hit debian unstable as well as Ubuntu Trusty!

Hi Phillip,

It looks like libparted 3.2 includes several patches to fix loop labels, starting with:

libparted: fix loop labels to not vanish
http://git.savannah.gnu.org/cgit/parted.git/commit/?id=32d637298717446a4edd3c8fbe637462fab4c000

(Thanks for your efforts on parted 3.2 by the way. :-)

With the loop label fixes in libparted, now is probably a good time to revisit this patch.

Will you have time to revisit this patch and address the suggestions in comment #16?

Curtis

Hi Phillip,

Mike has been working on GParted read-only support for whole disk devices (no partition table).  It appears that libparted does not set up a virtual "loop" partition table if libparted does not recognize the disk signature (e.g., LVM2 PV or Reiser4).  As such Mike has pursued a different path.  See:

Bug 741430 - GParted cannot recognise LVM signature on unpartitioned drive

Curtis

Right, so just like you do with any blank disk, you create a partition table.  In this case, you choose the loop label, and then you can format the fake partition with the filesystem of your choice.

Testing of patch in comment #6 using method from comment 25 has been posted in bug 741430 comment 15.

Portions of the patches in this report by Phillip have been incorporated into the following report:

   Bug 743181 - Add unpartitioned drive read-write support

Also thank you Phillip for fixing issues with "loop" labels in libparted.

Marking this report as a duplicate of the above listed report.

*** This bug has been marked as a duplicate of bug 743181 ***