Partitions display wrong in gnome -disks - ok in gparted

[hockenberry]

* Impact

gnome-disk-utility sometime displays the wrong partitons informations

* Test case

On a system with an extended partition start gparted, close it and start gnome-disk-utility, the layout displayed should be correct

* Regression potential
check that partitions handling is still working correctly in g-d-u

--------------------

The partitions displayed by gnome-disk-utility are wrong. When i use gparted the partitions displayed are correct.

The display became wrong after i deleted 1 partition from the disk using gnome-disk-utility.

Here is a screenshot of the 2 tools vision of the same disk:
http://pasteboard.co/PjWpqeNzi.png

Here is the fdisk:
hippo@hippo-camp:~$ sudo fdisk -l
[sudo] password for hippo:
Disk /dev/sdc: 465,8 GiB, 500107862016 bytes, 976773168 sectors
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: 0x1c0966b0

Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 63 758587953 758587891 361,7G 7 HPFS/NTFS/exFAT
/dev/sdc3 758589438 903041023 144451586 68,9G 5 Extended
/dev/sdc5 758589440 903041023 144451584 68,9G 83 Linux

hippo@hippo-camp:~$ lsb_release -rd
Description: Ubuntu 16.04.1 LTS
Release: 16.04

gnome-disk-utility:
  Installed: 3.18.3.1-1ubuntu1
  Candidate: 3.18.3.1-1ubuntu1
  Version table:
 *** 3.18.3.1-1ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

gparted:
  Installed: 0.25.0-1
  Candidate: 0.25.0-1
  Version table:
 *** 0.25.0-1 500
        500 http://archive.ubuntu.com/ubuntu xenial/main amd64 Packages
        100 /var/lib/dpkg/status

I get *very nervous* when tools that have write access to partitions can't display them properly.

Good hunt
Matt

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: gnome-disk-utility 3.18.3.1-1ubuntu1
ProcVersionSignature: Ubuntu 4.4.0-47.68-generic 4.4.24
Uname: Linux 4.4.0-47-generic x86_64
NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
CurrentDesktop: Unity
Date: Sat Nov 12 12:16:39 2016
ExecutablePath: /usr/bin/gnome-disks
InstallationDate: Installed on 2016-10-11 (31 days ago)
InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
SourcePackage: gnome-disk-utility
UpgradeStatus: No upgrade log present (probably fresh install)

[hockenberry (hockenberry32)]

After initial reporting: i close the app and relaunch it, same problem, partitions are still wrongly displayed in disks.

[hockenberry (hockenberry32)]

Relaunching the app does not solve the issue but rebooting does:
https://dl.dropboxusercontent.com/u/1307844/ubuntu_bug_disks2.png

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[kurac palac (ko-te-jebe)]

Same thing here + regular crashing when executing commands (format, SMART, disk imaging)

[hockenberry (hockenberry32)]

i fixed the broken link in the original post (dropbox has decided to break things without notice to the user...), welcome pasteboard.co!

[hockenberry (hockenberry32)]

updated link for #3:
http://pasteboard.co/Pk4dEPgiY.png

[Corey Kearney (snkiz-deactivatedaccount)]

17.10 still happening

[kurac palac (ko-te-jebe)]

Why is still no one assigned to this?

[Jerzy Orlowski (jerzyorlowski)]

I have the same problem. I have an encryoted partition on extended volume and I cannot manage it. gnome-disks does not work (shows free space). Gparted does not suppport modifying encrypted disks.

[Francis Chin (chinf)]

I see a similar problem with incorrect partition information in gnome-disk-utility. I am not sure if it's exactly the same as the OP's issue as in my case the problem is solely triggered by running GParted, and not by the deletion/modification of partitions as mentioned by the OP.

I suspect that GParted is somehow causing udisks2 to report incorrect information. Running "udisksctl info -b /dev/<partition device>" for the extended partition (the one that's incorrectly displayed by gnome-disk-utility) - shows the Block object's Size is 0 instead of 1024 and "IsContainer" value is false instead of true. Rebooting restores the values to be correct.

If the OP is still around and can confirm that udisksctl also shows incorrect partition data in their case, then perhaps this bug would be better assigned to the udisks2 package rather than gnome-disk-utility (there is an upstream bug tracker in Gitlab for the latter in any case).

My testing so far has only been on 16.04; there is a newer udisks2 packaged with 18.04 onwards, so if time permits I'll try and replicate this there too.

[hockenberry (hockenberry32)]

OP here, unfortunately I changed my PC since reporting this bug and further testing would be irrevelant. Not sure what you mention is similar though. My issue was with the gnome disk utility, gparted worked perfectly.

[Francis Chin (chinf)]

I've tested with 18.04 and the newer udisks also shows the same behaviour.

From further digging I've found that there is an open issue for a udisks partition property loss bug which seems to be an exact match at https://github.com/storaged-project/udisks/issues/425

[Francis Chin (chinf)]

Re: comment #14: I never said GParted wasn't working - I said that in my case running GParted was causing Disks (gnome-disk-utility) to show buggy behaviour.

From reading the udisks2 issue, the problem seems to do with the udev change event that's triggered either by running GParted or making partition changes using gnome-disk-utility, so our cases may have the same root cause. Running "udevadm info <partition device>" before and after the triggering action also shows the loss of partition info for me.

Perhaps udev is the next place to look, as per udisks issue 425?

[Bougron (francis-bougron)]

Hello
tested today with DAILLY COSMIC!!!!

The partitions displayed by gnome-disk-utility are good the first time.

But stopping gnone-disk-utility, and using gparted ONLY to SEE and stopping it.
then reusing gnomme-dish-utility show that extended partition shows that the extended partition has disappeared.

[Bougron (francis-bougron)]

Of course, it is DAILY DISCO (19.04), See sncreemshot.

[Vincent Raspal (vinraspa)]

Hello.
I have the same problem on both ubuntu 16.04 and 18.10.
The problem appeared after removing a logical partition from and extended.

* The extended partition is correctly displayed in gnome-disk-utility after system start up
* The extended partition does not show anymore in gnome-disk-utility after gparted is launched (until next startup).
* The extended partition does not show anymore in gnome-disk-utility after creating then removing a new logical partition in gnome-disk-utility (until next startup).
* The extended partition is correctly displayed in gparted.

[Sancho (san.san)]

Hi,
I'm on Cinnamon Mint 19.0 / 19.1 and have the same problem:
After starting GParted once, the partition info for GNOME Disks (extended partition only) is permanently lost, even without any action in GParted.
The corruption shows the extended partition empty, but it is not.
Also see https://gitlab.gnome.org/GNOME/gparted/issues/33
Please, it's time to move!

[Sebastien Bacher (seb128)]

Thanks for the comment here, it would make more sense to write your finding on the upstream report though since Ubuntu doesn't have a dedicated udisk/gdu maintainer and it's more likely that the info are useful upstream

[Sancho (san.san)]

Even if it would, I (n00b) don't know what you mean by "upstream".
In Debian they still have serious udisks probs with add-, change-, update events (#571, 572, 573, 574, 581, 613), but I fail to see the context to simply opening GParted.
And I don't gitMi$o, sorry.

[pothos (pothos)]

Found the problem: The Debian source for the libparted package does not include the patch introduced by commit c6dc6e5d in 2015 (No official parted release since 2014, so picking commits is unfortunately needed).

[hockenberry (hockenberry32)]

OP here. When I see this thread I wonder how a gnome-disk problem can become a parted one. Did anyone read my bug report???

[Colin Watson (cjwatson)]

@hockenberry32: I don't think your sarcasm is warranted. gnome-disks uses udisks2, which uses libblockdev, which uses libparted. I confirmed gnome-disks misbehaviour with extended partitions that was fixed by cherry-picking the parted fix mentioned in comment #23.

[Launchpad Janitor (janitor)]

This bug was fixed in the package parted - 3.2-25

---------------
parted (3.2-25) unstable; urgency=medium

  * Cherry-pick from upstream:
    - libparted: BLKPG_RESIZE_PARTITION uses bytes, not sectors (closes:
      #926735, LP: #1641308).

 -- Colin Watson <email address hidden> Mon, 15 Apr 2019 15:38:11 +0100

[A Raghuram (araghuramindia)]

I am using Ubuntu Bionic on Desktop. Same problem i.e. once gparted is opened, the gnome disk utility displays the partitions incorrectly. Will this be fixed any time soon ?

[PERCE-NEIGE (perce-neige)]

Same problem, it is unable to see extended partitions.

[Sebastien Bacher (seb128)]

I've uploaded a SRU fix to bionic

[Robie Basak (racb)]

Hello hockenberry, or anyone else affected,

Accepted parted into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/parted/3.2-20ubuntu0.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Robie Basak (racb)]

> * Regression potential
> check that partitions handling is still working correctly in g-d-u

Yes, but I think some more detail is required here. An accidental regression caused by this patch could lead to data loss.

Please see https://wiki.ubuntu.com/StableReleaseUpdates#Procedure - we need "a discussion of how regressions are most likely to manifest, or may manifest even if it is unlikely, as a result of this change" and (implied) thoughts towards specifically what needs to be tested based on that discussion.

I've accepted the patch into proposed as it seems correct and important to fix, but I don't think this should be accepted into bionic-updates after SRU verification until the documented regression mitigation steps are completed in full.

[Sebastien Bacher (seb128)]

@Robie, ack. I will try to update that section but if others want to help with it that would be welcome

[Łukasz Zemczak (sil2100)]

The version of parted in the proposed pocket of Bionic that was purported to fix this bug report has been removed because the bugs that were to be fixed by the upload were not verified in a timely (105 days) fashion.