Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 608020 - RHEL6: system-config-kdump displays bogus
RHEL6: system-config-kdump displays bogus
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: system-config-kdump (Show other bugs)
6.0
All Linux
high Severity high
: rc
: ---
Assigned To: Roman Rakus
Han Pingtian
:
: 609151 (view as bug list)
Depends On: 622868
Blocks: 626787
  Show dependency treegraph
 
Reported: 2010-06-25 08:24 EDT by Issue Tracker
Modified: 2014-01-12 19:12 EST (History)
9 users (show)

See Also:
Fixed In Version: system-config-kdump-2.0.2.1-18.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 609487 626787 (view as bug list)
Environment:
Last Closed: 2010-11-10 16:41:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Issue Tracker 2010-06-25 08:24:04 EDT
Escalated to Bugzilla from IssueTracker
Comment 1 Issue Tracker 2010-06-25 08:24:06 EDT
Event posted on 06-16-2010 11:02am EDT by peter.pols@fujitsu-siemens.com

Description of problem:
The settings offered in the system-config-kdump dialog are bogus. system-config-kdump does not parse /etc/kdump.conf correctly. It does not offer a sensible selection for "Partition" ("file:///(None)" is the only available option).

How reproducible:
always

Steps to Reproduce:
start system-config-kdump

Actual results:
see attached screenshot

Expected results:
- reasonable selection for Partition: (e.g. all existing but not mounted partions, I don't know what this is intended to do)
- parse /etc/kdump.conf correctly
- restart kdump cleanly when "Apply" is clicked

Additional info:
1. system-config-kdump falsely warns the user that the system needs to be rebooted for the changes to take effect. This is only true if kdump was disabled before the tool was called (and no kdump memory reserved). 

2. When Apply is clicked, system-config-kdump runs mkdumprd and displays "Error handling kdump services", although "service kdump status" tells me "kdump is operational".

This event sent from IssueTracker by astokes  [Support Engineering Group]
 issue 1026073
Comment 2 Issue Tracker 2010-06-25 08:24:07 EDT
Event posted on 06-25-2010 03:22am EDT by akarlsso

Hi there Adam,

Taken a look at this to clarify it further, and the problem, as
described:

--
Attempt to configure kdump via the system-config-kdump UI.

1. UI Partition selection will only work if:
  1.1 partition or LV has stanza in /etc/fstab
  1.2 partition or LV is ext2 or ext3 type
  1.3 hand-configure kdump.conf and this is not the case
2. FS type ext4 is not a supported fstype by s-c-kdump *UI*
  2.1 except that the kdump.conf examples are all ext4
3. UI Path field behaves strange
  3.1 Path gets autocorrected based on what is in root fs, not target
partition
  3.2 The behaviour restricts the usefulness of the UI
4. Documentation is almost entirely absent from the package
--

I'd missed off being specific about the UI in point 2. Other than that,
this is the problem as shown/experienced by the customer and I've run
through the points myself, I see the same thing.

Thanks,

/Anders


Internal Status set to 'Waiting on SEG'

This event sent from IssueTracker by astokes  [Support Engineering Group]
 issue 1026073
Comment 3 RHEL Product and Program Management 2010-06-25 08:42:54 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 4 Roman Rakus 2010-06-28 04:42:40 EDT
(In reply to comment #2)
> Event posted on 06-25-2010 03:22am EDT by akarlsso
> 
> Hi there Adam,
> 
> Taken a look at this to clarify it further, and the problem, as
> described:
> 
> --
> Attempt to configure kdump via the system-config-kdump UI.
> 
> 1. UI Partition selection will only work if:
>   1.1 partition or LV has stanza in /etc/fstab
>   1.2 partition or LV is ext2 or ext3 type
>   1.3 hand-configure kdump.conf and this is not the case
Adding ext4 support to s-c-kdump is really easy.


> 2. FS type ext4 is not a supported fstype by s-c-kdump *UI*
>   2.1 except that the kdump.conf examples are all ext4
The same as 1)

> 3. UI Path field behaves strange
>   3.1 Path gets autocorrected based on what is in root fs, not target
> partition
Yep, autocorrection should be used only for "file:///" (not target) selection.

>   3.2 The behaviour restricts the usefulness of the UI
I agree.

> 4. Documentation is almost entirely absent from the package
Yep, I'm not good documentation writer.

> --
> 
> I'd missed off being specific about the UI in point 2. Other than that,
> this is the problem as shown/experienced by the customer and I've run
> through the points myself, I see the same thing.
> 
Hopefully adding ext4 support is enough.

> Thanks,
> 
> /Anders
> 
> 
> Internal Status set to 'Waiting on SEG'
> 
> This event sent from IssueTracker by astokes  [Support Engineering Group]
>  issue 1026073
Comment 5 Roman Rakus 2010-06-28 04:55:18 EDT
(In reply to comment #1)
> Event posted on 06-16-2010 11:02am EDT by peter.pols@fujitsu-siemens.com
> 
> Description of problem:
> The settings offered in the system-config-kdump dialog are bogus.
> system-config-kdump does not parse /etc/kdump.conf correctly. It does not offer
> a sensible selection for "Partition" ("file:///(None)" is the only available
> option).
As already mentioned, this is not due to bad parsing of /etc/kdump.conf. Partitions are get from /etc/fstab.

> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> start system-config-kdump
> 
> Actual results:
> see attached screenshot
> 
> Expected results:
> - reasonable selection for Partition: (e.g. all existing but not mounted
> partions, I don't know what this is intended to do)
all (ext2, ext3) from /etc/fstab are used. I will add ext4.

> - parse /etc/kdump.conf correctly
Can you please specify what is not correctly parsed?

> - restart kdump cleanly when "Apply" is clicked
Right, this should be enhanced.

> 
> Additional info:
> 1. system-config-kdump falsely warns the user that the system needs to be
> rebooted for the changes to take effect. This is only true if kdump was
> disabled before the tool was called (and no kdump memory reserved). 
I will look deeper into it.

> 
> 2. When Apply is clicked, system-config-kdump runs mkdumprd and displays "Error
> handling kdump services", although "service kdump status" tells me "kdump is
> operational".
s-c-kdump falsely identify the result of service handling. Should be fixed.

> 
> This event sent from IssueTracker by astokes  [Support Engineering Group]
>  issue 1026073    


This is a bit larger change of code and I'm not sure if the fixes will be ready for Snapshot 7.
Comment 6 Roman Rakus 2010-06-28 07:15:36 EDT
Can you please run /usr/share/system-config-kdump/system-config-kdump-backend.py as root, then run system-config-kdump as usual and paste here the output of backend run?
Comment 10 Roman Rakus 2010-06-29 10:38:16 EDT
*** Bug 609151 has been marked as a duplicate of this bug. ***
Comment 12 Roman Rakus 2010-06-30 08:26:22 EDT
In system-config-kdump-2.0.2.1-18.el6 are fixed following bugs:
- ext4 support
- Identification of the service handling (check the status, if not 0 show the error message and output)
- Show error massage when dbus call failed. It needs to be enhanced. I will clone this bug to track it.
Comment 14 Karel Volný 2010-08-10 11:50:54 EDT
I cannot get it working on PPC because of bug #622868 => back to ASSIGNED, hope
this fix can make it in time
Comment 15 Karel Volný 2010-08-10 11:55:58 EDT
please, could you either provide exact reproducer for the dbus problem or confirm that the new version works for you (that the patch from comment #8 got it into the build correctly)?
Comment 16 Karel Volný 2010-08-10 11:57:33 EDT
(In reply to comment #12)
> - Show error massage when dbus call failed. It needs to be enhanced. I will
> clone this bug to track it.    

bug #609487, just for the record
Comment 17 Gary Smith 2010-08-10 12:35:27 EDT
(In reply to comment #15)
> please, could you either provide exact reproducer for the dbus problem or
> confirm that the new version works for you (that the patch from comment #8 got
> it into the build correctly)?    

AFAIK, the patch in comment#8 is insufficient to resolve this issue because of the lack of asynchronous dbus calls, as explained by Roman in comment#9.

I'm therefore assuming that both fixes are present in system-config-kdump-2.0.2.1-18.el6 which should be available as of compose RHEL6.0-20100701.0?

I will therefore ask the Partner to re-test using snapshot7 (system-config-kdump-2.0.2.1-19.el6) onwards and report back.


Regards, Gary
Comment 18 Karel Volný 2010-08-11 06:27:22 EDT
(In reply to comment #17)
> AFAIK, the patch in comment#8 is insufficient to resolve this issue because of
> the lack of asynchronous dbus calls, as explained by Roman in comment#9.

ah sorry, I confused what the issue is - I was thinking about the text of the error message, not the cause itself

> I'm therefore assuming that both fixes are present in
> system-config-kdump-2.0.2.1-18.el6 which should be available as of compose
> RHEL6.0-20100701.0?

no, the asynchronous calls are to be implemented in 6.1 - the bug #609487
(Roman, please correct me if I got it wrong again ... I'm getting a bit weary, I need some real vacation ...)
Comment 19 Gary Smith 2010-08-11 06:34:29 EDT
(In reply to comment #18)
> > I'm therefore assuming that both fixes are present in
> > system-config-kdump-2.0.2.1-18.el6 which should be available as of compose
> > RHEL6.0-20100701.0?
> 
> no, the asynchronous calls are to be implemented in 6.1 - the bug #609487
> (Roman, please correct me if I got it wrong again ... I'm getting a bit weary,
> I need some real vacation ...)    

Ah, I need my eyes tested, I missed that.

So, would that suggest that the underlying fix is in 6.0 (this BZ) but it can't be tested because of the async dbus issue which will be fixed in 6.1 (#609487) ?

I'll await Roman's confirmation...
Comment 20 Anders 2010-08-11 07:21:37 EDT
Have tried the 20100806.n.0 nightly on an X60s here, and I can:
 * configure kdump with the GUI tool
 * it shows in the Partition selector ext4 filesystems/devices now
 * There's still some strangeness about how it calculates what's a correct directory to use
    Example: I picked '/var/crash' as the path, and then picked /dev/mapper/VolGroup-lv_home (ext4) as the Partition. It'll then create /home/var/crash to use. I can't pick '/vole' as the path though, as that does not exist in the root filesystem, and it will not be created in /home either.
 * There's no longer any errors reported around d-bus, the service restarts, settings are saved etc., all as expected.

 * Not tried raw devices yet, as I don't have one available right this minute.

/Anders
Comment 22 Roman Rakus 2010-08-11 08:47:34 EDT
(In reply to comment #19)
> (In reply to comment #18)
> > > I'm therefore assuming that both fixes are present in
> > > system-config-kdump-2.0.2.1-18.el6 which should be available as of compose
> > > RHEL6.0-20100701.0?
> > 
> > no, the asynchronous calls are to be implemented in 6.1 - the bug #609487
> > (Roman, please correct me if I got it wrong again ... I'm getting a bit weary,
> > I need some real vacation ...)    
> 
> Ah, I need my eyes tested, I missed that.
> 
> So, would that suggest that the underlying fix is in 6.0 (this BZ) but it can't
> be tested because of the async dbus issue which will be fixed in 6.1 (#609487)
> ?
> 
> I'll await Roman's confirmation...    

Now s-c-kdump uses synchronous calls, what may leads in timeouts. But when s-c-kdump catches that exception it does not show appropriate message. With the system-config-kdump-2.0.2.1-18.el6 (and later) it shows some cool message. But, I don't know how to reproduce it. I'm not hitting those timeouts.
And in 6.1 s-c-kdump will use async calls.
Comment 23 Roman Rakus 2010-08-11 08:50:41 EDT
(In reply to comment #20)
> Have tried the 20100806.n.0 nightly on an X60s here, and I can:
>  * configure kdump with the GUI tool
>  * it shows in the Partition selector ext4 filesystems/devices now
nice

>  * There's still some strangeness about how it calculates what's a correct
> directory to use
>     Example: I picked '/var/crash' as the path, and then picked
> /dev/mapper/VolGroup-lv_home (ext4) as the Partition. It'll then create
> /home/var/crash to use. I can't pick '/vole' as the path though, as that does
> not exist in the root filesystem, and it will not be created in /home either.
Yep, but this wasn't fixed. Can you please create a new bug against it?

>  * There's no longer any errors reported around d-bus, the service restarts,
> settings are saved etc., all as expected.
And if there will be any error, there will popup message window saying more about the failure.

> 
>  * Not tried raw devices yet, as I don't have one available right this minute.
> 
> /Anders
Comment 24 Roman Rakus 2010-08-11 09:48:55 EDT
Changing status back to modified. Please test what is fixed.
Comment 26 Karel Volný 2010-08-24 08:39:21 EDT
(In reply to comment #23)
> (In reply to comment #20)
> >  * There's still some strangeness about how it calculates what's a correct
> > directory to use
> >     Example: I picked '/var/crash' as the path, and then picked
> > /dev/mapper/VolGroup-lv_home (ext4) as the Partition. It'll then create
> > /home/var/crash to use. I can't pick '/vole' as the path though, as that does
> > not exist in the root filesystem, and it will not be created in /home either.
> Yep, but this wasn't fixed. Can you please create a new bug against it?

I've created bug #626787 to track the issue

(In reply to comment #24)
> Changing status back to modified. Please test what is fixed.

I can confirm the fixes also with the newere version, now it starts on ppc,
displays ext4 partitions etc. so moving to VERIFIED
Comment 27 releng-rhel@redhat.com 2010-11-10 16:41:59 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

Note You need to log in before you can comment on or make changes to this bug.