Activity log for bug #1074606

Date Who What changed Old value New value Message
2012-11-03 10:46:03 martin suchanek bug added bug
2012-11-03 21:06:04 Phillip Susi gparted (Ubuntu): status New Invalid
2012-11-07 02:10:42 Phillip Susi bug watch added https://bugzilla.gnome.org/show_bug.cgi?id=678379
2012-11-07 02:10:42 Phillip Susi bug task added gparted
2012-11-07 02:11:09 Phillip Susi gparted (Ubuntu): importance Undecided Medium
2012-11-07 02:11:09 Phillip Susi gparted (Ubuntu): status Invalid Triaged
2012-11-07 02:12:33 Phillip Susi summary gparted raid wrong information gparted identifying incorrect raid arrays
2012-11-07 02:15:38 Phillip Susi description Hi, I have noticed that information about raid (in my case raid0 arrays) are completely wrong. Partition name is wrong - !!! it is always adding 'p1' at the end of the device name (partition). Label is wrong - is not detected at all. flags is empty Managed flags is empty. used and unused is empty. The thing is that I am normally running on that OS instance without any problem. Fsck saying it is clean. lsb_release -rd Description: Ubuntu 12.10 Release: 12.10 apt-cache policy gparted gparted: Installed: 0.14.0-1~getdeb1 Candidate: 0.14.0-1~getdeb1 Version table: *** 0.14.0-1~getdeb1 0 500 http://archive.getdeb.net/ubuntu/ quantal-getdeb/apps amd64 Packages 100 /var/lib/dpkg/status 0.12.1-1 0 500 http://archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages apt-cache policy libparted0debian1 libparted0debian1: Installed: 2.3-10ubuntu2 Candidate: 2.3-10ubuntu2 Version table: *** 2.3-10ubuntu2 0 500 http://archive.ubuntu.com/ubuntu/ quantal/main amd64 Packages 100 /var/lib/dpkg/status This errors have apperead in the previous versions of gparted as well BUT not all of them. From the version 14 release it is all information wrong and it is not even possible to change them. It is only valid for raid0 arrays. I am not aware of if those errors appeared on other raid level configurations. Let me know if you need more information. Regards, M. On startup, gparted complains with several popups that it has an internal parted bug trying to stat /dev/md/XXXX. This appears to be caused by its reliance on running mdadm --examine --scan to identify raid arrays. Recent versions of mdadm now report the existence of "containers" that are not usable block devices, but gparted thinks they are. It also reports the preferred major number rather than the actual. In other words, if the metadata says it is supposed to be /dev/md0, that is what mdadm reports, however it may have been activated as /dev/md127 instead, causing gparted to try to use a device that does not exist.
2012-11-07 04:26:31 Bug Watch Updater gparted: status Unknown Incomplete
2012-11-07 04:26:31 Bug Watch Updater gparted: importance Unknown Medium
2012-11-15 01:46:53 Phillip Susi gparted (Ubuntu): status Triaged In Progress
2012-11-15 01:46:55 Phillip Susi gparted (Ubuntu): assignee Phillip Susi (psusi)
2012-11-15 01:47:22 Phillip Susi nominated for series Ubuntu Quantal
2012-11-16 15:59:05 Bug Watch Updater gparted: status Incomplete Confirmed
2012-11-22 19:19:23 Bug Watch Updater gparted: status Confirmed Incomplete
2012-11-28 21:41:41 Dimitri John Ledkov bug task added gparted (Ubuntu Quantal)
2012-11-29 23:12:55 Bug Watch Updater gparted: status Incomplete Confirmed
2012-12-03 19:34:11 Phillip Susi branch linked lp:~psusi/ubuntu/quantal/gparted/drop-swraid
2012-12-03 19:34:59 Phillip Susi gparted (Ubuntu Quantal): status New In Progress
2012-12-03 19:35:01 Phillip Susi gparted (Ubuntu Quantal): assignee Phillip Susi (psusi)
2012-12-03 19:41:30 Phillip Susi description On startup, gparted complains with several popups that it has an internal parted bug trying to stat /dev/md/XXXX. This appears to be caused by its reliance on running mdadm --examine --scan to identify raid arrays. Recent versions of mdadm now report the existence of "containers" that are not usable block devices, but gparted thinks they are. It also reports the preferred major number rather than the actual. In other words, if the metadata says it is supposed to be /dev/md0, that is what mdadm reports, however it may have been activated as /dev/md127 instead, causing gparted to try to use a device that does not exist. SRU Justification: Users get a popup reporting internal errors/bugs relating to oddly named raid arrays that do not exist. There was a module that probed for mdadm devices by running mdadm --examine --scan to scan all disks for raid metadata. This is incorrect and sometimes reports incorrect information so this module was removed, and gparted now relies on /proc/partitions to detect active raid arrays. There should be little to no chance of regression. I realize that normally SRU bug fixes should be deployed to the development version first, but since raring is still running the same version which is synced to debian, I would rather just wait until I upload the new upstream release that contains this fix in a few days, which will then be synced to raring. End SRU justification. On startup, gparted complains with several popups that it has an internal parted bug trying to stat /dev/md/XXXX. This appears to be caused by its reliance on running mdadm --examine --scan to identify raid arrays. Recent versions of mdadm now report the existence of "containers" that are not usable block devices, but gparted thinks they are. It also reports the preferred major number rather than the actual. In other words, if the metadata says it is supposed to be /dev/md0, that is what mdadm reports, however it may have been activated as /dev/md127 instead, causing gparted to try to use a device that does not exist.
2012-12-03 19:41:42 Phillip Susi bug added subscriber Ubuntu Sponsors Team
2012-12-03 19:41:49 Phillip Susi gparted (Ubuntu Quantal): importance Undecided High
2012-12-07 11:57:09 James Page removed subscriber Ubuntu Sponsors Team
2012-12-07 15:21:48 Phillip Susi bug added subscriber Ubuntu Sponsors Team
2012-12-12 23:10:00 Brian Murray removed subscriber Ubuntu Sponsors Team
2012-12-13 05:49:01 Bug Watch Updater gparted: status Confirmed Fix Released
2013-01-12 10:27:06 Launchpad Janitor branch linked lp:debian/gparted
2013-01-12 12:09:13 Launchpad Janitor gparted (Ubuntu): status In Progress Fix Released
2013-01-12 12:43:11 Launchpad Janitor branch linked lp:ubuntu/gparted
2013-01-14 18:44:31 Phillip Susi branch unlinked lp:debian/gparted
2013-01-14 18:44:43 Phillip Susi branch unlinked lp:ubuntu/gparted
2013-01-14 18:58:32 Phillip Susi description SRU Justification: Users get a popup reporting internal errors/bugs relating to oddly named raid arrays that do not exist. There was a module that probed for mdadm devices by running mdadm --examine --scan to scan all disks for raid metadata. This is incorrect and sometimes reports incorrect information so this module was removed, and gparted now relies on /proc/partitions to detect active raid arrays. There should be little to no chance of regression. I realize that normally SRU bug fixes should be deployed to the development version first, but since raring is still running the same version which is synced to debian, I would rather just wait until I upload the new upstream release that contains this fix in a few days, which will then be synced to raring. End SRU justification. On startup, gparted complains with several popups that it has an internal parted bug trying to stat /dev/md/XXXX. This appears to be caused by its reliance on running mdadm --examine --scan to identify raid arrays. Recent versions of mdadm now report the existence of "containers" that are not usable block devices, but gparted thinks they are. It also reports the preferred major number rather than the actual. In other words, if the metadata says it is supposed to be /dev/md0, that is what mdadm reports, however it may have been activated as /dev/md127 instead, causing gparted to try to use a device that does not exist. SRU Justification: Users get a popup reporting internal errors/bugs relating to oddly named raid arrays that do not exist. There was a module that probed for mdadm devices by running mdadm --examine --scan to scan all disks for raid metadata. This is incorrect and sometimes reports incorrect information so this module was removed upstream, and gparted now relies on /proc/partitions to detect active raid arrays. There should be little to no chance of regression. End SRU justification. On startup, gparted complains with several popups that it has an internal parted bug trying to stat /dev/md/XXXX. This appears to be caused by its reliance on running mdadm --examine --scan to identify raid arrays. Recent versions of mdadm now report the existence of "containers" that are not usable block devices, but gparted thinks they are. It also reports the preferred major number rather than the actual. In other words, if the metadata says it is supposed to be /dev/md0, that is what mdadm reports, however it may have been activated as /dev/md127 instead, causing gparted to try to use a device that does not exist.
2013-01-23 14:19:01 Marc Deslauriers bug added subscriber Ubuntu Stable Release Updates Team
2013-01-31 18:46:14 Phillip Susi description SRU Justification: Users get a popup reporting internal errors/bugs relating to oddly named raid arrays that do not exist. There was a module that probed for mdadm devices by running mdadm --examine --scan to scan all disks for raid metadata. This is incorrect and sometimes reports incorrect information so this module was removed upstream, and gparted now relies on /proc/partitions to detect active raid arrays. There should be little to no chance of regression. End SRU justification. On startup, gparted complains with several popups that it has an internal parted bug trying to stat /dev/md/XXXX. This appears to be caused by its reliance on running mdadm --examine --scan to identify raid arrays. Recent versions of mdadm now report the existence of "containers" that are not usable block devices, but gparted thinks they are. It also reports the preferred major number rather than the actual. In other words, if the metadata says it is supposed to be /dev/md0, that is what mdadm reports, however it may have been activated as /dev/md127 instead, causing gparted to try to use a device that does not exist. SRU Justification: Users get a popup reporting internal errors/bugs relating to oddly named raid arrays that do not exist. There was a module that probed for mdadm devices by running mdadm --examine --scan to scan all disks for raid metadata. This is incorrect and sometimes reports incorrect information so this module was removed upstream, and gparted now relies on /proc/partitions to detect active raid arrays. There should be little to no chance of regression. Test Case: create an mdadm raid array, but do NOT add it to /etc/mdadm.conf. After a reboot, mdadm will activate it as /dev/md127 instead of /dev/md0 because it isn't registered in the conf file. Gparted thinks it should be /dev/md0 and errors because it doesn't exist. End SRU justification. On startup, gparted complains with several popups that it has an internal parted bug trying to stat /dev/md/XXXX. This appears to be caused by its reliance on running mdadm --examine --scan to identify raid arrays. Recent versions of mdadm now report the existence of "containers" that are not usable block devices, but gparted thinks they are. It also reports the preferred major number rather than the actual. In other words, if the metadata says it is supposed to be /dev/md0, that is what mdadm reports, however it may have been activated as /dev/md127 instead, causing gparted to try to use a device that does not exist.
2013-02-21 10:34:55 Colin Watson gparted (Ubuntu Quantal): status In Progress Fix Committed
2013-02-21 10:34:59 Colin Watson bug added subscriber SRU Verification
2013-02-21 10:35:01 Colin Watson tags verification-needed
2013-02-22 04:45:18 Launchpad Janitor branch linked lp:ubuntu/quantal-proposed/gparted
2013-11-08 06:37:22 Steve Langasek gparted (Ubuntu Quantal): status Fix Committed Won't Fix