Bug 236280

Summary: s-c-kdump should detect xen kernel via /proc/xen
Product: Red Hat Enterprise Linux 5 Reporter: David Lehman <dlehman>
Component: system-config-kdumpAssignee: David Lehman <dlehman>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: dlehman, nhorman
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.0.12-1.el5 (RHEL5.1) Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-07 16:46:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Lehman 2007-04-12 20:15:15 UTC
+++ This bug was initially created as a clone of Bug #222056 +++

Description of problem:
Our current methodology for detecting whether or not we're running on a xen
kernel is a bit flawed, in 
that it relies solely on the kernel's uname -r output. Its possible someone
could be running a xen kernel 
without the substring 'xen' in its uname -r output (or vice versa), so checking
for the presence of /proc/
xen is much safer.

Version-Release number of selected component (if applicable):
kexec-tools-1.101-162.el5

-- Additional comment from jwilson on 2007-03-16 14:38 EST --
The change below does the trick. Of course, this is likely all moot, since we're
trying to enable kdump for dom0 kernels for 5.1...

Index: firstboot_kdump.py
===================================================================
RCS file: /cvs/dist/rpms/kexec-tools/RHEL-5/firstboot_kdump.py,v
retrieving revision 1.10
diff -u -r1.10 firstboot_kdump.py
--- firstboot_kdump.py  9 Jan 2007 20:27:19 -0000       1.10
+++ firstboot_kdump.py  16 Mar 2007 18:32:15 -0000
@@ -100,14 +100,8 @@
         self.arch = os.popen("/bin/uname -m").read().strip()
 
         # Check for a xen kernel, kdump doesn't work w/xen just yet...
-        self.xenKernel = self.runningKernel.find("xen")
-
-       # the find method above returns the index of the 
-       # found string, or -1 if not found.  I'm adding one here
-       # so that I can easily test for found/not found later on
-       # since adding one implies that 0 == not found, and
-       # !0 == found
-       self.xenKernel = self.xenKernel + 1
+        if os.access("/proc/xen", os.R_OK):
+            self.xenKernel = 1
 
         # Fedora or RHEL?
         releaseFile = '/etc/redhat-release'


-- Additional comment from pm-rhel on 2007-03-21 19:00 EST --
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

-- Additional comment from jwilson on 2007-04-12 15:31 EST --
Dave, I can't recall... Do we have a bug open to detect a xen kernel via
/proc/xen in system-config-kdump and/or is it already doing so?

-- Additional comment from dlehman on 2007-04-12 16:12 EST --
No we don't. We're using the uname output there also.

Comment 1 RHEL Program Management 2007-06-05 20:31:48 UTC
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release.  Since this
bugzilla is in a component that is not approved for the current
release, it has been closed with resolution deferred.  You may
reopen this bugzilla for consideration in the next release.

Comment 5 RHEL Program Management 2007-10-16 04:02:18 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.