| Summary: | drakconf crashed with mdadm array | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | jeff deifik <jeff> |
| Component: | RPM Packages | Assignee: | Martin Whitaker <mageia> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | mageia, ouaurelien, thierry.vignaud |
| Version: | 7 | Keywords: | PATCH |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| See Also: | https://bugs.mageia.org/show_bug.cgi?id=27582 | ||
| Whiteboard: | |||
| Source RPM: | drakxtools-18.21-1.mga7.src.rpm | CVE: | |
| Status comment: | fixed in git master | ||
| Attachments: | Patch to handle RAID components created on raw disk devices | ||
|
Description
jeff deifik
2020-05-30 19:20:32 CEST
Jani Välimaa
2020-05-30 19:23:27 CEST
Summary:
crashed when I run it =>
drakconf crashed when I run it 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) You means diskdrake crashed, not the control center, right? Keywords:
(none) =>
NEEDINFO 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.
Martin Whitaker
2020-11-10 12:59:30 CET
See Also:
(none) =>
https://bugs.mageia.org/show_bug.cgi?id=27582 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.
Martin Whitaker
2020-11-16 00:44:38 CET
Source RPM:
drakconf-13.23-1.mga7 =>
drakxtools-18.21-1.mga7.src.rpm
Martin Whitaker
2020-11-19 21:16:41 CET
Assignee:
mageiatools =>
mageia 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 |