Jeff
Does it happen every time you run it?
Can you give the console output when running drakconf from the console.
There are several other drakconf crash bugs outstanding, we need to know whether yours is similar to them, or a new case.

CC: (none) => lewyssmith

drakconf
Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 525.
"cannot run /usr/sbin/isodumper" since it is not installed [Writing ISO] at /usr/libexec/drakconf line 833.
GLib-LOG **: posix_spawn avoided (child_setup specified)  at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 67.
GLib-LOG **: posix_spawn avoided (child_setup specified)  at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 67.
Too late to run INIT block at /usr/lib64/perl5/vendor_perl/Glib/Object/Introspection.pm line 257.
Ignore the following Glib::Object::Introspection & Gtk3 warnings
Subroutine Gtk3::main redefined at /usr/share/perl5/vendor_perl/Gtk3.pm line 525.
Error: The primary GPT table is corrupt, but the backup appears OK, so that will be used.
INTERNAL ERROR: unknown device sdb1
MDK::Common::Various::internal_error() called from /usr/lib/libDrakX/devices.pm:131
devices::entry() called from /usr/lib/libDrakX/devices.pm:146
devices::make() called from /usr/lib/libDrakX/fs/type.pm:257
fs::type::call_blkid() called from /usr/lib/libDrakX/fs/type.pm:264
fs::type::type_subpart_from_magic() called from /usr/lib/libDrakX/fsedit.pm:292
fsedit::get_hds() called from /usr/libexec/diskdrake:74

I have seen messages like this when dealing with mdadm arrays.
The array is fine, but I have seen messages like 'unknown device sdb1' before.

Thank you for this information. This is not like the other drakconf crashes.

Assigning to the Tools group.

CC: lewyssmith => (none)
Summary: drakconf crashed when I run it => drakconf crashed with mdadm array
Assignee: bugsquad => mageiatools

You means diskdrake crashed, not the control center, right?

Keywords: (none) => NEEDINFO
CC: (none) => thierry.vignaud

Likely. I accessed it through the control center.
The control center did not crash.

Also the hardware info applet crashed in the control center crashed.

I have been reporting issues installing mageia when a mdadm array is present for several years and several releases. Pretty sure the issue is ongoing.

It seems the whatever program that examines disks doesn't like mdadm arrays, and often crashes when it encounters them.

gparted doesn't have any issues looking at disks in a mdadm array.

Related to this it seems:
https://bugs.mageia.org/show_bug.cgi?id=27582

CC: (none) => ouaurelien

Currently diskdrake only supports mdadm arrays created from disk partitions with the correct partition type ("Linux RAID"), not arrays created from raw devices. If you use diskdrake to create the RAID array, everything works well.

Maybe we could detect raw devices that are part of an existing array and exclude them from the devices diskdrake can modify.

CC: (none) => mageia

I created the array with mdadm and brand new disks.
I don't expect diskdrake to work with it; I just expect it not to crash and produce fatal errors.

This is stopping me from looking at my hardware configuration as well as failing to fully install linux kernel updates. I am sure there are other issues with diskdrake producing fatal errors as well.

Created attachment 11991 [details]
Patch to handle RAID components created on raw disk devices

This patch modifies fsedit::get_hds() to detect raw disk devices that contain a mdadm superblock and add them to the raw_hds list instead of the hds list. This avoids the internal error and allows the RAID array to be properly displayed in diskdrake. diskdrake does not display raw HDs, so it is not possible to add or remove the array components, but I don't see that as a problem - we should be encouraging users to create the array components in partitions.

Fixed in cauldron with drakxtools 18.35.

Mageia 7 is EOL since July 1st 2021.
There will not have any further bugfix for this release.

You are encouraged to upgrade to Mageia 8 as soon as possible.

@reporter, if this bug still apply with Mageia 8, please let us know it.

@packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead.

This bug report will be closed OLD if there is no further notice within 1st September 2021.

Hi bug reporter and hi assignee and others involved,

Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly.

This report is being closed as OLD because it was filed against Mageia 7, for which  support ended on June 30th 2021.

Thanks,
Marja

Status: NEW => RESOLVED
Resolution: (none) => OLD